"Yazılım dünyasında büyük dönüşümler genellikle yavaş başlar. Sonra bir gün geriye bakarız ve aslında her şeyin çoktan değişmiş olduğunu fark ederiz."
Okuma süresi: ~12 dakika
Giriş
Yıllardır kurumların yazılım stratejisi oldukça basitti. ERP satın al. PDKS satın al. Doküman yönetim sistemi satın al. IoT platformu satın al. Kurumlar yazılım üretmezdi. Yazılım satın alırdı.
Bunun çok iyi sebepleri vardı. Yazılım geliştirmek pahalıydı, yavaştı ve ciddi uzmanlık gerektiriyordu. Bir kurumsal sistemi sıfırdan geliştirmek çoğu kurum için gerçekçi değildi.
Ama son birkaç yılda bir şey değişmeye başladı. Üretken yapay zekâ araçları yazılım geliştirme hızını dramatik biçimde değiştirdi. Küçük ekipler, geçmişte büyük yazılım organizasyonlarının aylarca geliştirdiği sistemleri günler içinde üretebilir hale geldi.
Bu değişim doğal olarak şu soruyu ortaya çıkarıyor:
Kurumlar artık kendi yazılımlarını geliştirebilir mi?
Bu yazı bu soruya mimari, süreç ve insan perspektifinden bakmaya çalışıyor.
Paket Yazılım Dönemi Nasıl Ortaya Çıktı?
1990'lı yıllarda yazılım dünyası bugünkünden çok farklıydı.
O yıllarda yazılım firmaları genellikle her müşteri için o kuruma özel yazılım geliştirirdi. Bir proje yazıldığında o proje o kurumun olurdu.
- Veri modeli o kuruma göre tasarlanırdı
- İş süreçleri o kuruma göre kodlanırdı
- Sistem o kurumun gerçekliğini yansıtırdı
Sonra yazılım üreticileri aynı sistemi farklı müşterilere satabilmenin yollarını aramaya başladı. Böylece "paket program" dönemi doğdu. ERP sistemleri, PDKS çözümleri, doküman yönetim sistemleri ve daha pek çok kurumsal yazılım bu modelle yayıldı.
Bu model ilk bakışta harikaydı.
- Geliştirme maliyeti birçok müşteri arasında paylaşıldı
- Kurumlar hızlı şekilde yazılım kullanmaya başladı
- Yazılım üreticileri ölçeklenebilir iş modelleri kurdu
Ama zaman içinde başka bir problem ortaya çıktı. Kurumların dijital dünyası silo halinde çalışan uygulamalardan oluşmaya başladı.
Entegrasyon Çağı
Bir kurum ERP kullanıyordu. Başka bir sistem PDKS tutuyordu. Başka bir sistem dokümanları yönetiyordu.
Bu sistemlerin konuşması gerekiyordu. Böylece entegrasyon dönemi başladı. Bu entegrasyonlar yıllar içinde farklı şekiller aldı:
- Veritabanı üzerinden entegrasyon
- SOAP servisleri
- REST API'leri
Ancak çoğu entegrasyon güçlü bir kontrat yönetimi olmadan geliştirildi. Sonuçta her yazılım güncellemesi potansiyel bir risk haline geldi. Bir sistem güncellendiğinde diğer sistemler bozulabiliyordu. Kurumlarda şu cümle çok tanıdık hale geldi:
"Bu sistemi güncellersek diğer sistemler etkilenir mi?"
Güncelleme Problemi
Birçok paket yazılım üreticisi sağlam yazılım geliştirme metodolojileri kullanmıyor.
- Kontrat sürümleme yoktur
- Backward compatibility çoğu zaman düşünülmez
- Dev → Test → Prod döngüsü yeterince güçlü değildir
Bu nedenle güncellemeler çoğu zaman riskli hale gelir. Birçok kurum güncelleme yaparken şunu hisseder:
Bir şeyi düzeltirken başka bir şeyi bozuyor olabiliriz.
Kurum İçi Geliştirmenin Problemleri
Paket yazılımların sınırlamaları nedeniyle bazı kurumlar kendi yazılımlarını geliştirmeye çalıştı.
Ama bu yol da kolay değildi. Kurumsal geliştirme ekiplerinin karşılaştığı sorunlar oldukça tanıdıktır:
- Backlog'da yıllarca bekleyen işler
- Küçük ekiplerle büyük sistemler geliştirme zorunluluğu
- Hızla demode olan teknoloji stack'leri
- Yeni teknolojilere adaptasyon zorluğu
- Ekip değişikliklerine karşı kırılganlık
Birçok kurum şu iki seçenek arasında sıkıştı:
- Paket yazılım esnek değildi
- Kurum içi geliştirme yavaştı
Öğrenme Problemi
Kurum içi geliştirme ekiplerinin bir başka problemi de öğrenme kapasitesiydi. Bir kurum kendi yazılımını geliştirdiğinde çoğu zaman yalnızca kendi deneyimlerinden öğrenir. Bu nedenle kurum içi uygulamalar çoğu zaman "en iyi uygulama" olarak kabul edilir.
Paket yazılım üreticileri ise farklı müşterilerden öğrenebilir. Ama onların da başka bir problemi vardır. Bir özellik tüm müşterilerin işine yaramıyorsa çoğu zaman geliştirilmez.
Bunun yerine başka bir şey yapılır:
parametrizasyon.
Zaman içinde birçok kurumsal yazılım şu hale geldi:
- On binlerce parametre
- İş akış motoru ile özelleştirme
- Karmaşık konfigürasyon ekranları
- Anlaşılması zor davranışlar
Paradigma Değişimi
Bugün yaşanan değişim yalnızca "AI ile kod yazmak" değildir.
Asıl değişim şudur:
Kurumlar artık yazılım tüketicisi değil, dijital servis üreticisi olabilir.
Ama bunun gerçekleşebilmesi için kurumların uygulama değil platform düşünmesi gerekir.
Stateless Development
AI çağında yazılım geliştirme farklı bir modele evriliyor. Bu modelin temel varsayımı şaşırtıcıdır:
Projede çalışan herkes için bugün ilk gün olabilir.
Bir geliştirici projeye yeni katılmış olabilir. Bir AI ajanı projeye yeni dahil olmuş olabilir. Akşam olduğunda ise projede olmayabilirler.
Bu model ilk bakışta kaotik görünür.
Ama sistem bilgisi insanların kafasında değil sistemin içinde tutulduğunda bu durum bir risk olmaktan çıkar. Dokümantasyon, kontratlar, testler ve mimari kararlar sistemin hafızası haline gelir.
Uzun yıllardır yazılım mühendisliğinde arzulanan bir hedef vardı:
Gerçekten stateless geliştirilebilen sistemler.
AI ile birlikte bu hedef ilk kez pratik olarak mümkün hale geliyor.
AI'nin Kolektif Öğrenme Avantajı
Bir insan geliştirici kariyeri boyunca sınırlı sayıda projede çalışır. AI sistemleri ise geniş açık kaynak ekosisteminden öğrenir.
Bu nedenle bazen tek bir insanın sahip olamayacağı kadar geniş bir perspektif sunabilir. Bu AI'nın her şeyi bildiği anlamına gelmez.
Ama farklı yaklaşımları karşılaştırabilen bir kolektif deneyim sağlar.
Çoklu AI Ajanları ile Geliştirme
Bugün bir projede üretken şekilde çalışmak için çoğu zaman şunlar yeterlidir:
- İki farklı AI sağlayıcısından ajan
- Bir insan geliştirici veya mimar
İşin ilginç tarafı şu:
Bu insan ve AI ajanların her biri için o gün projedeki ilk gün olabilir. Akşam olduğunda ise projeden ayrılmış olabilirler. Ama sistem ayakta kalır.
Çünkü bilgi bireylerde değil sistemdedir.
AI Ekosisteminin Hızla Evrilmesi
Bugün konuştuğumuz pratikler altı ay sonra farklı bir noktaya evrilmiş olacak. AI gelişimi doğrusal değil logaritmik ilerliyor. Yakın gelecekte projelerde şu tür uzman AI ajanları görmek şaşırtıcı olmayacak:
- Veri ambarı uzmanı AI
- Güvenlik mimarı AI
- Performans analizi yapan AI
- Yalın süreç uzmanı AI
Bugün kurumların istihdam etmekte zorlandığı uzmanlıklar projelere kolayca dahil olabilir. Bir sonraki adım ise AI ajanlarının birbirleriyle doğrudan iletişim kurabilmesi.
Sonuç
İnsan meraklı bir varlık.
Aynı anda umut ile korku arasında yaşayan, yeni şeyleri denemek isteyen ama risklerden çekinen bir bilinç. AI çağında yazılım geliştirme de tam olarak bu duyguların arasında şekilleniyor.
Ama bir gerçek giderek daha görünür hale geliyor. AI yazılım üretimini demokratikleştiriyor.
Kurumlar artık yalnızca yazılım satın almak zorunda değil. İsterlerse kendi dijital platformlarını kurabilirler.
Ve bu platformlar yalnızca insanlar tarafından değil,
insanlar ve AI ajanlarının birlikte çalıştığı yeni bir üretim modeliyle geliştirilebilir.
AI çağında en büyük risk yanlış karar vermek değildir.
En büyük risk hiç başlamamaktır.
Yazarın Notu
Bu metni kaleme alan insan tarafı olarak şunu açıkça söylemek isterim.
Bu yazıda anlatılan tarih yalnızca kitaplardan veya arşivlerden derlenmiş bir teknoloji kronolojisi değildir. Bu satırları yazan kişi, burada bahsedilen dönemlerin tamamında aktif olarak çalışmış bir yazılım geliştirici, sistem mühendisi ve yazılım mimarıdır.
1990'lı yıllarda kurumlara özel yazılım geliştirilen dönemde de vardım. Paket yazılımların yükselişini de yaşadım. SOAP servislerinin entegrasyon mucizesi olarak görüldüğü günleri de hatırlıyorum. REST API'lerin ortaya çıkışını da. Ve her birinin beraberinde getirdiği sorunları da.
Bu nedenle bu metindeki birçok gözlem tekil bir örneğe dayanmıyor. Çoğu hüküm yıllar boyunca farklı kurumlarda, farklı projelerde, tekrar tekrar yaşanmış deneyimlerin ortak sonucudur.
Bazen genç geliştiriciler "yeni geldik diye eksik miyiz" diye sitem edebiliyor. Elbette değiller. Her nesil kendi zamanının araçlarıyla dünyayı yeniden kurar.
Ama yazılım dünyasında bazı kalıplar onlarca yıl boyunca tekrar eder. Bu yazı o tekrar eden kalıpların içinden konuşuyor.
Dolayısıyla burada anlatılanlar bir arşiv taramasının sonucu değil, uzun bir mühendislik pratiğinin içinden süzülmüş gözlemlerdir.
Not
Bu makale, insan ve yapay zekâ arasında gerçekleşen uzun bir fikir alışverişinin sonucunda ortaya çıktı. Sorular, itirazlar, karşı argümanlar ve yeni fikirlerle birlikte şekillendi.
AI ile düşünmek yalnızca metin üretimini değil, fikirlerin olgunlaşma hızını da değiştiriyor.
