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.

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.