Günümüzde artık yapay zeka sistemleri ve girişimleri oldukça yaygınlaştı; hatta eminim bunu okuyan senin dahi bir yapay zeka girişimi yapıp parayı vurma niyetin vardır. Son bir yıldır ben de verdiğim danışmanlıklar vesilesiyle girişimlerin başarıya ulaşması için çaba gösteriyorum. Bu süreçte sahada gördüğüm en net tablo şu: Karşılaştığımız sorunların büyük bölümü artık sadece "kod yazabilmek" değil, işin arkasındaki mühendislik mimarisi ve operasyonel gerçeklik.
Artık yapay zeka araçlarına ve yazılıma/koda erişim çok daha kolay olduğu için insanlar bunu zahmetsiz bir fırsat olarak görebiliyor. Karşılaştığım insanların büyük bölümü zaten bir büyük dil modeli (LLM) ile fikirlerini olgunlaştırmış, çevresindeki insanlarla tartışmış ve kâğıt üzerinde "yapılabilir" olduğuna inandığı bir planla karşıma geliyor. Fakat sorunlar burada bitmiyor; tam aksine burada başlıyor.
1) Teknik Bilginin HİÇ Olmaması ve "Vibe Coding" Yanılgısı
Artık birçok girişimci, yazılım mühendisliğinin ve sistem mimarisinin önemini azımsamaya başladı. Claude veya Cursor yardımıyla birkaç saatte ortaya çıkardıkları basit web siteleri ve arkadaki spagetti kod yığını, girişimcinin özgüvenini dimdik ayakta tutarken; sistemin kendisini üretim ortamında (production) yalnızca görüntü olarak bile zar zor ayakta tutuyor.
Veritabanı şeması olmayan, asenkron yük altında (concurrency) kilitlenen, API güvenliği ve bellek yönetimi sıfır olan bir prototipin "bitmiş bir ürün" olmadığını açıklarken bile ciddi anlamda yıpranıyorum. Çalışıyor gibi görünen bir arayüz, ölçeklenebilir bir yazılım mimarisi demek değildir.
2) Finansal Fizibilitenin ve Birim Maliyetlerin Doğru Yapılmamış Olması
İlk maddede bahsettiğim, basit bir sistemi yapay zekaya yazdırmanın getirdiği özgüven ve "ben bunu kendi başıma yaparım" algısı, yapay zeka içerikli bir start-up’ın "küçük" diyebileceğimiz başlangıç masraflarıyla yüzleşince bam diye duruyor.
Her gün gelişen araçlar ve modeller, bugün benim bile inşa ettiğim bir sistemle diğer bir sistemde tamamen farklı bulut platformları, vektör veritabanları (Vector DB) veya çıkarım (inference) uç noktaları kullanmamı zorunlu tutuyor. Artan kullanıcı trafiğinde token maliyetlerinin (token billing), GPU kiralama giderlerinin ve gecikme (latency) optimizasyonunun nereye varacağını zaman zaman ben bile hesaplarken zorlanıyorum. Durum böyleyken, teknik altyapıyı bilmeyen bir girişimcinin bu birim ekonomiyi (unit economics) ve bulut maliyetlerini hesaplaması imkansız hale geliyor.
3) Ekip Yetersizliği ve Coğrafi Yetenek Açmazı
Türkiye özelinde konuşmak gerekirse, İstanbul’da onlarca yetenekli genç mühendis var. Fakat İstanbul’un endüstriyel altyapısı, sosyal olanakları, kendini geliştirme imkanları, finansal merkez olması ve hem tekniğin hem akademinin kalbi konumunda bulunması, iyi mühendisleri İstanbul’a öyle bir odaklamış ki; diğer illerimizdeki girişimciler maalesef yetersiz insanların ellerine kalmış durumda.
Anadolu’daki projelerde karşılaştığım geliştiricilerin çoğunun gerçek bir akademik ve teknik temeli olmadığını, üstelik teknik kabiliyet eksikliklerini gizlemek amacıyla girişimciye sürekli yalan söyleyen kişiler olduğunu ne yazık ki fark ediyorum. Bu yüzden en büyük illerimiz dışındaki şehirlerde çıkan sistemler, mimari ve kod kalitesi açısından çoğu zaman çöp niteliğinde. "Koyunun bulunmadığı yerde keçiye Abdurrahman Çelebi derler" diye bir söz vardır; maalesef sektörde bu sözün birebir karşılığını yaşıyoruz.
4) Hızlı Para Kazanma Hırsı ve Sürdürülebilir Yatırım Bütçesinin Oluşturulmamış Olması
İkinci maddeden farklı olarak, elinde gerçekten sermayesi ve bütçesi olan girişimcilerin bile bu tarz teknoloji girişimlerinin geleneksel esnaflıktan farklı olduğunu, yatırımın geri dönüş (ROI) sürelerinin uzun olabileceğini hesaplamamış olması ciddi sorunlara yol açıyor. Esnaflıkta veya klasik ticarette kısa vadede telafi edilebilen dönmeyen ödemeler, bir teknoloji girişiminde yapılamayan kritik altyapı yatırımlarına, o da kaçırılan pazar fırsatlarına sebep oluyor.
1 sene boyunca tek kuruş gelir elde etmeden sadece model ince ayarına (fine-tuning), veri temizliğine, sunucu maliyetlerine ve AR-GE’ye para yakmak zorunda kalabileceklerini (runway yönetimi) söylediğimde, o ilk baştaki heyecan yerini paniğe bırakıyor.
5) Tersine Çevrilmiş Mühendislik Sıralaması
Aslında bir mühendis olarak doğru ürün geliştirme sıralamasını yapsam:
- En kolay ama en kritik iş olarak fikrin şemalaştırılması, veri akışının ve sistem mimarisinin (System Design) çizilmesi,
- İkinci olarak evrak süreçleri, regülasyonlar ve mağaza/API onayları,
- Üçüncü ve son olarak sistemin teknik olarak inşa edilip; kodun, backend’in, model katmanlarının ve tüm teknik bileşenlerin bir araya getirilip kurgulanması olurdu.
Fakat girişimciler şu adımlarla ilerliyor: Claude’a bir prompt ver ve bir taslak oluştur (bunun mükemmel ve bitmiş bir ürün olduğunu düşün), hemen mağaza onayları ve deploy süreçleri için uğraşmaya başla, sistem ilk entegrasyonda patlayınca da bunalıp bir mühendise ulaş. Fark ettiyseniz, işin temeli olan fikrin şemalaştırılması ve mimari tasarım tamamen atlandı.
6) Rakiplerin Büyüklüğünün Farkında Olmamak
Bu cümle büyük oranda kendini açıklıyor fakat sahadaki tabloyu şöyle özetleyebilirim: Daha yeni işe başlamış girişimciler bile, açık kaynaklı bir modeli veya hazır bir API’yi kendi arayüzlerine bağladıklarında (AI Wrapper), arkalarında milyarlarca dolarlık GPU kümeleri (cluster), özel veri boru hatları (data pipelines) ve yüzlerce kişilik AR-GE ekibi olan küresel teknoloji devleriyle aynı kulvarda yarışabileceklerini sanıyorlar. Büyük model sağlayıcıların (OpenAI, Anthropic, Google vb.) tek bir güncelleme ile kendi girişimlerinin çözdüğü sorunu standart bir özellik (feature) olarak ücretsiz sunabileceği gerçeğini hesaba katmıyorlar.
7) Fikri Altyapının Eksik Olması Nedeniyle Hangi Fikir Değerli Hangisi Çöp Ayırt Edememek
Temel bilgisayar bilimleri, algoritma mantığı ve veri yapıları üzerine bir fikri altyapı olmadığında, girişimci hangi problemin gerçekten derin öğrenme veya makine öğrenimi gerektirdiğini, hangisinin ise basit bir if-else kural setiyle veya standart bir veritabanı sorgusuyla çözülebileceğini ayırt edemiyor. Ortada özgün bir veri seti, alan (domain) uzmanlığı veya optimize edilmiş bir RAG (Retrieval-Augmented Generation) mimarisi yokken, sadece "üzerine ChatGPT bağlanmış" sığ fikirler devrimsel bir icatmış gibi savunuluyor. Hangi fikrin gerçek bir mühendislik değeri taşıdığını, hangisinin çöp olduğunu ayırt edememek hem zamanı hem de sermayeyi sıfırlıyor.
Sonuç: Prompt Yazmakla Sistem İnşa Etmek Aynı Şey Değildir
Yapay zeka araçlarının kod üretimini hızlandırdığı ve prototipleme eşiğini düşürdüğü su götürmez bir gerçek. Ancak bir dil modeline prompt yazarak çalışan bir demo elde etmekle; binlerce kullanıcının aynı anda girdiği, gecikme sürelerinin (latency) milisaniyelerle ölçüldüğü, veri güvenliği sağlanmış ve finansal olarak kendi kendini döndürebilen bir yapay zeka ürünü inşa etmek arasında devasa bir mühendislik uçurumu var.
Bugün batan yapay zeka start-up’larının çoğu "yapay zeka çalışmadığı için" batmıyor; temel yazılım mühendisliği prensiplerini, sistem mimarisini, birim maliyet hesabını ve doğru ekip kurgusunu "artık bunlara gerek kalmadı" diyerek çöpe attıkları için batıyor. Eğer gerçekten kalıcı bir teknoloji girişimi kurmak istiyorsanız, işe bir dil modeline kod yazdırmakla değil; çözeceğiniz problemi şemalaştırmakla, maliyeti kuruşu kuruşuna hesaplamakla ve işi gerçekten bilen mühendislerle masaya oturmakla başlamalısınız.
