Yapay zeka ile kod yazmak: neyi devrediyorum, neyi asla devretmiyorum

Yapay zeka kodlama asistanlarını her gün kullanıyorum. Bu yazıyı da iki uç görüşten bıktığım için yazıyorum. Bir tarafta “artık geliştiriciye gerek yok” diyenler, diğer tarafta “hepsi saçmalık, bir satırına güvenmem” diyenler. Benim deneyimim ikisinin arasında bir yerde ve bence daha ilginç bir yerde.

En iyi benzetme şu: yapay zeka asistanı, dünyadaki bütün dokümantasyonu okumuş ama senin projeni ilk kez gören, çok hızlı, hiç yorulmayan ve arada bir büyük bir özgüvenle uyduran bir ekip arkadaşı. Böyle birine hangi işi verirsin, hangisini vermezsin? Cevap aşağı yukarı aynı.

Kısa cevap: Tekrar eden, doğrulaması kolay ve kapsamı net işleri devrediyorum: şablon kod, test iskeleti, dönüştürme betikleri, eski kodu açıklama. Mimari kararları, güvenlik açısından kritik kodu, veritabanı üzerindeki geri dönüşsüz işlemleri ve son onayı devretmiyorum. Kuralım basit: anlamadığım kodu birleştirmiyorum.

Rahatça devrettiklerim

• Şablon kod: CRUD ekranları, form doğrulama kuralları, migration dosyaları, API istemcileri. Kalıbı belli, yanlışı kolay görülen işler.
• Test iskeleti: “Bu fonksiyon için sınır durumlarını da kapsayan testler yaz” isteği çoğu zaman iyi bir başlangıç verir. Testlerin gerçekten doğru şeyi test edip etmediğine yine ben bakarım.
• Tek seferlik betikler: CSV’yi temizleyip veritabanına aktaran bir betik, karmaşık bir düzenli ifade, bir awk satırı. Bir kez çalışıp atılacak koda harcanan zaman en çok burada kazanılıyor.
• Eski kodu okumak: Devraldığım, yorum satırı olmayan, 2000 satırlık bir PHP dosyasının ne yaptığını özetletmek. Burada model okuma hızımı artırıyor ama anlamayı benim yerime yapmıyor.
• Metin işleri: Dokümantasyon, commit mesajı taslakları, arayüz metinlerinin çevirisi. Bu site iki dilli ve İngilizce metinlerin ilk taslağında epey yardım aldım, son okuma yine bende.

Asla devretmediklerim

• Mimari ve veri modeli: Hangi tabloların olacağı, servislerin nasıl ayrılacağı, neyin önbelleğe alınacağı. Bu kararlar projenin iş kurallarını bilmeyi gerektiriyor ve yanlışının bedeli aylar sonra ödeniyor.
• Kimlik doğrulama, yetki ve ödeme kodu: Model buralarda da kod yazabilir ve çoğu zaman düzgün görünen kod yazar. Sorun da tam olarak bu, düzgün görünmesi. Bu kodu satır satır, sanki bir yabancının gönderdiği bir değişikliği inceler gibi okurum.
• Geri dönüşü olmayan komutlar: Üretim veritabanında DELETE, DROP, sunucuda rm -rf. Asistan önerebilir ama çalıştırma kararı ve tuşa basan parmak benim.
• Gizli bilgiler: .env dosyası, API anahtarları, müşteri verisi. Bunları sohbet penceresine yapıştırmam. Örnek veri gerekiyorsa sahte veri üretirim.

Karşılaştığım tuzaklar

1. Olmayan paketler ve fonksiyonlar

Model bazen var olmayan bir fonksiyonu ya da Composer, npm paketini büyük bir özgüvenle önerir. İşin kötü tarafı, saldırganlar modellerin sık uydurduğu paket adlarını gerçekten kaydedip içine zararlı kod koymaya başladı. Bu yöntemin artık bir adı bile var: “slopsquatting”. Önerilen her yeni bağımlılığı kurmadan önce paket sayfasına bakarım: kim yayınlamış, ne zamandır var, kaç kişi kullanıyor?

2. Eskimiş bilgi

Modelin bilgisi eğitildiği tarihte donar. Bir kütüphanenin yeni sürümünde değişmiş bir API’yi eski haliyle yazabilir. İstek yaparken sürümü açıkça söylerim (“Laravel 13, PHP 8.4”) ve emin olmadığım her şeyi resmi dokümantasyondan kontrol ederim.

3. Görünmeyen güvenlik açıkları

En sık gördüğüm iki örnek: metin birleştirerek kurulan SQL sorgusu ve eksik yetki kontrolü. İkincisi daha sinsi. /invoice/42 adresini açan kullanıcının o faturanın sahibi olup olmadığını kontrol etmeyen bir kod, çalışır, testleri geçer ve herkesin faturasını herkese gösterir. PHP güvenlik önlemleri yazısındaki listeyi, yapay zekanın yazdığı koda da aynen uyguluyorum.

4. Sessiz davranış değişikliği

“Şu fonksiyonu daha okunur yap” dediğinde model bazen bir sınır durumunu da “düzeltir”. Boş dizi eskiden null dönerken şimdi hata fırlatıyordur. Test yoksa bunu fark etmezsin, müşteri fark eder.

5. Fazla kod

İstenenden fazlasını yazma eğilimi var: kimsenin istemediği bir soyutlama katmanı, üç farklı yapılandırma seçeneği, gereksiz bir arayüz. Her fazladan satır, ileride okunacak, bakımı yapılacak ve hata çıkarabilecek bir satır. “Daha kısa ve daha sade yaz” demek çoğu zaman sonucu iyileştiriyor.

Çalışma düzenim

1. Küçük parçalar: “Fatura modülünü yaz” yerine “şu tabloya şu alanları ekleyen migration’ı yaz”. Küçük istek, kolay inceleme demek.
2. Bağlam ver: Kullandığım sürümler, klasör yapısı, isimlendirme kuralları. Birçok araç, projeye özel kuralları bir dosyada tutmaya izin veriyor. O dosyaya yazdığım her kural, aynı hatayı yüzüncü kez düzeltmekten kurtarıyor.
3. Önce plan: Büyük bir değişiklikte önce yaklaşımı anlatmasını istiyorum, kodu sonra. Yanlış yolu erken fark etmek, yanlış kodu sonradan düzeltmekten çok daha ucuz.
4. Testler çit gibidir: Testleri olan bir projede asistan çok daha güvenli çalışır, çünkü neyi bozduğu hemen görünür.
5. Farkı satır satır oku: Bir meslektaşın isteğini onaylar gibi. Anlamadığım satır varsa ya sorarım ya da atarım.
6. Küçük commit: Her adım ayrı bir commit. Bir şey ters giderse geri almak kolay olsun.

Peki gerçekten hızlandırıyor mu?

Evet, ama eşit olarak değil. Sıkıcı işleri çok hızlandırıyor, zor işleri pek değil. Zor iş hâlâ problemi doğru anlamak, doğru soruyu sormak ve doğru kararı vermek. Asistan bu kararların sonucunu daha hızlı koda dökmeme yardım ediyor, kararı vermiyor.

Müşteri açısından bunun anlamı şu: rutin kısımlar daha hızlı teslim edilebiliyor ama kodun sorumluluğu hâlâ onu teslim eden geliştiricide. “Bunu yapay zeka yazdı” bir mazeret değil. Teslim ettiğim her satırın arkasında ben duruyorum.

Yapay zeka tarafında bir başka konuyu da merak ediyorsan: yapay zeka yanıtlarında kaynak gösterilmek için içerik nasıl yazılır?