- Yapay zeka kod yazma ajanları, geliştirici uyurken bile kod üretip branch'e değişiklikleri yansıtıyor; ancak sonuçların doğruluğunu ve güvenilirliğini doğrulamak zor
- Yapay zekanın yazdığı kodu yine aynı yapay zeka test ederse bir kendi kendini tebrik makinesine dönüşüyor ve ilk niyetten farklı yanlış anlamaları yakalayamıyor
- TDD'nin temel ilkesini ödünç alarak, kod yazmadan önce önce kabul kriterlerini yazıp ajanın buna göre implemente etmesini ve ardından ayrı doğrulama yapılmasını sağlıyor
- Doğrulama aracı olarak Claude Code'un headless modu (claude -p) ile Playwright MCP birleştirilerek 4 aşamalı bir pipeline kuruluyor; ayrı bir backend gerekmiyor
- Ajan çıktısına güvenmek için işe başlamadan önce "tamamlandı"nın tanımını netleştirmek gerekiyor; bu, prompt yazmaktan daha zor ama zorunlu bir süreç
Otonom ajanlarda kod doğrulama sorunu
- Gastown gibi yapay zeka araçlarıyla ajanlar saatler boyunca kod yazıp branch'e değişiklikler yansıtıyor, ancak ortaya çıkan sonucun gerçekten doğru olup olmadığını anlayacak güvenilir bir doğrulama yöntemi yok
- Son 6 ayda 100'den fazla mühendise Claude Code atölyesi verildiğinde, her ekipte aynı sorunun görüldüğü ortaya çıktı
- Claude'u günlük PR süreçlerinde kullanan ekiplerde haftalık merge edilen PR sayısı 10'dan 40-50'ye çıktı; bu da kod incelemeye çok daha fazla zaman harcanmasına yol açtı
- Sistem ne kadar otonom çalışırsa sorun o kadar büyüyor — bir noktadan sonra diff incelemek yerine deploy'u izleyip sorun çıkmamasını umuyorsunuz ve hataları ancak deploy sonrasında fark ediyorsunuz
Mevcut çözümlerin sınırları
- Daha fazla reviewer işe almak çözüm değil; hız yetişmiyor ve kıdemli mühendislerin bütün gün yapay zeka tarafından üretilmiş kod okuması verimsiz
- Claude kendi yazdığı kodun testlerini de yazarsa, sistem kullanıcının gerçekte ne istediğini değil, Claude'un istediğini sandığı şeyi doğrulamış olur
- Regresyon hatalarını yakalayabilir ama asıl yanlış anlamayı (misunderstanding) tespit edemez
- Aynı yapay zekayı hem yazım hem doğrulama için kullanmak onu bir "kendi kendini tebrik makinesi (self-congratulation machine)" haline getirir
- Kod incelemesinin asıl amacı, orijinal yazardan farklı ikinci bir göz sağlamaktır; yapay zekalar arası çapraz inceleme ise aynı kaynaktan geldiği için aynı şeyleri kaçırır
TDD'nin doğru yakaladığı temel nokta
- TDD'nin ilkesi: önce test yaz, sonra kodu yaz, test geçince dur (daha fazlasını implemente etme)
- Çoğu ekibin TDD yapmamasının sebebi, kodun ne yapması gerektiğini önceden düşünmenin zaman alması
- Yapay zeka hız sorununu çözdüğü için bu mazeret ortadan kalkıyor — artık yavaş olan kısım kodun doğru olup olmadığına karar vermek
- Unit test yerine, özelliğin ne yapması gerektiğini düz metinle anlatmak daha kolay
- Örnek: "Kullanıcı e-posta ve parola ile kimlik doğrular. Geçersiz kimlik bilgileri verildiğinde 'Invalid email or password' gösterilir. Başarılı olursa /dashboard'a gider. Session token 24 saat sonra sona erer"
- Bu kriterler kod editörü açılmadan yazılabilir; ajan implemente eder, başka bir sistem de doğrular
Gerçek uygulama örnekleri
-
Frontend değişikliği
- Spec dosyası temel alınarak kabul kriterleri (Acceptance Criteria) oluşturulur
- AC-1: Geçerli kimlik bilgileriyle /login açıldığında /dashboard'a redirect edilir ve session cookie ayarlanır
- AC-2: Yanlış parola girildiğinde tam olarak "Invalid email or password" gösterilir ve /login sayfasında kalınır
- AC-3: Alanlar boşsa submit butonu devre dışı olur veya inline hata gösterilir
- AC-4: 5 başarısız denemeden sonra giriş 60 saniye engellenir ve bekleme süresi mesajı gösterilir
- Her kriter net biçimde geçti/kaldı olarak değerlendirilebilir
- Ajan özelliği kurduktan sonra, Playwright browser agent her AC için doğrulama yapar, ekran görüntüsü alır ve kriter bazında değerlendirme raporu üretir
- Bir şey başarısız olursa, hangi kriterin başarısız olduğu ve tarayıcıda tam olarak ne görüldüğü açıkça anlaşılır
-
Backend değişikliği
- Aynı pattern tarayıcı olmadan uygulanır
- Gözlemlenebilir API davranışı (status code, response header, error message) tanımlanır ve curl komutları ile doğrulanır
-
Sınırlar
- Spec'in kendisindeki yanlış anlamayı yakalayamaz — spec baştan yanlışsa doğrulamayı geçse bile özellik yine yanlış olabilir
- Playwright'ın yakalayabildikleri: entegrasyon hataları, render bug'ları, gerçek tarayıcıda bozulan davranışlar
- Bu, "doğrulanmış doğruluk" kadar geniş bir iddia değildir; ama kod incelemesinin istikrarlı biçimde yakalayabildiğinden daha fazlasını yakalar
-
İş akışı özeti
- Prompt'tan önce kabul kriterlerini yaz → ajan kriterlere göre implemente etsin → doğrulamayı çalıştır → yalnızca başarısız olanları incele (diff değil, başarısızlık incelemesi)
Nasıl kuruluyor: 4 aşamalı pipeline
- Claude Skill ile implemente edilmiş (github.com/opslane/verify); claude -p (Claude Code headless modu) ve Playwright MCP kullanıyor
- Ayrı bir custom backend ya da ek API key gerekmiyor; yalnızca mevcut Claude OAuth token kullanılıyor
-
1. aşama: Pre-flight
- Saf bash, LLM çağrısı yok
- Geliştirme sunucusunun çalışıp çalışmadığını, kimlik doğrulama session'ının geçerliliğini ve spec dosyasının varlığını kontrol eder
- Token harcamadan önce hızlıca fail eder
-
2. aşama: Planner
- Bir kez Opus çağrılır
- Spec'i ve değişen dosyaları okuyup, her doğrulama için ne gerektiğine ve nasıl çalıştırılacağına karar verir
- Kodu okuyarak doğru selector'ları bulduğu için class name tahmin etmez
-
3. aşama: Browser Agents
- Her AC için bir kez Sonnet çağrılır, hepsi paralel çalışır
- 5 AC varsa 5 ajan bağımsız olarak gezinir ve ekran görüntüsü alır
- Sonnet, Opus'a kıyasla 3-4 kat daha ucuzdur ve tıklama tabanlı işlerde eşdeğer performans sunar
-
4. aşama: Judge
- Son bir Opus çağrısı, tüm kanıtları okuyup her kriter için şu sonucu döndürür: pass, fail veya needs-human-review
-
Kurulum
- Claude Code plugin'i olarak kurulabilir:
/plugin marketplace add opslane/verify
- Ya da repo clone edilip özelleştirilebilir — her aşama, net girdilere ve yapılandırılmış çıktılara sahip tek bir claude -p çağrısıdır
- Model değiştirilebilir, aşama eklenebilir, --dangerously-skip-permissions seçeneğiyle CI entegrasyonu yapılabilir
Temel ders
- Asıl nokta şu: "Tamamlanmış"ın tanımını önceden yazmazsanız sonuca güvenemezsiniz"
- Kabul kriterleri yazmak prompt yazmaktan daha zordur; ama edge case'leri önceden düşünmeye zorlayarak kaliteyi artırır
- Mühendislerin TDD'ye direnmesinin sebebiyle aynı şekilde, başta daha yavaş hissettirdiği için buna da direnç gösterilir
- Kabul kriterleri olmadan yapılabilen tek şey çıktıyı okuyup doğru olmasını ummaktır
- Bu, yapay zeka odaklı geliştirme ortamında güvenilirlik sağlamak için zorunlu bir süreçtir
2 yorum
Ne kadar TDD uygularsan uygula, LLM'in testleri manipüle edip geçecek hale getirdiği şu anki seviyede insan incelemesi kesinlikle gerekli..
Hacker News yorumları
Bu aralar çıkan LLM framework’leri sanki geliştirmeyi daha da zor ve pahalı hale getiriyor
Varsayılan ayarlarla bile epey yol alınabiliyorken, modellerin sürekli değiştiği bir ortamda sayısız wrapper ve harness yapmak verimsiz geliyor
Gece boyunca çalıştırıp para yakan bu yaklaşımın ileride PHP meme’leri gibi alay konusu olarak kalacağını düşünüyorum
Yazıya göre “son 6 ayda 100’den fazla mühendise Claude Code atölyesi verildi”
Gece gündüz çalıştırıp sonunda AI şirketi iflas ettiğinde, geriye de sadece %80’i AI tarafından yazılmış spagetti kod kaldığında kimin güleceğini görürüz
Bugünün full-stack JS/TS ortamından ziyade, 15 yıl önce PHP ile yaptıklarımın daha iyi olduğunu bile düşünüyorum
PHP hâlâ yaşıyor ve gelişiyor. LLM tooling de sonunda bu şekilde temel araçlardan biri olacak
BA, PO, QA, SWE arasındaki sınırlar bulanıklaşıyor. Artık iş ve geliştirme arasında duran hibrit roller ortaya çıkıyor
İnsanlar bugünlerde sanki sırf agent kullanmış olmak için kullanıyor
Ben yazı yazma ve review için sadece iki tane çalıştırıyorum, buna rağmen 5–7 kat verimlilik gayet mümkün
Spec incelemeye daha çok zaman ayırıyorum, coding işini agent 10–30 dakikada bitirdiği için acele etmeye gerek kalmıyor
Yarın da iş devam edecek, o yüzden gece boyu çalıştırmanın özel bir anlamı yok
Müşteri açısından bakınca bug’ın Hindistan’dan mı, San Francisco’dan mı, AI’dan mı geldiğinin pek farkı yok
Bu, son dönemde moda olan “agent orkestrası” yaklaşımına göre çok daha kontrollü bir yöntem
Bu yüzden Claude’un spec’e gerçekten uyup uymadığını kontrol etmek için verify skill’i kendim yaptım
Claude’a red-green-refactor kalıbını kullandırınca test kalitesi belirgin biçimde artıyor
Hatta red/green/refactor alt agent’ları oluşturup birbirlerini doğrulatınca oldukça iyi çalışıyor
Buradaki ana nokta, context’leri birbirine karıştırmamak
Reward hacking gerçekten var ve buna karşı savunma geliştirmek zor
Bu rehbere baksanız da kötü test sorunu hâlâ büyük
Sonuçlar iyi olduğu için ilkeleri ve örnekleri ve starter repo’yu paylaştım
Yazan ile doğrulayanı ayırmak önemli; aynı model olsa bile context ayrılınca kalite yükseliyor
Mevcut LLM context sınırları yüzünden gerçek agent’lar hâlâ mümkün değil
500 satırı aşan kodlarda hata oranı hızla artıyor, 200 satır civarı sınır gibi
Sonuçta LLM, ancak hesap makinesi gibi tekrar tekrar kullanılan bir araç konumunda
Ben bu olguya “Test Theatre” diyorum
Bununla ilgili yazıyı burada yazdım. Özellikle kaçınılması gereken bir şey
İyi testler tasarım kalıplarını ve bağımlılıkları doğrulamalı, ayrıca debugging’e yardımcı olmalı
Örneğin Schemathesis ile kullanıcı izinlerini veya 5xx yanıtlarını otomatik doğruluyorum
Bununla ilgili POC’yi buraya koydum
Son zamanlarda agent orchestration denemeleri yapıyorum
Kilit nokta LLM çağrılarını azaltıp bunları deterministik script pipeline’larıyla birbirine bağlamak
Ayrıntıları bu yazıda anlattım
Şu deney notunda olduğu gibi, asıl önemli olan LLM değil script’ler
Ben iş operasyonları için 6 agent çalıştırıyorum
Pazar araştırması, içerik yazımı, video senaryosu gibi çeşitli rolleri üstleniyorlar
“Gece boyunca çalıştırmak” biraz abartılı bir fikir; pratikte işe yarayan şey net hedefler ve dar kapsam
Asıl darboğaz yürütme değil, context yönetimi
Bu kişinin gerçekte ne yaptığını pek anlamıyorum
LinkedIn’de sadece Claude ile ilgili yazılar görüyorum
Ciddi bir iş yapan hiçbir şirket için kabul edilebilir değil
Sonunda kod boşta kalıyor, çünkü asıl mesele onu nasıl satacağını bulmak oluyor
Bu, sadece test yazan birini işe alınca ortaya çıkan sorunla aynı
Sonuçta sadece “kod, yazıldığı şekilde çalışıyor”u doğrulamış oluyorsun
Asıl önemli olan net bir spec tanımı
Diğer mühendislik alanları bu hatayı tekrar etmiyor ama yazılımda bunun bu kadar yaygın olması şaşırtıcı
İlk sürüm yanlış olsa bile, sonradan davranışın değişmemesini garanti ediyor
Birçok danışmanlık şirketi acceptance criteria tabanlı doğrulama ile çalışıyor
Bugünkü AI artık geliştirmeye yardımcı olan bir araç değil, geliştiricinin yerini alacak bir seviyeye geldi
Kod üzerinde artık kontrol ya da doğrulama kuramıyor olmamız ciddi bir sorun
Bu, yeni bir geliştirme yöntemi değil; anlamanın yerine güvene dayanan dinsel bir dönüşüm gibi hissettiriyor
Özerklik düşük olsa bile, yalnızca doğrulanabilir kodu merge ederim