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ı önerme 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. Test’i çalıştır. Geçtiğini 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ı atlamayın

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üşmeyin. Ö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ı” unutmayın. Her oturumda hangi karara neden vardığınızı anlatmak gerekiyor. Bunu otomatikleştirmek için:

  • Repo’da CLAUDE.md veya .ssot/ gibi durumun anlık özetini tutuyorum.
  • Önemli kararları orada 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 yap” 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 şeyi gerçekten okuduğun, anladığın, gerekirse savunabildiğin koddan emin olana kadar merge etme.

Sonuç

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

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