Sohbet modelleri ve kodlama ajanları farklı araçlardır
Baştan ayırmakta fayda var, çünkü ikisi birbirine karıştırılıyor. Ajan tabanlı bir kodlama aracı editöründe veya terminalinde yaşar, deponu okur ve dosya yazar. Sohbet çalışma alanı ise düşündüğün yerdir: bir yığın izini yapıştırırsın, bir yaklaşım üzerine tartışırsın, bir diffi incelersin, hiç kullanmadığın bir kütüphaneyi anlarsın ve tasarım belgesini taslak haline getirirsin.
Çoğu geliştirici sonunda ikisini de kullanır ve model seçimi sohbet tarafında daha çok önem taşır, çünkü diff yerine akıl yürütmeyi okuyorsundur. Üç modeli karşılaştırmak için üç ayrı aboneliğe para vermenin anlamsızlaştığı yer de burasıdır.
| Ne yapıyorsun | Model eğilimi | Notlar |
|---|---|---|
| Zor akıl yürütme: eşzamanlılık, ince bir yarış durumu, mimari bir ödünleşim | Claude ve GPT belirgin şekilde farklılaşır | İkisine de sor. İkinci bir görüşün kendini fazlasıyla amorti ettiği durum budur |
| Sık karşılaşılan zeminde uygulama hızı | GPT | Hızlı, o dile uygun, kalıp kod ve dönüştürmede iyi |
| Büyük, tanıdık olmayan bir kod tabanını veya uzun bir şartnameyi okumak | Gemini | En geniş bağlam penceresi, sistemin daha fazlası aynı anda sığar |
| Bir hatayı veya kavramı açıklamak | Hangi çerçeveleme oturuyorsa | Farklı modeller farklı şekilde açıklar, mesele de bu |
| Katı yapılandırılmış çıktı: yapılandırma, JSON, şema | GPT | Bir formata tam olarak uymada en güvenilir |
Yığın izini yapıştırmaktan daha iyi hata ayıklama istemleri
Bir hatayı yapıştırıp neyin yanlış olduğunu sormak bir tahmin üretir. Tahmin çoğu zaman doğrudur, yanlış olduğunda ise sahip olmadığın bir sorun için makul görünen bir düzeltmenin peşinden koşarak yirmi dakika kaybedersin. Bu istemler yanıtın şeklini değiştirir.
İstem: düzeltmelerden önce hipotezler
Hatayı, kodu ve şimdiden elediklerimi veriyorum. Henüz bir düzeltme verme. En olası dört nedeni olasılığa göre sırala ve her biri için, onu doğrulayacak veya eleyecek en ucuz tek kontrolü belirt. Hata: [yapıştır]. Kod: [yapıştır]. Şimdiden elenenler: [liste].
İstem: sadece bazen ortaya çıkan hata
Bu hata aralıklı olarak, yaklaşık [sıklık] sıklıkta, [koşullar] altında başarısız oluyor. İlgili kodu ve ortam hakkında bildiklerimi veriyorum. Bu spesifik belirtiyi üretebilecek aralıklı başarısızlık kategorilerini sırala (zamanlama, sıralama, kaynak tükenmesi, dış bağımlılık, çalıştırmalar arası durum sızıntısı, saat veya saat dilimi, önbellekleme). Her biri için, verdiklerim içindeki hangi kanıtın onu desteklediğini veya çürüttüğünü ve onları ayırt etmek için neyi loglamam gerektiğini söyle.
İstem: uygulamadan önce düzeltmeyi açıkla
Bu düzeltmenin neden işe yaradığını, neyi düzeltmediğini ve neyi bozabileceğini açıkla. Eğer altta yatan neden başka bir yerdeyse ve bu bir belirti yaması ise, bunu açıkça söyle.
Bu son istem, yapay zeka yardımının en pahalı sınıfını yakalar: kod tabanında gerçek kusur kalırken belirtiyi ortadan kaldıran bir değişiklik.
Aynı sorunda iki model, ki bu bir gösteriş değil
Yanıt açıkken tek bir model yeterlidir. Bu teknik, emin olmadığın sorunlarda karşılığını verir ve işe yaramasının nedeni, modellerin aynı değil farklı şekillerde hata yapmasıdır.
Yararlı kalıp, ikisine de sorup beğendiğini seçmek değildir. Birine sorup, yanıtını diğerine vermektir:
İstem: bir yanıtın çekişmeli incelemesi
Başka bir mühendis bu soruna şu çözümü önerdi. Neyin yanlış olduğunu bul: uç durumlarda doğruluk, eşzamanlılık, hata yönetimi, [ölçek]'te performans veya gözden kaçan daha basit bir yaklaşım. Eğer gerçekten sağlamsa, itiraz uydurmak yerine bunu açıkça söyle. Sorun: [yapıştır]. Önerilen çözüm: [yapıştır].
İki sonuç da işe yarar. Ya ikinci model, birleştirmeden önce artık bildiğin gerçek bir açık bulur, ya da aynı fikirde olur ki bu, itiraz etmek için her türlü teşviki varken gelen gerçek bir kanıttır. Bunu aynı modelle yinelemekle karşılaştır, bu genelde kendi kendine hak verir.
Aynı kalıp tasarım kararlarına da uygulanır:
İstem: karşı tarafı savun
[Bağlam ve kısıtlar] için [A yaklaşımını] [B yaklaşımına] tercih ediyorum. B için en güçlü savunmayı yap. B'nin doğru seçim olması için kısıtlarımız hakkında neyin doğru olması gerekir ve bunlardan herhangi biri burada doğru mu?
Whizi'nin yan yana karşılaştırma özelliği tam olarak bunun için var ve modelleri yan yana karşılaştır sayfasında belgelenmiştir.
Kod incelemesi ve tanıdık olmayan kodu okumak
İstem: bir diffi talepkar bir inceleyici gibi incele
Bu diffi incele. Sırayla kategoriler: doğruluk hataları, güvenlik sorunları, ele alınmamış hata durumları, yarış durumları, ardından stil. Her bulgu için önem derecesini, spesifik satırı ve burada neden genel olarak değil de özellikle önemli olduğunu belirt. Biçimlendirme hakkında yorum yapma. Diff sorunsuzsa, bunu söyle. Bağlam: bu kod tabanı [yığın ve kurallar] kullanıyor. Diff: [yapıştır].
İstem: az önce devraldığın bir kod tabanını anla
İşte ana kaynak dosyaları. Şunları üret: giriş noktaları, istekten yanıta veri akışı, paylaşılan ve nerede değiştirilen durum, dış bağımlılıklar ve her biri kullanılamadığında ne olduğu, ve karmaşıklık ile bağımlılığa dayanarak hata içermesi en olası üç bölüm. Sana verdiklerimden neyi belirleyemediğini açıkça söyle.
Bu son talimat göründüğünden daha önemlidir. Modeller, yapıştırmadığın bir dosyanın davranışını, adından çıkarım yaparak seve seve tarif eder. Açık bir bilinmeyenler listesi zorunlu kılmak, neyi okumaya gitmen gerektiğini söyler.
İstem: aklına gelmeyecek testi yaz
Bu fonksiyon için, muhtemelen düşünmediğim girdilere odaklanarak test durumları yaz: sınırlar, boş ve null, unicode, çok büyük değerler, eşzamanlı çağrılar ve uygulamadaki her örtük varsayım. Her test için, kontrol ettiği varsayımı belirt. Fonksiyon: [yapıştır].
Gerçekten zaman kaybettiren hata biçimleri
Uydurma API'ler. Modeller, özellikle yakın zamanda değişmiş veya daha az yaygın kütüphaneler için, var olmayan metot adlarını, parametreleri ve yapılandırma anahtarlarını kendinden emin bir şekilde üretir. İmza doğru görünecektir. Tanıdık olmayan herhangi bir şeyin üzerine inşa etmeden önce gerçek belgelendirmeyi kontrol et.
Kendinden emin yanlış düzeltmeler. Tonda hiçbir sinyal yoktur. Sorununu eriten bir düzeltme ile ince, yeni bir sorun ekleyen bir düzeltme aynı özgüvenle sunulur. Değişikliğin neyi bozabileceğini her zaman sor.
Eski kalıplar. Eğitim verisi, bir çerçeve hakkında yazılan kod hacmine doğru kayar, bu da genelde bir önceki büyük sürümdür. Yanıt birkaç yıl öncesinden geliyormuş gibi hissettiriyorsa, muhtemelen öyledir. İstem içinde hangi sürümde olduğunu söyle.
Sessiz kapsam genişlemesi. Bir düzeltme istersin ve genelde bir yeniden yapılandırma alırsın. Diffi incelenebilir tutmak için mümkün olduğunca az değişiklik yap ve değiştirdiğin her satırı ve nedenini listele ekle.
Güvenlik tiyatrosu. Bir model, kodundaki zafiyet sınıflarını adlandırabilir, bu ilk geçiş için gerçekten faydalıdır ama bir denetim değildir. Tehdit modelini, dağıtımını veya veri hassasiyetini bilmez.
Bu, araç setinin geri kalanıyla nereye oturuyor
Editör entegrasyonunun veya ajan tabanlı kodlama aracının yerini almaz. Aynı anda açık tutmak için gereken iki aboneliğe ek olarak, yanıtları karşılaştırdığın üç tarayıcı sekmesinin yerini alır.
Çoğu geliştiricinin ulaştığı pratik kurulum: hızlı sorular için bir varsayılan model, ilk yanıt ikna edici olmadığında geçtiğin ikinci bir model, ve önünde büyük miktarda kod veya uzun bir şartname olduğunda Gemini. Hepsi tek bir konuşmada, böylece zaten oluşturduğun bağlam yeniden yapıştırılmak yerine geçiş boyunca taşınır.
Daha derinlemesine kapsam için kodlama için yapay zeka, kodlamaya odaklı alternatifler karşılaştırması ve Claude kodlama istem paketi sayfalarına bak. Bu kurulumu Whizi içinde çalıştırmanın mekaniği birden fazla modelle kod yaz ve hata ayıkla sayfasında.
- Bir düzeltme istemeden önce sıralanmış hipotezler ve ucuz kontroller iste
- İlk modelin yanıtını ikinci bir modele ver ve açığı bulmasını iste
- Önerilen bir düzeltmenin neyi bozabileceğini ve bir belirti yaması olup olmadığını her zaman sor
- Eski kalıplardan kaçınmak için dilini, çerçeveni ve sürümünü istemde belirt
- Tanıdık olmayan herhangi bir API'yi üzerine inşa etmeden önce gerçek belgelendirmeye karşı doğrula
- Diffleri incelenebilir tutmak için "mümkün olduğunca az değişiklik yap ve her değişikliği listele" ekle
- Sorunun normal bir istemde sığdığından daha fazla kod kapsadığı durumlarda geniş bağlamlı modeli kullan
Sık sorulan sorular
Neden tek bir kodlama modeliyle kalmayayım?
Rutin işler için tek bir model yeterlidir. Değer, gerçekten emin olmadığın sorunlarda ortaya çıkar, çünkü modeller aynı yerde değil farklı yerlerde hata yapar. A modelinin önerdiği çözümü B modeline verip kusuru bulmasını istemek, ya birleştirmeden önce gerçek bir sorunu gün yüzüne çıkarır ya da anlamlı bir doğrulama sağlar. Tek bir modelle yinelemek çoğunlukla kendi kendine hak vermekle sonuçlanır.
Bu, ajan tabanlı bir kodlama aracının yerine mi geçiyor?
Hayır, farklı sorunları çözerler. Bir ajan kod deponda yaşar ve dosyaları düzenler. Bir sohbet çalışma alanı akıl yürüttüğün yerdir: yığın izleri, tasarım tartışmaları, diff incelemesi, tanıdık olmayan bir kütüphaneyi anlamak ve tasarım belgesini taslak haline getirmek. Çoğu geliştirici ikisini de kullanır ve model seçimi sohbet tarafında daha çok önem taşır, çünkü sonuçtaki diff yerine akıl yürütmeyi değerlendiriyorsundur.
Kodlama için hangi model en iyisidir?
Bu göreve bağlıdır, ki dürüst yanıt ve bu sayfanın var olma nedeni budur. GPT, sık karşılaşılan uygulama işlerinde genellikle daha hızlı ve o dile daha uygun olma eğilimindedir. Claude, ince akıl yürütmede, tanıdık olmayan mimarilerde ve bir şeyin neden o şekilde davrandığını açıklamada genellikle daha güçlüdür. Gemini, soru büyük miktarda kod veya şartnameyi aynı anda tutmayı gerektirdiğinde kazanır. Onları kendi gerçek sorunlarında bir hafta boyunca karşılaştırmak herhangi bir kıyaslamadan daha iyidir.
Özel (proprietary) kod yapıştırabilir miyim?
Whizi konuşmalarında eğitim yapmaz ve her sağlayıcının veri politikası, o modeli etkinleştirmeden önce incelemen için mevcuttur. İşvereninin politikası genellikle bağlayıcı kısıtlamadır ve büyük ölçüde değişir, bu yüzden kontrol et. Kısıtlamaların geçerli olduğu durumlarda, pratik bir yaklaşım, sorunu yapıyı içeren ama iş mantığını içermeyen minimal bir örnekte yeniden üretmektir, ki bu genelde zaten daha iyi bir yanıt verir.
Her şeyi yeniden yazmasını nasıl durdururum?
Açıkça talimat ver: mümkün olduğunca az değişiklik yap, mevcut yapıyı ve adlandırmayı koru, ve değiştirdiğin her satırı tek satırlık bir nedenle listele. İstenmeyen yeniden yapılandırmalar, yapay zeka önerilerinin incelenemez hale gelmesinin başlıca nedenidir ve diffi kısıtlamak, akıl yürütebileceğin bir değişiklik ile baştan okumak zorunda kaldığın bir değişiklik arasındaki farkı yaratır.