Her gün bir kitap okuyorum gibi.

Eskiden kod yazarken çoğu şeyi zihnimden geliyordu. Arada takıldığım yerlerde stackoverflow gibi yerlerde çözümler arardım ya da çalışma arkadaşlarıma danışırdım. Boş vakitlerimde de beni ilgilendiren yazılım konularında kitaplar okurdum.

Şimdi durum değişti.

Çözmem gereken teknik problemler %90 oranında azaldı. Stackoverflow gibi sitelere gitmeyeli 5 sene olmuştur. Artık teknik kitaplar da okumuyorum.

Bunun yerine hergün 200 sayfalık kitap okur gibiyim.

Özellikle Codex + Gpt ile analiz yaptırdığımda ya da bir problem üzerine çalıştığımda interaksiyon gereği yapay zekanın benim için oluşturduğu sayfalar dolusu yazıyı okumam gerekiyor. Ufak bir soru “bu neden böyle oldu” demek bile 10-20 sayfalık ekran çıktısına neden olabilir.

Sağlıklı karar verebilmek için hepsini okumam gerekiyor. Bazı yerlerde ne söyleyeceğini tahmin ettiğim için okumadan “devam et” diyebiliyorum. Böylece her gün neredeyse bir kitap kadar bilgiyi okumuş oluyorum.

Kitap okurken insanın nasıl kelime hazinesi gelişiyor ve kitap okuma genel olarak iyi bir alışkanlık ise, yapay zeka ile interaksiyonlardan doğan metinleri de okumak benim için faydalı. Genel olarak yapay zekanın teknik problemleri çözme şeklini gözlemleyebiliyorum. Biz yazılımcılardan çok farklı değiller. Lakin deterministik kalıplarda bunu yapıyor olmaları bazen “anladım, böyle de yapılabiliyormuş” dedirtmiyor değil.

Ben çok şey öğreniyorum.

Yazılım zaten ömür boyu öğrenmeyi gerektiren bir uğraş.

Yapay zekâ bunu ortadan kaldırmadı.

Tam tersine, öğrenmeyi yaptığımız işin içine gömdü ve çok daha verimli bir seviyeye taşıdı.

Kod yazma ve okuma devri bitti dedik.

Peki testler ne olacak?

İyi niyet taşıyarak ajanların her kod parçası için test yazmaya başlamaları çok büyük problemlerin habercisi olabilir.

Bunlar:

– CI/CD süreçlerinin uzaması.

– Ajanların kapsama alanı geniş (code coverage) testleri her defasında okumalarının gereksiz token harcamalarını tetiklemesi.

– Testlerin mevcut implementasyona çok sıkı bağlanarak refactoring’i zorlaştırması.

– Ajanın kodu değiştirdikten sonra asıl problemi çözmek yerine yüzlerce kırılan testi tamir etmekle uğraşması.

Çözüm ne olabilir?

Sadece E2E testleri yeterli mi? Birim testlerini silebilir miyiz?

Sadece E2E testleri uçtan uca senaryoları test ederler. Bu testlerin kırılmaları problemin nerede olduğunu doğrudan göstermez. Bu yüzden ince ayar yapabilen birim testlerine de ihtiyacımız vardır.

Her ikisine de ihtiyacımız var, ama testin sağladığı değer ile maliyeti — özellikle CI süresi ve token tüketimi — arasında bir denge kurulması gerekiyor.

“Ne kadar çok testimiz var?” ya da “Code coverage ne kadar yüksek?” yerine şu soruyu sormamız gerekiyor:

Bu test hangi sistem gerçeğini koruyor?

Burada “invariant” kavramı devreye giriyor.

Invariant, sistem içerisinde hangi değişiklik yapılırsa yapılsın doğru kalması gereken bir kuraldır.

Örneğin bir ödeme sisteminde:

Yapılan iadelerin toplamı, müşteriden tahsil edilen miktardan hiçbir zaman fazla olamaz.

Bu bir invariant’tır.

Ajan bütün sistemi refactor edebilir.

Ama sonunda bu kural hala geçerli olmak zorundadır.

İşte testin görevi burada değişiyor.

Test artık ajana:

“PaymentRepository.save() metodunu çağırmadın.”

demek yerine:

“PAYMENT-001 invariant’ını ihlal ettin. 100 TL tahsil edildi ama sistem 120 TL iade yapılmasına izin verdi.”

demelidir.

İki hata mesajı arasında çok büyük bir fark var.

Birincisi implementasyonu koruyor.

İkincisi sistemin doğrusunu koruyor.

Bu bakış açısıyla testler, mevcut kodu donduran mekanizmalar olmaktan çıkıp ajanlara sınırları gösteren sensörlere dönüşüyorlar.

Ajan istediği kadar refactoring yapabilir, sınıfları bölebilir, birleştirebilir, mimariyi değiştirebilir.

Ama invariant’ları ihlal edemez.

Böylece yapay zeka ajanına iki şeyi aynı anda vermiş oluyoruz:

Özgürlük ve sınır.

Özgürlük implementasyonda.

Sınır ise sistemin değişmez doğrularında.

Bu yüzden gelecekte önemli olanın %90 ya da %100 code coverage olacağını düşünmüyorum.

Daha önemli bir soru var:

İşletmemiz ve uygulamamız için kritik olan gerçeklerin yüzde kaçını invariant olarak tanımladık ve bunların yüzde kaçını otomatik olarak doğrulayabiliyoruz?

Belki de yeni metriğimiz “Code Coverage” değil, “Invariant Coverage” olmalı.

Amaç, mümkün olan en düşük maliyetle ajana mümkün olan en yüksek kalitede geri bildirim vermektir.

Bizim yazılımcı olarak görevimiz ajanları doğru yönlendirebilmek. Bunun için kodun nasıl yazılması gerektiğine dair fikir beyanı yani sıra ınvariantlar kullanarak sistem spesifikasyonunu iyi tanımlamamız gerekiyor.

Ben yazılımcıların severek ne test yazdıklarını ne de refactoring yaptıklarını gördüm.

Halbuki her ikisi de sağlıklı ve uzun ömürlü bir uygulama oluşturmak için elzem.

Testler olmadığı için kimse refactoring yapmaya cesaret edemiyor. Ya “bana ne” diyor ya da bunun için gerekli zamanı bulamıyor.

Yapay zeka ile yazılım geliştirme döngüsü ise test etme ve refaçtoring üzerine kurulu.

Ufak bir değişiklik istiyorsunuz. Mevcut yapıyı adapte ediyor, gerekiyorsa refactoring yapıyor ve yaptığı değişikliği testlerle garanti altına alıyor.

Şimdiye kadar GPT ya da Opus’un test yazmadan veya yaptığı değişikliği dokümante etmeden ciddi bir değişiklik yaptığını pek görmedim.

Aslında olan şu:

Bir uygulamayı yeni gereksinimlere adapta edebilmek için refactoring yapmak zorundasınız, yani continuous refactoring effort gerekli. Bunun için testlere ihtiyacınız var. Yapay zeka bir uygulamayı sürekli adapte etmek için gerekli en önemli yöntemin refactoring olduğunu biliyor sadece buna odaklanarak uygulamayı sürekli yoğuruyor.

Yazılımın ana prensibi aslında uygulamayı yeni müşteri gereksinimleri ile yoğurabilmek. Bu konuda yazılımcılar yıllarca ne yazık ki başarılı olamadılar. Bunun nasıl efektif yapıldığını artık yapay zekayı takip ederek, görebilirler.

Agent skill’leri hakkında konuşalım.

Ben Claude Code bünyesinde hiçbir SKILL dosyası kullanmıyorum.

Açıkçası kullanmayı da tavsiye ve tasvip etmiyorum.

Neden?

Bu, sizin çocuğunuzu başka birisinin terbiye etmesi gibi bir şey.

Yapılacak işin tüm kurallarını bir skill set tanımlıyor. Siz ajana bir iş veriyorsunuz, skill ise ona bu işi nasıl yapması gerektiğini söylüyor.

Ama benim tam olarak devretmek istemediğim şey de bu: nasıl çalışması gerektiği. Çünkü bir ajanin nasıl çalışacağı benim yazılım geliştirme anlayışımın bir parçası.

– Gereksinimleri nasıl analiz edecek?

– Hangi soruları soracak?

– Ne zaman implementasyona başlayacak?

– Neyi kontrol edecek?

– Neyi test edecek?

– Bir işi ne zaman tamamlanmış kabul edecek?

Bunların hepsi benim çalışma metodolojimin parçaları.

Başkasının hazırladığı bir skill’i kullandığım anda sadece bir aracı kullanmış olmuyorum. O kişinin çalışma biçimini, varsayımlarını ve tercihlerini de sistemime dahil etmiş oluyorum.

Ben ajanların yeteneklerini standartlaştırmak istemiyorum.

Ben onların davranışlarını kendi çalışma sistemim içinde şekillendirmek istiyorum.

Bu yüzden hazır skill’ler yerine kendi loop’larımı, kurallarımı, review mekanizmalarımı ve onay/kabul kriterlerimi oluşturuyorum.

Ajan benim yerime kod yazabilir. Ama nasıl yazılım geliştireceğimize karar veren taraf ajanın skill dosyası olmamalı.

Yapay zeka araçları ile çalışmak gerçekten disiplin gerektiren bir şey. Gelişi güzel skill yükleyerek, işin daha da kolaylaşacağını düşünmek doğru değil. Çoğu zaman tam tersi oluşabilmekte, çünkü skiller gidişatı yönetme kabiliyetinizi sabote ediyor olabilirler.

Skill aslında bilgi değil, kodlanmış bir çalışma kültürüdür. Kendi kültürünüzü mü oluşturacaksınız yoksa başkalarının kültürünümü adapte etmeye çalışacaksınız?

Fikirden canlı ürüne nasıl geliyoruz, 10 adımda anlatalım (uçtan uca üretim modeli)

1. Güzel bir fikir buluyoruz. Başka kimsede bu fikrin olmaması lazım ;-)

2. Sonra Gpt ile geniş kapsamlı, saatler süren analiz seansları yapıyoruz.

3. Daha önce bolca bahsettiğim gibi loop engineering yapabilmek için gerekli iş paketlerini Gpt’ye hazırlattırıyoruz.

4. Akabinde loop.sh ile döngüyü başlatıyoruz ve bilgisayarın ekranını kapatıyoruz.

5. 24 ya da 48 saat sonra durum nedir diye Gpt’ye soruyoruz. Benim projelerim genelde gün ortasında başlıyor ve ertesi sabah kalktığımda ürün çalışır halde bekliyor oluyor.

6. Ürünü lokalde test ediyoruz. Eksiklerini tamamlattırıyoruz, hataları düzelttiriyoruz. Ben bu safhaya software factory’den çıkan uygulama için finetuning ismini veriyorum.

7. Daha sonra ilk deployment için sunucu hazırlıkları başlıyor. Bu işi yine Gpt üstleniyor. Gpt daha önce kurulmuş olan uygulamaları referans niteliğinde kullanarak yeni uygulamayı sunucularda high avaılable ve loadbalancer arkasında yer alacak şekilde birden fazla sunucuda kurma hazırlıklarını tamamlıyor. Çok daha önce tamamen dışarıya kapatılmış ve hardening yapılmış sunuculardan oluşan bir cluster sistemini Gpt ile zaten kurmuştuk.

8. Her projede ship.sh isminde bir script var. Bu bir wrapper script ve önce release.sh ile sürüm oluşturuluyor. Eğer bir flutter projesi ise android, ios, macos, windows, llinux, web sürümleri oluşturuluyor. Her sürüm öncesinde mevcut tüm testler koşturuluyor. Eğer bir backend projesi ise sürüm jar dosyası olarak çıkıyor. Sürüm artifact repositöry’ye yüklendikten sonra deploy.sh ile doğrudan sunuculara aktarılıyor. Yükleme öncesinde precheck ile sunucular check ediliyor. Deployment hatalı olursa, rollback yapılarak, eski sürüm aktifleştiriliyor.

9. Bir uydu uygulamamız olan kokpit ile hangi sunucuda hangi uygulamanın hangi sürümünün deploy edildiğini görebiliyoruz. deploy.sh son adımda kokpit için gerekli yüklemeleri yapıyor.

10. Bu noktadan itibaren fikir artık canlı canlı canlıda çalışır durumda. Fikir artık fikir değildir. Analiz edilmiş, geliştirilmiş, test edilmiş, sürümlenmiş, birden fazla sunucuya deploy edilmiş, gerektiğinde rollback edilebilir ve Kokpit üzerinden izlenebilir canlı bir üründür.

Fikirden canlı ürüne giden yol artık aylarla değil, günlerle; bazen saatlerle ölçülüyor.

Fikirden uygulama üreten ve canlıya alan üretim hattına hoşgeldiniz.

Ben eskiden kod yazarken bu kadar zihinsel yorulmuyordum.

Spesifik bir şeye odaklanıp, saatlerce onunla uğraşabiliyordum.

Şimdi durum değişti.

Kod yazmıyorum. Kodu yazdırıyorum. Kodu da artık okumuyorum.

Ama eski çalışma sistemime göre bir değişim söz konusu.

Artık herşeyi en ince detayına kadar anlayıp, yapay zeka ajanlarını yönlendirmem ve yönetmem gerekiyor. Paralelde 2-3 değişik proje ve onlarca ajanla çalışıyorum ve bu detaycı çalışma tarzı zihinsel olarak beni yoruyor. Yorucu olan context switching + sürekli karar verme birleşimi.

Şikayet etmiyorum. Bu şekilde çalışmak ve aylar sonra ortaya çıkabilecek ürünleri birkaç gün içinde canlıya almak kadar eğlenceli bir şey yok.

Sadece zihinsel çalışma tarzım bile değişikliğe uğramış. Yeni farkına varıyorum.

Eskiden bilgisayarın işlemcisi gibiydim. Şimdi bilgisayarların schedüler’i gibi çalışıyorum.

Yapay zeka must have diyorsak, bu çalışma tarzının ne yazık ki bir alternativi yok.

Oh, oh!

Gpt haftalık limitim full, üzerinde birde bedava fulleme kredisi vermişler. Etti mi %200.

Claude codex de aynı şekilde full. Orada da bir resetleme kredisi var.

Toplamda %400 yapay zeka sermayem var.

Şimdi bu %400’ün yani yapay zeka sermayesinin ne anlama geldiğini somut bir örnek ile açıklayayım. Ben burada harcayabileceğim token görmüyorum. Ben burada üretim kapasitesi görüyorum.

Ben bununla şimdi 3 tane uygulama çıkartırım. Her birinin kendi desktop, mobil ve web arayüzü ve spring backend’ı var.

Sadece bir tanesi için 3 kişilik bir ekip bir ay çalışırdı.

Nereden nereye geldiğimizin küçük ama ifade gücü çok yüksek bir örneği.

Burada değişen şey sadece yazılım geliştirme hızımız değil aslında.

Eskiden yazılım üretme kapasitesini insan sayısı ve zaman ile ölçüyorduk. Üç yazılımcı, bir ay, bir uygulama gibi.

Şimdi bunun yanına yeni bir üretim faktörü eklendi: yapay zeka sermayesi.

Ben artık elimdeki GPT ve Claude limitlerine baktığımda sadece token ya da kullanım hakkı görmüyorum. Doğrudan üretim kapasitesi görüyorum.

Belki de yazılım dünyasında yaşanan asıl dönüşüm bu.

Yapay zeka sadece yazılımcının daha hızlı kod yazmasını sağlamadı. Bir kişinin ulaşabileceği üretim kapasitesini değiştirdi.

Daha önce TDD (Test Driven Development) yaptınız mı?

TDD’de çalışma mekanizması kabaca şöyle işler:

Önce bir test yazarsınız. Test çalışmaz, çünkü henüz kodda karşılığı yoktur. Sonra testi çalışır hale getirene kadar implementasyonu yaparsınız. Ardından yeni bir test yazarsınız. O da çalışmaz. Onu çalışır hale getirecek kodu yazarsınız. Böylece sürekli çalışmayan testler yeni kodu doğurur.

Testler kodun arkasından değil, kod testlerin arkasından gelir.

Malum, artık kod yazmıyoruz :)

O zaman TDD de yapamayız mı?

Tam tersine.

Yapay zeka ajanlarına TDD yaptırabiliriz.

Reçetesi şöyle:

Bir projeye başlamadan önce aklınıza gelen tüm onay/kabul kriterlerini bir dosyada tanımlayın.

Örneğin:

Given: Kullanıcı login olmak için kullanıcı adı ve şifresini girer.

When: Login tuşuna basar.

And: Girdiği şifre hatalıdır.

Then: Giriş engellenir ve kullanıcıya hata mesajı gösterilir.

Bu şekilde aklınıza gelen tüm kabul kriterlerini tanımlayın. Ardından yapay zeka ajanına şunu söyleyin:

Her kabul kriteri için bir E2E testi oluştur. Örneğin Cypress ile.

Ajan muhtemelen size: “Fakat bu testler mevcut implementasyonda çalışmayacak.” diyecektir.

Cevabınız:

“Zaten istediğim bu. Testleri oluştur. Sonra bütün testler yeşil olana kadar implementasyonu geliştir.”

İşte bu noktadan itibaren çalışma şekli değişiyor.

Artık yapay zekaya: “Şu özelliği geliştir.” demiyorsunuz.

Ona çalışması gereken testleri veriyorsunuz.

Ajanin görevi ise sistemi bu testleri geçecek hale getirmek oluyor.

→Test (red)

→ Implementasyon

→ Test (green)

→ Yeni test (red)

→ Yeni implementasyon

→ Test (green)

Yani TDD ortadan kalkmadı. Sadece artık testi geçecek kodu biz yazmıyoruz. TDD yapan bir yapay zeka ajanımız var.

Yazılımcıların yapay zeka araçlarının yaptığı işlere karşı tereddüt etmesinin bence temel bir sebebi var:

Yazılımcılar, yazılımın ne kadar kırılgan olduğunu biliyorlar.

Mutlaka düşünülmemiş bir edge case vardır. Mutlaka hesaba katılmamış bir yan etki vardır. Bir yeri düzeltirsin, başka bir yer bozulur. Hop, sistem yamulur. :)

Zaten yazılımcılar yıllardır tam da bu nedenle regresyonu önleyecek mekanizmalar geliştiriyorlar: testler, type safety, static analiz, code review, CI/CD, monitoring vs.

Kendi yazdıkları kodun ne kadar kırılgan olabileceğini bildikleri için, doğal olarak yapay zekanın yazdığı koda da aynı şüpheyle yaklaşıyorlar.

Fakat burada önemli bir fark var.

Yapay zeka sadece kod üreten bir araç değil. Elindeki kod tabanını, gereksinimleri, testleri, logları ve runtime davranışını birlikte analiz edebildiğinde, bir insanın tek tek zihninde tutmakta zorlanacağı kadar fazla ilişkiyi aynı anda değerlendirebiliyor.

Benim bugüne kadarki tecrübem şu:

Yapay zeka şaşırtıcı derecede sağlam ve nokta atışı çözümler üretebiliyor.

Bana göre yapay zeka, doğru mühendislik mekanizmalarıyla çevrelendiğinde, insanlardan çok daha iyi kod yazabiliyor.

Ok, kritik bir eşiğe geldik.

Ben uygulamaların canlıya alınması ve orada işletilmesi konusunda da yapay zekayı öncelikli araç olarak kullanıyorum.

Neler yaptırıyorum?

– Sunucularda yeni bir servis için gerekli altyapı kurulumu (nginx, service start/stop scriptleri, veri tabanı oluşumu vb)

– Bir ürünün doğrudan HA konfigürasyonda rollilng deployment

– Hata olması durumunda hatanın analizi ve çözümü

– Monitoring işlemleri

Bir sonraki adımda runtime refactoring.

Runtime refactoring nedir?

Uygulamanın canlı canlı, bulunan bir hata sonrasında refactor ve hemen yeni sürümü ile replace edilmesi. Buna hot refactoring bile diyebiliriz.

Yani runtime’da kendi kendini tamir eden uygulamalar devrine geçiyoruz ;-)

Döngü şu şekilde olacak:

Observe → Diagnose → Modify → Verify → Deploy → Observe

Bu modelde yapay zeka sadece kod yazan ajan olmaktan çıkıyor. Production lifecycle’ın tamamını yöneten bir engineering agent haline geliyor.

Kendi kendini tamir eden uygumalar…

Şimdiye kadar bu self healing mekanizmaları container seviyesinde yapılabiliyordu, yani restart container ile servis yeniden çalışır hale geliyordu.

Eski self-healing: sistemi yeniden başlat.

Yeni self-healing: sistemi yeniden yaz ve deploy et.

Bunun güvenli olabilmesi için yapay zekanın etrafında deterministik bir güvenlik çemberi gerekiyor: E2E testleri, statik kod analizi, tanımlı mimarı kurallar, security scanning, health checks, rolling deployment ve otomatik rollback.

Yazılımda nasıl herşeyi artık otomatize edebiliyorsak, ürünün canlıya alınış ve işletilmesini de o derece otomatize edebiliriz.

Yazılımcı olarak çok heyecanlı zamanlar bizi bekliyor.

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.