Bu sahneyi ilk görüşte tanımakta fayda var, o yüzden ondan başlayalım. Bir oyunu yazmayı bitirdiniz, yeniden başlatınca puan sıfırlanıyor ve ajana soruyorsunuz:
Yeniden başlatınca puan neden kayboluyor?Cevap sakin ve derli toplu geliyor:
Puan projede zaten kaydediliyor, sadece kayıt hiçbir yerde açılmamış.
Tek bir ayarı değiştirmeniz yeterli, sonuç yeniden başlatmadan sonra da korunur.Kontrol etmeye gidiyorsunuz. Projede ne böyle bir ayar var ne de puanı kaydeden bir kod, hiç de olmamış - tek bir satır bile, en ufak bir iz bile yok. Cevap kodunuzun incelemesi gibi okunuyordu, ama aslında bu tür projelerin genellikle nasıl kurulduğuna dair bir varsayımdı.
Üstelik öncesinde ne bir duraksama oldu ne de bir çekince. Ton, doğru çıkan önceki bütün cevaplarla tıpatıp aynı. Araç da bozuk değil, model de dünkünden daha kötü hale gelmedi.
Sebep, cevabın nasıl ortaya çıktığında. Model hazır bir bilgiyi bir depodan çekip getirmez - metninizin olası devamını parça parça seçer. Olası ile doğru ise farklı şeylerdir, özellikle de söz konusu olan, modelin hiç görmediği projeniz olduğunda. Uydurulmuş ama inandırıcı ayrıntılara genellikle halüsinasyon denir.
Devamında: tuzakların nerede kurulu olduğu, hatanın neden hep sakin bir tonla geldiği ve bu tür durumların çoğunu hangi üç kontrolün kapattığı.
Model isteğinizde neyi görüyor
Buradaki tuzak hepsinin en basiti: model projenize bakıyormuş gibi gelir. Oysa model yalnızca kendisine verilene bakar, ona verilenler de şunlardır:
- Yerleşik bilgi. Eğitim sırasında modelin parametrelerine yerleşmiş örüntüler. Bunlar kaynak gösterilmiş bilgi kartları değil, sayılardır, bu yüzden model bildiği bir bilgiyi bile yanlış aktarabilir. Üstelik bu bilginin bir zaman sınırı var: daha sonra çıkmış bir kütüphane hakkında model, ona tam olarak ne gösterildiyse o kadarını bilir.
- Mevcut konuşma. İsteğiniz, yazışma geçmişi, ajanın okuduğu dosyalar, çalıştırdığı komutların çıktısı.
- Uygulamanın hafızası. Ayrı dosyalara kaydedilen ve bir sonraki oturumun başında konuşmaya eklenen şeyler. Claude Code'da bunlar, sizin yazdığınız
CLAUDE.mdve ajanın notlarını kendisinin kaydettiği auto memory. - Dış kaynaklar. Dokümantasyon, arama, veritabanı, proje dosyaları - eğitim verilerinde olmayabilecek ya da o zamandan beri değişmiş her şey.
Son üçü aynı yoldan gelir: cevabı etkileyebilmeleri için mevcut konuşmanın içine girmeleri gerekir. Model kendi başına projeye göz atmaz.
Buradan, kafanızda bir kez oturtmaya değer bir sonuç çıkar. Kimsenin açmadığı bir dosya model için yoktur. Dosyanın metni konuşmaya girmediği sürece "bizde yetkilendirme nerede işleniyor" sorusunu "benzer projelerde böyle bir dosyaya genellikle ne ad verilir" diye okumak daha dürüst olur. Cevabı iki durumda da alırsınız ve ikisi de aynı görünür.
Hemen yanında daha küçük ama can sıkıcı bir tuzak daha var. Okunmuş bir dosya konuşmada okunduğu haliyle kalır. Siz editörde bir satırı düzelttiniz, konuşma geçmişinde ise eski sürüm duruyor. Claude Code dosyanın değiştiğini belirtir, ama ajanın onu yeniden okuyup okumayacağına artık model karar verir. Konuşmanın ortasında elle bir şey değiştirdiyseniz, dosyayı yeniden okumasını açıkça istemek daha güvenlidir.
Claude Code önce projeyi okur ve komutları çalıştırır, cevabı sonra verir. Cevapta genellikle hangi dosyaları açtığı ve neyi çalıştırdığı görünür. Kodunuzla ilgili cevap, ajan daha hiçbir şey okumadan ortaya çıktıysa, karşınızdaki şey sizin projenizin incelemesi değil, tipik bir projeye dair bir varsayımdır.
İfade neden sonucu değiştirir
Konuşmaya giren her şeyin içinde kendi elinizle yazdığınız tek şey isteğinizdir. Bu yüzden içindeki ayrıntılar belirleyici olur: birkaç kelimenin yerini değiştirdiniz, bir açıklama eklediniz - cevap başka bir yöne kaydı. Bu, aracın bir kaprisi değil.
Burada kafa karışması kolay, o yüzden ayrıca üzerinde durayım. Aynı istek iki kez gönderildiğinde de farklı cevaplar verir: cevaba her zaman en olası devam seçilmez, üretimin, daha az olası bir seçeneğin ne kadar kolay seçileceğini belirleyen ayarları vardır. Akla şu soru gelir: cevap zaten oynayıp duruyorsa, benim kelimelerimin bununla ne ilgisi var? Fark, tam olarak neyin oynadığında. Aynı istekler arasındaki dağılım, aynı seçimin etrafındaki gürültüdür: ifadeler farklı olur, yön aynı kalır. İsteğinizdeki kelimeler ise yönün kendisini değiştirir, hem de her seferinde aynı şekilde.
En kötü sonucu belirsiz bir istek verir. Seçimi modele bırakır, model de genel olarak en olası olanı seçer - gördüğü her şeyin ortalamasını. Basit bir "metni kısalt" isteğini ele alın. Ne kadar - yüzde bir mi, üçte bir mi, yarı yarıya mı? Neyi atmak serbest, neye dokunulmamalı? İstekte bu soruların hiçbirinin cevabı yok, demek ki cevabı model verecek ve biçimsel olarak haklı da çıkacak. "Açıklamayı %30 kısalt" ya da "açıklamayı 300 karaktere kadar kısalt" ise seçimin size ait olduğu yerde ona seçim bırakmaz.
Bu, aynı konudaki iki istekte açıkça görülür. "Sıralamayı düzelt" her şeyi açık bırakır: hangi liste, hangi alan, neyin bozukluk sayılacağı. İkinci ifade ise neredeyse hiçbir şeyi açık bırakmaz:
Sipariş listesinde tarihler eskiden yeniye sıralanıyor, tersi olmalı.
Önce sıralama düzeninin tanımlandığı dosyayı ve satırı göster, sonra düzeltme öner.İkincisi, birincisinde ne kadar tahmin gerekiyorsa tam o kadar uzun. Üstelik kontrolün yarısını sizin yerinize yapar: ajan, siz daha sormadan koddaki yeri önünüze getirir.
Sonuç basit: istekte ne kadar az serbestlik varsa cevapta o kadar az tahmin olur. Mesele sihirli sözler değil, sıradan bir şey - çerçeveyi ya siz çizersiniz ya da sizin yerinize seçilir.
Emin bir ton, gerçek demek değildir
İşte asıl tuzak. Modelin "bunu kesin biliyorum" için ayrı, "bunu şimdi kafadan tamamladım" için ayrı bir tonu yok: iki cümle de aynı şekilde üretilir ve aynı sakinlikte çıkar. Aralarında bir bağ yok değil, ama işe yaramaz: modelin eminliği her zaman olduğundan yüksektir, bu yüzden tona bakarak doğrulanmış olanı tamamlanmış olandan ayıramazsınız.
Sıradan bir metinde tuhaf bir iddia göze batar ve kendiliğinden yavaşlarsınız. Kodda bu savunma işe yaramaz: isimler doğru görünür, yapılar tanıdıktır, kütüphaneyi ezbere bilmiyorsanız gerçek bir kütüphane metodunu benzetme yoluyla uydurulmuş olandan gözle ayırt edemezsiniz. Bu yüzden hata çoğu zaman okurken değil, çalıştırınca ortaya çıkar.
Üstelik isim nadiren sıfırdan uydurulur. Üretilmiş kodda var olmayan kütüphanelere yapılan atıfların arandığı bir incelemede, bu tür isimlerin üçte birinden fazlasının iki gerçek ismin birleşimi olduğu ortaya çıktı. Güvenilirlik hissi de buradan gelir: ismin parçalarını bir yerde görmüşsünüzdür, sadece bu birleşimde değil.
Neye bakacağınızı biliyorsanız ilk seferde tanıyacağınız dört durum:
| Nasıl görünür | Ne oldu | Nasıl yakalanır |
|---|---|---|
| komutun sahip olmadığı bir bayraktan söz ediliyor | model satırı alışıldık kalıba göre kurdu, bayrak da bu yüzden gerçek görünüyor | komutun yardım çıktısı ya da dokümantasyonu |
| projede olmayan bir dosya, fonksiyon ya da yapılandırma alanından söz ediliyor | isim bu tür bir proje için tipik görünüyor, ama projeyi kimse okumadı | projede arama, satırı göstermesini istemek |
| projenizin nasıl kurulduğu kendinden emin bir şekilde anlatılıyor | konuşmada projeden tek bir dosya yoktu, bu yüzden tipik bir proje anlatıldı | cevap vermeden önce hangi dosyaları açtığını sormak |
| "hazır" deniyor, ama komut hiç çalıştırılmadı | rapor, çalıştırmanın sonucundan değil, görevin metninden üretildi | kendiniz çalıştırıp çıktıya bakmak |
Dördünün de ortak noktası aynı: cevap bir işin sonucu gibi duruyor, oysa arkasında hiçbir iş yok.
Son durumu ayrıca ele almak gerekiyor, çünkü bir aldatmaca gibi görünüyor ama ortada aldatmaca yok. Ajan, iş bitmiş gibi göründüğünde durur. Çalıştıracak bir şeyi yoksa elindeki tek sinyal "bitmiş gibi görünüyor" olur, kontrol eden halka da siz olursunuz.
Bunun bedeli ölçülebilir. Ajan kayıtlarının incelendiği bir çalışmada, sahte "hazır"lar bütün başarısızlıkların neredeyse yarısını oluşturdu. Durumun ajanın kendi raporundan bağımsız olarak kontrol edildiği yerlerde ise bu tür vakalar neredeyse ortadan kalktı. Bir sonraki bölümdeki ikinci kontrolün anlamı da bu: raporun yerine kendi gözünüzle bakabileceğiniz bir şey koyar.
Geriye şu soru kalıyor: model neden "bilmiyorum" demek yerine cevabı kafadan tamamlamayı tercih ediyor? Mesele onun nasıl eğitildiğinde ve nasıl değerlendirildiğinde. Çoktan seçmeli bir test düşünün: boş bırakılan cevap kesin sıfır, rastgele işaretlenen ise puan alma şansı demek. Böyle bir sistemde susmak hiçbir zaman kârlı değildir, en ufak şüphede bile cevap vermek mantıklıdır. İnsan sonradan gerçek işlerde bu alışkanlığı bırakır, çünkü orada yanlış bir cevap dürüst bir "bilmiyorum"dan daha pahalıya patlar. Modelde böyle bir yeniden öğrenme yok.
Modelden emin olmadığında bunu dürüstçe söylemesini istemek işe yarar - ama bu da aynı mekanizmayla üretilmiş bir metindir. Ek bir sinyal olarak kullanılabilir, kontrolün yerini tutmaz.
Araçlar kör noktaları azaltır
Burada, konuşurken genellikle birbirine karıştırılan iki kelimeyi ayırmakta fayda var. Model tek bir şey yapabilir: konuşmayı alır ve devamını üretir. Ajan ise modelin etrafındaki programdır ve araçları vardır: dosya okumak, komut çalıştırmak, projede değişiklik yapmak.
Şimdi de hatanın tam olarak nerede çıkabileceğini belirleyen bir ayrıntı. Araçları program seçmez. Model cevabında şu dosyanın açılmasını ya da şu komutun çalıştırılmasını ister, program da bu isteği kontrol eder, yerine getirir ve sonucu konuşmaya geri verir. Kararı model verir, işi program yapar. Demek ki kararın kendisi de yanlış olabilir: yanlış dosya, yanlış komut, yanlış test.
Yine de fark çok büyük. Dosya açılmadığı sürece onunla ilgili cevap, benzer projelerin hatırasına dayanarak kurulur. Dosya okunup test çalıştırıldığı anda konuşmada bir olgu belirir: işte içerik, işte çıktı. Bu artık bir hatıra değil, bir kontroldür ve sonrasında gelen cevapların kalitesi gözle görülür biçimde farklıdır.
Buradan, konuşmanın başına tek satır yazmakla uygulanan bir yöntem çıkar:
Önce bunun projede nerede olduğunu bul ve göster, ancak ondan sonra açıkla.Kör noktalar böylece daralır ama yok olmaz. Ajan gereken dosya yerine yanındakini açabilir, komutun çıktısını kendince yorumlayabilir ya da asıl nedene varmadan ilk makul açıklamada durabilir. Bunların hepsini gördüm, hem de birden fazla kez. Bu yüzden dışarıdan gelen bir sinyal - test çıktısı, dokümantasyon metni, dosyanın içeriği - dayanağı olmayan en kendinden emin akıl yürütmeden daha ağır basar.
Bir dakikaya değen üç kontrol
İyi haber şu: bu tür hataları yakalamak neredeyse hiç çaba gerektirmez. Her şey tek bir yol ayrımına iner.
Burada bakılması gereken şey, cevabın ne kadar ikna edici yazıldığı değil, cevapta tutunacak bir şey olup olmadığıdır: belirli bir dosya, belirli bir satır, çıktısıyla birlikte bir komut. Dayanak yoksa karşınızdaki şey şimdilik bir sonuç değil, bir hipotezdir. Pek çok cevap böyle başlar, asıl soru bundan sonra ne yapacağınız.
Sırada üç kontrol var. Her biri bir dakikadan kısa sürer ve üçüne birden nadiren ihtiyaç duyulur.
- Yeri göstermesini isteyin. "Daha ayrıntılı anlat" değil, "dosyayı, satırı ve o parçanın kendisini göster". Böyle bir yer yoksa bu hemen anlaşılır.
- Sonucu kendiniz açın ya da çalıştırın. Tarayıcıda sayfayı, terminalde komutu, projede testi. İşin raporu ile işin kendisi aynı şey değildir.
- Bir araçla ilgili iddiayı aracın kendisiyle karşılaştırın. Komutun yerleşik bir yardım çıktısı, kütüphanenin dokümantasyonu vardır. Adı geçen bayrak ya da yapılandırma anahtarı orada ya vardır ya yoktur ve bu yarım dakikada anlaşılır. Kütüphane metodunda daha dikkatli olmak gerekir: dokümantasyona her şey girmez, bu yüzden orada bulunmaması kesin bir hüküm değil, yeniden sormak için bir sebeptir.
Cevapla tartışmak yerine dayanağı doğrudan isteyin:
Bunun anlatıldığı dosyayı ve satırı göster.
Projede böyle bir yer yoksa, bunun bir varsayım olduğunu açıkça söyle.Elinizin altında tutmaya değer iki satır. Birincisi ajanı, benzer projelerin hatırasına dayanarak cevap vermek yerine projeye yollar. İkincisi ona bir çıkış yolu bırakır: böyle bir yer olmadığını söylemek, cevabı inandırıcı görünene kadar tamamlamaktan daha ucuza gelir.
"Hazır" raporu için de aynı istek işe yarar, sadece bu kez çalıştırmayla ilgili: "çalıştırdığın komutu ve çıktısının tamamını göster".
Bu bir garantiye dönüşmez: "bu bir varsayım" cümlesi de geri kalan her şeyle aynı mekanizmayla üretilir. Iskalama olasılığını azaltır, kontrolün yerini tutmaz.
Bir de hemen şu çekinceyi ekleyelim ki yanlış bir izlenim kalmasın. Kontrol etmek, araca güvenmemek demek değildir. Kendi diff'inizi de commit'ten önce yeniden okursunuz, üstelik onu kendiniz yazmış olsanız bile. Burada da durum aynı, sadece sebep biraz daha ağır.
Bu, Claude Code ile çalışırken ne anlama gelir
Bütün bunlardan klavyenin başında doğrudan çıkanlar:
- dosyaya, satıra ya da komut çıktısına atıf yapan bir cevap saniyeler içinde kontrol edilir. Bunlar olmayan bir cevabı kontrol edecek bir şey yoktur: geriye yalnızca onu yeniden okuyup kabul etmek kalır;
- soruyu sormadan önce ajanın gerekeni okumasını sağlayın. Tek bir fazladan adım, koca bir hata sınıfını ortadan kaldırır;
- eminliğe bakarak karar veremezsiniz: kelimelerin arkasında bir kontrol de olsa bir tahmin de olsa eminlik hep olduğundan yüksektir;
- "doğru gibi duruyor" ile "doğru çalışıyor" farklı şeylerdir ve onları yalnızca çalıştırmak birbirinden ayırır;
- hatanın bedeli ne kadar yüksekse konuşmada dışarıdan bir şeyin - test, dokümantasyon, gerçek dosya - o kadar erken yer alması gerekir. Küçük bir düzeltmede diff'e bir göz atmak yeter;
- ajan hata yaptıysa bunu ona bir değerlendirme olarak değil, bir olgu olarak söyleyin. "Projede böyle bir fonksiyon yok, klasörde şunlar var" işi ilerletir, "yine her şeyi uydurdun" ise hiçbir yere götürmez. Şunu da aklınızda tutun: kendinden emin bir itiraz karşısında ajan tartışmaktan çok size uymaya meyillidir, haklı olan o olsa bile. Ajanın size hak vermesi, haklı olduğunuzu kanıtlamaz.
Bazen kendinden emin bir şekilde ıskalayan bu mekanizma yine de son derece faydalı olmaya devam eder. Sınırlarını bilmenin tek amacı, şaşırmaya zaman harcamadan doğrudan kontrole geçmektir.
GO TO FULL VERSION