Bu yazıda
Bir COCOMO II tablosuna bakıp ekibinizin iki sprintte teslim ettiği bir proje için 33 takvim ayı öngördüğünü gördüyseniz sorunu zaten biliyorsunuz: Bugün üretimde kullanılan her tahmin modeli, geliştiricilerin her satırı elle yazdığı, bağlam değiştirmenin bir bedeli olduğu ve takvimin akşam 17:00’de durduğu bir dünyaya göre kalibre edilmiştir. O dünya artık yok. Yakın zamanda 286 KLOC büyüklüğünde, 672 dosyalı, çok alt sistemli bir uygulamayı sıfırdan geliştirdik (protokol katmanı, veri katmanı, işleme motoru, platform entegrasyonu) ve 7 günde teste hazır bir alfa sürümüne ulaştık. Modellerin tamamı (COCOMO Basic/Intermediate/Post-Architecture, Function Points, SLOC temel çizgisi, Putnam/SLIM) 30,3 takvim ayı medyan tahmin verdi. Medyan verimlilik çarpanı: 4.240×. En temkinli temel çizgi bile (karmaşık sistemler için 25 SLOC/geliştirici-gün) 1.433× saptı. Modeller yanlış değil. Yanlış uygulanıyorlar. Aşağıda model model döküm, aynı yazara ait ampirik kalibrasyon ve 2024 ile 2026 arasındaki RCT literatürünün, ajan tabanlı yapay zekânın süreyi nerede kısalttığı ve nerede kısaltmadığı konusunda gerçekte ne söylediği yer alıyor.
Tahminleri Alt Üst Eden Proje
RIADVICE’ta yakın zamanda karmaşık ve zengin özellikli bir uygulama geliştirdik: dağıtık bir mimaride birden çok alt sistemi koordine eden türden bir uygulama. Yeni bir uygulama gerektiren pazar ihtiyaçları doğrultusunda, tek bir kod tabanından mobil ve masaüstünü hedefleyen yerel (native), çapraz platform bir ortam olarak geliştirildi. Ölçeği kod tabanı anlatıyor:
- 672 kaynak dosyaya yayılmış 286.662 SLOC (~286 KLOC)
- 1.329.399 satırlık toplam değişim (churn): 862.488 ekleme ve 466.911 silme
- Teste hazır ilk alfaya ulaşmak için 7 aktif geliştirme gününde 700 commit
- Onlarca dile tam yerelleştirme
- Hedef ortam için sıfırdan inşa edilmiş, birbirinden tamamen bağımsız birden çok alt sistem: protokol işleme, veri yönetimi, işleme (rendering) ve platform entegrasyonu
Bu bir sarmalayıcı ya da yüzeysel bir arayüz yenilemesi değildi. Mevcut çözümlerin karşılayamadığı pazar gereksinimlerini karşılamak için sıfırdan inşa edilmiş yerel bir uygulamaydı. Tek bir satır yazmadan önce projeye, kod tabanı büyüdükçe ona karşı sektör standardı yazılım eforu tahmin modellerinin tamamını çalıştıran özel bir analiz aracı bağladım. Amaç dürüsttü: Klasik modellerin öngördüğü ile yapay zekâ destekli bir teslimatın gerçekte ürettiği arasındaki farkı ölçmek. Sonuçlar bir yuvarlama hatası değil. Bir kategori kırılması.
Tahmin Modellerinin Öngördüğü ve Gerçekte Olan
Araç, yazılım mühendisliği literatüründeki tüm büyük tahmin modellerini çalıştırıyor: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached ve Embedded, ayarlanmış), COCOMO II Post-Architecture (ayarlanmış), Function Points, SLOC Verimlilik Temel Çizgisi ve Putnam/SLIM. Modeller, özgün kaynak literatürde yayımlanan sabitler kullanılarak proje türüne göre kalibre edildi.
| Tahmin modeli | Öngörülen efor | Öngörülen takvim | Gerçeğe göre hızlanma |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 kişi-ay | 33,3 ay | 2.282× |
| COCOMO Basic (Semi-Detached) | 1.696 kişi-ay | 33,7 ay | 4.240× |
| COCOMO Basic (Embedded) | 3.200 kişi-ay | 33,1 ay | 8.000× |
| COCOMO Intermediate (Semi-Det., ayarlanmış) | 1.259 kişi-ay | 30,4 ay | 3.148× |
| COCOMO Intermediate (Embedded, ayarlanmış) | 2.376 kişi-ay | 30,1 ay | 5.940× |
| COCOMO II Post-Architecture (ayarlanmış) | 1.703 kişi-ay | 30,3 ay | 4.257× |
| Function Points (kaba hesap) | 17,9 kişi-ay | 7,5 ay | 45× |
| SLOC Verimlilik Temel Çizgisi (25 SLOC/geliştirici-gün) | 573 kişi-ay | 573,3 ay | 1.433× |
| Putnam/SLIM | atlandı (süre < 30 gün; T 4/3 patlıyor) | uygulanamaz | uygulanamaz |
Tüm modellerdeki medyan verimlilik çarpanı 4.240×. En temkinli model bile gerçekte olandan kabaca 1.400 kat daha uzun bir teslim süresi öngörüyor. En iyimser model olan Function Points bile 7,5 takvim ayı öngördü: gerçekleşen 7 günden 45 kat daha uzun. Modellere göre bu projenin 7 aydan 47 yıla kadar sürmesi gerekiyordu. Bir alfa sürümü 7 günde teste hazırdı.
Modeller birbirleriyle de uyuşmuyor: 50× ile 8.000× arası
Bu modeller birbiriyle uyuşmuyor. Aynı kod tabanında tahminler 17,9 ile 3.200 kişi-ay arasında değişiyor: 178 katlık bir açılım. COCOMO II, SEER-SEM, SLIM ve TruePlanning’i 51 gerçek proje üzerinde karşılaştıran SEAA 2013 kıyaslaması %50 ile %100 arasında MMRE buldu. COCOMO NASA veri kümesi üzerinde yapılan 2023 tarihli bir değerlendirme, MMRE’yi 1,0 civarında ve PRED(0,25) değerini 0,0 buldu: Tek bir proje bile %25’lik hata bandı içinde tahmin edilemedi. Bu modeller hiçbir zaman yapay zekâ destekli bir proje için tasarlanmadı. Ancak modellerin yanılma payı hesaba katılsa bile farkın büyüklüğü, yapısal bir şeyin değiştiğini gösteriyor.
Araştırmalar Ajan Tabanlı Yapay Zekâ ve Geliştirici Verimliliği Hakkında Gerçekte Ne Diyor?
4.240× rakamı uç bir değer ve onu abartmak istemiyorum. Sıfırdan başlanan (greenfield) projelerde iskelet kod üretimi değişim hacmini şişirir ve SLOC, değerin zayıf bir göstergesidir. O halde hakemli literatüre bakalım. Copilot tarzı asistanlar mütevazı ama gerçek kazanımlar sağlıyor. Peng ve ark. (2023), yapay zekâ eşli programcı kullanan geliştiricilerin bir görevi %55,8 daha hızlı tamamladığını buldu (%95 GA: %21 ile %89). Bugüne kadarki en büyük çalışma olan Microsoft/Accenture/Fortune 100 RCT’si (2025, n=4.867) tamamlanan görevlerde %26 artış buldu. Google’ın şirket içi RCT’si (2024), görev süresinde ~%21 azalma buldu. BIS/Ant Group saha deneyi (2024), kıdemsiz çalışanlarda kod çıktısında %55 artış ölçtü. Dürüst özet: uygun görevlerde 1,26× ile 1,56×. Gerçek, ama dönüştürücü değil. Ajan tabanlı yapay zekâ farklı bir düzlemde çalışıyor. Cognition’ın Devin hakkındaki 2025 değerlendirmesi, müşteri sonuçlarında ETL geçişlerinde 10×, Java sürüm geçişlerinde 14× ve güvenlik düzeltmelerinde 20× bildirdi. Nubank, daha önce çok yıllık ve bin mühendislik bir çaba olarak tahmin edilen, milyonlarca satırlık bir yeniden düzenlemede 12× verimlilik artışı ve 20× maliyet tasarrufu bildirdi. Bizim uygulamamız tam olarak bu aralıkta yer alıyor: Commit histogramı 22:00, 00:00 ve 01:00’de yoğun patlamalar gösteriyor; bu, ajan güdümlü oturumların imzasıdır. Karşıt kanıtlar da gerçek. Metr.org’un 2025 RCT’si (olgun projelerde 246 görev üzerinde 16 deneyimli geliştirici), yapay zekânın tamamlanma süresini %19 artırdığını buldu: Deneyimli geliştiricileri tanıdık kod tabanlarında yavaşlattı. Yapay zekâ aracı benimseyen 807 GitHub deposu üzerinde yapılan 2026 tarihli bir farkların farkı çalışması (He ve ark., MSR ’26), “geçici” bir hız artışı ve uzun vadede yavaşlamaya yol açan, kod karmaşıklığında “kalıcı” bir artış buldu. Başlık her şeyi söylüyor: Speed at the Cost of Quality (Kalite Pahasına Hız). Ortak görüş: Yapay zekâ sıfırdan başlanan ve yapılandırılmış geliştirmede çok, tamamlama görevlerinde mütevazı ölçüde yardımcı olur ve olgun kod tabanlarında hıza zarar verebilir. Kalite borcu gerçek.
Modeller Neden Çöküyor: Üç Yapısal Değişim
Klasik modellerdeki maliyet etkenlerinin hiçbirinde “geliştiricinin hiç uyumayan ve kod tabanının tamamını bağlamında tutan otonom bir ajanı var” diye bir ayar yok. Üç değişim süre eğrisini çökertiyor:
- Yazma darboğazı ortadan kalktı.
Modeller, eforun önemli bir kısmının mekanik olduğunu varsayar: kalıp kod (boilerplate), iskelet kod, tekrarlayan yeniden düzenlemeler, yerelleştirme kaynakları ve diğer yapılandırılmış veriler. Bu uygulamada hacmin büyük bölümü, bir ajanın toplu halde üretebileceği ya da dönüştürebileceği son derece düzenli metin ve bağlantı kodundan oluşuyor. Elle yazılan kodun kendisi bile (iskelet kod, yapıcılar, platform yapıştırıcı kodu) artık satır satır yazılmıyor, toplu halde üretiliyor.
- Bağlam değiştirmenin maliyeti çöküyor.
Protokol katmanı, veri katmanı ve işleme motoru arasında geçiş yapan bir insan, her seferinde bağlam yükleme bedeli öder. 672 dosyalık deponun tamamını okumuş bir ajan bu bedeli bir kez öder. Bu asimetri, bu büyüklükte bir kod tabanında hızla katlanır.
- Takvim artık darboğaz değil.
Modeller kişi-ayı, bir insanın iş gününü varsayan bir kadro denklemiyle takvim ayına dönüştürür. Ajan oturumları gece boyunca sürer. Commit histogramı 07:00’den 01:00’e kadar kesintisiz bir üretim gösteriyor: 8 değil, 18 aktif saat.
Aynı Yazara Dayalı Ampirik Kalibrasyon
Parametrik modeller arasında büyüklük mertebeleri kadar fark olduğu için, aynı ekosistemdeki üç başka üretim deposunda ajan tabanlı bir yapay zekâ aracını benimsemeden önceki ve sonraki kişi-gün başına kod değişimimi karşılaştıran, projeler arası ampirik bir kalibrasyon da çalıştırdım:
| Proje | YZ öncesi değişim/geliştirici-gün | YZ dönemi değişim/geliştirici-gün | Çarpan |
|---|---|---|---|
| Proje A (yük dengeleyici) | 673 | 2.056 | 3,1× |
| Proje B (raporlama hizmeti) | 239 | 2.127 | 8,9× |
| Proje C (işleme hizmeti) | 1.322 | 982 | 0,7× |
| Toplam (ortalama / medyan) | uygulanamaz | uygulanamaz | 4,2× / 3,1× |
Aynı yazar, aynı alan, gerçek bakım çalışması. Ampirik çarpan 3× ile 9× arasında: 4.240× seviyesindeki sıfırdan geliştirme rakamından çok daha temkinli ve yayımlanmış ajan tabanlı yapay zekâ araştırmalarının üst ucuyla tutarlı. Bir proje aslında yavaşladı: Kazanımlar evrensel değil, göreve bağlı.
Proje Planlaması İçin Anlamı
Yazılım projelerini hâlâ kalibre edilmemiş modellerle ve günde 25 SLOC temel çizgisiyle tahmin ediyorsanız, yapay zekâ destekli işlerde bir ile üç büyüklük mertebesi arasında yanılırsınız. RIADVICE’ta şöyle yapıyoruz:
- Kendi geçmişinize göre kalibre edin. Yapay zekâ ile ve yapay zekâ olmadan kişi-gün başına kendi kod çıktınızı karşılaştırın. Bu daha ucuz ve daha dürüsttür; bir proje planında savunabileceğiniz 3× ile 9× arası bir aralık ortaya koyar.
- Sıfırdan geliştirmeyi bakımdan ayırın. Ajan tabanlı yapay zekânın çarpanı sıfırdan ve yapılandırılmış geliştirmede en büyük, olgun kod tabanlarının bakımında en küçüktür (bazen negatiftir). İkisine tek bir sayı uygulamayın.
- Kalite borcu için bütçe ayırın. Yapay zekânın getirdiği hız, karmaşıklıkta kalıcı artışlarla birlikte gelir. Bir sağlamlaştırma aşaması planlayın ve ölçün: Her sürümde döngüsel karmaşıklığı izleyin ve kopyala-yapıştır tespiti çalıştırın.
- Eğrinin yalnızca başını değil, tamamını tahmin edin. Hata yoğunluğunuzu iki katına çıkaran 10 katlık bir hız kazanımı, 10 katlık bir kazanım değildir: daha uzun bir stabilizasyon kuyruğu pahasına öne çekilmiş bir takvimdir.
Sonuç
Her tahmin modelinin 7 ay ile 47 yıl arasında sürmesi gerektiğini söylediği bir proje, 7 günde teste hazır bir alfa sürümüne ulaştı. 4.240× medyan çarpanı kimsenin proje planı olmamalı. Ancak bu, karmaşık yazılım geliştirmenin süresinin, eforu yeniden sıkıştıran güç tarafından yeniden sıkıştırıldığına dair net bir sinyal. Yayımlanmış araştırmalar, yapay zekânın 1,26× düzeyinde hafif bir itkiden 20× düzeyinde bir sıçramaya kadar uzanan sonuçlar verdiğini; olgun kod tabanlarında gerçek bir negatif getiri riski ve ölçülebilir bir kalite bedeli taşıdığını gösteriyor. Bize bu projenin onlarca yıl sürmesi gerektiğini söyleyen modeller, bugün hâlâ kurumsal tahmin tablolarında çalışan modellerin ta kendisi. Soru, ajan tabanlı yapay zekânın proje süresini değiştirip değiştirmediği değil; araştırmalar bunu yanıtladı. Soru, tahmin pratiğinizin kanıtlara yetişip yetişmediği. Rakamlarınız hâlâ COBOL ve assembly üzerinde kalibre edilmiş 1981 tarihli bir modelden geliyorsa yeniden kalibre etmenin ya da en azından onun verdiği takvime inanmayı bırakmanın zamanı geldi.
“Uygulamada karşılaşılan tahmin zorluklarını daha iyi ele almak için hâlâ önemli bir iyileştirme alanı var.”
Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013
🏆 Güvenilir Mühendislik ve Bulut Uzmanlığı
RIADVICE: Yazılım Mühendisliğinde Güvenilir İş Ortağınız
Karmaşık yazılım sistemlerini, yapay zekâ çağında zamanında, bütçesinde ve kaliteli teslim etmeyi sağlayan mühendislik disiplini ve araçlarla tasarlıyor, geliştiriyor ve devreye alıyoruz.
Hizmetlerimiz Hakkında Daha Fazla Bilgi →
📚 Kaynaklar ve İleri Okuma
Bu yazı, yapay zekâ destekli yazılım geliştirme verimliliği ve yazılım eforu tahmini üzerine hakemli araştırmalara, randomize kontrollü çalışmalara ve sektör saha raporlarına dayanmaktadır:
- Yapay Zekâ Verimlilik Çalışmaları (RCT’ler ve Saha Deneyleri)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590: görev tamamlama süresinde %55,8 azalma
- Cui, R., et al. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers Microsoft Research: n=4.867, tamamlanan görevlerde %26,08 artış
- Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944: Google RCT’si, n=96, görev süresinde ~%21 azalma
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Metr.org: RCT, n=16, 246 görev; yapay zekâ tamamlanma süresini %19 artırdı
- He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects, arXiv:2511.04427: 807 GitHub deposu üzerinde farkların farkı (DiD) çalışması; MSR ’26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks Tekrar çalışması bulgusu: %13 artış (anlamlı değil)
- Ajan Tabanlı Yapay Zekâ Sektör Raporları
- Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work ETL geçişlerinde 10×, Java geçişlerinde 14×, güvenlik düzeltmelerinde 20×
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin Milyonlarca satırlık yeniden düzenlemede 12× mühendislik saati, 20× maliyet tasarrufu
- BIS / Ant Group (2024). Saha deneyi; kod çıktısında %55 artış, ağırlıklı olarak kıdemsiz çalışanlarda
- Yazılım Eforu Tahmini: Temeller ve Doğruluk
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: özgün COCOMO
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: 161 proje üzerinde kalibre edildi
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models 51 projede COCOMO II, SEER-SEM, SLIM, TruePlanning; MMRE %50 ile %100
- Kemerer, C. F. (1993). An empirical validation of software cost estimation models, Communications of the ACM
- Nguyen, V., et al. (2019). Determining relevant training data for effort estimation using window-based COCOMO calibration 341 + 93 proje üzerinde pencere tabanlı kalibrasyon
- Ahmad, M., & Wani, M. A. (2023). Evaluation of COCOMO Model Accuracy in Software Effort Estimation MMRE ~1,0, PRED(0,25) = 0,0
- Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimation problem. IEEE TSE: Putnam/SLIM modeli
⚡ RIADVICE.com, güvenilir mühendislik, bulut uzmanlığı ve kurumsal düzeyde yazılım çözümlerini zamanında, bütçesinde ve kaliteli şekilde sunar.
