Yeni bir backend sürümü için ship.sh ile deployment başlattım. Lakin sunucu bir türlü ayağa kalkmıyor. Dakikalarca EventListener içinde bekliyor.

Konvansiyonel yöntemlerle bu problemi nasıl çözerdim?

Thread dump alarak.

Thread dump içinde çalışan tüm thread’lerin stack trace’lerini görebilir, sistemin nerede takıldığını veya bir deadlock olup olmadığını analiz edebilirim.

Bunun için sunucuya bağlanmam, gerekli komutları hazırlamam, thread dump almam, kendi bilgisayarıma aktarmam, bir thread dump viewer ile açmam ve analize başlamam gerekirdi.

Bu analiz belki bir saatimi bile alabilirdi.

Eğer oradan bir sonuca ulaşamazsam, bir sonraki adım olarak heap dump ile devam ederdim.

Bunların hiçbirisini yapmadım tabii ki. ;-)

GPT’ye sadece şunu söyledim:

“Sunucu ayağa kalkmıyor, analiz et.”

Nasıl analiz etmesi gerektiği konusunda hiçbir bilgi vermedim.

Şu anda kendi kararıyla thread dump almış ve onu inceliyor.

Yani ben ona çözüm yöntemini tarif etmedim. Problemi tarif ettim.

Hangi teşhis aracını kullanması gerektiğine, hangi verileri toplaması gerektiğine ve bunları nasıl analiz edeceğine kendisi karar verdi.

Ben bu satırları yazarken muhtemelen çözümü de implemente ediyordur.

Dur, bir bakayım. :)

Aklın yolu birdir. Yapay zekada çorbayı bizim gibi şu ile yapıyor. Ondan başka bir şey beklememek gerekiyor. Sadece daha hızlı düşünüyor ve yapıyor. Ben yazılımcı olarak thread dump nedir, nasıl alınır, nasıl analiz edilir sorularına cevap veremiyorsam, yapay zekanın çalışma şeklini anlayamam, anlamdıramam ve yönlendiremem. Bu yüzden sadece iyi bir mühendis iyi bir yapay zeka kullanıcısına dönüşebilir.

Bir production bug’ın çözülmesi günler, hatta haftalar alabilir.

Çünkü bug’ın kendisini düzeltmek, sürecin sadece küçük bir parçasıdır.

Önce problemin fark edilmesi gerekir. Sonra anlaşılması ve kategorize edilmesi.

Ardından önceliğinin belirlenmesi, bir ticket’a dönüştürülmesi ve bir yazılımcıya atanması gerekir.

Yazılımcı problemi yeniden analiz eder, ilgili kodu bulur, çözümü geliştirir, test eder ve deployment süreci başlar.

Yani production bug çözmek şimdiye kadar pahalı bir işti. ;-) Çünkü sürecin her aşamasında insan vardı ve her insan sisteme yeni bir bekleme süresi ekliyordu.

Yapay zeka ajanlarıyla bu zincirin büyük bölümü ortadan kalkabilir:

Bug oluşur → tespit edilir → analiz edilir → ilgili kod bulunur → fix hazırlanır → testler çalıştırılır → çözüm doğrulanır → ve yeni deployment

Bütün bunlar aynı bağlamı paylaşan ajanlar tarafından ardışık ve otonom olarak gerçekleştirilebilir.

Hemen kendimden örnek vereyim, çünkü benim buradaki paylaşımlarımın temelinde bu konularda yaptığım somut tecrübeler yatıyor.

Biraz önce yeni bir uygulama içindeki icon upload kısmını kullanmak istedim. Ama her defasında yetkiniz yok reddini aldım. Hemen Gpt’ye sordum, burada ne oluyor diye. O da hemen nokta atışı CORS tanımlamarında PUT’un eksik olduğunu hemen bunu fix’leyebileceğini söyledi. Hemen hallet sonra yeni sürümü deploy et dedim. Aynen de öyle yaptı. Hatayı keşfedip, canlıya yeni bir sürüm almak toplamda 10 dakika sürmedi. Uygulama yeni hali ile şu anda deploy ediliyor ve ben biraz sonra icon upload yapabileceğim.

Daha önce günlerle, bazen haftalarla ölçülen bir süreç artık dakikalarla ölçülebilir.

Asıl devrim yapay zekânın daha hızlı kod yazması değil.

Yazılım geliştirme süreçlerindeki bekleme sürelerini ortadan kaldırması.

Bugün bir yazılımcı ile iş görüşmesi yapsam, kendisine neredeyse hiçbir şey sormazdım.

Önüne bir bilgisayar koyardım.

Bilgisayarda Codex ve Claude Code hazır olurdu. Bunun yanı sıra uygulamalarımızın kaynak kodlarına da erişimi olurdu.

Sonra:

“Canlıda şöyle bir problem çıktı. Düzeltin lütfen” der ve sadece yaptıklarını seyrederdim.

Ardından Jira’dan gerçekçi bir ticket açardım:

“Bunu implemente edin lütfen.”

Bu kadar.

Bu iki işlem sırasında aslında bilmek istediğim hemen hemen her şeyi görürdüm:

– Problemi nasıl analiz ediyor?

– Kod tabanında nasıl geziniyor?

– Yapay zekaya ne kadar doğru bağlam verebiliyor?

– Doğru soruları sorabiliyor mu?

– AI’ın ürettiği çözümü körü körüne kabul mü ediyor, yoksa sorguluyor mu?

Test ediyor mu?

– Mevcut mimariyi anlayıp ona uygun hareket edebiliyor mu?

– Bir hata çıktığında AI ile birlikte nasıl debug ediyor?

– Ve en önemlisi: AI’ı bir sohbet robotu olarak mı, yoksa gerçek bir mühendislik aracı olarak mı kullanıyor?

Yapay zekaya gerçekten aşina bir aday için bunlar günlük iş akışının doğal parçalarıdır.

Aşina olmayan bir aday içinse aynı görevler bir anda Kaf Dağı’na dönüşebilir.

Bence artık yazılımcı mülakatlarında “Ne biliyorsun?” sorusundan çok daha önemli bir soru var:

“Elindeki yapay zeka ile ne yapabiliyorsun?”

Gelelim başka bir kutsal akdin demistifiye edilmesine:

“Sadece ürünün gelişmiş ve stabil hali sürüm olarak canlıya alınır. Onu stabilize etmek için her şey mübahtır.”

Yanlış!

Yazılım geliştirmek çok maliyetli olduğu için, sürüm oluşturmak ve canlıya almak da bu maliyet dünyasının bir parçasıydı.

Bir değişikliği üretmek pahalıydı. Test etmek pahalıydı. Hataları bulmak ve düzeltmek pahalıydı. Release hazırlamak pahalıydı. Bir şey ters giderse geri dönmek daha da pahalıydı.

Dolayısıyla doğal çözüm şuydu:

Değişiklikleri biriktir → test et → stabilize et → paketle → sürüm oluştur → canlıya al.

Böylece release’in kendisi bir olaya dönüştü.

Ama yapay zeka yazılım üretme maliyetini dramatik biçimde düşürüyorsa, sadece kod yazma biçimimiz değil, release mantığımız da değişmek zorunda.

Artık soru şu olmayabilir:

“Bu sürüm canlıya alınacak kadar stabil mi?”

Asıl soru şu olabilir:

“Bu değişikliği neden hala canlıya almadık?”

Küçük değişiklikler, küçük riskler, otomatik testler, feature flag’ler, observability, hızlı rollback ve yapay zeka destekli geliştirme…

Bunların birleştiği dünyada amaç mükemmel ve büyük sürümler üretmek değil;

değişiklik ile production arasındaki mesafeyi mümkün olduğunca sıfıra yaklaştırmak.

Belki de demistifiye edilmesi gereken şey “release” kavramının kendisidir.

Eskiden büyük şirketler küçük şirketleri yutardı.

Sonra teknoloji gelişti. Küçük şirketler, büyük şirketler için ciddi birer tehdit olmaya başladı.

Şimdi yapay zeka geldi.

Yeni dönem bence daha farklı olacak:

AI-native şirketler, AI-native olmayan şirketleri zorlayacak.

Neden?

Çünkü AI-native bir şirket sadece yapay zeka kullanan şirket değildir. Ürün geliştirmesini, operasyonlarını, pazarlamasını, müşteri hizmetlerini, analizlerini ve karar mekanizmalarını en başından yapay zeka etrafında tasarlayan şirkettir.

Böyle bir şirket daha az insanla daha fazla iş yapabilir.

Ama bence asıl büyük avantajı bu bile değil.

Asıl avantajı değişim hızıdır.

Piyasa değişir → adapte olur.

Müşteri beklentisi değişir → ürünü değiştirir.

Yeni bir fırsat çıkar → dener.

Çalışmaz → geri döner.

Çalışır → ölçekler.

Bunların hepsini klasik organizasyonlardan çok daha hızlı yapabilir.

Bugün bir şirket kuruyorsanız, yapay zekayı şirketin etrafına eklenen bir araç olarak değil, şirketin merkezindeki işletim sistemi olarak düşünmeniz gerekiyor.

Mevcut bir şirketiniz varsa iş daha da zor. Çünkü yıllardır oluşmuş süreçleri AI-native hale getirmek, sıfırdan AI-native bir organizasyon kurmaktan bazen daha zor olabilir.

Bu yüzden radikal bir yöntem bile düşünülebilir:

Mevcut şirketinizin yanında ikinci, tamamen AI-native bir yapı kurun. Eski şirketin bilgisini, müşterilerini, ürünlerini ve tecrübesini bu yeni yapıya taşıyın. Ama eski çalışma biçimini taşımayın. Yeni şirketi baştan AI-native tasarlayın.

Ve dönüşüm tamamlandığında eski yapıyı kapatıp yenisiyle devam edin.

Çünkü önümüzdeki dönemde rekabet avantajı sadece yapay zeka kullanmak olmayacak. Rakibinizin haftalar içinde yaptığı değişikliği saatler içinde yapabilmek olacak.

Kod yazma, okuma devri kapandı dedik. Tepkiler gecikmedi. Lakin hakikatler kendini kısa sürede gösteriyor.

Yazılımcıların bilimum çalışma yöntemleri tepe taklak olmuş durumda.

Bu yazılım mühendisliğinin sonu değil. Tam tersine, artık daha fazla mühendislik söz konusu, çünkü yazılımcılar sistemler inşa etmeye odaklanacaklar. Bunun için de mühendislik yetileri gerekiyor.

Tabi yapay zekadan tek nasibini alan sadece yazılımcılar değil.

Sıra devops’larda ;-)

Sağolsunlar, devops takım arkadaşlarımız otomasyon teriminin kitabını yazdılar.

Ama yapay zeka ile artık otomasyon başka bir seviyeye çıkıyor.

Eskisi gibi sürüm yap, deploy et, monitör et, hataları bu işleri devri de artık kapanmıştır.

Devops’lar onlarca araç kullanarak bu seviyede, çoğu şeyi elden yaparak çalıştılar.

Artık ihtiyaç duydukları tek araç yapay zeka ve bu aracın canlı ortamları için nasıl efektif kullanılabileceği.

Kendimden örnek vereyim. Bu yazıyı da aslında aynı sebepten dolayı kaleme alıyorum, çünkü yapay zeka güzel ama canlıda durum farklı diyenlerin artık çok da haklı olmadıklarını bir örnekle açıklayacağım.

Şimdi bir ürün sürümünün canlıya alış sürecini düşünün. Bu sürümü oluşturmakla başlar, canlıda ilk health smoke testlerine kadar sürer. Akabinde loglar, servisin kendisi, performansı vs monitör edilir. Bir hata oluştuğunda yazılmcılar için bir jira ticket açılır ve konu devops için kapanır. Buraya gelmeden önce de devops ekibi uygulama için gerekli altyapıyı hazırlar. Bu fiziksel donanımın tahsisi ile başlar, işletim sistemi kurulumu ve hardening ile devam eder, akabinde ansibel, nginx, postgres vb altyapı kurulumu ile son bulur. Bu yapıyı oluşturmak için onlarca, yüzlerce bash, python, perl script oluşturulur.

Eski düzen böyle idi.

Yeni düzende çalışma tarzı şu şekilde olacak.

Ben: gpt uygulamın yeni sürümünü deploy et.

Benim örneğimde Gpt ssh üzerinden sunuculara doğrudan ulaşabiliyor.

Release ve deployment için gerekli scriptleri oluşturmasını sağladım. Aslında bu scriptleri koşturuyor, logları kontrol ediyor. Gpt tam anlamıyla sunucular üzerinde neler olup, bittiğini uzaktan takip edebiliyor.

Bu yüzden Gpt’nin sürüm oluşturması, uygulamayı sunucuya deploy etmesi, deployment esnasında oluşan hataları yakalayıp, düzeltmesi, sonrasında logları okuyarak, uygulamanın durumunu takip etmesi onun için çocuk oyuncağı.

Benim belki saatler sürecek araştırma sonunda bulabileceğim bir root cause problemi anında buluyor ve bu problemi çözmek için atılması gereken adımları öneriyor.

Aynı şekilde sunucu tahsisi ile başlayan altyapı kurma çalışmalarını da Gpt’ye yaptırdım. Benim 2 hafta içinde kuracağım bir cluster sistemini 12 saat içinde sıfırdan kurdu.

Peki devops rolü bitti mi? Hayır! Yazılımda olduğu gibi ne yapılmasını çok iyi bilen, tecrübeli devops’lara ihtiyacımız var. Sadece onlar bu otomasyonu bir adım öteye götürebilirler.

Canlı tecrübesi olmayanlar!

Daha önce sürüm yapıp, canlı deployment’i, bir canlı problemi için kök neden analizi, thead ya da ya heapdump ya da memory leak analizi yapmamış ve gerekli monitoring ve tracing altyapısını kurmamış birisi süper bir uygulama da geliştirse, onu canlıda işletemeyeceği için bu alandaki faaliyetlerinin hiçbir anlamı yoktur.

Lokalde çalışıyor söylemine başvuranlara selamlar.

Evet, yeni ortaya çıkan bir yapay zeka söylemini de demistifiye edelim.

Söylem şöyle:

“Yapay zeka ile geliştirilmiş uygulamalar canlıda patlar ve sen ne yaptığını bilmiyorsan başın büyük beladadır.”

Doğru.

Ama insan tarafından geliştirilmiş uygulamalar da canlıda patlar.

Bu yüzden onlarca yıldır yazılım mühendisliğinde şu mekanizmaları oluşturuyoruz:

– Automated tests

– E2E tests

– Static analysis

– Monitoring

– Logging

– Metrics

– Tracing

– Health checks

– Feature flags

– Canary deployments

– Blue/green deployments

– Automated rollback

– Load balancing

– Redundancy

Bunların varlık sebebi zaten yazılımcının yazdığı kodun hatasız olduğuna güvenmememizdir.

Yapay zeka burada yeni bir problem ortaya çıkarmadı. Sadece kod üretim hızını dramatik şekilde artırdı.

Dolayısıyla artık asıl soru:

“Yapay zekanın yazdığı kodu tamamen anlayabiliyor muyum?” değil.

Asıl soru:

“Bu sistem yanlış davrandığında bunu tespit edecek, etkisini sınırlandıracak ve sistemi tekrar sağlıklı duruma getirecek mekanizmalarım var mı?”

Eğer cevabınız hayır ise, kodu yapay zekanın yazmış olması probleminiz değildir.

Probleminiz software engineering’dir.

Yapay zeka çağında iyi yazılım mühendisi, sistemdeki her satır kodu bilen kişi olmak zorunda değil.

Sistemin doğru çalışıp çalışmadığını nasıl kanıtlayacağını, yanlış çalıştığında bunu nasıl göreceğini ve nasıl kontrol altına alacağını bilen kişi olmak zorunda.

Ve tam da bu yüzden yapay zeka ile otonom yazılım geliştirmek için çok iyi yazılım mühendisi olmak hâlâ son derece önemli.

Tam otonom yazılım yani kod yazmadan, okumadan ajanların software factory tarzı ve loop engineering ile ürün çıkardikarı bir ortam için gerekli olan şeyler:

1. Tecrübeli ve gidişata hükmedip, yönetebilecek bir senior yazılımcı

2. Bu şahsın ne istediğini ya da müşterinin ne istediğini çok iyi bilmesi

3. İyi gereksinim analizi ve code review yapabilen bir llm (örneğin gpt sol/astra)

4. İyi kod yazabilen bir llm (örneğin opus)

5. İyi tanımlanmış ve teknik detayları ihtiva eden bir CLAUDE.md dosyası

6. Projenin altyapısını kurgulamak için oluşturulmuş referans mimarı

7. Referans kaynaklı, elden implemente edilmiş birkaç modül

8. Software factory pattern ve loop engineering yöntemini kullanabilmek için oluşturulmuş döngü mekanizması ve analiz yapan dil modeli ile oluşturulmuş geniş kapsamlı çalışma paketleri

9. Api hardening ve rate limiting çin gerekli kuralların tanımlanmış olması

10. Test türlerinin ve kapsama alanlarının tanımlanmış olması

11. Ürünü kabul etmek için kullanılacak onay/kabul kriterlerinin tanımlanmış olması

12. Onay/kabul kriterlerini testlere dönüştürüp, koşturabilecek bir test çatısı oluşturulması

13. Sürüm oluşturmak ve canlı deploment için gerekli mekanizmanın oluşturulması (release.sh, deploy.sh; kısaca ship.sh)

14. Canlıda smoke testlerin koşturulabileceği yapının oluşturulması

15. Canlıda log dosyaların ve oluşan hataların dil modelleri ile paylaşımı ve bugfix döngülerinin kurgulanması

16. Uygulamanın karşıladığı her isteği bir traceİd ile işaretlenmesi; bu daha sonra tüm istek zincirini topluca görselleştirmek ve analiz etmek için dil modellerinin kullanacağı en etkili araç olacaktır

17. Monitoring için grafana, prometheus, zıpkın ve graylog gibi araçların kullanımı.

Şimdi loop.sh komutunu girerek, döngüyü başlatabilirsiniz. Hiçbir şeye müdahil olmadan uygulama ihtiva ettiği özelliklere göre 24/36/48/72 saat içinde tamamlanmış olacaktır.

Not: bu vibecoding değildir. Bu ne istediğıini net olarak bilen, bunun karşılığı çıktıyı alabilmek için gerekli kontrol ve yönlendirmeleri yapabilen, ürünü canlıya alıp, orada işletebilecek altyapıyı kendisi kurabilen birisinin yeni çalışma tarzıdır.

Eski yazılım mühendisliği dünyası ile yeni, yapay zeka destekli yazılım mühendisliği dünyası arasında muazzam bir çatışma ve çakışma yaşanıyor.

Bunu burada paylaştığım yazılara gelen yorumlarda da açıkça görüyorum.

Siz kör birisine mavi rengin nasıl göründüğünü anlatamazsınız.

Aynı şekilde, eski yazılım mühendisliği dünyasından gelen birisine, yeni yapay zeka destekli yazılım dünyasının sunduğu imkânları anlatmak da çok zor.

Çünkü bazı şeyleri anlamak için onları deneyimlemek gerekiyor.

Eskimiş bir perspektiften bakıyor olmak kötü. Ama daha da kötüsü, o perspektifin eskidiğinin farkında olmamak.

Yapay zeka, yazılım mühendisliğinde sadece kullandığımız araçları değiştirmiyor;

yazılım geliştirme biçimimizi, hızımızı, soyutlama seviyemizi ve hatta yazılım mühendisinin rolünü değiştiriyor.

Bu yüzden mesele birkaç yeni AI aracı öğrenmek değil.

Mesele, yeni yazılım mühendisliği dünyasına geçmek.

Ve bence bunun için fazla vaktimiz yok.

Bir programcının hataları anlama (root cause analizi) ve bugfix yapma hızını düşünün. Programcıların takılıp, kaldığı en belirgin alanlar bunlardır: troubshooting, root cause analizi ve bugfix.

Bunun nedeni nedir?

Programcıların yapay zekaya kıyasla sahip oldukları bağlam kapasitesi.

Ben yapay zekaya milyon satırllık logları bir seferde yükleyip, ana root cause analiz yap diyebilirim. Bu onun 5 dakikasını alır. Sonraki 5 dakika da bugfix yaparak, sorunu ortadan kaldırır ya da tavsiyelerde bulunarak, hatanın giderilmesini sağlar.

Aynı şeyi bir programcı ile yapın. Nasıl bir sonuç alırsınız? Sonuç alıp, almama garatiniz yok. Muhtemelen analiz ya yapılamayacak, çünkü çok karmaşık bir sistemden bahsediyoruz ya da bu analiz çok zaman alacak, çünkü programcının zihninde gerekli mental modeli oluşturması için veriye ihtiyacı var yani milyon satırlık loglara ve koda. Önce onları okuması, sonra anlaması sonra gerekli bağlamı oluşturması gerekiyor. Makina bunu dakikalar içinde yaparken, insan günlerce uğraşabilir.

Bu yüzden yapay zeka çok daha hızlı analiz yapabilir ve çok hızlı da bugfix. 

Ben canlıdaki runtime analizinin yapay zeka araçları için biçilmiş kaftan olduğunu düşünüyorum. Bu amaçla Gpt ve Opus’un canlı ortamında oluşan tüm verilere Grafana, Prometheus, Zıpkın ve Graylog üzerinden oluşmasını ve analiz etmesini sağlayacağım. Bu şekilde oluşan hataları anında lokalize etme, gerekli bugfixleri yapma, yeni bir sürüm oluşturma ve uygulamayı yeniden deploy etmeleri mümkün olacak. Kod bazında refactoring neyse, runtime bazında refactoring de bu olacak.

Yavaş yavaş yapay zeka karşıtı savunmalar runtime’a doğru kaymaya başladı.

İlk zamanlar kod yazmaya gerek yok dediğimizde, “olur mu öyle şey, kod yazabilmek her zaman önemlidir ve yapay zeka bir yere kadar yazabilir” karşılığı veriliyordu.

Sonra kod yazmama olayı kabul gördü bu argüman cephesi kod review tarafına çekildi. Review yapmak hala şarttı ve bunu insanlar yapmalıydı.

Ben artık kod yazmaya gerek kalmadığı gibi kod okumaya da gerek kalmadii iddiasını savunuyorum. Buna karşılık olarak runtime’a bir exception gelirse, yok şu olursa, yok bu olursa gibi argümanlar geliyor. Kodu okuyabilip, düzeltebilmeliymişiz. Yani karşıtlık cephesi bu noktadan itibaren runtime’e taşınmış durumda.

Ben buna da bir karşılık verme idiasındayım. Artık buna da gerek yok, çünkü yapay zeka runtime logları üzerinden çok kolay bir şekilde akışı oluşturup, gerekli hataları tespit ettikten sonra gerekli buğfixleri yapabilir. Aslında yapay zekanın parlayacağı en doğal ortam runtime ortamı olacak, çünkü orada canlı, canlı olup, biteni takip edebilecek, öngörüler yapacak, gerekli adaptasyonları implemente edecek ve tavsiyelerde bulunacak. 

Yeni iddiam yapay zeka çok daha hızlı ve daha iyi buğfix yapabilir.

Bakalım bu noktada yapay zeka karşıtı savunmalar nereye çekilecek.

Runtime’dan sonra gidecek fazla bir yerleri kalmadı. Bence yapay zeka gerçeklerini artık kabullenmek gerekiyor.

Şimdi çok komplike olan bir sürecin nasıl bir komut ile halledilir hale geldiğinden yani kompozisyon ve soyutlamanın nelere kadir olduğundan bahsetmek istiyorum.

Bir ürün için release ve deployment sürecini düşünün. Sürüm için bir ürüne, deployment için bir altyapıya ihtiyacınız var.

Siz sadece release.sh komutu ile bir sürüm oluşturup, deploy.sh ile bunu altyapınıza deploy ediyorsunuz.

Bu ikisi, özellikle deploy.sh komutu çok karmaşık bir yapıyı çok basit bir şekilde kullanılır hale getiriyor.

deploy.sh komutunun çalışabilmesi için bir sunucuya, onun üzerinde bir işletim sistemine, sunucuya erişmek için ssh’ya, sunucu üzerinde uygulanın çalışma ortamı ayarlarına, deployment işlemi öncesinde kimin bu işi yapabileceğine karar veren bir identity servisine (SSO; Single Sign On), tanımlı rol ve yetkilere, ürün için nginx, postgres, redis gibi altyapı komponentlerine, deployment sürecini yöneten ve hata oluşması durumunda sürümü geri alabilen (rollback) bir araca ihtiyacınız var. Burada uzatmamak için networking, security ve ölçekleme konularına girmedim bile.

Sadece deploy.sh diyebilmek için kocaman bir altyapı dünyası kurmanız gerekiyor. Deploy yapan şahsın bunların hiçbirinden haberi bile olmak zorunda değil.

Benim örneğimde önce release.sh ile bir sürüm oluşturuyorum, akabinde deploy.sh ile sunuculara bu versiyon yükleniyor ve son adımda upload.sh ile oluşan tüm sürüm dosyaları versiyonlu olarak artıfact repository’ye yükleniyor. Bu üç adımın arka arkaya atılması gerekiyor.

Yazılım geliştirme aslında büyük ölçüde kompozisyon ve soyutlama üzerine kurulu. Durum böyle ise, benim bu üç adımı tek bir adıma dönüştürmem gerekir.

Yine benim örneğimde bunun karşılığı ship.sh. Tek bir komut ve altında kocaman bir okyanusvarı bir yapı.

Buraya nasıl geldim?

Önce yapmak istediklerim hakkında bir fikrim vardı. Sonra bunu netleştirdim ve ürünü geliştirdim. Daha sonra gerekli altyapıyı kurdum. Üzerine identity servisini inşa ettim. Akabinde release, deploy ve upload mekanizmasını oturttum. Şimdi sadece ship.sh yazarak, istediğim ürünü, istediğim yere deploy ediyorum. 

Dışardan bakınca tek bir script gibi duruyor: ship.sh

Karmaşıklık ortadan kalkmadı. Organize edildi ve görünmez hale getirildi.

ship.sh sadece bir kompozisyon ve geldiğim soyutluk seviyesine işaret ediyor. Onun altında release/deploy/upload soyutlamaları vardı. Yani soyutlamalar da bir zaman sonra yeni soyutlamalar yapmak için yapı taşına dönüşüyor.

Ben bir zaman sonra şu ürünü canlıya al komutunu sesli olarak beyan edeceğim. Yapay zeka aracı ship.sh komutunu koşturacak ve bu tek cümlenin altında yüzlerce, hatta binlerce teknik işlem gerçekleşiyor olacak.

Son 30 yılda yazılımda olan gelişmeler bu prensibe dayanıyor. Karmaşıklık yok olmuyor, sadece aşağıya doğru taşınıyor.

Programcılığın kısa bir geçmişine bakalım:

Delikli kartlar → Assembly → yüksek seviyeli diller → framework’ler → low-code/no-code → yapay zekâ ile doğal dil

Neden makineler ile münasebetimizi doğal dillere kadar taşıdık?

Doğal dille programlama aslında aniden ortaya çıkmış bir devrim olmayabilir. 70-80 yıldır ilerlediğimiz yönün mantıksal sonucu olabilir.

İnsan doğası gereği etrafını düşündüğü kadar, kullandığı dil ile de algılıyor. İnsan konuştuğu dil ile düşünüyor, kavramlar oluşturuyor ve dünyayı bu kavramlar üzerinden anlamlandırıyor.

Bu yüzden makinelere hükmetmek için geliştirdiğimiz dilleri de zaman içinde kendi dilimize yaklaştırdık.

İlk başlarda insan makinenin dilini öğrenmek zorundaydı. Sonra programlama dilleri makinenin dilinden uzaklaşıp insanın düşünme biçimine yaklaşmaya başladı.

MOV, JMP gibi makineye yakın komutlardan if, else, while, class, person, customer, order gibi insana ait kavramlara geldik.

Java, Python veya başka bir yüksek seviyeli programlama dili bu açıdan sadece teknik bir gelişme değildi. Aynı zamanda insanın makineye:

“Ben senin gibi düşünmek istemiyorum, sen beni anlamaya çalış.”

deme çabasıydı.

Yapay zekâ ile belki de bu uzun yolculuğun en önemli eşiğini geçiyoruz.

70-80 yıl boyunca programlama dillerini insana yaklaştırdık.

Şimdi ise ilk defa programlama dilini aradan çıkarmaya başlıyoruz.

Makineye nasıl yapacağını anlatmak yerine, kendi dilimizde ne istediğimizi anlatıyoruz.

Belki de yapay zekâ ile değişen şey programlamanın kendisi değil. İnsan ile makine arasında kimin kimin dilini öğrenmek zorunda olduğu.

Yapay zeka ile çalışmaya başlayan birisinin tipik dönüşüm evreleri:

1.) Hiçbir yapay zeka aracı kullanmadan önceki evre:

“Sadece bir hype, cok gördük.”

2.) İlk temas:

“OMG.”

3.) Yapay zeka araçları ile ilk ciddi çalışma:

“Bu benim işlerimi gerçekten hızlandırıyor.”

4.) Günlük kullanım:

“Bunu daha önce nasıl yapıyordum?”

5.) İş yapış biçiminin değişmesi:

Artık yapay zekayı mevcut iş akışına eklemez. İş akışını yapay zekanın etrafında yeniden tasarlamaya başlar.

6.) Delegasyon evresi:

“Bunu neden ben yapıyorum ki?”

Yapay zekaya soru sormaktan, yapay zekaya iş vermeye geçer.

7.) Orkestrasyon evresi:

Tek bir modelle çalışmak yerine farklı modelleri, agent’ları ve araçları birbirine bağlamaya başlar. Kendisi işi yapan değil, işi yapan sistemi yöneten kişiye dönüşür.

8.) Otonomi evresi:

Promptlar uzamak yerine kısalmaya başlar. Çünkü sistem artık bağlamı, kodu, kuralları ve hedefleri bilir. İnsan giderek daha az “nasıl yapılacağını”, daha fazla “ne yapılacağını” tarif eder.

9.) Son evre:

Yapay zekayı artık bir araç olarak görmez.

Onu, istediği kadar scale edebildiği yeni bir tür iş gücü olarak görmeye başlar.

Ve sonra dönüp ilk evrede söylediği cümleyi hatırlar:

“Sadece bir hype, çok gördük..” 😄

Çok az yapıldığına şahit olmakla birlikte, eskiden nasıl refactoring yapılırdı?

Testler yoksa zaten refactoring diye bir şey söz konusu olamazdı. Testler olsa bile çok büyük çapta refactoringler yapıldığına şahit olmadım. Genelde bir sınıf ya da metot bazında refactoring işlemleri yapılırdı, çünkü oluşacak yan etkilerin tespit edileceğinin garantisini kimse veremezdi.

Oysaki yıllarca SRP, OCP, DIP yani SOLID ile mükemmel mimariler oluşturduk, tüm implementasyonları gizledik, dışarıya tanımlı API’ler sunduk, Spring ile dependecy injection yaptık.

Peki refactoring yapmayacaksak neden bu kadar refactor edilebilir mimariler oluşturduk? Çünkü yapabildiğimiz için.

Kodun yeniden yapılandırılması yani refactoring dış davranışı değiştirmeden, iç implementasyonu yenileme işlemidir. Buradaki amaç implementasyonun mevcut gereksinimleri kapsayacak şekilde yenilenmiş olmasıdır.

Hep OCP (open closed principle) ya da DIP (dependency ınversion principle) mevcut implementasyonu gelecek yeni gereksinimlere açık tutmak için varmış gibi algılandı ve uygulandı. Oysaki bu tasarım prensipleri daha iyi refactoring yapabilmek için vardır. Ama yazılımın bu kısmı çok kişiyi ilgilendirmediği ve SOLID ile kod yazmak daha zevkli olduğu için işin sadece kod yazma kısmına konsantre olundu.

Sonuç: koca koca, yeniden yapılandırılamayan, extend edilemeyen, hantal monolitler.

Bu yüzden bir uygulamanın ömrü on sene ile sınırlı hale geldi.

Ama yapay zeka ile durum tamamen değişti. Artık kodu yeniden yapılandırmak bir maliyet ve zaman problemi olmaktan çıkmaya başladı.

Eskiden aylar sürebilecek, kimsenin dokunmaya cesaret edemediği bir monoliti bugün yapay zeka desteğiyle parça parça yeniden yapılandırmak mümkün.

Üstelik yapay zeka sadece kodu değiştirmiyor. Mevcut sistemi analiz edebiliyor, bağımlılıkları tespit edebiliyor, testler oluşturabiliyor, refactoring işlemini gerçekleştirebiliyor ve ardından testleri tekrar çalıştırarak dış davranışın değişmediğini kontrol edebiliyor.

Bu aslında refactoring’in yıllardır vaat ettiği seydi:

Dışarıdan aynı sistem, içeride tamamen farklı bir implementasyon.

Bence yapay zekanın yazılım dünyasında yaratacağı en büyük değişimlerden biri de burada olacak.

Artık bir uygulamayı 10 yıl boyunca büyütüp, sonunda “buna artık dokunamayız, yeniden yazmamız gerekiyor” demek zorunda değiliz.

Gerektiğinde bir modülü, bir bounded context’i, hatta uygulamanın büyük bir bölümünü yeniden yapılandırabiliriz.

Bu noktada SOLID, Clean Architecture, DDD gibi yaklaşımların anlamı da değişiyor. Bunların amacı sadece “güzel kod yazmak” değil.

Asıl amaç değiştirilebilir yazılım üretmek.

Ve belki de ilk defa elimizde, bu değiştirilebilirliği gerçekten kullanabilecek kadar ucuz ve hızlı bir araç var: yapay zeka.

Bu yüzden geleceğin önemli yazılım geliştirme becerilerinden biri kod yazmak değil, mevcut bir sistemi güvenli bir şekilde sürekli yeniden yapılandırabilmek olacak.

Kod artık kutsal değil.

Davranış kutsal.

Implementasyon değişebilir.

Eskiden projelerimizde birçok açık kaynaklı ürünü kullanırdık:

• SSO için Keycloak, OpenLDAP
• Chat için Mattermost
• Git için Gitea, GitLab
• CI/CD için Jenkins
• Artifact repository için Nexus
• Storage için MogileFS, MinIO
• Wiki için MediaWiki
• CRM için EspoCRM, SuiteCRM

Bunların yerine geçecek uygulamaları kendimiz geliştirmek aklımızın ucundan bile geçmezdi.

Neden geçsin ki?

Bu ürünleri kullanarak ciddi anlamda zamandan tasarruf ediyorduk. Bunun karşılığında ise kendimizi bu ürünlerin sunduğu yapının içine sokuyor; kurulum, konfigürasyon, güncelleme, migration ve özellikle security açıklarıyla sürekli ilgilenmek zorunda kalıyorduk.

Hatta Mattermost, Gitea ve benzeri ürünleri kullandığım dönemlerde, gerekli security update’lerini zamanında yapmadığım için birden fazla sunucu kaybettiğim bile oldu.

Artık benim için durum değişti.

Yukarıda saydığım ürünlerin hiçbirisini kullanmıyorum.

Onların yerine, doğrudan kendi gereksinimlerime göre tasarlanmış uygulamalar geliştiriyorum.

Örneğin:

SSO / OAuth2

Uydu uygulamalarımızın login işlemleri için kendi SSO/OAuth2 sistemimizi geliştiriyorum.

Ben bu satırları yazarken sistem yaklaşık %70 oranında tamamlanmış durumda.

Gereksinimleri yaklaşık 7 saat önce tanımladım. O zamandan beri GPT ve Opus birlikte büyük ölçüde otonom bir şekilde implementasyonu gerçekleştiriyorlar.

Sistem tamamlandığında bütün uydu uygulamalarını yeni login sistemine geçireceğim.

Böylece bir çalışanın sadece tek bir hesabı olacak ve bütün uygulamalara aynı hesap üzerinden giriş yapabilecek.

Git & CI/CD

Gitea benzeri, tamamen kendi ihtiyaçlarımıza göre şekillendirilmiş bir Git uygulaması geliştirdim.

Artık bütün Git repository’lerimiz burada bulunuyor.

CI/CD süreçleri de sistemin bir parçası. Her commit ile pipeline otomatik olarak çalışıyor.

Dolayısıyla ayrıca Jenkins’e ihtiyacım kalmadı.

Artifact Repository

Oluşturulan uygulama sürümleri için Nexus benzeri kendi artifact repository uygulamamı geliştirmeye başladım.

Implementasyona dün başladım ve şu anda yaklaşık %80’i tamamlanmış durumda.

Nexus’un yüzlerce özelliğine ihtiyacım yok.

Sadece bizim gerçekten kullandığımız kısmını geliştiriyorum.

CRM

Müşteri ilişkilerini yönetmek için kendi CRM uygulamamızı geliştiriyorum.

Büyük ve genel amaçlı bir CRM ürününü kendi süreçlerimize uydurmaya çalışmak yerine, CRM doğrudan bizim süreçlerimize göre şekilleniyor.

Burada da implementasyon büyük oranda tamamlanmış durumda.

Storage

Kullanacağımız bütün görseller, videolar ve dosyalar için kendi storage sistemimi oluşturdum.

MogileFS benzeri çalışan bu sistemde bir dosyanın üç farklı kopyasını farklı node’lar üzerinde tutuyorum.

Bir node kaybolduğunda dosyanın diğer kopyaları sistemde kalmaya devam ediyor.

Peki geriye ne kaldı?

Şu anda kullandığım temel altyapı komponentleri şunlar:

• Grafana
• Prometheus
• Zipkin
• Graylog
• WireGuard
• PostgreSQL
• Nginx

Bence yazılım dünyasında asıl büyük değişim burada yaşanıyor.

Eskiden sadece bir SSO sistemini geliştirmek bile aylar sürebilirdi.

Bugün ise belirli ve sınırlı gereksinimleri karşılayan bir SSO sistemi birkaç günlük bir işe dönüşebiliyor.

Bu da yıllardır yaptığımız Build vs. Buy hesabını tamamen değiştiriyor.

Eskiden hazır bir ürünü kullanmak çoğu zaman tartışmasız şekilde daha ekonomikti.

Bugün ise yüzlerce özelliğini kullanmadığım, iç yapısını tam olarak bilmediğim, sürekli security update’lerini ve upgrade süreçlerini takip etmek zorunda olduğum büyük bir sistem yerine; sadece kendi gereksinimlerimi karşılayan küçük ve sade bir uygulamayı birkaç gün içinde geliştirmek benim için gerçek bir alternatif haline geldi.

Elbette bunun bir bedeli var.

Kendi yazılımını geliştirdiğinde mimarinin, security’nin, testlerin, backup’ın, monitoring’in ve bakımın sorumluluğunu da tamamen üstleniyorsun.

Fakat artık bunların önemli bir kısmını kontrol eden ve sürekli test eden araçları da yine AI desteğiyle oluşturabiliyoruz.

Bence yapay zekânın yazılım geliştirmede değiştirdiği en önemli şeylerden biri tam olarak bu:

Build vs. Buy dengesi yeniden kuruluyor.

Eskiden başkalarının yaptığı Lego parçalarını kullanıyorduk.

Çünkü her Lego parçasını kendimiz üretmek ekonomik olarak mantıklı değildi.

Şimdi ise ihtiyaç duyduğumuz Lego parçalarını birkaç gün içerisinde, tam istediğimiz şekil ve büyüklükte kendimiz üretebiliyoruz.

Belki de önümüzdeki dönemde yazılım geliştirmedeki en büyük değişimlerden biri bu olacak:

Başkalarının yaptığı Lego parçalarını birleştirmek yerine, kendi Lego parçalarımızı üretmeye başlayacağız.