Neden çevik yazılım teslimatında yapay zekâ başarısız olur: Mühendislik yöneticileri için örnekler ve çözümler

Birçok CTO, çevik yazılım teslimatında yapay zeka kullanımından çok şey bekliyor: Daha fazla hız, daha fazla otomasyon, daha fazla çıktı. Bu durum kısa vadede genellikle doğrudur. Yine de birçok ekip ve CTO, bu yerel hızlanmanın müşteri faydasına ve iş değerine nasıl dönüştüğünü kanıtlamakta başarısız oluyor.

Sorun şu ki, şirketler yapay zeka coşkusuyla yanlış şeyleri optimize ediyor: Daha fazla müşteri faydası yerine daha fazla token, daha fazla güven yerine daha fazla kod, daha iyi teslimat sistemleri yerine daha fazla ajan.

Bu makale bilinçli olarak diğer iki yazımıza bağlanır:

• Çevik yazılım geliştirmede yapay zekâ: 2026 araştırma durumu .
• CTO’lar ve mühendislik yöneticileri için yapay zekâ destekli yazılım geliştirme rehberi .

Burada mesele aradaki köprüdür: Çevik yazılım teslimatında yapay zeka pratikte neden başarısız oluyor? Örnekler, yöneticilerin neler yapabileceğini ve hangi çözümlerin gerçekten sürdürülebilir olduğunu somut olarak gösterecektir.

Yapay zekâ neden çevik yazılım teslimatında sıklıkla yanlış hedefi optimize eder

Yapay zeka bir üretkenlik kaldıracı olarak tanıtılır tanıtılmaz, birçok şirkette çok öngörülebilir bir şey gerçekleşir: Ölçülebilir olan hedef haline gelir. Bu durum, yeni “Tokenmaxxing” trendinde kendini gösteriyor. Pragmatic Engineer, Tokenmaxxing trendi üzerine

Bununla kastedilen, şirketlerin veya ekiplerin yüksek token tüketimini örtük veya açık bir şekilde iyi yapay zeka kullanımının bir işareti olarak görmeleridir. Bu hem ekonomik hem de organizasyonel açıdan tehlikelidir. Çünkü tokenlar en fazla bir girdi ölçüsüdür, ancak bir değer ölçüsü değildir.

Bu kalıp eskidir. Eskiden “Kod Satırı Sayısı” (Lines of Code) bir metrik olarak aşırı önemsenirdi, bugün ise token tüketimi veya yapay zeka kullanımına dair panolar. Her iki durumda da Goodhart Yasası’nın bir versiyonu geçerlidir: Bir metrik hedef haline geldiği an, metrik olma değerini yitirir. Martin Fowler, bir metrik sorunu olarak Kod Satırı Sayısı üzerine, Goodhart Yasası hakkında Wikipedia

Çevik yazılım teslimatında yapay zeka için bunun anlamı şudur: Kısa vadeli aktiviteyi maksimize edenler, genellikle daha fazla yapay zeka aktivitesi elde ederler. Ancak bu, otomatik olarak daha iyi bir çevik yazılım teslimatı anlamına gelmez.

Buna ilişkin araştırma durumu hayal kırıklığı yaratıyor: Bireysel düzeyde şimdiden belirgin verimlilik etkileri görülürken, ekip ve organizasyon düzeyinde ise çok daha az sağlam iyileşme var. Ayrıntıları burada özetledik: Çevik yazılım geliştirmede yapay zekaya ilişkin 2026 yılındaki çalışmaların durumu üzerine

Çevik yazılım teslimatında yapay zekanın başarısız olduğuna dair dört tipik örnek

İlk başarısızlık oldukça sıradandır: Ekipler belirgin biçimde daha fazla değişiklik üretir, ama bunların giderek azalan bir kısmını gerçekten anlar.

Yöneticiler için bu başlangıçta çoğu zaman iyi görünür:

• daha fazla Pull Request
• ilk uygulamaların daha hızlı olması
• daha fazla hikâyenin “tamamlanmış” olması

Karşı muhasebe daha sonra gelir:

• İncelemeler yüzeyselleşir
• sahiplik bulanıklaşır
• olay analizi daha uzun sürer
• kimse artık nerede neyin bozulabileceğinden tam emin olmadığı için refaktörlerden kaçınılır

Kent Beck, “Trust Factory” adlı makalesinde testler, incelemeler, refactoring ve artımlı teslimat gibi uygulamaların her şeyden önce güven inşa ettiğini açıklar. Yapay zeka, ekibin anlayabileceğinden, kontrol edebileceğinden ve sorumluluğunu alabileceğinden daha hızlı üretim yaptığında tam da bu güven ortadan kalkar. Kent Beck, Trust Factory’de mühendislikte güven üzerine

Addy Osmani benzer bir riski “Anlama Borcu” (Comprehension Debt) olarak tanımlıyor: Ekipler artık aktif olarak derinlemesine kavrayamadıkları daha fazla kod teslim ettikçe, her değişiklikle birlikte sistem ile anlayış arasındaki mesafe büyür. Addy Osmani, Anlama Borcu üzerine

Bu durum, uygulamadan elde edilen daha geniş bulgularla da örtüşüyor: 2026 yılında özetlenen bir Sonar araştırmasına göre, çoğu geliştirici yapay zeka tarafından oluşturulan kodun işlevsel doğruluğuna tam olarak güvenmiyor ve önemli bir kısmı bunun incelenmesini, insan tarafından yazılmış değişiklikleri kontrol etmekten daha zahmetli buluyor. Dolayısıyla sorun sadece düşük kalite değil, aynı zamanda ek doğrulama ve anlama çabasıdır. Doğrulama Borcu (Verification Debt) hakkındaki Sonar araştırması üzerine ITPro

İkinci başarısızlık, yöneticiler için daha da pahalıdır: Yapay zekâ üretim maliyetini düşürür, ama hata yapmanın maliyetini otomatik olarak düşürmez.

Ekipler gereksinimleri kötü biçimde bölüp küçülttüğünde, yetersiz doğruladığında ya da yalnızca içerde uyumladığında, yapay zeka sadece yanlış işi hızlandırır. Kelsey Hightower bunu LinkedIn gönderisinde çok açık biçimde şöyle özetliyor: “Productivity doesn’t matter if you’re working on the wrong thing.” Kelsey Hightower’ın yanlış üretkenlik hakkındaki LinkedIn gönderisi

Andrew Ng de 2025’te çokça alıntılanan bir söyleşide tam olarak bu yönde argüman veriyor: Yapay zeka kodlamayı ciddi biçimde hızlandırdı, ancak bununla birlikte asıl darboğaz yer değiştiriyor. Artık ana sorun uygulama değil, ürün sorusu:

Aslında ne inşa etmeliyiz ve gerçek kullanıcı geri bildiriminden ne kadar hızlı öğreniyoruz?

Kaynak: Andrew Ng ile ürün yönetimi darboğazı üzerine Business Insider söyleşisi

İşte bu yüzden yapay zeka, çevik yazılım teslimatında ancak gerçek müşteri yakınlığıyla başarılı olabilir. Prompt’tan koda giden yol hızlanırken, koddan müşteri geri bildirimine giden yol yavaş kalıyorsa, sadece çıktı ve değişiklik hacmi artar.

Çevik ürün çalışmalarına dair araştırmalar da tam olarak bu örüntüyü başka bir düzeyde gösteriyor: Agile Epics üzerine bir endüstri vaka çalışmasında araştırmacılar, kötü tanımlanmış gereksinimlerin churn’e, gecikmelere, kalite sorunlarına ve gereksiz maliyetlere yol açtığını anlatıyor. Yapay zeka bu tür darboğazları sihirli biçimde ortadan kaldıramaz. En fazla onları daha hızlı görünür kılar. Agile Epics ve gereksinim kalitesi üzerine ArXiv çalışması

Bu yüzden kör AI kullanımına karşı asıl dengeleyici güç daha az yapay zeka değil, daha iyi çevik teslimattır. Bunun için genel kaldıraçları arayanlar, burada bulur: Yapay zekâ destekli çevik yazılım geliştirmenin geleceğine ilişkin rehberimizde

Yapay zekânın çevik yazılım teslimatındaki geleceğine dair birçok tablo çekici görünür, çünkü sorumluluğu zarifçe görünmez kılar: Bir ajan kullanıcı geri bildirimini analiz eder, bir diğeri gereksinimleri yazar, bir diğeri uygular, bir diğeri test eder ve bir diğeri dağıtır.

Teknik olarak bunların bir kısmı yapılabilir. Örgütsel olarak ise işler hızla belirsizleşir.

Özellikle ajan tabanlı yazılım geliştirmede, eski yönetim sorusu daha sert biçimde sorulmak zorundadır: Kim karar veriyor? Kim kontrol ediyor? Sonuçların sorumluluğunu kim taşıyor? IBM, AI decision-making üzerine okunmaya değer bir genel bakışta temel problemi şöyle formüle ediyor: Sorumluluk insanda kalır; özellikle sistemler kararları hazırladığında veya hızlandırdığında. AI decision-making’de sorumluluk üzerine IBM

AI Agile Manifesto da burada doğru karşı söylemi kuruyor: İnsan yargısı olmadan daha fazla makine zekası ilerleme değil, yanlış bir yoldur. AI Agile Manifesto orijinal halinde

Tam da bu nedenle yalnızca araç yetenekleri hakkında konuşmak yetmez. Ajanlar gereksinimleri yorumladığında, değişiklik yaptığında ya da üretime yakın aksiyonlar tetiklediğinde, sorumluluğun örgütsel olarak daha net ve görünür hale gelmesi gerekir.

Dördüncü başarısızlık çoğu zaman ancak gecikmeyle görünür olur: Tek tek geliştiriciler veya ekipler son derece verimli görünürken, tüm organizasyon daha hantal hale gelir.

Bu, herkes yerel olarak yapay zekâyla optimize olurken, neredeyse kimse tüm sistemi güçlendirmediğinde olur:

• Mimari prensipler tutarsız biçimde uygulanır
• aynı sorunlar paralel olarak birden çok kez çözülür
• inceleme ve test sistemleri ezilip geçilir
• teslimat hatları tıkanma noktasına dönüşür
• olay yükü ve sonradan yapılan işler artar

Birgitta Böckeler, Harness Engineering üzerine InfoQ söyleşisinde, neden daha yüksek özerkliğin her zaman daha yüksek riskler getirdiğini ve bunun uygun feedforward ve feedback mekanizmalarıyla sınırlandırılması gerektiğini anlatıyor. Birgitta Böckeler ile Harness Engineering üzerine InfoQ podcasti

Bu durumun teorik bir risk olmadığı, kamuoyuna yansıyan birkaç vakayla görülüyor. Amazon, 2026’da bildirildiğine göre, ciddi incident serileri sonrasında iç guardrail’lerini sıkılaştırdı; bu serilerde agentik veya yapay zekâya yakın sistemler de bir etken olarak anıldı. Buradan çıkarılan ders dikkat çekiciydi: Daha fazla belgelenmiş değişiklik, daha fazla onay, kritik sistemlerde daha fazla “controlled friction”. Başka bir deyişle: Her yerel hızlanma genel sistemi iyileştirmez. Bazen yalnızca onun zayıf noktalarını daha hızlı görünür kılar. Amazon’un sıkılaştırılmış yapay zekâ guardrail’lerine ilişkin Business Insider haberi

Aynı entropinin ikinci ve farklı bir biçimi, yapay zekâ destekli sözde Vibe Coding’de görülüyor. Axios, 2026’da güvenlik araştırmacılarına dayanarak, aralarında binlerce hassas şirket verisi içerenlerin de bulunduğu yüz binlerce herkese açık artefaktan bahsetti. Burada tek bir prompt esasen başarısız olmuyor; standartlar, erişimler, varsayılanlar, güvenlik anlayışı ve yönetişimden oluşan bütün sistem başarısız oluyor. Vibe Coding ve herkese açık artefaktlar hakkında Axios haberi

Kısacası: Yapay zekâ ne kadar otonom olursa, onun çalıştığı organizasyonel ve teknik çerçeve o kadar önemli hale gelir.

Kısacası: Yapay zekâ ne kadar özerkse, içinde çalıştığı örgütsel ve teknik çerçeve o kadar önemlidir.

Kısa vadeli verimlilik ve tokenmaxxing neden yanlış yapay zekâ stratejisidir

Bazı yöneticiler, yapay zekânın yeni kaldıraç etkisine basit bir sonuçla yanıt verir: O zaman yalnızca mümkün olduğunca hızlı biçimde mümkün olduğunca fazla yapay zekâ kullanımını zorlamalıyız.

Bu tam olarak yanlış yönetim tepkisidir.`,`Neden?

Bu bağlamda “kısa vadeli üretkenlik” çoğu zaman yalnızca şunu ifade eder:

• daha fazla üretilen kod
• daha fazla AI oturumu
• daha fazla token tüketimi
• daha fazla yerelde çözülen görev

Ama bunların hepsi, KI’nın çevik yazılım teslimatında gerçekten belirleyici olduğu sorular hakkında hâlâ neredeyse hiçbir şey söylemez:

• Doğru problem çözüldü mü?
• Ekip değişikliği anlıyor mu?
• Değişiklik güvenli bir şekilde devreye alınabilir mi?
• Sistem, değişiklikten sonra daha mı iyi yoksa daha mı kırılgan?
• Organizasyon daha mı hızlı öğreniyor yoksa sadece daha mı telaşlı?

Tam da bu yüzden Tokenmaxxing bu kadar iyi bir uyarı sinyalidir. Şirketlerin yapay zekâ kullanımını bir amaç haline getirdiğinde ne olduğunu gösterir. O zaman çalışanlar, maliyet, entropi ve kör uçuş artsa bile, görünür biçimde ödüllendirilen şeyi tam olarak maksimize eder. Pragmatic Engineer’ın Tokenmaxxing trendi üzerine yazısı

Jez Humble bu yönetim sorununu, mevcut yapay zekâ dalgasından çok önce net biçimde açıklamıştı: Yöneticiler doğrudan üretkenliğe odaklandığında, uzun vadeli iyileştirmeler çoğu zaman tam da bu yüzden yapılmaz. Agile software delivery’de yapay zekâ için bu etki daha da güçlenir. Jez Humble’ın üretkenlik odağı ve gerçekleşmeyen uzun vadeli iyileştirmeler üzerine

Bunun yerine işe yarayan şey: Agile software delivery’de yapay zekâ için dört sağlam çözüm

1. Sorumluluğu açıkça insanda tutmak

KI hızlandırabilir, önerebilir ve yükü hafifletebilir. Ama karar ve kalite sorumluluğunun belirsizleşmesi için bir bahane olmamalıdır.

Pratikte bu şu anlama gelir:

• mimari, güvenlik ve ürünle ilgili kararlar için net sahipler
• sadece AI etkinliğini ödüllendiren başarı metrikleri olmaması
• KI tarafından üretilen değişiklikler için açık inceleme ve onay kuralları

2. Sadece KI araçları değil, bir mühendislik harness’i kurmak

Birçok ekip önce modellere, en son da bu modellerin güvenli çalışabildiği koşullara yatırım yapar. Tam tersinin yapılması gerekir.

KI için çevik yazılım teslimatında sağlam bir harness’a örnek olarak şunlar dahildir:

• iyi spesifikasyonlar
• küçük, doğrulanabilir iş paketleri
• otomatik testler
• statik analiz
• kontrollü sandbox ortamları
• net mimari bağlamlar
• CI, teslimat ve üretimden gelen hızlı geri bildirim

Eğer bu düşünce ilgini çekiyorsa, spesifikasyon destekli yapay zekâ çalışması konusunda OpenSpec ve GitHub Spec Kit de faydalı referanslardır: Spesifikasyon destekli ürün geliştirme için OpenSpec, Spec-driven geliştirme için GitHub Spec Kit

3. Müşteri geri bildirimini kod üretiminden daha hızlı hale getirmek

KI ancak öğrenme döngüleri de hızlandırıldığında sürdürülebilir bir teslimat kaldıraçıdır. Aksi halde yalnızca gerçeğin önüne daha hızlı geçilmiş olur.

Bu somut olarak şunu ifade eder:

• daha küçük sürümler
• müşterilerle gerçek geri bildirim döngüleri içeren daha fazla deney
• özellik kullanım verilerinin daha tutarlı analizi
• destek ve kullanıcı sinyallerinin daha hızlı değerlendirilmesi

Sadece coding hızını artırıp feedback hızını ve kalitesini artırmayan biri, AI-native bir organizasyon kurmaz; John Cutler’ın tanımladığı gibi yalnızca daha hızlı bir “Feature Factory” kurar. Bakınız: 12 Signs You’re Working in a Feature Factory

4. Retrospektifleri ve öğrenme döngülerini ciddiye almak

KI çevik yazılım teslimatında başarısız oluyorsa, nedenler çoğu zaman sistemiktir. O zaman tek tek prompt’ları veya araçları optimize etmek pek yardımcı olmaz.

Ekiplerin, tekrar eden kalıpları görünür kıldığı ve sistematik olarak çözdüğü rutinlere ihtiyacı vardır:

• Nerede anlayışı kaybediyoruz?
• Nerede inceleme kuyruğu büyüyor?
• Nerede KI faydadan çok yeniden iş üretir?
• Nerede yerel hızı tüm sistem pahasına optimize ediyoruz?

Tam da bu yüzden retrospektifler güncelliğini korur. Scrum geçmişinden kalma bir ritüel olarak değil, değişim sıklığının daha yüksek olduğu bir ortamda organizasyonel öğrenme mekanizması olarak.

Sonuç: KI’nın çevik yazılım teslimatında başarısız olması çoğu zaman yetersiz KI’dan kaynaklanmaz

Asıl ironi şu: Birçok organizasyon KI ile başarısız olur; çünkü fazla temkinli oldukları için değil, çok kısa vadeli yönettikleri için.

Kısa vadeli üretkenliği, sürdürülebilir değer yaratımı ve delivery sisteminin iyileştirilmesiyle karıştırırlar. Token tüketimini değer yaratımıyla karıştırırlar. Otonom kod üretimini organizasyonel olgunlukla karıştırırlar.

Bu yüzden daha iyi yönlendirici soru şu değildir: “Ekiplerimizi daha da fazla KI kullanmaya nasıl ikna ederiz?”

Bunun yerine daha çok şu olmalıdır:

• Hangi koşullar altında KI gerçekten teslimatımızı iyileştirir?
• Yapay zekâ şu anda değer zincirinde nerede yeni darboğazlar oluşturuyor?
• Yapay zekâ, düzeltmemiz gereken sistemik eksikleri nerede açığa çıkarıyor?
• Hızlanma entropiye dönüşmesin diye hangi organizasyonel yetkinlikleri güçlendirmeliyiz?

Bunun için önce soğukkanlı kanıtı görmek istiyorsan, buradan devam et: Yapay zekanın çevik yazılım geliştirmedeki araştırma durumu .

Doğrudan yönetim kaldıraçlarını arıyorsan, buradan devam et: Agile yazılım geliştirmede yapay zekâ için CTO’lar ve Engineering Manager’lar rehberi .

Yapay zekanın çevik yazılım teslimatındaki SSS

Yapay zekâ ekibime neden daha fazla output veriyor ama daha iyi delivery vermiyor?

Çünkü daha fazla output otomatik olarak daha iyi delivery anlamına gelmez. Review’ler, testler ve geri bildirim aynı hızda ilerlemezse, özellikle karmaşıklık artar.

Yapay zekâ destekli yazılım geliştirmede Tokenmaxxing ne anlama gelir?

Tokenmaxxing, yapay zekâ kullanımını veya token tüketimini hedef haline getirmek demektir. Bu aktiviteyi ölçer, ama değeri ölçmez.

Engineering Manager'lar yalnızca yapay zekâ üretkenliğini artırmaya çalışmak yerine ne yapmalı?

Sorumluluğu, testleri, review’leri ve geri bildirim döngülerini güçlendirmelidirler. Yapay zekâyı uzun vadede faydalı kılan şey ancak budur.

Yoğun yapay zekâ desteği alan ekiplerin hâlâ agile ritüellere ihtiyacı var mı?

Evet, ama farklı bir odakla. Daha az durum güncellemesi, daha çok geri bildirim, öğrenme ve sürekli iyileştirme.

Bir Engineering Manager olarak, yapay zekânın yazılım geliştirmede gerçekten işe yarayıp yaramadığını nasıl ölçerim?

Lead Time’ı, inceleme çabasını, hata oranını ve müşteri faydasını ölçün. Salt çıktı yeterli değildir.

Neden ekibim yapay zekâ ile daha hızlı oluyor ama sonuçlar daha iyi olmuyor?

Çünkü daha fazla kod otomatik olarak daha iyi sonuçlar vermez. Temiz incelemeler, testler ve geri bildirim olmadan yalnızca entropi artar.

Yapay zekâ için yazılım geliştirmede gerçekten hangi KPI’ları takip etmeliyim?

Döngü süresini, Defect Rate’i, yeniden çalışma miktarını, dağıtım güvenliğini ve müşteri geri bildirimine kadar geçen süreyi takip edin. Yalnızca token’lar çok az şey söyler.

Yapay zekâ tarafından üretilen kodun ekibimi ileride yavaşlatmasını nasıl engellerim?

Değişiklikleri küçük tutun, bunları düzgünce test edin ve net bir inceleme talep edin. Yapay zekâ hız getirebilir, ama anlayışın yerini almamalıdır.