Tessl: Kodlama ajanını yalnızca kendi dosyalarınızla sınırlamanın dört yolu

Kodlama ajanlarıyla yazılım geliştirme üzerine çalışan Tessl’in blogunda 12 Ekim 2026’da yayımlanan bir yazıda, Parento’da kıdemli yazılım mühendisi ve “Harness Engineering” çalışmasının yazarı Ian Johnson, bir kodlama ajanını yalnızca depoda size ait dosyalarla nasıl sınırlayabileceğinizi anlatıyor. Johnson’ın ana tezi şu: Ajanı bağlayan her kısıt, sizin sahip olduğunuz bir dosyadır; asıl soru hangilerini yazma zahmetine girdiğinizdir.

Deney: Kural seti olmadan bir görev

Johnson, üç farklı dönemden kod barındıran gerçekçi bir depoda bir ajana tek bir görev verdi ve hiçbir kural seti (charter) sunmadı. Depoda doğru çalışan 2026 tarihli bir alan katmanı vardı, ancak 2023’ten kalma dev bir “her şeyi yapan” dosya ve kimsenin dokunmaması gereken donmuş bir 2021 modülü bunu sayıca bastırıyordu. Ajan doğru koda hiç bakmadı: Zar atışı için tohumsuz random.randint kullandı, var olan bir yardımcı fonksiyonla bir günlük kaydını yeniden yazdı ve donmuş modüle iki kez müdahale etti. Sonuç, sekiz kontrolden yalnızca biriydi. Johnson’a göre depoda bozuk bir şey yoktu; ajan önündeki kodu kopyaladı ve onu durduracak her şey henüz yazılmamış bir dosyaydı.

Dört kaldıraç

Yazara göre CLAUDE.md yazmak iyi bir tavsiye ama dört kaldıraçtan yalnızca biri:

• Talimat: CLAUDE.md; deponun ne olduğunu şimdiki zamanla anlatır.
• Kısıt: .claude/rules/; yola göre kapsamlandırılmış kurallar, her biri kendisine neden olan olayın tarihini taşır.
• Yetenek: .claude/commands/, .claude/skills/, .claude/agents/, .claude/settings.json ve .mcp.json; ajanın neye uzanabileceğini ve neyi çalıştırmasına izin verildiğini belirler.
• Denetim: .claude/hooks/; ajanı reddedebilen tek katman.

Johnson, talimat ve kuralların okunduğunu ve okunan her şeyle tartışılabileceğini, ajanın çevresindeki kodun çeliştiği bir kuraldan kendini ikna ederek vazgeçebileceğini söylüyor. Hook ise okunmuyor; tur içinde çalışan ve ret döndüren bir koşul. Yazıda kırk satırlık bir Python betiğinin hem yazmayı durduran bir PreToolUse hook’u hem de CI’ın çalıştırdığı make gate olarak, mantık tekrarı olmadan iki noktada kullanıldığı anlatılıyor. Yazar, kuralların yalnızca kodla çeliştiği yerde yazılması gerektiğini; kod tabanının zaten uyduğu bir kuralın hiçbir şeyi kısıtlamadığını vurguluyor.

Sonuçlar ve sınırlar

Aynı görevin üç çalıştırmasında kural setsiz çalıştırma 3 dosyayı değiştirip 49 satır ekledi ve 8 kontrolden 1’ini geçti; kural setli çalıştırma 3 dosyayı değiştirip 102 satır ekledi ve 8’in 8’ini geçti. Johnson, daha büyük farkın daha iyi sonuç olduğunu ve değiştirilen satır sayısını optimize etmeye çalışanların bunu hatırlaması gerektiğini not ediyor. Ancak dokuzuncu kontrol olan erişim denetiminin bu özellik için doğru olup olmadığını hiçbir betik karara bağlayamadı. Sekiz kontrolü de geçen çalıştırmayı inceleyen bir alt ajan, aralarında bir yetki hatası da bulunan üç gerçek kusur buldu. Yazara göre “yeşil bir puan kartı doğru bir değişiklik değildir”; mekanik olarak tespit edilemeyen bu boşluk, inceleme dikkatinin gitmesi gereken yerdir.

Johnson, sonucun kendi seçtiği kurallarla tek bir depoda ve tek bir görevde yapılan bir gösterim olduğunu, oranların başka depolarda farklı olacağını belirtiyor. Önerisi: Önce kural seti olmadan bir görevi çalıştırıp önceden yazılmış kontrollerle puanlamak, ardından kaldıraçları tek tek ekleyerek hangi kaldıracın hangi kontrolü değiştirdiğini kaydetmek.

Kaynak: Tessl Blog: How to constrain a coding agent using only files you own