Kodu ajan yazıyor — peki çalışmasını kim denetliyor?

Bir ajana görev verebilir, depoda değişiklikler yapmasını bekleyebilir ve incelemeniz için bir pull request taslağı alabilirsiniz. Ancak kodla birlikte şu soru da ortaya çıkar: Sonuç göreve uygun mu ve testler önemli bir sorunu gözden kaçırdı mı?

4 Şubat 2026'da GitHub, Claude ve Codex'i kodlama ajanları olarak herkese açık önizlemeye sunduğunu duyurdu. Şirket, ajanlara issue'lar ve pull request'ler üzerinden görev verilebildiğini, ardından hazırladıkları PR taslağının incelenebildiğini bildirdi. Bu, söz konusu iş akışının geliştirme arayüzünde yer aldığını doğruluyor; ancak zaman tasarrufu sağladığını veya kod kalitesini artırdığını kanıtlamıyor.

Dolayısıyla mesele yalnızca ajanın kod yazıp yazamayacağı değil. İnsanların devredilen görevin etrafında hangi işleri yapması gerektiği de önemli: kısıtları belirlemek, çalışmayı izlemek ve sonucu değerlendirmek.

Gözetim, yalnızca son incelemeden ibaret değil

21 Eylül 2026'da arXiv'de yayımlanan bir ön baskıda araştırmacılar, bir kodlama ajanının denetlenmesini aşamalı bir süreç olarak ele almayı öneriyor. The Work Behind Delegation başlıklı çalışma, 19 deneyimli geliştiricinin gözlemlerine ve iş akışı şemalarına dayanıyor. Yazarlar yedi gözetim aşamasını tanımlıyor ve bu çerçeveyi Reddit'teki herkese açık geliştirici tartışmalarına uyguluyor.

Yazarların anlattığı yaklaşımlar arasında planlamaya daha fazla önem vermek, bazı gözetim görevlerini başka ajanlara devretmek ve tekrarlanan talimatları yeniden kullanılabilir materyallere dönüştürmek bulunuyor. Bu, zaman maliyetlerini ölçen bir çalışma değil, analitik bir çerçeve: geliştiricilerin denetime ne kadar zaman ayırdığını ya da bu sürecin elle çalışmaktan daha hızlı olup olmadığını ortaya koymuyor. arXiv sayfasında ön baskı inceleme aşamasında olarak işaretlendiğinden, bulguları geçici kabul etmek gerekir.

Uygulamada üç eylemi birbirinden ayırmak yararlı olur. Görevi tanımlama, amacı ve kısıtları belirler. İzleme, ajanın amaçtan sapıp sapmadığını fark etmeye yardımcı olur. İnceleme ise gereksinimleri, kodu ve testleri dikkate alarak sonucun kabul edilip edilemeyeceğini değerlendirmeyi sağlar. Bir aşamadaki başarı, sonrakinde de başarıyı garanti etmez: yama makul görünebilir ama yanlış sorunu çözebilir ya da kapsamlı biçimde yeniden çalışılması gerekebilir.

Topluluk deneyimi, istatistik değildir

r/LocalLLaMA'daki bir tartışmada bir katılımcı, yerel modeller ve ajanlarla ilgili deneyiminin hayal kırıklığı yarattığını yazdı: kendi ifadesine göre sonuçları düzeltmesi ve ajanlara talimatları hatırlatması gerekiyordu. Aynı başlıktaki diğer katılımcılar kendileri için daha yararlı bir iş akışı tarif etti: görevleri sınırlandırmak, aşamalı çalışmak ve kodu dikkatle incelemek. Bunlar, modeller arasında karşılaştırılabilir bir test veya ekiplerin üretkenliğine ilişkin bir ölçüm değil, bireysel kullanıcı gözlemleridir.

Bu farklı yorumlar, deneyimin göreve, modele, ortama ve çalışma biçimine bağlı olabileceğini gösteriyor. Ancak tek bir tartışmadan hangi uygulamaların ortalamada daha etkili olduğunu veya sorunların ne sıklıkta yaşandığını belirlemek mümkün değil. Başlık yerel modellerle ilgili; bu nedenle oradaki gözlemleri tüm ajan araçlarına doğrudan genellememek gerekir.

İnsan katılımı, tek başına devretmenin işe yaramadığı anlamına gelmez. Geliştirici görevi parçalara ayırabilir, değişiklikleri inceleyebilir ve gereksinimleri netleştirebilir; sonucun sorumluluğu yine kendisinde kalır. Ancak görevi tanımlamak, düzeltmeler ve inceleme için harcanan zaman hesaba katılmadan toplam iş yükünün azalıp azalmadığını söylemek mümkün değildir.

PR taslağı, kabul edilmiş PR demek değildir

GitHub'ın tarif ettiği iş akışında ajana bir issue atanabiliyor ve karşılığında bir pull request taslağı alınabiliyor. Taslağın oluşturulmasıyla kabul edilmesi arasında şu sorular yanıt bekliyor: Değişiklik gereksinimleri karşılıyor mu, uç durumlar dikkate alınmış mı, testler yeterli mi ve çözüm projenin mimarisine uyuyor mu?

Bu ölçütleri tek bir metriğe indirgemek mümkün değil. Oluşturulan değişikliklerin sayısı, kullanılabilir değişikliklerin sayısına eşit değildir; testlerin başarıyla geçilmesi de yamanın tüm önemli özelliklerini doğrulamayabilir. Görünüşte kaliteli bir sonuç bile onu hazırlamak ve incelemek için ne kadar çalışma gerektiğini göstermez.

Genel etkiyi değerlendirmek için tüm döngüyü hesaba katmak gerekir: görevi tanımlama, sonucu bekleme, inceleme, düzeltmeler ve kodun sonraki bakımı. Ele alınan kaynaklar böyle bütüncül bir karşılaştırma sunmuyor.

Neler çıkarılabilir?

Ön baskı, gözetimi ele almak için bir çerçeve öneriyor; GitHub ise ajana görev verilip hazırlanan PR'ın incelendiği bir iş akışını duyurdu. Reddit'teki tartışma, bazı kullanıcıların yerel modellerle çalışırken hem güçlüklerden hem de yararlı yöntemlerden söz ettiğini gösteriyor. Bu materyaller birlikte, devredilen kodun incelemesinin nasıl düzenleneceği sorusunu gündeme getiriyor; ancak net üretkenlik artışına yanıt vermiyor.

Bunlardan, geliştiricilerin genel olarak kod yazmaktan gözetim yapmaya geçtiği, ajanların her zaman ek iş çıkardığı veya sektörün üretkenliğini artırdığı sonucu çıkarılamaz. Bu tür çıkarımlar için farklı görevlerde ve ekiplerde zaman ile kaliteyi karşılaştıran ölçümler gerekir.

Ekiplerin uygulamada soracağı soru daha somut: Ajan hangi değişiklikleri kendi başına hazırlayabilir, birleştirmeden önce neler denetlenmeli ve sonucun başlangıçtaki görevi yerine getirmesinden kim sorumlu? Görevi devretmek bu mühendislik çalışmasını ortadan kaldırmaz; yalnızca nerede başladığını ve neye odaklandığını değiştirir.