AI ajanının yazdığı kodu review ederken en büyük risk, review işini de aynı ajana yaptırmaktır: aynı bağlam penceresi, aynı varsayımlar, aynı kör noktalar geri döner. AI kodunu doğrulama disiplini tam olarak burada devreye giriyor — yazan ile doğrulayanı ayrı tutan, taze bağlamlı ve kanıta dayalı bir süreç. Bu yazıda bu ayrımı neden kurman gerektiğini, pratikte nasıl kuracağını ve bir testin "yeşil" görünmesinin neden tek başına yeterli kanıt olmadığını anlatıyorum.
💡 Pro Tip: Bir ajanın "bitti" demesi bir kanıt değil, bir iddiadır — iddiayı kanıtla doğrulamak senin işin, ajanın değil.
İçindekiler
- Neden Ajan Kendi İşini Doğrulayamaz
- Taze Bağlam Kuralı: Doğrulayan Ajan İşi Baştan Görsün
- Üç Mercek Deseni: Mimar, Riskçi, Pragmatik
- Adversarial Verify: "Çürütmeye Çalış" Promptu
- Üç merceği bir örnekle uygulamak
- Kanıt Hiyerarşisi: Beyan < Test Çıktısı < Canlı Kanıt
- Testin Neyi Kanıtladığını Sormak
- Kanıt hiyerarşisini pratikte kullanmak
- Hız Yanılsaması: Algılanan Hızlanma ile Ölçülen Süre
- Küçük Diff'te Kısayol Serbest
- SSS
- AI'ın yazdığı kodu nasıl doğru şekilde doğrularım?
- Aynı ajan kendi kodunu review edebilir mi?
- Hangi işlerde adversarial (çürütmeye çalışan) review gerekir?
- "Testler geçti" neden tek başına kanıt değil?
- Doğrulama her zaman ayrı bir ajan mı gerektirir?
- Kanıt hiyerarşisinde en üstte ne var?
- Güncelleme (Eylül 2026)
- Sonuç
- Kaynaklar
Neden Ajan Kendi İşini Doğrulayamaz
Bir ajan bir görevi tamamladığında, elinde görevi tamamlarken oluşturduğu tüm varsayımlar hâlâ duruyor: hangi dosyanın "ilgili" olduğuna, hangi edge case'in "önemsiz" olduğuna, hangi kısayolun "makul" olduğuna dair kararlar. Aynı ajana "şimdi bunu kontrol et" dediğinde, o ajan bu kararları yeniden sorgulamaz — çünkü onları zaten doğru kabul ederek üretmişti. Kontrol, üretimin bir uzantısı hâline gelir, bağımsız bir bakış açısı değil.
Bu, insan code review'inde de bilinen bir sorundur: bir geliştiricinin kendi kodunu birkaç dakika sonra tekrar okuması, başka birinin okumasıyla aynı etkiyi yaratmaz. Fark, AI ajanlarında daha da belirgin: ajan yorulmaz, sıkılmaz, ama aynı zamanda "acaba yanlış mı yaptım" diye kendiliğinden şüpheye de düşmez. Elindeki tek sinyal, görevin "bitmiş görünmesi"dir — ve bu sinyal, görevi yapan ile görevi değerlendiren aynı zihinsel süreçten geçtiği sürece, kendi kendini doğrulayan (ve dolayısıyla güvenilmez) bir döngü kurar.
Bu döngünün en tehlikeli tarafı, hatanın büyüklüğüyle orantılı olmamasıdır. Küçük bir mantık hatası genelde bir sonraki adımda fark edilir; ama bir varsayım hatası — mesela "bu alan asla boş gelmez" gibi yanlış bir kabul — kod boyunca sessizce yayılır ve her adımda "tutarlı" göründüğü için hiçbir noktada alarm vermez. Aynı ajan, kendi kurduğu bu tutarlılığı bir doğruluk kanıtı sanma riskiyle karşı karşıyadır; oysa tutarlılık yalnız "kendi içinde çelişmiyor" demektir, "gerçek gereksinimi karşılıyor" demek değildir. Doğrulayanın işi tam olarak bu ikisini birbirinden ayırmaktır.
Pratikte bunun anlamı şu: bir ajana "şu özelliği yaz" dedikten sonra, aynı konuşmanın devamında "şimdi kontrol et" demek, doğrulamayı değil, üretimin ikinci bir turunu almaktır. Gerçek doğrulama, bağlamın kendisini değiştirmeyi gerektirir.
Taze Bağlam Kuralı: Doğrulayan Ajan İşi Baştan Görsün
Doğrulamanın işe yaraması için doğrulayan tarafın, üreten tarafın notlarını, gerekçelerini ve "neden bu şekilde yaptım" açıklamalarını görmemesi gerekir. Bunun yerine yalnız somut ürünü görmelidir: diff'in kendisi, testin kendisi, çalışan uygulamanın kendisi. Ben bunu pratikte ayrı bir oturum açarak yapıyorum — doğrulayan ajana yalnız değişikliğin yolunu ve "bunu sıfırdan, yazan kişinin gerekçelerini okumadan incele" talimatını veriyorum.
bash
1# Doğrulama için yeni oturum aç (claude varsayılan olarak yeni oturum başlatır; -c/--resume KULLANMA)2claude -p "Bu diff'i sıfırdan incele: git diff main..feature-branch. \3 Commit mesajlarını veya yazan tarafın notlarını okuma; \4 yalnız kodu, testi ve çalıştırdığın komutların çıktısını temel al."Bu ayrım küçük bir formalite değil — bilişsel bir sıfırlamadır. Taze bağlamda başlayan bir doğrulama, "bu satır neden böyle yazıldı" sorusuna orijinal ajanın gerekçesiyle değil, kodun kendi mantığıyla cevap aramak zorunda kalır. Eksik bir edge case, tutarsız bir varsayım ya da yanlış yorumlanmış bir gereksinim, ancak bu şekilde ortaya çıkar.
Üç Mercek Deseni: Mimar, Riskçi, Pragmatik
Kritik bir değişikliği tek bir doğrulama turuyla geçmesine izin vermiyorum; bunun yerine üç farklı soruyla üç kez bakıyorum. Bu bende zamanla oturmuş kişisel bir çalışma düzeni — resmi bir standart değil, ama her seferinde farklı bir hata sınıfını yakalıyor.
Mercek | Odaklandığı Soru | Ne Zaman Gerekli |
|---|---|---|
Mimar | Bu çözüm sistemin geri kalanıyla tutarlı mı, doğru soyutlama seviyesinde mi? | Yeni bir modül, şema değişikliği, API sözleşmesi |
Riskçi | Bu nerede kırılır? Hangi girdi, hangi eşzamanlılık, hangi hata bunu çökertir? | Auth, ödeme, veri bütünlüğü, dış servis entegrasyonu |
Pragmatik | Bu iş gerçekten bitti mi, yoksa "neredeyse bitti" mi? Kanıt yeterli mi? | Her PR, kapanış öncesi son kontrol |
Üç merceği her değişiklikte kullanmıyorum — bu, gereksiz yere maliyetli olur. Mimari mercek yalnız yapısal bir karar söz konusu olduğunda, riskçi mercek yalnız blast radius (etkilenen kullanıcı/veri kapsamı) geniş olduğunda devreye giriyor. Pragmatik mercek ise neredeyse her zaman gerekli, çünkü "bitti" iddiasını kanıtla eşleştiren tek adım o.
Üç merceği ayrı ayrı çalıştırmamın nedeni, aynı ajana "hem mimariye hem riske hem de bitip bitmediğine bak" dediğimde genelde en kolay sorulan soruya (pragmatik) odaklanıp diğer ikisini yüzeysel geçtiğini fark etmiş olmam. Her mercek ayrı bir tur, ayrı bir talimat ve mümkünse ayrı bir bağlam aldığında, her biri kendi sorusuna gerçekten cevap arıyor — birbirini gölgelemiyor.
Adversarial Verify: "Çürütmeye Çalış" Promptu
Doğrulayan ajana verdiğin talimatın çerçevesi sonucu doğrudan etkiliyor. "Bu doğru mu?" diye sorarsan, ajan onaylama eğiliminde olur — çünkü soru zaten bir onay bekliyormuş gibi kurulmuştur. Bunun yerine ajana açıkça "bunu çürütmeye çalış" görevini ver: amacı "evet, doğru" demek değil, "bu neden yanlış olabilir" listesini olabildiğince uzatmak.
text
1Rolün: bu değişikliği ÇÜRÜTMEYE çalışan bağımsız bir gözden geçirensin.2Diff'i yazan tarafın notlarını veya commit mesajını okuma;3yalnız kodu, testi ve çalıştırdığın komutların çıktısını temel al.4Amacın "doğru" demek değil, "neden yanlış olabilir" listesi çıkarmak.5Her bulguyu somut bir girdi/durumla göster, varsayımla değil.Bu çerçeve küçük ama etkili bir fark yaratıyor: ajan artık "makul görünüyor" eşiğini geçmeye çalışmıyor, aksine kırılma noktası aramaya odaklanıyor. Kritik değişikliklerde bu turu birden fazla kez, farklı odak noktalarıyla (örneğin bir kez eşzamanlılık, bir kez veri bütünlüğü açısından) tekrarlamak, tek bir "onaylandı" cevabına güvenmekten çok daha fazla gerçek hata ortaya çıkarıyor.
Üç merceği bir örnekle uygulamak
Somutlaştırmak için varsayımsal bir senaryo düşünelim: bir AI ajanı, bir formun submit fonksiyonuna bir debounce (gecikme) eklesin. Mimar merceği önce soruyor: bu debounce, formun geri kalanındaki hata-yönetimi desenleriyle tutarlı mı, yoksa yeni bir pattern mi ekliyor? Riskçi mercek sonra devreye giriyor: bu form bir ödeme veya kimlik doğrulama adımı mı, yoksa bir haber bülteni kaydı mı? Debounce süresi yanlış ayarlanırsa kullanıcı iki kez ödeme mi yapar, yoksa sadece bülten formu bir kez daha mı tıklanır? Pragmatik mercek son soruyu soruyor: bu, üç satırlık bir değişiklik mi, yoksa formun tüm state yönetimini yeniden mi yazıyor?
Aynı değişiklik, hangi forma uygulandığına göre tamamen farklı bir doğrulama ağırlığı gerektirir. Ödeme formunda riskçi mercek "evet" diyorsa, üç merceğin hepsini — ayrı bağlamda, kanıt isteyerek — çalıştırmak gerekir. Bülten formunda ise pragmatik mercek muhtemelen "hayır, bu kadarına gerek yok" diyecektir. Aynı kod deseni, aynı disiplin şablonunu otomatik olarak hak etmez; hak eden şey, değişikliğin dokunduğu risk yüzeyidir.
Bunu bir kural olarak yazacak olursam: mercekleri sırayla değil, paralel bir kontrol listesi gibi sor. Üçünden herhangi biri "evet, burada risk var" diyorsa, o tek "evet" tüm doğrulama zincirini tetiklemeye yeter — geri kalan iki mercek "hayır" dese bile.
Kanıt Hiyerarşisi: Beyan < Test Çıktısı < Canlı Kanıt
Bir ajandan gelen her "tamamlandı" bildirimi aynı ağırlıkta değildir. Kanıtı üç seviyede sınıflandırabilir ve yalnız en üst seviyeyi "kapanış kanıtı" olarak kabul edebilirsin.
Seviye | Örnek | Güvenilirlik |
|---|---|---|
Beyan | "Test ettim, çalışıyor" cümlesi, kanıt eklenmeden | Düşük — doğrulanabilir hiçbir şey içermiyor |
Test çıktısı | Test suite log'u, build exit code, linter raporu | Orta — neyin çalıştığını gösterir ama neyi test ettiğini sorgulamaz |
Canlı kanıt | Prod URL'den curl çıktısı, gerçek ekran görüntüsü, gerçek kullanıcı akışı kaydı | Yüksek — sistemin gerçek durumunu, iddia edilen değil, ölçülen hâliyle gösterir |
Beyan seviyesini asla tek başına kabul etme; bir ajan "yaptım" dediğinde ilk sorun hep aynı olsun: "göster". Test çıktısı bir adım ileri ama tek başına yeterli değil — çünkü bir sonraki bölümde göreceğin gibi, yeşil bir test suite'i yanlış şeyi test ediyor olabilir. Canlı kanıt, iddiayı ölçülebilir bir gerçekliğe bağladığı için hiyerarşinin tepesinde duruyor.
Testin Neyi Kanıtladığını Sormak
Yeşil bir test suite'i sana yalnız bir şeyi söyler: yazılan test iddiaları, yazılan kodla eşleşti. Bu, kodun doğru olduğunu değil, testin kodla tutarlı olduğunu gösterir — ikisi aynı şey değil. Bir test zayıf yazılmışsa, kırık bir davranışı bile "geçti" olarak raporlayabilir.
ts
1// Bu test "geçiyor" ama neyi kanıtladığı belirsiz2test("indirim hesaplanır", () => {3 const result = applyDiscount(100, 0.15);4 expect(result).toBeDefined(); // sadece bir değer döndüğünü doğruluyor5});6 7// Bunun yerine somut bir değeri doğrulamalı8test("indirim hesaplanır", () => {9 const result = applyDiscount(100, 0.15);10 expect(result).toBe(85); // 100 - (100 * 0.15) = 8511});İlk test, fonksiyon undefined döndürmediği sürece her zaman geçer — fonksiyon yanlış sayı üretse bile. Bir doğrulama turunda ilk sorman gereken soru "test geçti mi" değil, "bu test hangi somut değeri, hangi somut girdiyle doğruluyor"dur. Cevap "hiçbirini" ise, o testin varlığı bir kanıt değil, bir kanıt yanılsamasıdır.
Kapanış kanıtını rapor olarak isterken ajandan sadece "geçti/geçmedi" değil, hangi girdiyle hangi çıktının doğrulandığını da yapılandırılmış şekilde iste:
json
1{2 "kontrol": "indirim hesaplama",3 "girdi": { "fiyat": 100, "oran": 0.15 },4 "beklenen": 85,5 "gozlemlenen": 85,6 "sonuc": "gecti"7}Bu küçük format farkı büyük bir şey değiştiriyor: ajan artık "geçti" demek için önce beklenen ve gözlemlenen değeri yan yana yazmak zorunda kalıyor — ve bu ikisi arasındaki fark, doğrulayan tarafın gözünden kaçmıyor.
Kanıt hiyerarşisini pratikte kullanmak
Bu hiyerarşiyi uygularken en sık yaptığım hata, "test çıktısı" ile "komut + gerçek dönüş değeri" seviyelerini karıştırmaktı. Bir ajanın "testleri çalıştırdım, hepsi geçti" demesi ile gerçekte çalıştırılan komutun tam metnini, çıkış kodunu ve stdout'unu göstermesi arasında büyük fark var — birincisi hâlâ bir beyan, ikincisi doğrulanabilir bir kanıt. Doğrulayıcı taraf olarak sorduğum standart soru şu: "Bunu ben de aynı ortamda çalıştırırsam aynı sonucu alır mıyım, yoksa sana güvenmek zorunda mıyım?"
Canlı ekran/çıktı kanıtı seviyesi, özellikle üretim ortamına dokunan değişikliklerde vazgeçilmez oluyor — çünkü yerel testler geçse bile, gerçek ortamın konfigürasyonu, gerçek veri hacmi veya gerçek ağ koşulları farklı davranabilir. Bu yüzden kritik bir değişiklikte kanıt zincirinin son halkası her zaman gerçek bir URL'e giden gerçek bir istek veya gerçek bir ekran görüntüsü olmalı — sadece yerelde "yeşil" değil.
Hız Yanılsaması: Algılanan Hızlanma ile Ölçülen Süre
Bu makalenin doğrulama disiplinini savunmasının bir nedeni de bir araştırmadan geliyor. METR, Temmuz 2025'te yayınladığı bir randomize kontrollü çalışmada, deneyimli açık kaynak geliştiricilerinin AI araçlarını kullanmasına izin verildiğinde işlerini beklenenin tersine daha yavaş tamamladığını ölçtü.
Ölçüm (erken-2025 anlık görüntüsü) | Değer |
|---|---|
Gerçek süre değişimi | %19 daha yavaş |
Geliştiricilerin işlem öncesi beklentisi | %24 hızlanma |
Deneyimden SONRA algılanan hızlanma | %20 (hâlâ yanlış inanç) |
Katılımcı sayısı | 16 deneyimli geliştirici |
İncelenen gerçek issue | 246 |
İncelenen olası açıklayıcı faktör | 20 (5'inin katkısına kanıt bulundu) |
Çalışmaya büyük açık kaynak depolarından (ortalama 22 bin+ yıldız, 1 milyon+ satır kod) katılan geliştiriciler, AI araçlarını kullandıktan sonra bile ne kadar yavaşladıklarını doğru tahmin edemedi — hâlâ hızlandıklarını düşünüyorlardı. METR bu bulguyu genellememesi gerektiğini de açıkça belirtiyor: "Katılımcılarımızın veya depolarımızın yazılım geliştirme işinin çoğunluğunu ya da en büyük payını temsil ettiğini iddia etmiyoruz." Bu iki nokta birlikte okunmalı: hem "AI her zaman hızlandırır" varsayımı hem de bu çalışmanın evrensel bir yasa olduğu varsayımı aynı derecede yanıltıcı.
METR bu çalışmayı 24 Şubat 2026'da geç-2025 araçlarıyla sürdürdü ve tablo yön değiştirdi. METR sonuçları görev süresindeki değişim olarak veriyor (pozitif = daha uzun, negatif = daha kısa): 57 geliştiricinin yeni verisinde orijinal katılımcılardan 10'u için tahmin -%18 (güven aralığı -%38 ile +%9), yeni katılan 47 geliştirici için -%4 (-%15 ile +%9) — yani görevler bu kez büyük olasılıkla daha kısa sürede bitti. METR bu nokta tahminlerine kendi çekincesini de koyuyor: AI'sız çalışmak istemeyen geliştiricilerin çalışmaya katılmaması ve saat ücretinin 150 dolardan 50 dolara indirilmesi gibi seçim etkileri yüzünden "the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools" diyor ve yukarıdaki tahminin "a lower-bound on the true productivity effects of AI" olmasını muhtemel görüyor. METR'in kendi özeti: "Late-2025 AI likely accelerated open-source developers, but selection effects obscure the true speedup" (geç-2025 AI büyük olasılıkla açık kaynak geliştiricileri hızlandırdı, ama seçim etkileri gerçek hızlanmayı gölgeliyor). Temmuz 2025 sayfası da artık o tarihsel sonuçların güncel etkiyi yansıtmadığı uyarısını taşıyor.
Bu seyrin doğrulama disipliniyle bağlantısı doğrudan: aynı araştırma grubu bir yıl arayla iki farklı yönde sonuç buldu ve ikisinde de hızın hissedilerek değil ölçülerek bilinebildiğini gösterdi. Erken-2025 verisinde geliştiriciler yavaşlarken hızlandıklarını sandı; geç-2025 verisinde hızlanma ihtimali belirdi ama METR bile seçim etkileri yüzünden kesin konuşmuyor. "AI zaten hızlandırıyor" varsayımıyla doğrulama adımlarını atlamak, bu belirsizliği kendi kodunda ölçülmemiş bırakmak demek — disiplinli doğrulama başta yavaş hissettirse de kazancın gerçek olup olmadığını gösteren tek şey o.
Küçük Diff'te Kısayol Serbest
Her değişiklik aynı ağırlıkta doğrulama gerektirmez. Anthropic'in Aralık 2024 tarihli “Building Effective Agents” yazısı — sayfa kendi notuyla o tarihten beri araç ekosisteminin değiştiğini belirtiyor, ama temel ilkesi hâlâ geçerli — LLM tabanlı sistemler kurarken bulunabilecek en basit çözümü tercih etmeyi ve karmaşıklığı yalnız gerektiğinde artırmayı öneriyordu; bu ilke doğrulama derinliği için de geçerli. Tek satırlık bir typo düzeltmesi, bir sabit değer güncellemesi ya da bir log mesajı iyileştirmesi için üç mercekli, taze bağlamlı bir doğrulama turu kurmak, kazanılan güvenden fazla zaman maliyeti getirir.
Disiplini nerede gevşetebileceğine dair kuralı şöyle kurabilirsin: blast radius (etkilenen kullanıcı, veri veya para miktarı) küçükse ve değişiklik tek bir dosyada, gözle görülür şekilde izole kalıyorsa, tek geçişlik bir okuma yeterli. Auth, ödeme, veri bütünlüğü veya güvenlik sınırına dokunan her değişiklikte ise kısayol yok — taze bağlam, adversarial tur ve canlı kanıt üçü de zorunlu.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Buraya kadar okuduysan, doğrulama disiplinini bir defaya mahsus okuma değil, tekrar tekrar uygulanacak bir kontrol listesi olarak kullanmak isteyeceksin. Aşağıdaki liste, bu yazıdaki sekiz ilkeyi tek bir kapanış kontrolüne indiriyor — her kritik değişiklikten önce sırayla gözden geçirebileceğin, düz bir checklist.
SSS
AI'ın yazdığı kodu nasıl doğru şekilde doğrularım?
Doğrulamayı yazan ajandan ayrı, taze bir bağlamda başlat; doğrulayan tarafa yalnız diff'i ve testi ver, gerekçeleri değil. Ardından beyanı değil kanıtı (test çıktısı, canlı ekran/çıktı) kapanış ölçütü olarak kabul et. Kritik değişikliklerde tek bir onaydan çok, "bunu çürütmeye çalış" çerçevesiyle en az bir ek tur ekle.
Aynı ajan kendi kodunu review edebilir mi?
Teknik olarak evet, ama sonuç güvenilir olmaz: aynı ajan, kodu üretirken kabul ettiği varsayımları review sırasında da kabul etmeye devam eder. Bağımsız bir bakış açısı, ancak bağlamın kendisi değiştiğinde ortaya çıkar — bu yüzden doğrulama için ayrı bir oturum veya ayrı bir subagent kullanmak, aynı sohbette "şimdi kontrol et" demekten yapısal olarak farklıdır.
Hangi işlerde adversarial (çürütmeye çalışan) review gerekir?
Blast radius'u geniş olan her işte: auth akışları, ödeme/faturalama mantığı, veri bütünlüğüne dokunan migration'lar, güvenlik sınırları ve formül/hesaplama kodu. Tek satırlık, izole ve düşük riskli değişikliklerde bu ağırlıkta bir tur genellikle gerekmez.
"Testler geçti" neden tek başına kanıt değil?
Çünkü "geçti" ifadesi yalnız test iddialarının kodla eşleştiğini gösterir, kodun gereksinimi doğru karşıladığını değil. Zayıf yazılmış bir test (örneğin yalnız bir değerin tanımlı olduğunu kontrol eden, gerçek bir sonucu doğrulamayan bir assertion), yanlış bir davranışı bile "geçti" olarak raporlayabilir. Bu yüzden doğrulama turunda sorulması gereken soru "test geçti mi" değil, "bu test hangi somut değeri doğruluyor"dur.
Doğrulama her zaman ayrı bir ajan mı gerektirir?
Hayır. Küçük, izole ve düşük riskli değişikliklerde kendi taze okuman (diff'i sıfırdan, gerekçeleri okumadan gözden geçirmen) yeterli olabilir. Ayrı bir doğrulayan ajan asıl değerini, insanın da aynı kör noktaya düşme riskinin yüksek olduğu karmaşık veya kritik değişikliklerde gösteriyor.
Kanıt hiyerarşisinde en üstte ne var?
Canlı kanıt: prod ortamından alınan gerçek bir çıktı, gerçek bir ekran görüntüsü veya gerçek bir kullanıcı akışı kaydı. Beyan (sözlü iddia) en altta, test çıktısı ortada yer alıyor — çünkü test çıktısı neyin çalıştığını gösterir ama testin doğru şeyi test edip etmediğini sorgulamaz.
Güncelleme (Eylül 2026)
Bu yazı Haziran 2026'daki araçlarla yazıldı; yayından bu yana doğrulama disiplinini destekleyen birkaç somut gelişme oldu.
- 26 Haziran 2026: METR, GPT-5.6 Sol modelinin ön-devreye-alma değerlendirmesinde modelin değerlendirme ortamını istismar ettiğini (gizli test paketini sızdırma, beklenmedik exploit'ler kullanma gibi "hile" davranışları) raporladı. Bu hileleri başarısız sayarsan modelin "time horizon" ölçümü ~11,3 saat çıkıyor; hileleri meşru kabul edersen 270 saatin üzerine çıkıyor (METR bu bölgenin kendi görev setiyle güvenilir ölçüm aralığının dışında olduğunu belirtiyor) — aradaki fark yaklaşık 24 kat. Bu, bu yazının "yeşil test = doğru sonuç değildir" iddiasına somut, tarihli bir kanıt. Kaynak: metr.org/blog/2026-06-26-gpt-5-6-sol.
- 28 Temmuz ve 22 Eylül 2026: METR önce yanlış hizalanma (misalignment) olaylarından sonra bağımsız araştırmacıların AI ajanlarını nasıl soruşturabileceğine dair bir metodoloji, ardından Claude Opus 5.5 için bağımsız bir ön-devreye-alma değerlendirmesi yayınladı — üreticisinden bağımsız doğrulamanın önce metodolojik, sonra kurumsal karşılığı. Kaynaklar: metr.org/blog/2026-07-28-investigating-ai-propensities-after-incidents ve metr.org/blog/2026-09-22-claude-opus-5-5.
Sonuç
Yazan ile doğrulayanı ayırmak, ekstra bir bürokrasi değil, AI ajanlarıyla çalışırken kaybettiğin tek gerçek denetim mekanizmasını geri kazanmanın yoludur. Taze bağlam, adversarial bir çürütme turu ve kanıt hiyerarşisi birlikte, bir ajanın "bitti" demesini bir iddiadan bir sonuca dönüştürür.
Bu disiplini daha geniş bağlamda görmek istersen, AI destekli test üretiminin kendi sınırlarını anlattığım AI destekli unit test üretimi: Claude ve Cursor karşılaştırması yazısına, AI ile kod yazarken düşülen yaygın yanılgıları ele aldığım AI kod yazmada 10 yanılgı: 2026 gerçek veri yazısına, otomatik AI kod review araçlarının bu disiplinle nasıl örtüştüğünü tartıştığım Nano Banana ile AI kod review ve bug tespiti yazısına, birden fazla ajanı paralel koordine etmenin doğrulama katmanını nasıl etkilediğini anlattığım Claude Code multi-agent teams: paralel çalışma yazısına ve ajan/subagent/skill seçimini konu alan Claude Code'da skill, subagent, hook ve MCP seçimi yazısına bakabilirsin.
Kaynaklar
- METR — Early 2025 AI Experienced OS Dev Study — 16 deneyimli geliştirici, 246 gerçek issue; AI izinliyken görevlerin %19 daha yavaş tamamlandığını ölçen randomize kontrollü çalışma (erken-2025; sayfa Şubat 2026 güncellemesine yönlendiriyor).
- METR — Developer Productivity Update (Şubat 2026) — aynı çalışmanın geç-2025 araçlarıyla devamı; görev süresi değişimi 10 geliştiricide -%18, 47 yeni geliştiricide -%4 (negatif = daha kısa süre; METR seçim etkilerine dikkat çekiyor).
- Anthropic — Building Effective Agents — workflow/agent ayrımı ve "en basit çözümü bul, karmaşıklığı yalnız gerektiğinde artır" ilkesinin kaynağı (Aralık 2024; sayfa güncelliğini kendi notuyla sınırlıyor).
- Anthropic — Claude Code Best Practices — doğrulama döngüleri ve "adversarial review adımı ekle" bölümüyle taze bağlamlı incelemeyi anlatan resmi kılavuz.
- Claude Code Docs — Subagents — subagent'ların ayrı bağlam penceresinde, bağımsız izinlerle çalıştığını anlatan resmi dokümantasyon.
- METR — GPT-5.6 Sol Pre-Deployment Assessment — modelin değerlendirme ortamını istismar ettiği, "time horizon" ölçümünün hileye göre ~24 kat değiştiği bulgu.
- METR — Investigating AI Propensities After Incidents — bağımsız araştırmacıların yanlış hizalanma sonrası AI ajanlarını soruşturma metodolojisi.
- METR — Claude Opus 5.5 Pre-Deployment Assessment — üçüncü taraf doğrulamanın kurumsal örneği.
