Yapay zekâyla kod yazma meselesi, dışarıdan bakınca gerçekten dikkat çekici görünüyor. Bir şeyler söylüyorsun, kod akıyor, testler geliyor, hatta bazen “aa bu mimari öneri fena değil” dediğin anlar bile oluyor… ama işin aslı şu: hız tek başına hiçbir şey çözmüyor. Asıl mesele, o hızın direksiyonunu kimin tuttuğu.
Geçen yıl Kasım ayında, Kadıköy’de küçük bir SaaS paneli üzerinde çalışırken bunu bizzat yaşadım. Model öyle bir özgüvenle kod üretti ki ilk bakışta “tamam ya, bu iş oldu” dedim. Sonra iki gün sonra fark ettim: yapı benim kafamdaki akıştan kaymıştı. Çalışıyordu ama garipti, hani evin planı var gibi görünüyor da kapı başka yere açılıyor ya — tam öyle bir his (ki bu çoğu kişinin gözünden kaçıyor). İçim sıkıştı o an.
Neden herkes aynı anda hem hevesli hem tedirgin?
Bir şey dikkatimi çekti: Kod üretimi son iki yılda resmen ucuzladı. Önce IDE içi otomatik tamamlama geldi, sonra sohbet ekranları… ardından repo içine giren ajanlar, terminalden çalışan asistanlar ve neredeyse sizin yerinize dosya düzenleyen araçlar çıktı (ki bu çoğu kişinin gözünden kaçıyor). Bu kadar seçenek olunca kafanın karışması çok normal, açık konuşayım ben de ilk başta “bunun sonu nereye gidiyor ki?” diye düşündüm durdum.
Küçük bir detay: 2024’ün başında İstanbul Levent’te bir ekip toplantısında bunu uzun uzun tartıştık. Bir arkadaşım dedi ki: “Artık prompt yazmayı öğrenmek yetmiyor, workflow tasarlamak gerekiyor.” O cümle kulağa biraz süslü gelmişti doğrusu — ama sonra hak verdim. Çünkü mesele sadece model değil; modelin nasıl yönlendirildiği, neye eriştiği. Hangi sınırlar içinde kaldığı asıl soruyu oluşturuyor.
Hmm, bunu nasıl anlatsamdı…
İşin tuhaf tarafı şu: araçlar geliştikçe beklenti de yükseliyor ama kontrol hissi aynı hızda artmıyor (ki bu çoğu kişinin gözünden kaçıyor). İnsanlar bazen güvenlik izinlerinden bahsediyor — dosyalara erişsin mi, shell açsın mı, production’a dokunsun mu, bunlar önemli tabi (buna dikkat edin). Ama benim için asıl soru bu değil. Ben şuna bakıyorum: bu sistem benim düşünme biçimimi bozuyor mu?
Kontrol dediğimiz şey aslında üç ayrı katman
Bence kontrol dört ayağa dayanıyor demek daha doğru olurdu — ama hadi sade gidelim. Bağlam kontrolü, yön kontrolü. Iş akışı kontrolü olmadan yapay zekâ size yardımcı olmuyor; yavaş yavaş sizi sürüklemeye başlıyor. Yani sorun “kod yazması” değil… sorun “hangi kodu neden yazdığınıza sizden fazla karar vermesi”. Fark büyük.
| Kontrol Alanı | Ne Anlama Geliyor? | Kayıp Olursa Ne Olur? |
|---|---|---|
| Bağlam | Araç projenin niyetini ve geçmişini biliyor mu? | Kod parçaları rastgeleleşir |
| Yön | Mimarinin ana çizgisini kim belirliyor? | Ajan kendi yolunu çizer |
| İş akışı | Siz onaylayıp yönlendiriyor musunuz? | “Vibe coding” denilen sisli alan başlar |
Beni en çok rahatlatan şey: Ajanı kaptan koltuğuna oturtmamak
Garip gelecek ama, Dürüst olayım — bir dönem ben de modaya kapılıp her şeyi ajana bırakmaya çalıştım. En çok da de Berlin’deki kısa seyahatimde otelde geç saatlere kadar oturup “nasıl olsa araç halleder” kafasına girdim. Sonuç? Hızlı çıktı aldım evet… fakat çıktının yarısını ertesi gün geri söktüm. Hem vakit kaybı, hem moral bozukluğu.
Araya gireyim: Bundan sonra yaklaşımı ters çevirdim. Ajanı işçi gibi kullandım diyeyim — kaba kaçmasın ama durum biraz o hesap. Tasarımı ben kurdum, karar noktalarını ben belirledim, sınırları ben çizdim; ajan ise uygulamayı hızlandırdı. Bu değişiklik kulağa küçük geliyor olabilir, ama pratikte oyun değiştiriyor. Gerçekten. Bu konuyla ilgili Morgan Stanley Bitcoin ETF’si: Geç Kalan Hamle Neyi Değiştirir? yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Kısa bir not düşeyim buraya.
Yapay zekâya en çok güvendiğim anlarda bile son sözü kendime bırakıyorum; çünkü kodun sahibi olmak istiyorsanız sadece sonucu değil, kararı da sahiplenmeniz gerekiyor.
Bazen tam olarak hangi desenin gerektiğini biliyorum; bazen de birkaç seçenek istiyorum ve aralarındaki takası değerlendiriyorum. Mesela performans mı daha hayati yoksa okunabilirlik mi? Kısmi otomasyon mu yeterli, yoksa uçtan uca ajan mı mantıklı? İşte burada insan yargısı devreye giriyor — makineler bu noktada hâlâ biraz ham kalıyor, şaşırtıcı ama öyle. Google’dan Android Kullanıcılarına 135 Milyon Dolarlık Payout: Şimdi Ne Yapmalı? yazımızda bu konuya da değinmiştik.
Küçük startup ile kurumsal ekip arasında fark büyük
Küçük bir startup’ta AI destekli kodlama hızlı kazanımlar veriyor çünkü ekip zaten az kişiyle çok iş çıkarma peşinde oluyor. Ama enterprise seviyede tablo değişiyor; orada uyumluluk, denetim izi ve standartlaşma daha ağır basıyor. Geçen ay Ataşehir’de görüştüğüm bir ürün ekibi bunu net anlattı: “Hız güzel ama kim neyi niye değiştirdiğini göremezsek bize maliyeti büyüyor.” Haklıydılar, itiraz edemedim.
- Küçük ekip: Hızlı prototip için agent iyi çalışır. (bence en önemlisi)
- Büyüyen ekip: Kod standardını korumak için sıkı review şarttır.
- Kurumsal yapı: Loglama ve erişim sınırı olmazsa olmazdır.
Kod ucuzlayınca yargı daha değerli oluyor
Burası önemli. Eskiden kötü kod yazmak bile zaman alırdı; şimdi birkaç saniyede tonlarca kötü fikir üretebiliyorsunuz. Evet, biraz sert söyledim ama gerçek bu gibi duruyor. Kodun ucuzlaması harika bir şey — deney yapmayı kolaylaştırıyor, bu kesin. Ama aynı zamanda yanlış yolu da korkunç derecede hızlandırıyor. Çift taraflı kılıç işte. Bu konuyla ilgili yapay konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Bu yüzden artık iyi geliştiriciyi sadece hızlı yazan kişi olarak görmek bana eksik geliyor. Asıl marifet, neyi yazmaman gerektiğini bilmekte yatıyor (en azından benim deneyimim böyle). Bir de şunu söyleyeyim: kendi projemde Şubat 2025’te küçük ama ders niteliğinde bir olay yaşadım (evet, doğru duydunuz). Bir login akışını modele yaptırdım. Gayet temiz görünüyordu — ta ki edge case’leri test edene kadar, özellikle hatalı token yenileme senaryolarında işler karıştı. Sistem çalışıyordu ama güven duygusu zayıftı; yani kâğıt üstünde süperdi, pratikte ince ayar gerekiyordu.
Neyi kabul edip neyi reddedeceğinizi bilmek lazım
// AI ile çalışma prensibim
1) Önce hedefi ben tanımlarım
2) Sınırları ben koyarım
3) Modelden alternatif istersem açıkça söylerim
4) Üretilen kodu körlemesine merge etmem
5) Kritik parçaları elle doğrularım
6) Test olmadan "tamam" demem
// Kural basit:
Eğer anlamadıysan — kullanma.
Eğer açıklayamıyorsan — kabul etme.
Eğer bakım yükünü artırıyorsa — yeniden düşün.
Sohbet ekranından repoya uzanan yolun bedeli var
// AI ile çalışma prensibim
1) Önce hedefi ben tanımlarım
2) Sınırları ben koyarım
3) Modelden alternatif istersem açıkça söylerim
4) Üretilen kodu körlemesine merge etmem
5) Kritik parçaları elle doğrularım
6) Test olmadan "tamam" demem
// Kural basit:
Eğer anlamadıysan — kullanma.
Eğer açıklayamıyorsan — kabul etme.
Eğer bakım yükünü artırıyorsa — yeniden düşün.
Editör içinde sohbet etmek kolay geliyor çünkü zihinsel sürtünme az oluyor. Ama o rahatlık bazen tembellik yaratıyor. Ben bunu özellikle Chrome’da dikey sekmelerle çalışırken fark ettim — gözünüz sürekli yeni pencerelerde gezmeye başlayınca odak da dağılıyor ya, AI araçlarında da benzer bir durum var (buna dikkat edin). Çok fazla öneri, çok fazla sapma riski demek. Ha, bu arada şu link beni geçenlerde tekrar düşündürdü:
Yapay Zekâ Ajanı Akıllı Değil Asıl Güç Araçlarda! (buna dikkat edin)
Şunu söyleyeyim, Aynı mantığı güvenlik tarafında da görüyoruz aslında. Bir aracın size fayda sağlaması için güçlü olması yetmez; görülebilir olması gerekiyor. Şimdi, ben bunu özellikle token sızıntıları üzerine okurken hissettim, mesela şu haber bayağı ders niteliğinde:
Snowflake Müşterilerini Vuran Token Sızıntısı Zincir Kırıldı.
Gücün olduğu yerde sınır yoksa risk de büyüyor. Neyse, uzatmayayım.
Daha sağlıklı AI çalışma biçimi nasıl kuruluyor?
Açık konuşayım — ben artık üç aşamalı ilerlemeyi tercih ediyorum: önce düşünceyi netleştiriyorum, sonra modelden taslak alıyorum, en sonunda kendi filtremden geçiriyorum. Bu kadar basit görünüyor ama bir düşüneyim… çoğu hata zaten bu sıranın bozulmasından çıkıyor. Model önce çözüme atlıyor, siz sonra problemi tarif etmeye çalışıyorsunuz — işler tam da orada dağılıyor işte.
Peki bunun pratik karşılığı ne? Mesela feature eklerken doğrudan “bana component yaz” demek yerine önce davranışı tarif ediyorum: hangi kullanıcı görecek, hangi veri gelecek, hangi durumda hata dönecek, test senaryosu ne olacak… Bu şekilde model kendince roman yazamıyor. Daha kontrollü gidiyoruz. Baya işe yarayan kısım da burası oldu doğrusu — küçük ama etkisi büyük bir değişiklik.
Kullanabileceğiniz basit yaklaşım seti
- Niyet: Neyi yapmak istediğinizi tek cümlede tanımlayın.
- Sınır: Mimaride dokunulmaması gereken yerleri söyleyin.
- Taslak: Modelden seçenek isteyin, tek cevap istemeyin.
- Review: Herhangi kritik parçada insan onayı verin.
- Test: Mutlaka edge case deneyin.
Peki hiç hayal kırıklığı olmadı mı? Oldu tabii!
Evet, beklediğim kadar iyi olmayan anlar da yaşadım. Bilhassa karmaşık state yönetimi olan yapılarda model bazen yüzeysel kalabiliyor. Görünürde düzgün duran kod, arka planda gereksiz bağımlılıklarla dolu çıkabiliyor. Sonra siz temizlemek zorunda kalıyorsunuz… ve o noktada kazandığınız hızın bir kısmını geri ödüyorsunuz. Acı ama gerçek.
Bana göre bu durum AI’nin başarısız olduğu anlamına gelmiyor. Sadece sınırlarını gösteriyor. Ben bunu kabul ettiğim gün rahatladım açıkçası — araçtan mucize beklemeyi bıraktığınızda, onun gerçekten faydalı olduğu yerleri görmeye başlıyorsunuz. Bu arada Anthropic’in güvenlik odağını izlerken verdiği sinyaller de ilginçti; isterseniz şuna da bakabilirsiniz:
Anthropic’in Mythos Hamlesi: Güvenlikte Yeni Bir Vitrin!
Sıkça Sorulan Sorular
Yapay zekâyla kod жaзarken bayağı teslim olmak doğru mu?
Pek doğru sayılmaz. En sağlıklısı yapay zekâyI yardımcı gibi görmek, ana kararları ise sizin vermenizdir. Böylece hem hız kazanırsınız hem de proje üzerindeki hakimiyetinizi kaybetmezsiniz.
AI tool’lariyla code review hala gerekli mi?
Vallahi gerekli: Bilhassa mimari karar içeren yerlerde gözle doğrulama şart. Otomasyon iyi hoş, ama bakım yükünü ancak insan sezgisi dengeliyor.
Küçük startup’lar için agent kullanımı mantıklı mı?
Evet, eğer kapsam dar tutulursa mantıklı olabilir. Prototiplemede ciddi hız sağlar; fakat temel mimariyi sürekli ajanın eline bırakırsanız teknik borcu büyütürsünüz.
En büyük risk nedir?
Bence en büyük risk yanlış kode gitmekten ziyade kontrol hissini kaybetmektir. Kod çalışsa bile onu neden öyle yaptığınızı anlayamazsanız ileride bakım işi zorlaşır.
Kaynaklar ve İleri Okuma
Claude Code Resmi Dokümantasyonu/a>
OpenAI Codex Duyurusu
GitHub Copilot Resmi SayfasI / GitHub Features
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.
