Kodlama ajanı çıktısını doğrulamak: solo geliştirici için 7 adım

Bir kodlama ajanının işi bitirmesi, kodun yayına hazır olduğu anlamına gelmiyor. Benim için doğru teslim noktası 'değişiklik yapıldı' değil; neyin değiştiğini anlayabildiğim, testlerin anlamlı biçimde geçtiği ve geri dönüş yolunun açık olduğu an. Ajanı hızlı bir uygulayıcı olarak kullanıyorum, son kararı veren kişi olarak değil.

GitHub'ın bulut ajanı kendi geçici ortamında kodu inceleyebiliyor, plan çıkarabiliyor, değişiklik yapabiliyor, test ve linter çalıştırabiliyor. Sonuç yine bir diff ve pull request olarak insanın önüne geliyor.[1] Bu ayrım önemli: ajanın çalışabilmesi başka şey, değişikliğin doğru olduğuna karar vermek başka şey.

Aşağıdaki akış kullandığım belirli bir ürüne bağlı değil. Claude Code, Codex, Copilot ya da başka bir ajanla aynı sırayı uygulayabilirsin. Her görevde yedi adımın tamamı aynı ağırlıkta olmayacak. NIST'in AI Risk Management Framework Playbook'u da kendi önerilerinin eksiksiz uygulanacak tek bir kontrol listesi olmadığını, kullanım senaryosuna göre seçilmesi gerektiğini söylüyor.[4] Küçük bir metin düzeltmesiyle ödeme akışındaki değişikliği aynı kapıdan geçirmek gereksiz; ikisini aynı rahatlıkla onaylamak ise tehlikeli.

1. Başarı ölçütünü koddan önce yaz

Ajana 'ayarlar sayfasını düzelt' demek fazla açık uçlu. Bunun yerine görülebilir sonucu tarif ediyorum: kaydet düğmesi yalnızca form değiştiğinde aktif olacak, başarısız istek eski değeri koruyacak, mevcut klavye akışı bozulmayacak. Böylece değerlendirme, ajanın kendinden emin açıklamasına değil önceden yazılmış bir beklentiye dayanıyor.

Kabul ölçütünde en az bir olumsuz senaryo bulunmalı. Ağ bağlantısı kesilirse, boş veri gelirse ya da kullanıcı aynı işlemi iki kez yaparsa ne olacağını yaz. Ajanlar mutlu yolu hızla tamamlıyor; sessiz hatalar çoğu zaman kenarda kalıyor. Daha önce yazdığım

'çalışıyor' görünen ama yanlış olan kod notunda da sorun tam olarak buydu: derlenen çıktı, ürün davranışının doğru olduğunu kanıtlamıyordu.

2. Görevin sınırını diff ile ölç

Önce değişen dosyaların listesini, sonra diff'i okuyorum. Görev bir form doğrulamasıysa paket güncellemesi, alakasız yeniden adlandırma veya geniş bir biçimlendirme turu beklemem. Fazladan değişiklik bazen yararlı olabilir ama inceleme alanını büyütür. Gerekliyse ayrı göreve taşımak daha temiz.

Burada dosya sayısından çok sebep ilişkisine bakıyorum: her değişiklik kabul ölçütlerinden hangisine hizmet ediyor? Cevabı olmayan satır, silinmek ya da açıklanmak zorunda. GitHub da ajan akışını dal, diff, iterasyon ve hazır olunca pull request üzerinden kuruyor; yani gözden geçirilebilir değişiklik kaydı ürünün parçası.[1]

3. Test çalıştırdı mı diye değil, doğru şeyi test etti mi diye bak

Yeşil test ekranı rahatlatıcı ama tek başına zayıf bir sinyal. Önce mevcut testlerin gerçekten değişen davranışa dokunup dokunmadığını kontrol ediyorum. Sonra yeni hata ihtimali için küçük bir test arıyorum. Bir koşul eklendiyse iki tarafı da, veri dönüşümü değiştiyse sınır değerini, hata yönetimi değiştiyse başarısız isteği görmek isterim.

Ajanın yazdığı test, kendi uygulamasındaki hatayı tekrar edebilir. Bu yüzden test adını ve assertion'ı diff'ten ayrı okuyorum. Mümkünse bir kritik testi kendim değiştirip yanlış uygulamada kırıldığını görüyorum. OpenAI'ın Codex Security dokümanı da kod değişikliğini birleştirmeden önce incelemeyi ve bulguların düzeltmesini sınırlı yamalarla doğrulamayı öneriyor.[3]

4. İzinleri görevin riskine göre daralt

Kod yazmak için production veritabanına, ödeme anahtarına veya tüm ev dizinine erişim gerekmiyorsa ajan bunları görmemeli. Varsayılanım çalışma klasörü, yerel test komutları ve gerekliyse sınırlı ağ erişimi. Anthropic'in güvenlik dokümanında Claude Code'un salt okunur başladığı, dosya düzenleme ve komut çalıştırma gibi ek eylemler için izin istediği belirtiliyor.[2] Aynı doküman çalışma dizini sınırı, dosya sistemi ve ağ izolasyonu ile hassas işlemlerde açık onay öneriyor.[2]

Onay pencerelerini otomatik geçmek hız kazandırıyor gibi görünür, fakat bir süre sonra insan yalnızca düğmeye basan parçaya dönüşüyor. Sık ve güvenli komutları allowlist'e almak mantıklı. Paket kurma, dışarıdan veri çekme, migration, silme ve production'a yazma ise ayrı kontrol noktası olarak kalmalı.

5. Dış girdiyi kod gibi şüpheli kabul et

Ajan bir issue, web sayfası, log veya üçüncü taraf dokümanı okuyorsa bu içerik bilgiyle birlikte modelin davranışını yönlendirmeye çalışan metin de taşıyabilir. Prompt injection bu nedenle klasik kullanıcı girdisi doğrulamasından farklı bir katman açıyor. Anthropic, güvenilmeyen içeriği doğrudan modele pipe etmemeyi, önerilen komutları onaydan önce okumayı ve kritik dosya değişikliklerini doğrulamayı öneriyor.[2]

Pratikte araştırma ile uygulamayı ayırıyorum. İlk tur yalnızca kaynak ve plan üretiyor. İkinci tur, seçtiğim bilgiyi kullanarak sınırlı klasörde değişiklik yapıyor. Böylece bir web sayfasının içindeki talimatın terminal yetkisine kadar kesintisiz ilerlemesini zorlaştırıyorum.

6. Üç ayrı kapı koy: teknik, ürün, geri dönüş

Tek bir 'onaylandı' yerine üç soruya cevap arıyorum. Teknik kapı: build, tip kontrolü, test ve güvenlik taraması geçti mi? Ürün kapısı: kabul ölçütü gerçek arayüzde veya API çıktısında karşılandı mı? Geri dönüş kapısı: sorun çıkarsa bu değişikliği veri kaybetmeden nasıl geri alacağım?

Özellikle şema, migration, kimlik doğrulama ve ödeme işlerinde geri dönüş planı kod kadar önemli. Bir commit'i geri almak kolay olabilir; o commit'in dönüştürdüğü veriyi geri almak olmayabilir. Bu görevlerde ajan taslağı hazırlayabilir, ama canlı uygulama ve son doğrulama insanda kalmalı.

7. Sonucu ajanın özetinden bağımsız anlat

İncelemeyi bitirdiğimde değişikliği kendi cümlelerimle tek paragrafta açıklayamıyorsam henüz birleştirmiyorum. Hangi davranış değişti, hangi risk kaldı ve bunu hangi kanıtla kabul ettim? Ajanın teslim mesajını kopyalamak sayılmaz. Amaç kodun her satırını ezberlemek değil; sorumluluğunu aldığın değişikliğin sınırını bilmek.

Kodlama ajanı seçimi rehberinde araçları görev türüne göre ayırmıştım. Doğrulama tarafında da benzer bir kural var: model ne kadar güçlü olursa olsun, kanıt türünü görev belirliyor. Görsel değişiklik ekran kontrolü ister; veri işlemi örnek kayıt ve tersine çevirme denemesi ister; güvenlik düzeltmesi ise saldırı yolunun gerçekten kapandığını göstermeli.

Kısa doğrulama kartı

Birleştirmeden önce kendime şu yedi satırı gösteriyorum:

• Beklenen davranış ve en az bir hata senaryosu yazılı.

• Diff görev sınırında; alakasız değişiklik yok.

• Testler değişen davranışı ve başarısız yolu kapsıyor.

• Ajan yalnızca gereken dosya, komut, ağ ve secret erişimine sahip.

• Dış içerik ile komut yürütme arasında insan kontrolü var.

• Teknik kontrol, ürün kontrolü ve geri dönüş yolu tamam.

• Değişikliği ajanın metnine bakmadan açıklayabiliyorum.

Bu akış ajanı yavaşlatmak için değil, hızını kullanılabilir hale getirmek için var. Beş dakikada yazılan kodu bir saat boyunca anlamaya çalışıyorsam kazanç yok. Küçük, ölçülebilir görev; dar izin; görünür diff; davranışı sınayan test ve açık geri dönüş yolu bir araya geldiğinde ajan gerçekten zaman kazandırıyor.