AI coding agent’larıyla 2 yıldır günlük çalışıyorum. İlk yıl naif kullandım, ikinci yıl disiplin geliştirdim. Bu yazı disiplinin somut hali.

Sayısal olarak ne kadar hızlandığım önemli değil — önemli olan kodun kalitesi azalmadı. Aksine, kod tabanına gelen junior’ların ürettiği bug’lardan daha azını ürettim. Bu bir başarı değil, ajan kullanmamayı öneren bir reklam değil — ne işe yaradığına dair bir gözlem.

1. Ajana plan yaptırma, onayla, sonra yazdır

“Bana auth modülü yaz” demek = kontrolsüz. İşe yarayan akış:

  1. “Auth modülü için bir plan çıkar. Endpoints, DB tabloları, edge case’ler.”
  2. Planı oku, sor, düzelt.
  3. “Plana göre yaz” — ama büyük modüllerde adım adım.

Onaylı planın olmadan kod yazma izni verme. Her zaman.

2. Sınırlı erişim ver

Bir ajanın rm -rf çalıştırabilmesi gereksiz. Sandbox tercih:

  • Read-only filesystem mount’lar dışında.
  • Network erişimi sadece belirli endpoint’lere.
  • Production secrets’a erişim asla. Local mock veya scrubbed copy.

Bu “ajan kötü niyetli” varsayımı değil, “hata yapabilir” varsayımı.

3. Test ettir, çalıştır, geri al

Ajan kod yazdı. Şimdi:

  1. Test yazdır (ya da var olan testleri çalıştır).
  2. Testi çalıştır. Geçtiği iddiası yetmez — gerçekten gör.
  3. Manuel smoke test yap. Ajanın iddialarına değil, gözüne güven.
  4. Şüphe varsa git checkout . — tekrar dene.

Ajanın özeti gerçek değil. Yalan söylemiyor — sadece kendi çıktısının iyi olduğunu varsayıyor. Doğrulama insan işi.

4. Code review aşamasını atlama

Ajanın ürettiği kod, junior bir mühendisin ürettiği kod gibi gözden geçirilmeli. “Ajan zaten kontrol etmişti” yanılgısına düşme. Özellikle:

  • Güvenlik. SQL injection, XSS, auth bypass.
  • Performance. N+1 query’ler, gereksiz cache invalidation.
  • Boundary condition’lar. Boş input, çok büyük input, Unicode.

Bunları yakalamak için statik analiz iyi, ama insan gözü vazgeçilmez.

5. Bağlamı saklı tut

Ajanın “geçmişe sahip olmadığını” unutma. Her oturumda hangi karara neden vardığını anlatmak gerekiyor. Bunu otomatikleştirmek için:

  • Repo’da CLAUDE.md veya .ssot/ gibi yerlerde durumun anlık özetini tutuyorum.
  • Önemli kararları oraya yazıyorum: “PostgreSQL kullanıyoruz çünkü…, Redis cache-only modunda çalışıyor çünkü…”.
  • Ajan oturumun başında bunu okur, daha tutarlı kararlar verir.

6. Ajanı tek mühendise yerleştirme

Bir ajanı senior bir mühendis yerine koymak yanlış. Ajanı bir senior mühendisin uzantısı olarak kullanmak doğru. Junior mühendislere doğrudan “ajan’a yaptır” demek genellikle felaket — çünkü:

  • Ajanın çıktısını eleştirel okumayı bilmiyorlar.
  • Doğru soruyu sormayı henüz öğrenmediler.
  • “Çalışıyor” ile “doğru çalışıyor” arasındaki farkı henüz hissedemiyorlar.

Junior’a verilecek görev, ajanı denetlemek olabilir — ama yönetmek değil.

7. Üretime ulaşan kodun her satırından sorumlu sensin

Bu en önemlisi. Ajanın yazdığı bir SQL injection açığını sen merge ettiysen, sorumluluk senin. “AI yazdı” ifadesi PR review’unda bahane değil.

Pratik karşılığı: ajanın ürettiği her şeyin gerçekten okuduğun, anladığın, gerekirse savunabildiğin kod olduğundan emin olana kadar merge etme.

Sonuç

Ajanlar inanılmaz kuvvetli aletler. Onları “30 saniyede özellik üreten sihirli sopalar” olarak görmek başarısızlık. Onları “bir senior mühendisin uzantısı olan stajyer” olarak görmek başarı. Hangi tarafı seçtiğin, ortaya çıkan yazılımın kalitesini belirliyor.

İki yılın sonunda hâlâ aynı disipline uyuyorum çünkü işliyor.