Asistan ne yapar, siz ne yaparsınız?
VS Code’un belgesi bu çalışma biçimini şöyle tanımlıyor: yapay zekâ ajanları yazılım geliştirme işlerini değişen düzeylerde özerklikle tamamlar. Düzeyi siz seçiyorsunuz. Belgedeki üç izin seviyesi elle onay, yardımlı ve tümüne izin. Programın ilk aylarında elle onayda kalıyoruz: asistan bir dosyayı değiştirmeden ya da bir komut çalıştırmadan önce soruyor.
Hangi asistanı kullanacağınız ikinci planda. Kuralları asistanın kendi ayar ekranına değil, deponun içindeki tek bir dosyaya yazıyoruz. Asistan değiştirdiğinizde sıfırdan başlamıyorsunuz; yeni araç aynı dosyayı okuyor.
İş bölümü net: asistan yazar, siz karar verir ve denetlersiniz. Bir sayfanın yayına girmesinin sorumluluğu asistana devredilemiyor.
AGENTS.md: asistanın okuduğu README
AGENTS.md kendi sitesinde şöyle tarif ediliyor: ajanlar için bir README; yapay zekâ kod ajanlarının projenizde çalışabilmesi için gereken bağlamı ve talimatları koyduğunuz, yeri belli bir dosya. Deponun köküne konuyor. Biçimi bugün Linux Foundation çatısı altındaki Agentic AI Foundation yürütüyor ve 60.000’den fazla açık kaynak projede kullanılıyor.
İlk sürümünüz kısa olacak. Projenin amacı bir cümle. Ardından geçen saatte elle yazdığınız kurallar: her sayfada tek h1; header, nav, main ve footer; görsellerde width, height ve alt; her sayfaya özgü title ve meta açıklama. Sonra yasaklar: dışarıdan betik ya da yazı tipi ekleme, yer tutucu metin bırakma, iletişim bilgisi uydurma.
Dosyanın bir sınırı var ve bilmeniz gerekiyor. Claude Code’un belgesi bunu açıkça yazıyor: bu dosyalar zorunlu yapılandırma değil, bağlamdır. Asistan kurala çoğu zaman uyar, her zaman değil. Aynı belge talimat ne kadar belirli ve kısa olursa uyumun o kadar tutarlı olduğunu da ekliyor. “Temiz kod yaz” bir kural değildir; “her görsele width ve height yaz” bir kuraldır.
Bu dosya programın sonuna kadar sizinle büyüyor. Her ay kritikte çıkan hatalar bir sonraki sürüme kural olarak giriyor: 2. ayda canonical ve robots.txt, 3. ayda kaynak gösterme, 4. ayda bot politikası.
İstem, plan, onay
İyi bir istem üç parçadan oluşuyor. Kapsam: hangi dosya, hangi sayfa. Kısıt: neye dokunulmayacak. Kabul ölçütü: işin bittiğini nereden anlayacağız. “İletişim sayfası yap” yerine şunu yazıyoruz: iletisim.html dosyasını oluştur; ana sayfadaki header ve footer’ı aynen kullan; adres ve telefonu benden iste, uydurma; sayfada tek h1 olsun.
Asistan işe başlamadan önce bir plan sunuyor. Planı okumadan onaylamıyoruz. Planda beklemediğiniz bir dosya adı görüyorsanız durdurup soruyorsunuz. Kabul ettiğiniz her adımdan sonra commit atıyorsunuz; bir sonraki adım işleri bozarsa dönecek bir yeriniz oluyor.
Neden denetliyoruz: çalışan kod güvenli kod değildir
Veracode’un 24 Mart 2026’da yayımladığı çalışma 150’den fazla dil modelini 80 kodlama göreviyle sınadı. Görevlerin yalnızca yüzde 55’inde güvenli kod çıktı. Dağılım daha da öğretici: SQL enjeksiyonunda başarı yüzde 82 iken siteler arası betik çalıştırma (XSS) testini geçenlerin oranı yüzde 15.
Çalışmanın asıl bulgusu zaman içindeki eğri. Modellerin sözdizimi doğruluğu yüzde 50’den yüzde 95’e çıkmış; güvenlik başarısı ise yüzde 45 ile 55 arasında yerinde saymış. Yani kod giderek daha doğru görünüyor, daha güvenli olmuyor. Dokuz maddelik kontrolün varlık nedeni bu fark.
Statik bir sitede en sık karşılaşacağınız risk daha basit: depoya giren bir anahtar. Üç kural uyguluyoruz. Anahtarlar .env dosyasında durur ve bu dosya .gitignore içindedir. Her commit’ten önce değişikliklere bakılır. Tarayıcıda çalışan koda hiçbir zaman anahtar yazılmaz. Deponuz herkese açıksa içine giren anahtar da herkese açıktır.
