Geçen ay İstanbul’da küçük bir ürün ekibinin yanında otururken aynı sahneyi bir kez daha yaşadım. Yapay zekâ, beş dakikada tertemiz görünen bir pull request hazırlamıştı. Dışarıdan bakınca pırıl pırıldı. Ama içine girince tablo değişti — isimlendirmeler tutarsızdı, mimari tercih projenin ruhuyla pek uyuşmuyordu ve en kötüsü, kimsenin ilk bakışta fark etmediği ufak bir güvenlik açığı vardı. Peki bunu neden söylüyorum? Hem de ciddi bir şey değil diyebilirdiniz, ama işte tam da o “ciddi değil” denen yerlerden başlıyor her şey.
AI ile kod yazmak artık “gelecek” değil. Günlük işin kendisi. Bunu inkâr etmek komik olur zaten. Ama hız kazanırken başka bir şey kaybediyoruz: bağlam. Kod çalışıyor olabilir, evet… fakat ekip ne yapıyor, bu servis neden böyle ayrılmış, yarın büyüyünce nereye toslayacak — bunları model bilmiyor. 2024 yazında Ankara’daki bir danışmanlık projesinde buna çok benzer bir durum yaşamıştım; modelin önerdiği çözüm teknik olarak gayet düzgündü,. Ekipteki iki yıllık refactor planını tek hamlede çöpe atıyordu. O gün şunu düşündüm: “Çalışan kod” ile “yaşayan kod” aslında aynı şey değil. Hiç değil.
Hız Var, Peki Kontrol Nerede?
AI destekli geliştirme araçları baya iş görüyor, bunu kabul etmek lazım (en azından benim deneyimim böyle). Tekrar eden işleri halletmekte fena sayılmazlar: boilerplate üretimi, test iskeleti kurma, basit endpoint’ler… Bunlarda ciddi zaman kazandırıyorlar, gerçekten. Ama PR aşamasına gelince iş değişiyor. Çünkü pull request sadece kod yığını değil — ekip içi bir anlaşma metni gibi bir şey bu (buna dikkat edin). Orada sadece “ne yazıldı” değil, “neden böyle yazıldı” da önemli.
Bir dakika — bununla bitmedi.
İşin aslı şu ki birçok takım AI çıktısını neredeyse doğrudan merge etmeye başladı. Açık konuşayım, bu biraz tembellik değilse bile alışkanlık gevşemesi. Bir süre sonra göz şuna alışıyor: biçim — en azından ben öyle düşünüyorum — düzgünse içerik de iyidir sanılıyor. Halbuki AI bazen çok düzgün paketlenmiş ama içi boş kutular verebiliyor.
Vallahi, Geçen sene Berlin’de çalışan bir arkadaşımın ekibinde de gördüm bunu. Üç kişilik startup, teslim tarihi sıkışıktı, herkes “nasıl olsa test geçiyor” diyordu. Sonra production’da aynı endpoint’in farklı veri tiplerinde saçmaladığını yakaladılar. Sorun büyük değildi belki — ama düzeltme süresi uzadı, çünkü kimse o PR’yi insan gözüyle didik didik etmemişti. Bir de o süre zarfında müşteri şikâyeti geldi. Neyse.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Neden “Çalışıyor” Demek Yetmiyor?
Bir kod parçasının çalışması iyi haber tabii. Ama tek başına yeterli değil. Yazılım geliştirme mutfağında en pahalı hata genelde ilk gün ortaya çıkmıyor — üç hafta sonra başka biri o koda dokununca patlıyor. AI bazen gereksiz soyutlama katmanları ekliyor, bazen de var olan yardımcı fonksiyon dururken yeni bir mini sistem kuruyor. Kağıt üstünde şık duruyor, pratikte ise biraz fazla süslü, biraz fazla dolaylı.
Bilmem anlatabiliyor muyum, Dur bir saniye, şunu da ekleyeyim (bizzat test ettim). AI’ın en sevmediğim tarafı bazen aşırı özgüvenli görünmesi. Sanki çözümü kesin bulmuş gibi davranıyor ama aslında projenin kural setini hiç umursamamış oluyor. Geçen mart İzmir’de yaptığımız kısa bir code review oturumunda bunu net gördüm; modelin önerdiği import düzeni bile takımın lint kurallarıyla çatışıyordu. Küçük detay gibi duruyor. Ama toplandığında can sıkıcı bir hal alıyor, inanın.
Bence, Böyle durumlarda sorun sadece kalite düşüşü olmuyor; teknik borç da sessizce büyüyor. Bir noktadan sonra herkes birbirinin bıraktığı yamaları okumaya çalışıyor, inceleme süresi uzuyor. Reviewer burnout dediğimiz şey tam burada başlıyor işte. Kimse kötü niyetli değil ama sistem kötü tasarlanmış oluyor. Ve kötü tasarlanmış sistem, iyi niyetli insanları da bir süre sonra tüketiyor (yanlış duymadınız)
Ve işler burada ilginçleşiyor. Artemis II Dönüşü: NASA’nın Deniz İnişi Nasıl İzlenir? yazımızda bu konuya da değinmiştik.
AI’ın En Çok Tökezlediği Yerler
- Bağlam eksikliği: Projenin tarihini ve geçmiş kararlarını bilmiyor.
- Aşırı genelleme: Her yerde işe yarar sandığı çözümü dayatabiliyor.
- Stil uyumsuzluğu: Takımın diline ve standartlarına uymayabiliyor. (bence en önemlisi)
- Mimari körlük: Kısa vadeli doğruyu seçip uzun vadeyi bozabiliyor.
- Sessiz riskler: Güvenlik ya da bakım maliyeti hemen görünmüyor. — ciddi fark yaratıyor
Kod İncelemesi İçin Basit Ama Sert Kurallar
Bir şey dikkatimi çekti: Lafı gevelemeden söyleyeyim: çözüm AI kullanmamak değil, onu denetimsiz bırakmamak. İyi review guideline’lar burada hayat kurtarıyor. Takım içinde net birkaç kural olduğunda hem hız korunuyor hem de çöp PR sayısı azalıyor. Ciddi fark var.
Aşağıdaki yaklaşım bana baya mantıklı geliyor; tartışmayı kişiselleştirmiyor, ölçü veriyor:
| Kontrol Noktası | Neye Bakılır? | Neden Önemli? |
|---|---|---|
| Bagalam uyumu | Kod mevcut mimariye uyuyor mu? | Sonradan refactor yükünü azaltir |
| Okunabilirlik | Isimler ve yapı anlasılır mı? | Ekip içi bakim kolaylaşır |
| Test kapsami | Kritik senaryolar var mı? | Sessiz hatalari yakalar |
PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Tabi burada mesele yalnızca kontrol listesi değil; kültür meselesi de var. Eğer ekipte “PR hızlı kapansın yeter” baskısı varsa, en iyi guideline bile kağıt üstünde kalır. Bu yüzden ben her zaman küçük takımlara önce üç soru soruyorum: Bu kod niye var? Başka nasıl yapılabilirdi? Yarın biri bunu okuyunca ne hisseder? Basit sorular. Ama etkisi büyük.
Küçük Startup ile Kurumsal Ekip Arasında Fark Ne?
AI çıktılarını doğrudan merge etmek hız kazandırır gibi görünür; gerçekte çoğu zaman inceleme maliyetini sonraya iter.
AI çıktılarını doğrudan merge etmek hız kazandırır gibi görünür; gerçekte çoğu zaman inceleme maliyetini sonraya iter.
Küçük startup’ta hedef genelde hayatta kalmak oluyor; dolayısıyla otomasyon cazip geliyor ve anlaşılır da bir tarafı var bunun (ciddiyim) — valla güzel iş çıkarmışlar —. Ama kurumsal tarafta durum farklı. Orada tek bir kötü PR, onlarca serviste zincirleme etki yaratabilir. Enterprise seviyede review guideline’lar daha sert olmak zorunda, yoksa maliyet sessizce kabarıyor. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Bi saniye — Küçük ekiplerde hafif kurallar yetebilir: zorunlu test, minimum iki göz, kilit dosyalarda ekstra onay. Kurumsalda ise branch policy, statik analiz, güvenlik taraması ve mimari onay mekanizmaları birlikte çalışmalı. Az önce küçük ekip için “hafif kurallar yeter” dedim ama aslında şunu da eklemek lazım: büyük organizasyonda asıl problem hız değil, koordinasyon eksikliği oluyor. AI o boşluğu doldurmuyor; bazen tam tersine büyütüyor.
Peki Review Guideline Nasıl Yazılır?
Burada sihir yok. İyi guideline kısa olur, net olur, yorum götürmez (yanlış duymadınız). Mesela “kod temiz olmalı” demek yerine “fonksiyon başına maksimum şu kadar sorumluluk”, “yeni dependency eklenmeden önce gerekçe yaz”, “public API değişiyorsa migration notu bırak” gibi somut maddeler lazım. Yoksa herkes kendi kafasına göre yorum yapar, sonra toplantıda laf dönüp dolaşıp aynı yere gelir.
Dur aslında — önce şunu söyleyeyim: guideline yazarken hedefiniz mükemmel metin üretmek olmamalı. Uygulanan metin üretmek olmalı. İkisi çok farklı şeyler.
# Basit review checklist örneği
- Kod mevcut mimariye uyuyor mu?
- Yeni bağımlılık gerçekten gerekli mi?
- Testler kritik akışları kapsıyor mu?
- Güvenlik / gizlilik riski var mı?
- İsimlendirme takım standardıyla uyumlu mu?
- Bu değişiklik ileride refactor gerektirir mi?
Açıkçası, Böyle bir listeyi ilk kez Şubat 2024’te Eskişehir’deki bir SaaS projesinde kullandım. Öncesinde review’ler uzun sürüyordu çünkü herkes kendi önceliğine göre bakıyordu. Sonrasında süre belirgin şekilde düştü. Mucize olmadı tabii — hayal kırıklığı yaşadığım nokta da biraz buydu — ama en azından tartışmalar daha az duygusal, daha çok teknik hale geldi. Bu bile başlı başına bir kazanım. Bu konuyla ilgili Apple Store’larda Sessiz Kapanışlar: 10 Nisan Notları yazımıza da göz atmanızı tavsiye ederim.
Küçük bir detay: Ha bu arada, prompt engineering kısmını da küçümsememek gerekiyor. Modelden ne istediğinizi iyi tarif ederseniz çıktının kalitesi yükseliyor; tarif etmezseniz size genel geçer cevap verip geçiyor. Neden önemli bu? Tıpkı usta-kalfa ilişkisi gibi: malzemeyi ve yönü verirsen güzel iş çıkarır, yön vermezsen kendi bildiğini okur.
Takımlar İçin Pratik Bir Uygulama Planı
İnanın, Bence uygulanabilir yol haritası şöyle olmalı: Bu konuyla ilgili Lenovo’nun Yeni Oyun Tableti Sürprizi: Neler Değişiyor? yazımıza da göz atmanızı tavsiye ederim.
- AI ile gelen her PR için insan onayı zorunlu olsun. — bunu es geçmeyin
- Kritik dosyalarda ikinci reviewer şart koşulsun. — bunu es geçmeyin
- Taslak açıklama yerine bağlam notu istensin.
- Test kapsamı için minimum eşikler tanımlansın. (bu kritik)
- Aynı hatalar tekrar ediyorsa guideline güncellensin.
Neyse, uzatmayalım. Bu planın güzel tarafı şu: takımı yavaşlatmadan kaliteyi yukarı çekebiliyor. Basit ama işe yarıyor. Bir de şu var: eğer şirketinizde güvenlik hassasiyeti yüksekse — finans, sağlık ya da altyapı gibi — insan incelemesi lüks değil, zorunluluk. Ben kendi masamda bunu defalarca gördüm; otomasyon ne kadar güçlü olursa olsun son sözü bilen biri söylemeyince iş raydan çıkabiliyor.
Peki AI tamamen sorun mu çıkarıyor?
Hayır elbette. Doğru kullanıldığında ciddi hız veriyor. Basit CRUD işleri, test oluşturma, dokümantasyon taslağı çıkarma gibi alanlarda gerçekten faydalı (inanın bana). Ama sınırı çizmek şart; yoksa model sizin yerinize düşünmeye başlamaz belki, ama siz düşünmemeye başlayabilirsiniz. Ve açık konuşayım, asıl tehlike biraz da bu.
Neyse, bu yüzden ben AI destekli geliştirmeyi bisiklet üzerindeki elektrik desteğine benzetiyorum. Yokuşta nefes aldırır, düz yolda keyiflidir; fakat direksiyonu bırakıp gidersen geçmiş olsun (ciddiyim)
Sıkça Sorulan Sorular
AI ile üretilen PR’leri neden mutlaka insan incelemeli?
Çünkü AI kodu çalıştırabilir ama bağlamı her zaman anlayamaz.
Mimari uyum, güvenlik. Okunabilirlik gibi konular insan gözü ister.
Hele bir de production’a giden değişikliklerde bu kontrol şarttır.
Küçük ekiplerde review guideline gerekli mi?
Evet, hatta çoğu zaman daha da gerekli. Küçük ekiplerde süreçler gayriresmî olduğu için hatalar daha kolay gözden kaçıyor. Kısacık bir checklist bile ciddi fark yaratabilir.
AI tarafından yazılan kodun kalitesini nasıl artırırım?
Daha iyi prompt yazmak ilk adım. Sonra çıktı üzerinde test odaklı ilerlemek ve stil kurallarını netleştirmek gerekiyor. Modeli tek başına bırakmak yerine yönlendirmek daha sağlıklı sonuç verir.
Review süresi çok uzarsa ne yapılmalı?
Büyük ihtimalle ya PR fazla büyük ya da guideline belirsizdir. Değişiklikleri küçültmek ve kontrol listesini sadeleştirmek işe yarar. Gereksiz tartışmaları azaltmak için karar kriterleri net olmalı.
Kaynaklar ve İleri Okuma
GitHub Pull Request Dokümantasyonu
Microsoft Azure DevOps Pull Request Guidance
OpenAI Blog ve DuyurularBunun yanında konuya yakın okumalar için şuralara da göz atabilirsiniz:
Yapay Zekâ Ajanlarında Maliyet Kontrolü Akıllı Model Seçimi,
AI ile Katalog Kaosunu Düzenli Veriye Çevirmek Perde Arkası,
Little Snitch Linux’a Geldi Sessiz Takip Sert Kontrol.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
