Yapay Zeka Kod Asistanlarıyla Verimli Çalışmak: Pratik Bir Oyun Kitabı

Bir junior mühendis artık doksan saniyede, makul görünen dört yüz satır kod üretebiliyor. Tüm sorun tek bir cümlede işte bu. Yazılım ship etmenin önündeki kısıt hiçbir zaman yazma hızı olmadı; kısıt anlamaktı, muhakemeydi ve doğruluğun yavaş yavaş birikmesiydi. Yapay zeka asistanları, pek de önemli olmayan o tek darboğazı kaldırmakta olağanüstü iyi; diğer tüm darboğazları ise oldukları yerde bırakıyorlar, hatta dikkatsizseniz daha da kötüleştiriyorlar.

Konuştuğumuz ekiplerin çoğu bu araçları potansiyellerinin belki dörtte biri kadarıyla kullanıyor. Ya asistanı sihirli bir kâhin gibi görüp çıktısını doğrudan production’a yapıştırıyorlar ya da ona o kadar güvensizler ki şık bir otomatik tamamlama aracı gibi kullanıp gerçek kaldıracı kaçırıyorlar. İki kamp da masada devasa bir değer bırakıyor. Bu yazı, orta yol için bir saha rehberi: kabul edilen her öneriyle kod tabanınızı sessizce çürütmeden bu araçlardan nasıl gerçek iş çıkarılır.

Nerede yardımcı oluyorlar, nerede sessizce zarar veriyorlar

Değer önerisinin dürüst versiyonu, pazarlamanınkinden daha dar ama daha kullanışlı. Asistanlar, sıkıcı ama iyi tanımlanmış işlerde mükemmeller: ilk ikisine benzeyen üçüncü CRUD endpoint’ini yazmak, bir veri yapısını bir biçimden başka bir biçime çevirmek, saf bir fonksiyon için testlerin iskeletini kurmak, bir config parser bağlamak, hedefe karar verdikten sonra bir refactor’ın mekanik %80’ini yapmak. Nasıl yapacağınızı zaten bildiğiniz ama yazmak istemediğiniz şeylerde çok iyiler. Aşina olmadığınız ama iyi belgelenmiş bir framework’te çalışırken gerçek bir hızlandırıcılar; bir saatlik dokümantasyon kazısını birkaç dakikaya indiriyorlar.

Tehlike şu: kötü oldukları şeylerde de aynı akıcılıktalar. Model yanıldığında gözle görülür biçimde tedirginleşmiyor. Bir eşzamanlılık probleminize, sabah 2’de production erirken görmeyeceğiniz bir race condition’la birlikte kendinden emin, iyi biçimlendirilmiş, makul bir çözüm üretiyor. Var olması gereken ama olmayan bir API metodu uyduruyor. Güvenliğe yakın kodlar yazıyor (auth kontrolleri, girdi doğrulama, kripto kullanımı) ve bunlar ders kitabı gibi görünürken içlerinde ince, istismar edilebilir bir açık barındırıyorlar.

Kötü bir mühendisin hata biçimi yanlış görünen koddur. Bir yapay zeka asistanının hata biçimi doğru görünen koddur. İkincisi çok daha pahalıdır.

İşe yarayan zihinsel model şu: asistana, son derece hızlı, geniş okumalı, sisteminize dair hiçbir hafızası olmayan, oyunda derisi bulunmayan ve “emin değilim” demekte patolojik bir yetersizlik gösteren orta seviye bir mühendis gibi davranın. Bu çerçeve, ne zaman yaslanacağınızı ve ne zaman ellerinizi direksiyonda tutacağınızı tam olarak söyler.

Bağlam oyunun tamamıdır

4x alan ekiplerle 1.2x alan ekipler arasındaki en büyük tek fark prompt zekâsı değil. Bağlam. Model yalnızca önüne koyduğunuz şey üzerine akıl yürütebilir ve varsayılan kabulü (jenerik, internetin ortalaması bir kod) kod tabanınızın istediği şey neredeyse hiçbir zaman değildir.

Önemsiz olmayan herhangi bir şey istemeden önce, modele ilk gününde bir yeni işe alıma vereceğiniz şeylerin aynısını verin:

• Dokunacağı asıl dosyalar ve içine çağrı yapacağı dosyalar; sizin onlara dair açıklamanız değil.
• Taklit edilecek mevcut desen. “Hata yönetimini şu şekilde yapıyoruz; işte temsili bir modül.”
• Kodda olmayan kısıtlar: performans bütçeleri, standartlaştırdığınız kütüphane, geçen sprint denediğiniz ve işe yaramayan o şey.
• Elinizdeyse arayüz ve test. Başarısız olan bir test, bir makineye verebileceğiniz en net spesifikasyondur.

“User service’e caching ekle” gibi bir istek jenerik bir bulamaç verir. Aynı istek; service dosyası, mevcut Redis wrapper’ınız, başka yerlerde kullandığınız cache-key konvansiyonu ve key’lerin tenant kapsamında olması gerektiğine dair bir notla birlikte verildiğinde, gerçekten review edip merge edebileceğiniz bir şey verir. Bağlamı toparlarken yaptığınız iş ek yük değil; işin ta kendisi. Üstelik bu, görevi kendiniz için düzgünce spesifiye etmek için zaten yapmanız gereken aynı düşünme işidir.

Vibe’ları değil, arayüzleri ve testleri spesifiye edin

Geri dönen şeyin kalitesi, içeri giren şeyin kesinliğiyle sınırlıdır. “Bunu hızlandır” bir dilektir. İyi bir görev spesifikasyonu küçük bir sözleşme gibi okunur: işte fonksiyon imzası, işte girdiler ve biçimleri, işte doğru çıktının neye benzediği, işte önemli olan kenar durumlar, işte değiştirmemeniz gerekenler.

Aynı şeyi istemenin şu iki yolunu karşılaştırın. İlki:

Query param’lardan tarih aralığını parse eden bir fonksiyon yaz.

İkincisi:

Implement parseDateRange(params: URLSearchParams): { start: Date; end: Date } | Error

Rules:
- Reads "from" and "to" params, both ISO-8601 date strings.
- If either is missing, default to the last 30 days (end = now).
- If "from" is after "to", return an Error, don't throw.
- Reject ranges longer than 366 days with an Error.
- Pure function. No timezone library — assume UTC.

Here are three existing parsers in this file to match style: [paste]

İkinci versiyon, alışkanlık hâline geldiğinde topu topu birkaç tuş vuruşu fazlasıdır ve modelin aksi hâlde tahminle çözeceği belirsizliğin neredeyse tamamını ortadan kaldırır. Daha da iyisi: önce test senaryolarını yazıp onları teslim edin. Testler, doğrulama görevi de gören kesin bir spesifikasyondur. Görevi “testleri değiştirmeden bu test suite’ini geçir” şeklinde ifade edebildiğinizde, bulanık bir üretken problemi, modelin gerçekten iyi olduğu kapalı döngülü bir probleme çevirmiş olursunuz.

Review döngüsü ve neden her satırı okumanız gerektiği

İşte bükülmeyen kural: merge ettiğiniz her satırdan, onu kim veya ne yazdı olursa olsun siz sorumlusunuz. Commit’teki author alanı pekâlâ sizinki olabilir, çünkü pager kesinlikle sizin elinizde olacak.

Bu apaçık görünüyor ama düzenli olarak ihlal ediliyor, çünkü üretilmiş kodu review etmek bir meslektaşın PR’ını review etmekten farklı hissettiriyor. Bir meslektaşın kodu, düşünen bir insanın onu doğru bulduğuna dair örtük bir garanti taşır. Üretilmiş kod böyle bir garanti taşımaz ama o kadar akıcıdır ki bir garantinin hissini ödünç alır. Üstünkörü geçme içgüdüsünü bilinçli olarak bastırmanız gerekir. Onu, zeki bir stajyerin teslim baskısı altında yazdığı ve anlamadığı bir kısmı uydurmuş olabileceği bir kod gibi okuyun; çünkü işlevsel olarak durum tam da budur.

Döngüyü sıkı tutan pratik taktikler:

• Diff’leri küçük tutun. Bir seferde tek bir mantıksal değişiklik isteyin. 60 satırlık bir diff dikkatlice okunur; 600 satırlık bir diff üstünkörü geçilip onaylanır ki bug’lar tam da burada girer.
• Apaçık olmayan kısımları açıklatın. “Burada neden bir lock kullandın?” Ya bir şey öğrenirsiniz ya da model bunu körü körüne kopyaladığını ifşa eder. İkisi de işe yarar.
• Güvenmeden önce çalıştırın. Makul ve doğru farklı eksenlerdir. Terminal beraberliği bozar.
• Sınırlardaki özgüvene güvenmeyin. Null yönetimi, boş koleksiyonlar, off-by-one, timezone matematiği, integer overflow, harici bir çağrının başarısızlık yolu. Akıcı-ama-yanlış işte burada yaşar.

Çıktıyı dikkatlice review etmek onu kendiniz yazmaktan uzun sürecekse, bu gerçek bir sinyaldir; bazen doğru karar onu kendiniz yazmak ve araçla boğuşmayı bırakmaktır.

Zorlayıcı işlev olarak testler

Testler, yapay zeka iş akışının bir vibe olmaktan çıkıp mühendislik olmaya başladığı yerdir. Aynı anda üç rol üstlenirler: modele teslim ettiğiniz kesin bir spesifikasyon, kendinden emin-ama-yanlış çıktıyı yakalayan otomatik bir doğrulayıcı ve bir sonraki değişikliği istediğinizde modelin “yardımsever” bir şekilde dokunmaması gereken bir şeyi refactor etmesine karşı bir regresyon ağı.

Karşılığını veren disiplin şu: testleri modele önerdirin ama assertion’ların sahibi siz olun. Modeller, yapıları gereği geçen testler yazmaya bayılırlar; fonksiyonun ne döndürdüyse onu döndürdüğünü assert ederler ki bu hiçbir şeyi doğrulamaz. Testi, kod yanlış olsaydı gerçekten başarısız olup olmayacağı açısından okuyun. Başarısız olamayan bir test, hiç test olmamasından kötüdür çünkü sahte bir güven imal eder. Üretilmiş bir test fazla yeşil görünüyorsa, implementasyondan bir satır silin ve testin kırmızıya döndüğünü teyit edin. Dönmüyorsa, o test bir tiyatrodur.

Ne zaman kapatacağınızı bilmek

Senior muhakeme, aracı kullanmakta olduğu kadar onu reddetmekte de kendini gösterir. Şu durumlarda kapatma düğmesine uzanın:

• Eşzamanlılık, sıralama ve dağıtık durum. Race condition’lar, lock sıralaması, idempotency, exactly-once teslimat. Model, yaygın durumda doğru görünen koda desen eşlemesi yapar ve sizi ısıran o iç içe geçmeyi sessizce atlar. Bunlar üzerine kendiniz akıl yürütün.
• Güvenlik açısından kritik yollar. Authentication, authorization, session yönetimi, kripto, güvenilmeyen girdiyi parse eden her şey. Makul görünmek, burada kabul edebileceğiniz bir standart değil.
• Gerçekten yeni alanlar. Eğitim verisinin az içerdiği bir şey yapıyorsanız (yeni bir protokol, özel bir sayısal yöntem, alışılmadık bir donanım kısıtı) modelin kendinden emin ortalaması kendinden emin biçimde yanlıştır.
• İnce bir biçimde yanlış olmanın felaket olduğu ve tespitin zor olduğu kod. Para, tıp, bug’ın sessizce ship olup bir dava olarak yüzeye çıktığı her şey.

Bunların hiçbiri bu alanlarda “hiç kullanma” anlamına gelmiyor; yine de taslak çıkarabilir, açıklayabilir veya bir lastik ördek görevi görebilir. Anlamı şu: kabul ettiğiniz şeyin çıtası çok yükselir ve asistan author olmaktan çıkıp bir araştırma yardımcısına dönüşür.

Faaliyeti değil, kaldıracı ölçmek

Önemli olan metrik üretilen satır sayısı, gönderilen prompt sayısı veya kabul edilen öneri sayısı değildir. Bunlar faaliyeti ölçer ve faaliyet ucuzdur. Bir ekip tuş vuruşu çıktısını dörde katlayıp daha yavaş ship edebilir, çünkü darboğaz akışın aşağısına, review’a, debug’a ve ince kusurların temizliğine kaymıştır.

Yapay zeka var olmadan önce de önemsediğiniz şeyleri ölçün: fikirden merge-ve-deploy’a kadar geçen döngü süresi, kusurların kaçış oranı, review’dan rahatça geçen PR’ların oranına karşı geri sekenlerin oranı. Üretilmiş-kod PR’larınız daha fazla geri sekiyorsa veya incident oranınız tırmanıyorsa, yazma hızını yeniden işe çeviriyorsunuz demektir; verimlilik kılığına girmiş negatif kaldıraç. Gerçek kaldıraç şuna benzer: aynı küçük ekip, haftada daha fazla doğru yazılım ship eder ve review sıkıcı kalır. Review giderek daha korkutucu hâle geliyorsa, yanlış değişkeni optimize etmişsiniz demektir.

Bu sizin için ne anlama geliyor

Bu araçlarla kazanan ekipler en zekice prompt’lara sahip olanlar değil. Mühendislik standartlarını tam olduğu yerde tutan ve asistanı bu standartlara daha hızlı ulaşmak için kullananlar. Disiplin, hendeğin kendisidir.

Gerçekten kullanacağımız bir kontrol listesi:

• Üretmeden önce spesifiye edin. Arayüz, girdiler, kenar durumlar, kısıtlar, eşleşilecek bir desen. Spesifikasyonu yazamıyorsanız, istemeye hazır değilsiniz.
• Bağlamı öne yükleyin. Gerçek dosyalar, mevcut desenler, yazılmamış kısıtlar. Model, ona söylemediğiniz hiçbir şeyi bilmez.
• Spesifikasyon olarak testleri tercih edin. Sahibi olduğunuz, başarısız olan bir test, var olan en iyi prompt’tur.
• Her satırı, bir stajyer teslim baskısı altında yazmış gibi okuyun. Diff’leri gerçekten okuyacak kadar küçük tutun.
• Çalıştırın, sonra güvenin. Makul ve doğru farklı şeylerdir.
• Eşzamanlılık, güvenlik ve yeni alanlar için kapatın. Author, yardımcıya dönüşür.
• Tuş vuruşlarını değil, döngü süresini ve kusurları ölçün. Review giderek korkutucu hâle geliyorsa, durun.

Bu şekilde kullanıldığında, bir yapay zeka asistanı küçük bir senior ekibin elindeki en büyük kaldıraç artışlarından biridir; onu iyi kullanmayı bu yüzden umursuyoruz. Diğer şekilde kullanıldığında ise, ilerleme gibi görünen teknik borcu üretmek için son derece verimli bir makinedir. Hangisini elde edeceğinize araç karar vermez. Siz karar verirsiniz.