Vibe Coding vs Gerçeklik: AI Modernizasyon Hikayelerinde Anlatılmayan Kısım

Bir CTO olarak son dönemde LinkedIn feed’imde gezinirken sürekli aynı yanılsamayla karşılaşıyorum: “Vibe Coding”, “Spec-Driven Development” veya “AI ile %40 verimlilik artışı”. Her şey ne kadar pırıltılı, değil mi? Ama yönetim kurulu toplantılarında veya mimari gözden geçirme panolarında gerçekler hiç de bu kadar parlak değil.

Gelin, kapalı kapılar ardındaki asıl gerçeği, Türkiye’nin (ve küresel dünyanın) yazılım “mutfağını” ve her gün masamıza gelen o sert gerçekleri kendi süzgecimden geçirelim.

1. Modernizasyon Çıkmazı: “Işıkları Açık Tutmak”

Bugün kritik sektörlerde (Sağlık, Finans, ERP) kalbimiz hala 2010 öncesi yazılmış, dokümantasyonu olmayan, devasa monolith yapılarda atıyor. Ekipleri ve bütçeleri yöneten biri olarak şunu net görüyorum:

İçeride en yetenekli mühendislerimiz (Senior/Lead seviyesindekiler bile) yeni özellikler mimarisi tasarlamak yerine, 15 yıl önce işten ayrılmış birinin yazdığı dokümansız metodun yan etkileriyle boğuşarak tükeniyor (burnout). Dışarıdan bakıldığında herkes son moda yapay zeka devrimlerinden bahsederken, bizim gerçekliğimiz çoğu zaman tam bir “Maintenance Hell” (Bakım Cehennemi).

2. Kodun Dışındaki “Karanlık Veri” (Dark Data) ve Kayıp Gereksinimler

Projelere girip kod tabanına baktığımda, iş mantığının çoğunlukla sadece temiz .cs veya .java dosyalarında durmadığını görüyorum. Benim teknik lider olarak en büyük kabuslarımdan biri, şirketin omurgasını tutan kuralların; veritabanındaki binlerce satırlık SP’lere (Stored Procedure) hapsolmuş veya konfigürasyon (XML/JSON) dosyalarına saçılmış “gizli kurallar” dizisi olmasıdır.

Standish Group’un o meşhur CHAOS Report verileri, başarısız projelerin %30-40’ının ardında “eksik veya hatalı gereksinim/iş mantığı” analizi olduğunu ortaya koyuyor. Dokümansız bir monolith yapıda, en gelişmiş yapay zeka asistanları bile sadece GitHub reposuna bakarak bu görünmez iş kurallarını çözemez. AI bize analizde inanılmaz hız katabilir ama o arkeolojik kazıyı asıl anlamlandıracak olan, yıllarını o sisteme vermiş domain uzmanlarımızdır.

3. AI, Monolith Yapılara Gerçekten “Hazır” mı?

Geçen yıl ekiplerime AI kod asistanı lisansları dağıttıktan sonra edindiğim en büyük ders şu oldu: Temel mimariniz sorunluysa, AI sadece “kötü tasarımı daha hızlı” üretmenize yarar.

Context Window ve Halüsinasyon Riski: AI asistanları belirli bir bağlam donanımına (Context Window) dayalı çalışıyor. Eğer elinizdeki dev projede her fonksiyon birbirine sıkı sıkıya bağlıysa (tightly coupled), modeli ne kadar beslerseniz besleyin o “büyük resmi” aynı anda işleyemiyor. Verinin 3 katman aşağıda nasıl mutasyona uğradığını modele sığdıramadığınızda ise halüsinasyon (hallucination) dediğimiz uydurma kod blokları başımıza dert oluyor.

Verimlilik Yanılsaması: McKinsey & Company’nin Unleashing developer productivity with generative AI raporunun söylediği şey, bizim sahadaki deneyimimizle birebir örtüşüyor: Yeni nesil mikroservis mimarilerinde (greenfield) bu yapay zeka melekleri gerçekten %50’lere varan verimlilik yaratıyor. Fakat eski, hantal “legacy” sistemlerde refactor ve kod anlama işlerine girdiğinizde, kazanç %10’un bile altına eriyip gidiyor. Çünkü AI, eski sistemde kod yazmaktan çok o kodu anlama duvarına çarpıyor.

4. Sonuç: Tofaş’a Tesla Otopilotu Takılmaz

Bir mühendislik lideri olarak artık olaya çok rasyonel bakmak zorundaym: Yapay zekayı sadece LinkedIn’de havalı “Vibe Coding” yetenekleri sergilemek ya da basit scriptler ürettirmek sığlığından çekip çıkarmalıyız. Eğer sistemlerimiz hantalsa, ilk işimiz o değerli AI kapasitesini “Modernizasyon Borcu”nu (Technical Debt) ödemek için harcamaktır.

Yönetici gözüyle ekiplerime verdiğim strateji şu şekilde:

• Dokümantasyon Üretimi: “Black box” halini almış eski kodu okutup, AI asistanlarına tersine mühendislikle dokümante ettireceğiz.
• Karakterizasyon Testleri (Characterization Tests): Monolith canavarına tek bir yeni özellik eklemeden önce, AI’a mevcut durumu koruyacak güvenlik ağını (birim ve entegrasyon testlerini) yazdıracağız.
• Bağımlılık Haritaları (Dependency Graph): Hangi servisin nereye dokunduğunu çıkarıp, “Strangler Fig Pattern” ile bu dehası ve derdi büyük monoliti güvenle ufaltacağız.