Geçen ay bir pull request inceledim: dört yüz satır, iki saatte yazılmış, bütün testleri geçiyor. Etkileyici, değil mi? Tek sorun şuydu: hata yönetimi bizim kod tabanımızdaki desene hiç benzemiyordu ve aynı modülde artık üç farklı hata yönetim yaklaşımı yaşıyordu — üçü de "çalışıyor", üçü de birbirinden habersiz. Kodu yazan arkadaş asistanın önerisini olduğu gibi kabul etmişti, çünkü öneri gerçekten çalışıyordu.
Ekibimiz bir yıldır günlük işte yapay zeka kod asistanlarını kullanıyor; bu süre bir bilanço çıkarmak için yeterli. Net cümle şu: doğru kullanımda ciddi ve ölçülebilir hızlanma var; yanlış kullanımda ise sessizce, kimse fark etmeden biriken bir teknik borç. İkisi arasındaki çizgiyi kitaplardan değil, kendi yaralarımızdan öğrendik.
Hız gerçek — ama belli bölgelerde
Önce hakkını verelim. Kalıp kod dediğimiz bölgede kazanç tartışmasız: DTO'lar, CRUD katmanları, veri dönüşümleri, test iskeletleri. Bu tür işlerde yüzde kırk-altmış zaman kazancı bizim ölçümlerimizde gerçekçi bir aralık. Bir mobil projede yalnızca API istemci katmanının üretimini asistana bırakıp gözden geçirme turuyla ilerledik; elle yazsak üç gün sürecek iş bir günde bitti.
İkinci verimli bölge, az bilinen alanın keşfi. Yıllardır dokunmadığınız bir kütüphanenin doğru kullanımını asistana sormak, dokümantasyon ve forum taramaktan belirgin hızlı. Üçüncüsü — ve bana sorarsanız asistanların en verimli işi — var olan fonksiyona edge-case testleri yazdırmak. İnsan, kendi yazdığı kodun kör noktalarını test etmekte kötüdür; asistanın böyle bir bağlılığı yok. Boş liste, sıfır, negatif değer, Unicode sürprizleri... Asistanın önerdiği test senaryolarının birkaçı, bizim gözden kaçırdığımız gerçek hataları yakaladı.
Listeye bir bölge daha ekleyeyim: tek kullanımlık işler. Log dosyasını ayrıştıran betik, veri taşıma script'i, karmaşık bir regex, iki formatı birbirine çeviren dönüştürücü... Bu kodlar üretime girmez, bir kez çalışır ve çöpe gider; asistanın en rahat bırakılabileceği bölge burasıdır, çünkü uzun vadeli tutarlılık derdi yoktur. Ekipte artık kimse regex'i elle yazmıyor ve açıkçası kimse de özlemiyor.
Çalışan ama size ait olmayan kod
Şimdi madalyonun öbür yüzü. Asistan kodu çalışan ama projenize ait olmayan bir tarzda üretir. Sizin hata yönetim felsefenizi bilmez, mimari sınırlarınızı tanımaz, adlandırma geleneklerinizden habersizdir ve — en sinsisi — aynı problemi her seferinde farklı bir desenle çözer. Tek tek bakıldığında her öneri makuldür; toplamına altı ay sonra baktığınızda ortaya kimsenin bütününü savunamadığı, tutarlılığını yitirmiş bir kod tabanı çıkar.
Teknik borcun klasik hâlinden farkı, görünmezliği. Acele yazılmış kötü kod kendini belli eder; asistan kodu ise temiz görünür, derlenir, test geçer. Borç, desenlerin sessiz çeşitlenmesinde birikir ve faturası yeni geliştirici alıştırırken, büyük refactoring yaparken, üretim hatasını kovalarken kesilir.
Bir de ekip gelişimi boyutu var; bunu konuşan az. Deneyimli geliştirici, asistanın önerisindeki sorunu kokusundan alır — o koku alma yetisini yıllarca kendi hatalarını ayıklayarak edindi. Ya mesleğe asistanla başlayan arkadaş? Cevabı hazır alan, debug'ın o öğretici sancısını hiç yaşamayan bir öğrenme kısa devresi riski gerçek. Bizim tedbirimiz basit: junior arkadaşlar asistan önerisini kabul etmeden önce ne yaptığını kendi cümleleriyle review'da anlatıyor. Yavaşlatıyor mu? Biraz. Ama üç yıl sonra ekipte hâlâ mühendis istiyoruz, prompt operatörü değil.
Girişteki pull request'in hikâyesi tam olarak buydu.
Güvenlik: eğitim verisinden gelen eski alışkanlıklar
İkinci risk daha az konuşuluyor ama daha tehlikeli. Asistanlar, eğitim verilerindeki milyonlarca kod örneğinden öğreniyor ve o verinin içinde bol miktarda eski, güvensiz kalıp var. Sahada bizzat gördüklerimiz: parola için zayıf hash önerisi, doğrulaması eksik girdi işleme, sabit kodlanmış anahtar deseni. Asistan bunları kötü niyetle değil, istatistikle öneriyor — internette o kalıp çok yazılmış, o kadar.
Bu yüzden bizde katı bir sınır var: kimlik doğrulama, ödeme, kriptografi gibi güvenlik kritik kodlar asistan yardımıyla yazılabilir, ama satır satır insan doğrulamasından geçmeden hiçbir yere gidemez. "Testleri geçiyor" bu bölgede yeterli cümle değil; test, aklınıza gelen senaryoyu doğrular, saldırgan ise aklınıza gelmeyeni dener.
Gizlilik tarafını da atlamamak lazım: müşteri kodunu bir asistana açmak, o kodu üçüncü tarafın sistemine göndermek demektir. Hangi aracın hangi planında verinin eğitimde kullanılıp kullanılmadığı, nerede saklandığı, sözleşmede ne yazdığı — bunlar teknik değil ama bizim sorumluluğumuzda olan sorular. Biz her müşteri sözleşmesinde bu konuyu açıkça netleştiriyoruz ve araçları kurumsal, eğitime veri vermeyen planlarla kullanıyoruz. Bir kez sorulmadan öğrenilirse, kaybedilen şey kod değil güven oluyor.
Bir yılın damıttığı dört kural
Deneme yanılmayla vardığımız ekip anayasası dört maddeden ibaret ve ilk maddesi tartışmaya kapalı: asistan çıktısı da insan kodu gibi review'dan geçer, istisnasız. "Asistan yazdı, hızlıca merge edelim" cümlesi bizde toplantı konusu olur.
İkincisi az önce anlattığım güvenlik sınırı. Üçüncüsü, prompt'a proje bağlamı vermek: mimari kararlarımızı, adlandırma düzenimizi, hata yönetim desenimizi asistana baştan anlatıyoruz. Bağlam verilen asistanın çıktısı, verilmeyenle kıyaslanmayacak kadar "bizden" oluyor; on dakikalık hazırlık, saatlerce düzeltmeden ucuz. Dördüncüsü de bir tür turnusol: kodu ekleyen kişi "bu neden böyle yazıldı?" sorusuna cevap veremiyorsa, o kod merge edilmez. Anlamadığınız kodu kabul etmek, imzalamadan senet vermeye benzer — asistan çağında bu eski kural her zamankinden değerli.
Bu dört kuralla bir yılı kapattık: verim aldık, borç almadık. En azından bilançoda görünen bir borç yok; onu da her çeyrek, desen tutarlılığına bakan küçük bir iç denetimle kontrol ediyoruz.
Bir tavsiye de ölçüm üzerine: bu araçların getirisini hisle değil, elinizdeki mevcut metriklerle izleyin. Pull request'in açılıştan merge'e ortalama süresi, review'da dönen düzeltme turu sayısı, üretime sızan hata oranı — asistan öncesi ve sonrası bu üç eğriye bakmak, "verimlilik arttı mı?" sorusunu duygudan arındırıyor. Bizde ilk ikisi belirgin iyileşti; üçüncüsü sabit kaldı, ki dört kuralın amacı da zaten tam buydu: hızlanırken hata oranını sabit tutmak.
"Peki hangi aracı kullanalım?" sorusuna bilerek girmedim; çünkü yanlış soru o. Araçlar birkaç ayda bir el değiştiriyor, bugünün favorisi yarın sıradanlaşıyor. Kalıcı olan, ekibinizin bu araçlarla çalışma sözleşmesi — review disiplini, güvenlik sınırı, bağlam pratiği, anlama şartı. Sözleşme sağlamsa aracı değiştirmek bir haftalık alışma; sözleşme yoksa en iyi araç bile borç üretmeye devam eder.
Asistanları ekibinize sokmayı ya da soktunuz da dizginlemeyi düşünüyorsanız, deneyimimizi paylaşmaktan memnuniyet duyarız — bu araçlar kalıcı, mesele onlarla nasıl yaşanacağını ekipçe öğrenmekte.