--- title: "AI-Assisted Engineering Workflow'um" description: "Claude Code ve benzeri ajanları üretim kodunda güvenle kullanmak için takip ettiğim yedi kural — alaycı bir yazı değil, bir disiplin manifestosu." url: https://sade.dev/tr/journal/ai-assisted-engineering-workflow/ lang: tr author: "Muhammet Şafak" published: 2026-05-10 updated: 2026-09-06 section: Journal tags: ["ai-workflow","productivity","opinion"] summary: "Coding agent'larla iki yıllık günlük çalışma yedi kural üretti ve yedisi de aynı noktaya çıkıyor: ajan, kodu kimin yazdığını değiştirdi; kimin sorumlu olduğunu değil. Onaylı plan olmadan kod yazdırma yok, sınırlı erişim, iddiaya değil kendi çalıştırdığın teste güven, junior kodu kadar sıkı review, ajanın bir geçmişi olsun diye repo'ya yazılmış kararlar ve savunamayacağın satırı merge etmemek." --- # AI-Assisted Engineering Workflow'um > Coding agent'larla iki yıllık günlük çalışma yedi kural üretti ve yedisi de aynı noktaya çıkıyor: ajan, kodu kimin yazdığını değiştirdi; kimin sorumlu olduğunu değil. Onaylı plan olmadan kod yazdırma yok, sınırlı erişim, iddiaya değil kendi çalıştırdığın teste güven, junior kodu kadar sıkı review, ajanın bir geçmişi olsun diye repo'ya yazılmış kararlar ve savunamayacağın satırı merge etmemek. 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. ## Sık sorulanlar **Ajana onaylı plan olmadan kod yazdırılır mı?** Her zaman hayır. İşe yarayan akış şu: önce plan çıkart, planı oku, sor ve düzelt, sonra plana göre yazdır — büyük modüllerde adım adım. Tek cümlede auth modülü istemek kontrolsüz iştir. **Ajanın testler geçti demesi yeterli mi?** Yeterli değil. Testi kendin çalıştır, manuel smoke test yap, şüphe varsa işi atıp 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. **Junior bir mühendise ajana yaptır denebilir mi?** Genellikle bu bir felaket. Junior, ajanın çıktısını eleştirel okumayı bilmiyor, doğru soruyu sormayı henüz öğrenmedi ve çalışıyor ile doğru çalışıyor arasındaki farkı henüz hissedemiyor. Junior'a verilecek görev ajanı denetlemek olabilir, ama yönetmek değil. **Üretime ulaşan ajan kodundan kim sorumlu?** Sen. Ajanın yazdığı bir SQL injection açığını sen merge ettiysen sorumluluk senindir; AI yazdı ifadesi PR review'unda bahane değildir. Pratikte: gerçekten okumadığın, anlamadığın, gerekirse savunamayacağın hiçbir şeyi merge etme.