Yapay zeka ile kod yazma: review odaklı iş akışı rehberi

Yapay zeka ile kod yazma sürecinde en sık görülen hata şudur: bir ticket açarsınız, açıklamayı sohbet penceresine yapıştırırsınız ve 200 satır makul görünen kod geri gelir. Derlenir, testler de geçer. İki gün sonra bir reviewer, kodun neden sizin retry sarmalayıcınızı yok saydığını sorar ve ekipte kimse cevap veremez. Sorun üretim adımında değil, onun etrafındaki her şeyde.

Burada yeni mühendislere verdiğim iş akışını anlatıyorum. Model, reposunuzu hiç görmemiş hızlı ve özgüvenli bir junior gibi ele alınır. Akış, yazma süresine değil, review süresine göre kurulmuştur.

Yapay zeka gerçekten kodlamayı hızlandırır mı?

Bazen hızlandırır, ama cevap göreve bağlı. Stack Overflow 2025 Geliştirici Anketi, katılımcıların yüzde 84'ünün yapay zeka araçlarını kullandığını ya da kullanmayı planladığını, buna karşın yalnızca yüzde 33'ünün çıktıya bir ölçüde güvendiğini gösteriyor. En büyük şikâyet, yüzde 66 ile kodun "neredeyse doğru, ama tam değil" olmasıdır. Ayrıca yüzde 45.2 oranında geliştirici, yapay zeka kodunda hata ayıklamanın beklenenden uzun sürdüğünü söylüyor.

Kontrollü veriler daha az parlak. 2025'te METR tarafından yayımlanan bir çalışmada 16 deneyimli açık kaynak geliştirici, iyi bildikleri reposlardan 246 gerçek issue üzerinde çalıştı. Yapay zekaya izin verildiğinde işi yaklaşık yüzde 19 daha yavaş bitirdiler, oysa kendilerini yaklaşık yüzde 20 daha hızlı hissediyorlardı. METR bundan sonra daha yeni veriler yayımladı. Bu yüzden bu rakamı 2025 başındaki araçların bir anlık görüntüsü olarak okuyun, nihai bir hüküm olarak değil.

Buradaki ders "yapay zeka yavaştır" demek değil. Hızın hissi güvenilmez bir ölçüdür. Ölçümü, ilk taslağın ne kadar çabuk çıktığıyla değil, ticket'tan birleştirilmiş PR'a kadar geçen dakikayla yapın.

Prompt yazmadan önce neyi yazmalısınız?

Kendi cümlelerinizle, on satırdan kısa bir plan. Bunu atlarsanız model boşlukları kendi tahminleriyle doldurur ve bu tahminler tanım gereği genel olur.

Benim şablonum kısadır:

1. Davranış değişikliği, tek cümlede.

2. Dokunmayı beklediğiniz dosyalar, emin olmasanız bile.

3. Yeni kodun yeniden kullanması gereken mevcut fonksiyon ya da kalıp.

4. Yapmaması gereken bir şey (yeni bağımlılık yok, şema değişikliği yok).

5. Çalıştığını nasıl anlayacaksınız: bir test, bir curl isteği, bir ekran görüntüsü.

İnsanların atladığı nokta üçüncü maddedir ve "neredeyse doğru" kodun çoğu buradan gelir. Model, withRetry yardımcınızın var olduğunu siz adını vermedikçe ya da okuyabileceği bir yerde değilse bilmez.

Bu beş maddeyi her yeni ticket için doldurmak yaklaşık iki dakika sürer. Bu iki dakika, modelin yanlış dosyada yanlış bir yardımcı yazdığını sonradan düzeltmenin maliyetiyle kıyaslanınca çok küçüktür.

"Tüm uygulamayı yap" tipi promptu atlayın. Hem yeni başlayanlar hem kıdemliler bundan aynı sonucu alır: kimsenin anlamadığı büyük bir diff ve yarım kalmış bir proje.

Pratikte iyi bir prompt nasıl görünür?

Gerçek bir işi alın: webhook gönderici, alıcı zaman aşımına uğradığında olayları düşürüyor. Zayıf bir prompt "webhook güvenilirliğini düzelt" der. Kullanılabilir olan ise bir ticket gibi okunur:

src/webhooks/sender.ts içindeki sendWebhook() fonksiyonuna üstel geri çekilmeli (exponential backoff) retry ekle.
lib/http.ts içindeki withRetry() fonksiyonunu yeniden kullan. En fazla 4 deneme, jitter açık.
Public imzayı değiştirme, bağımlılık ekleme.
İki kez başarısız olup sonra başarılı olan bir alıcı için bir vitest senaryosu ekle.

Bu prompt dosyayı, yeniden kullanılacak yardımcıyı, bir limiti ve bir kontrolü adlandırır. Sonuç, bir oturumda okunabilecek 30 satır civarında bir diff olur. Diff 150 satıra çıkarsa model dağılmış demektir. Düzeltmeye çalışmak yerine reddedin.

Burada iki küçük numara işe yarar. Önce plan isteyin ve dosyalara dokunulmadan önce okuyun: yanlış bir plan otuz saniyeye, yanlış bir diff on dakikaya mal olur. Cevap yanlış olduğunda tartışmak yerine ihlal edilen kısıtı yeniden yazın. "Yeni bağımlılık eklediniz, kural bağımlılık yok" cümlesi, bir paragraf açıklamadan daha iyi işler.

Hangi iş için hangi araç uygun?

Üç biçim var ve bunları karıştırmak ikinci en sık hata.

Satır içi tamamlama yazarken bir sonraki satırları tahmin eder. Kalıbın ekranda zaten göründüğü boilerplate ve testlerde iyidir. Editör içi sohbet, seçili kod hakkında sorulara cevap verir ve değişiklikleri parça parça kabul etmenizi sağlayan düzenlemeler önerir. Ajanlar bir görevi alır, dosyaları okur, komut çalıştırır ve size bir branch ile geri döner.

Seçimi, bir şeyi ucuzca doğrulayıp doğrulayamayacağınıza göre yapın. İki saniyede okuyabileceğiniz bir tamamlama düşük risklidir. 14 dosyaya dokunan bir ajan çalıştırması yüksek ödül ama yüksek review maliyeti demektir.

Cursor, editör öncelikli seçenektir: güçlü Tab tamamlaması ve paralel ajan oturumları olan, VS Code'un bir fork'u. Gün boyu editörde çalışıyorsanız değer. Ekibiniz JetBrains'te standartlaşmışsa ve geçmeyecekse atlayın.

GitHub Copilot, zaten GitHub kullanan ekipler için sürtünmesi düşük bir seçenek. PR'lar, issue'lar ve review tek yerde durur. Faturalamaya dikkat edin: Haziran 2026'da kullanıma dayalı AI Credits modeline geçti, bu yüzden yoğun ajan kullanımı koltuk fiyatının gösterdiğinden daha pahalıya gelir.

Claude Code terminal odaklı ve ajan tabanlıdır. Bir refactor ya da hata avını devredersiniz, sonra sonucu review edersiniz. Satır içi otomatik tamamlaması yoktur ve yalnızca Claude modellerini çalıştırır. Görev bazında devretmek istiyorsanız bu makul bir takas.

Aider, betiklenebilir ve git odaklı seçenektir. Her değişikliği bir commit mesajıyla otomatik commit eder, dolayısıyla geri almak git revert kadar kolaydır. Yalnızca model token'ları için ödersiniz, bu da maliyet üzerinde kontrol isteyenlere uygundur.

Model reposunu yok saymasın diye ne yapmalısınız?

Bağlamı bilerek verin. Kötü çıktıların çoğu, modelin ilgili dosyayı hiç görmemesinden kaynaklanır.

Üç alışkanlık yardımcı olur. Birincisi, tüm dizini değil, kalıbı tanımlayan iki üç dosyayı ekleyin. İkincisi, hatayı tarif etmek yerine başarısız testi ya da hata çıktısını olduğu gibi yapıştırın. Üçüncüsü, repoda kısa bir kurallar dosyası tutun: isimlendirme, hata yönetimi, yasaklı kütüphaneler. Çoğu ajan aracı bunu her çalıştırmada okur.

# AI-RULES.md
- Hatalar: services/ içinde throw değil, Result döndür
- HTTP çağrıları lib/http.ts üzerinden geçer (retry ve tracing var)
- PR açıklamasında not olmadan yeni bağımlılık yok
- Testler: vitest, *.test.ts dosyaları yanında

Bu dört satır, review yorumlarının şaşırtıcı bir kısmını ortadan kaldırır. İnsanlara da yardımcı olur. Dosya kısa tutulmalıdır: birkaç satırı geçen kurallar modelin dikkatini dağıtır ve hiçbiri okunmaz hale gelir. Her kuralın bir hatadan doğmuş olması da iyi bir işarettir, çünkü yalnızca gerçekten yaşanmış sorunlar yazılır.

Henüz tanımadığınız bir repoda değişiklik istemeden önce soru sorun. "Oturum süresi nerede zorlanıyor ve bunu kim çağırıyor?" diye sormak, "refresh token ekle" demekten daha iyi bir ilk prompttur. Cevabı okuyun, cevabın gösterdiği iki dosyayı açın ve ancak ondan sonra neyi değiştireceğinize karar verin. Bu, zaten yaptığınız grep, blame ve birine sorma döngüsünün aynısıdır, sadece daha hızlı.

Yapay zekanın yazdığı kodu nasıl review edersiniz?

Bir meslektaşınınkinden daha yavaş. Meslektaşınızın kod tabanınızla ilgili bir geçmişi vardır. Modelin yoktur.

Kontrol listem sırayla şöyle:

• Okumadan önce çalıştırın. Kendi yazdığınız geçen bir test, kendinden emin bir açıklamadan daha değerlidir.

• Import'ları okuyun. Uydurulmuş paketler ve tanıdık olmayan yardımcılar ilk orada görünür.

• Eksik olanlara bakın. Hata yolları, null kontrolleri, temizlik. Modeller mutlu yolu iyi yazar.

• Diff boyutuna bakın. 10 satırlık bir düzeltme istediyseniz ve 120 satır geldiyse, istemediğiniz bir şey yeniden yazılmış demektir.

• Açıklayamadığınız satırı silin. Review'da savunamadığınız bir satır birleşmez.

Commit'i küçük, mesajı dürüst tutun. "Webhook gönderici için retry eklendi (yapay zeka destekli, testler eklendi)" yeterlidir. Bunu gizlemek kimseye yardımcı olmaz ve sonraki hata ayıklamayı zorlaştırır.

Yapay zekaya neyi asla bırakmamalısınız?

Yanlış olmanın sessiz ve pahalı olduğu her şeyi. Kimlik doğrulama mantığı, ödeme akışları, veri migration'ları ve yetki kontrolleri, "neredeyse doğru" olanın testleri geçip üretimde patladığı yerlerdir.

Orada yine kullanabilirsiniz, ama farklı bir modda: kod yazması yerine kodunuzu review etmesini ve riskleri listelemesini isteyin. Beş olası sorunun listesini okumak üç dakikaya mal olur. Üretilmiş bir migration'ı okumak ise o migration'a güvenip güvenmeyeceğinizden şüphe ederek geçireceğiniz bir öğleden sonraya mal olur.

Öğreniyorsanız ikinci bir istisna var. Önce ilk sürümü kendiniz yazın, sonra modelden eleştirmesini isteyin. Üretilen sürümü her zaman kabul eden bir junior, programlamayı değil prompt yazmayı öğrenir ve bu açık ilk kesintide ortaya çıkar.

Ekip için bu nasıl değişir ve ilk hafta nasıl planlanır?

Bireyler ile ekipler arasındaki fark review yüküdür. Ajan kullanan tek bir geliştirici, reviewer'ların okuyabileceğinden fazla PR açabilir. Başta üç konuda anlaşın:

1. Boyut sınırı. Birkaç yüz satırı geçen PR'lar, kim ya da ne yazmış olursa olsun bölünür.

2. Açıklama normu. Bir değişikliğin yapay zeka destekli olduğunu belirtin ki reviewer'lar dikkatini buna göre ayarlasın.

3. Ortak kurallar dosyası. Konvansiyonlar için tek bir doğruluk kaynağı, beş ayrı kişisel prompttan iyidir.

Onboarding için gördüğüm en iyi kullanım, soruya dayalı okumadır. Yeni işe başlayanlar asistana şeylerin nerede olduğunu sorar, sonra kodda doğrular. Bu, bakımını yapamayacakları kodu eline vermeden "bu kimin?" sorularıyla geçen ilk haftayı kısaltır.

Kopyalayabileceğiniz bir ilk hafta planı şöyle olabilir. Birinci gün, yalnızca testler ve boilerplate için satır içi tamamlama kullanın. İkinci gün, her gün sohbete üç kod tabanı sorusu sorun ve her cevabı doğrulayın. Üçüncü gün, sohbetin görev başına bir küçük düzenleme önermesine izin verin ve her parçayı okuyun. Dördüncü gün, düşük riskli bir işte, örneğin bir config anahtarını dosyalar arasında yeniden adlandırmada, bir branch üzerinde bir ajan deneyin. Beşinci gün, review'da sizi rahatsız eden şeylerden kendi kurallar dosyanızı yazın.

Hafta boyunca bir sayıyı takip edin: ticket'a başlamakla birleştirilmiş PR arasındaki dakika, review düzeltmeleri dahil. Bu sayı düşmediyse, aracın işinize nerede uymadığını öğrenmişsiniz demektir ve bu da bir sonuçtur.

Yapay zekadan en hızlı ve dürüst kazancı üretimde değil, anlamada gördüm: tanımadığınız bir modülü saatler yerine on dakikada kavramak. Bu yaklaşım, kıdemli geliştiricilerin zamanını tekrar eden sorulara değil review'a ayırmasını sağlar. Ekibin her üyesi de aynı kuralları aynı dosyadan okuduğu için tutarsızlık azalır. Kodu yazmak işin hiçbir zaman yavaş kısmı değildi. Yavaş olan okumak, karar vermek ve doğrulamaktı. Aracı bunlara yöneltin, birleştirme düğmesindeki yargıyı kendiniz tutun. Gerisi kendiliğinden gelir.