Dikkat ettiyseniz, yapay zekanın yazılımcılar tarafından kabullenilme oranı son altı ayda dramatik bir şekilde arttı.
Eskiden “Yapay zeka kod yazamaz!” deniliyordu. Şimdi ise “Yapay zeka ile kod yazmak mesele değil, asıl mesele onu yönetebilmek!” deniliyor.
Kabulleniş, gerçeklerin her zaman en az 3-6 ay gerisinden geliyor.
Burada çok büyük bir sıkıntı görüyorum.
Çünkü yapay zekanın gelişim hızı ile yazılımcıların bu gelişimi kabullenme hızı arasında giderek büyüyen bir uçurum var.
Eğer bu gidişata yeterince hızlı adapte olunamazsa, bazı şeyler için artık çok geç olabilir.
Örneğin, tecrübeli bir senior developer altı aylık bir zaman diliminde yapay zekayı çok iyi kullanan, onunla uçtan uca ürün geliştirebilen bir yazılımcıya dönüşebilir.
Ama aynı altı ayı, bazı gerçekleri kabullenmekte zorlandığı için kaybederse, kariyerini ciddi anlamda riske atabilir.
Çünkü o altı ay boyunca sadece yapay zeka gelişmiyor. Onu kabullenmiş ve kullanmaya başlamış diğer yazılımcılar da gelişiyor.
Aradaki fark her geçen gün biraz daha açılıyor.
Asıl tehlike yapay zekanın yazılımcıların yerini alması değil, bazı yazılımcıların değişimi kabullenene kadar diğerlerinin çoktan yeni bir seviyeye ulaşmış olması.
Bu yüzden bugün kaybedilen altı ay, yarın altı aylık çalışmayla telafi edilemeyebilir.
Kod yazmak için IDE, yapay zeka ajanlarıyla etkileşime girmek için CLI kullanmak artık gereksiz.
Kod yazmıyoruz. O halde neden bir kod editörü kullanalım?
Ajanlarla sürekli etkileşime girmek de zaman kaybından başka bir şey değil. 30 farklı CLI penceresinde 30 ajanı yönetmeye çalışmak ölçeklenebilir bir yöntem değil.
Yapay zekaya işleri devrediyoruz ama bu sefer de ajanları yönetmek için bilgisayar başına mahkûm oluyoruz.
Geriye ne kalıyor?
– Dark Software Factory
– Loop Engineering
Dark Software Factory, yazılım üretim sürecinin insan müdahalesine ihtiyaç duymadan çalışmasını sağlayan yapı.
Loop Engineering ise bu yapının içinde ajanların iş paketlerini tamamlayana, kabul kriterlerini karşılayana ve sistem invariantlarını sağlayana kadar otonom çalışmasını sağlayan yöntem.
Bu ikisi bir araya geldiğinde IDE’ye, CLI’ye veya ajanlarla sürekli etkileşime girmeye ihtiyaç kalmıyor.
Biz ürünü tanımlıyoruz, kabul kriterlerini ve sınırlarını belirliyoruz. Gerisini yazılım fabrikası hallediyor.
Amacımız yapay zeka ajanlarıyla daha verimli çalışmak değil, onlarla çalışmak zorunda kalmamaktır.
Nokia ile günümüz yazılımcılarının kaderleri arasında ilginç paralellikler var.
Nokia bir zamanlar cep telefonu piyasasının tartışmasız lideriydi. Piyasadaki hakimiyetinin verdiği rahatlıkla kendisini yeterince yenileme ihtiyacı duymadı.
Sonra Apple geldi ve bütün oyunu değiştirdi.
Apple sadece yeni bir telefon üretmedi. Telefonun ne olduğunu yeniden tanımladı.
Nokia’nın elinde dünyanın en iyi mühendisleri vardı. Telefon üretmeyi çok iyi biliyorlardı. Ama artık mesele daha iyi telefon üretmek değildi. Telefon kavramının kendisi değişmişti.
Nokia bu dönüşüme ayak uyduramadı ve piyasadaki hakimiyetini kaybetti.
Gelelim günümüz yazılımcılarına.
Biz de yıllarca yazılım geliştirmeyi kod yazmak üzerinden tanımladık.
İyi yazılımcı olmak; iyi kod yazmak, algoritmaları bilmek, tasarım kalıplarına hakim olmak, temiz kod yazmak ve karmaşık sistemleri kod seviyesinde anlayabilmek demekti.
Bütün mesleki kimliğimizi bu yetenekler üzerine inşa ettik.
Sonra yapay zeka geldi.
Yapay zeka sadece kod yazmayı hızlandıran yeni bir araç getirmedi. Yazılım geliştirmenin ne olduğunu yeniden tanımlamaya başladı.
Artık kod yazmadan yazılım geliştirebildiğimiz bir döneme girdik.
Ama birçok yazılımcı hala eski dünyanın kavramlarıyla düşünüyor.
Yapay zekanın yazdığı kodun kalitesini, okunabilirliğini, hangi tasarım kalıplarını kullandığını tartışıyoruz.
Yapay zekayı daha hızlı kod yazmak için kullanmaya çalışıyoruz.
Tıpkı Nokia’nın daha iyi telefon üretmeye çalışması gibi.
Oysa değişen şey kod yazma hızımız değil, yazılım geliştirme biçimimizin kendisi.
Yazılımcının görevi artık kod üretmekten, üretilecek sistemin ne yapması gerektiğini tanımlamaya, sınırlarını çizmeye ve ortaya çıkan ürünün doğruluğunu güvence altına almaya doğru kayıyor.
Bunun için de farklı yeteneklere ihtiyacımız var.
Problem analizi, gereksinim mühendisliği, sistem tasarımı, kabul kriterleri, invariantlar ve yapay zeka ajanlarını organize edebilme becerileri ön plana çıkıyor.
Nokia’nın mühendisleri bir gecede kötü mühendisler haline gelmediler. Sadece sahip oldukları uzmanlığın değer yarattığı dünya değişti.
Bugün yazılımcıların karşı karşıya olduğu durum da bundan çok farklı değil.
Yıllarca bizi başarılı kılan yetenekler, gelecekte bizi başarılı kılacak yeteneklerle aynı olmak zorunda değil.
Buradaki asıl tehlike yapay zekanın kod yazabilmesi değil.
Asıl tehlike, yazılımcıların kendi mesleki kimliklerini kod yazma becerisinden bağımsız olarak yeniden tanımlayamamaları.
Nokia’nın sorunu telefon üretememesi değildi. Telefonun artık neye dönüştüğünü yeterince hızlı kavrayamamasıydı.
Yazılımcıların sorunu da kod yazamamaları olmayacak.
Yazılım geliştirmenin artık neye dönüştüğünü kavrayamamaları olacak.
Yazılım geliştirirken tek seferde bütün bir ürünü ortaya çıkarmak mı, yoksa birçok iterasyonla bir MVP’yi zaman içinde ürüne dönüştürmek mi daha iyi sonuç verir?
Benim favorim One-Shot Product.
Neden?
İterasyon bazlı MVP geliştirme yaklaşımının büyük ölçüde klasik yazılım geliştirme metodolojilerinden miras kaldığını düşünüyorum.
Eskiden bir ürünü geliştirmek aylar, hatta yıllar sürerdi. Müşteri de çoğu zaman ne istediğini tam olarak bilmezdi.
Bu yüzden önce bir MVP geliştirilir, müşteriye gösterilir, geri bildirimler alınır ve ürün birçok iterasyonla adım adım tamamlanırdı.
Artık bu yönteme eskisi kadar ihtiyacımız yok.
Eskiden aylar süren bir uygulamayı bugün yapay zeka ajanlarıyla birkaç gün içinde ortaya çıkarabiliyoruz.
Benim izlediğim yöntem şöyle:
Önce GPT ile inebildiğim en derin noktaya kadar analiz seansları yapıyorum.
Ürünü bütün yönleriyle ele alıyoruz. Gereksinimleri, mimariyi, iş akışlarını, kabul kriterlerini ve sistem invariantlarını netleştiriyoruz.
İkimizin zihninde de net bir ürün ortaya çıktığında, Loop Engineering için gerekli iş paketlerini oluşturuyoruz.
Ardından GPT + Opus ikilisi devreye giriyor ve Software Factory içinde ürünün geliştirilmesini üstleniyor.
Ben ise ortaya çıkan ürünü finetuning olarak adlandırdığım prompt engineering yöntemiyle tamamlıyorum.
Bu aşama genellikle çok uzun sürmüyor. Çünkü ürün, Software Factory’den çoğu zaman yaklaşık %95 oranında tamamlanmış olarak çıkıyor.
Yani tek vuruşta işin büyük kısmını halletmiş oluyoruz.
Buradaki temel düşüncem şu:
Eksik de olsa bütünden yola çıkıp onu tamamlamak, parçalardan yola çıkıp bütüne ulaşmaktan çok daha kolay.
MVP First yaklaşımında ise parçalar üzerinden ilerleyerek bütünü oluşturmaya çalışıyoruz.
Bu da bana göre ciddi bir zaman kaybına neden olabiliyor. Çünkü her yeni iterasyon, yeni prompt engineering seansları, değişen gereksinimler, yeniden ele alınması gereken mimari kararlar ve mevcut ürün üzerinde sürekli müdahaleler anlamına geliyor.
One-Shot Product yaklaşımında ise önce bütünü zihinsel olarak inşa ediyor, ardından yapay zeka ajanlarına bu bütünü gerçekleştirme görevini veriyoruz.
Önce bütün, sonra parçalar.
Bence yapay zeka çağında ürün geliştirmenin temel prensiplerinden biri bu olmalı.
Yıllarca bize “Yazdığın kod için dokümantasyon da yaz!” dediler.
İlk patlayan her daim kodun içine gömülü Javadoc vari dokümantasyonlar oldu. Çünkü üvey evlat muamelesi gördüler. Kod yazmak daha zevkliydi.
Genel olarak yazılım dokümantasyonunu kod ile güncel tutmak her zaman büyük bir problem olmuştur.
Artık kod yazmıyoruz. Dokümantasyon da yazmamıza gerek yok.
Bunun için bir yapay zeka ajanına “Mevcut sistem mimarisini analiz et ve güncel mimari dokümantasyonunu hazırla.” demek yeterli.
Hatta bir adım ileri giderek, her mimari değişiklikten sonra dokümantasyonun otomatik olarak güncellenmesini sağlayabiliriz.
Böylece dokümantasyon, yazılımcının yapmak zorunda olduğu angarya bir iş olmaktan çıkıp sistemin sürekli güncel tutulan bir çıktısı haline gelir.
Eskiden dokümantasyonu biz yazardık ve kodun gerisinde kalırdı. Şimdi koddan dokümantasyon üretiyoruz.
Bunu neden yazıyorum?
Vellkam Connect bünyesinde her çalışanın erişebileceği bir Bilgi Bankası, Doküman Store ve Akademi bulunuyor.
Akademi, özellikle yeni çalışanların onboarding süreçlerinde ihtiyaç duydukları eğitim materyallerini ve sistem kullanım kılavuzlarını barındıracak.
Yeni bir çalışanı sisteme dahil etmek için ona sistemi anlatan dokümanları vermek yeterli olacak. Üstelik bu dokümanları hazırlayan da sistemin kendisi olacak.
Bu amaçla şu anda onlarca dokümanın otomatik olarak üretilmesini sağlayacak altyapıyı oluşturdum.
Onlarca yapay zeka ajanı, belirlediğim içerik ve format kurallarına göre onlarca, belki yüzlerce PDF dokümanı, kullanım kılavuzu ve eğitim materyali hazırlayacak.
Üstelik sistem değiştikçe bu dokümanlar da güncellenecek.
Buradaki asıl dönüşüm dokümantasyon yazma işini yapay zekaya devretmek değil. Dokümantasyonu, yazılım geliştirme sürecinin doğal ve otomatik bir çıktısı haline getirmek.
Artık dokümantasyon yazılımın gerisinden gelmek zorunda değil. Yazılımla birlikte yaşayabilir.
Şirket yönetim kültürü olarak holakrasiyi benimsediğimizi daha önce paylaşmıştım.
Bu yönetim modelinde doğrudan yöneticiler bulunmuyor. Şirket, canlı bir organizma gibi hücrelerden ve onları kapsayan çemberlerden oluşuyor.
Klasik yönetim anlayışında yönetim kültürünü oturtmak için eli sopalı yöneticilere ihtiyaç duyarsınız. Günün sonunda yöneticiler neyin nasıl yapılacağına karar verir, çoğu zaman sorumluluk almadan çalışanları ellerindeki sopayla hizaya sokarlar.
Holakraside durum çok farklı.
Holakratik yönetim kültürünü oturtabilmek için öncelikle onun yaşayabileceği bir ortam oluşturmanız gerekiyor. Çünkü bu kültürü yukarıdan aşağıya dikte edecek yöneticiler yok.
Biz bu sorunu, çalışanlarımızın iletişim kurmak ve günlük işlerini yönetmek için kullandıkları Vellkam Connect uygulamasıyla çözdük.
En tepede Kurucu Çember bulunuyor. Onun altında diğer çemberler yer alıyor. Her çemberin altında başka çemberler veya hücreler bulunabiliyor.
Bu yapı klasik hiyerarşik bir organizasyon şemasına benzese de aslında öyle değil.
Buradaki amaç, çalışma alanlarını gruplamak ve hücreleri kendi sorumluluk alanlarına odaklanabilecek şekilde yapılandırmak.
Gelelim hücrelere.
Her hücrede tanımlı roller bulunuyor.
Örneğin sahadaki müşteri ilişkilerinden sorumlu Müşteri Onboarding Hücresinde, Müşteri Danışmanı isminde bir rolümüz var.
Bu rolün sorumlulukları, yetki alanları ve karar verme yetkileri tanımlı.
Bu role atanan çalışan ne yapması gerektiğini, hangi konularda karar alabileceğini ve yetkilerinin sınırlarını biliyor.
Böylece kendi sorumluluk alanında sürekli birilerine danışmadan, izin almadan ve hesap vermek zorunda kalmadan karar verebiliyor.
Rollerin yanında kurallar da var.
Her hücrenin çalışma biçimini belirleyen tanımlı kuralları bulunuyor.
Örneğin Müşteri Danışmanı, eksik müşteri bilgileriyle onboarding sürecini başlatamaz.
Bu bir kural.
Bunun gibi kurallar, hücrenin çalışma biçimini ve standartlarını belirliyor.
Hedefler ve metrikler de tanımlı.
Her hücrenin ulaşmak istediği hedefler ve bu hedeflere ne ölçüde ulaşıldığını gösteren metrikler bulunuyor.
Örneğin Müşteri Onboarding Hücresinin hedeflerinden biri, yeni müşterileri mümkün olduğunca hızlı canlı kullanıma geçirmek.
Bunun için kullandığımız metriklerden biri, ilk müşteri görüşmesinden canlı kullanıma geçişe kadar geçen süre.
Başlangıçta 72 saat olan bu süreyi zamanla 24 saate düşürmeyi hedefleyebiliriz.
Peki, bir şeyler yolunda gitmiyorsa ne oluyor?
İşte holakrasinin en önemli özelliklerinden biri burada devreye giriyor: Gerilimler.
Bir çalışan mevcut rollerin, kuralların veya hedeflerin işini yapmasını zorlaştırdığını düşünüyorsa bir gerilim kaydı oluşturabiliyor.
Her gerilim, potansiyel bir adaptasyon sürecinin başlangıcı.
Hücre sakinleri bu gerilimi değerlendiriyor, gerekli değişiklikleri tartışıyor ve belirlediğimiz karar alma mekanizması çerçevesinde kabul edilen değişiklikler ilgili alanın yeni bir sürümü olarak yürürlüğe giriyor.
Böylece hücreler kendi çalışma ortamlarını sürekli olarak değiştirebiliyor, iyileştirebiliyor ve gelişen ihtiyaçlara adapte edebiliyor.
Yani organizasyonu yöneticiler değil, organizasyonun içinde çalışan insanlar geliştiriyor.
Bizim holakrasiden beklentimiz de tam olarak bu.
Bir sonraki yazımda kararların nasıl alındığına, üst çemberlerin bu kararlarda ne kadar etkili olduğuna ve hücrelerin ne ölçüde bağımsız hareket edebildiğine değineceğim.
Hiç hamur işi yapıp fırına verdiyseniz iyi bilirsiniz.
Arada bir fırının kapağından içeri bakıp hamurun nasıl kabardığını, şekil aldığını görmek çok zevklidir.
İnsan emeklerinin karşılığını canlı canlı görür.
İşte yapay zeka ile ürün geliştirmek de artık fırına yemek vermek gibi bir şey. En azından bana böyle hissettiriyor.
Üstelik yemeği de artık kendiniz hazırlamıyorsunuz.
Star Trek dizisindeki yemek replikatörlerini hatırlayın. Ne yemek istediğinizi söylüyorsunuz, replikatör de onu sizin için hazırlıyor.
Yapay zeka ile ürün geliştirmek de giderek buna benziyor.
Ne istediğinizi tarif ediyorsunuz, fırına veriyorsunuz ve arada bir nasıl şekillendiğini kontrol ediyorsunuz. Loop engineering ile o yazılım replikatörlerini kullanmış oluyorsunuz.
Biraz daha tuz, biraz daha baharat, şurası biraz daha kızarsın derken…
Yapay zeka ile çalışan bir yazılımcıdan bütün ekibin işini yapmasını beklemenin doğru olmadığı fikri savunuluyor.
Galiba siz sektörü tanımıyorsunuz!
Eskiden fullstack developer diye bir rol vardı, hatırlarsınız belki.
Neden böyle bir rol ortaya çıktı?
Çünkü iki kişinin işini bir kişiye yaptırmak istediler. Üstelik o zaman yapay zeka falan da yoktu.
Sektörün temel eğilimi hep aynıdır: Daha az maliyetle daha fazla iş yaptırmak.
Şimdi sektör yeni bir gerçeği keşfediyor:
Yapay zeka ile çalışan tek bir yazılımcı, eskiden bir ekibin yaptığı işlerin büyük bölümünü tek başına üstlenebiliyor.
Siz gerçekten kapitalist piyasa dinamikleriyle çalışan bir sektöre, bunun doğru olmadığını söyleyerek yön verebileceğinizi mi düşünüyorsunuz?
Sektör her zaman ekonomik çıkarlarının peşinden gidecek.
Yarın işverenler, “Artık beş kişilik ekiplere ihtiyacımız yok. Tek kişilik ekipler kuruyoruz.” dediklerinde, bu talebi ya karşılayacaksınız ya da oyun dışında kalma riskiyle karşılaşacaksınız.
İşin ekonomik boyutunu bir kenara bırakalım.
Teknik açıdan baktığımızda da yapay zeka ile çalışan deneyimli yazılımcıların, eskiden bir ekibe ihtiyaç duyulan pek çok işi tek başlarına gerçekleştirebilecek kapasiteye ulaştıklarını görüyoruz.
Gereksinim analizi, mimari tasarım, frontend, backend, test, release, deployment ve operasyon…
Bütün bu alanlarda uzmanlaşmış ajanları yöneten tek bir mühendis düşünün.
Bu mühendisin üretim kapasitesini artık klasik ekip büyüklüğüyle ölçemezsiniz.
Yazılım geliştirmek için mutlaka bir ekip kurmak zorunda olduğumuz dönem sona eriyor.
Yerini yüzlerce yapay zeka ajanını yöneten, tek kişilik yazılım ekipleri alacak.
İster kabul edin ister etmeyin, sektörün ekonomik dinamikleri bu dönüşümü hızlandıracak.
Oluşturduğum Software Factory bünyesinde, Loop Engineering yaklaşımıyla projelerin nasıl otonom bir şekilde geliştirildiğinden daha önce birçok kez bahsettim.
Loop Engineering için GPT + Opus ikilisini kullanıyorum.
İş bölümü oldukça net:
Opus: Implementasyon ve kod geliştirme
GPT: Analiz, mimari değerlendirme ve code review
Opus Max 20x üyeliğiyle bu setup içerisinde 2-3 projeyi paralel olarak 7/24, kesintisiz geliştirmek mümkün. Üstelik haftalık ve saatlik kullanım limitlerim dolmuyor.
Lakin GPT tarafında durum farklı.
Özellikle Sol ve Astra modellerinin gelmesiyle birlikte haftalık kullanım kontenjanım artık iki gün bile yetmemeye başladı.
Bu yüzden haftalık rate limit engeline takılmamak için üç ayrı Pro hesabı kullanıyorum. Sürekli hesap değiştirmek zorunda kalıyorum.
İşin ilginç tarafı şu:
Artık yazılım üretim kapasitemi sınırlayan faktör ne yazılımcı sayısı ne de kod geliştirme hızı. Yapay zeka modellerinin kullanım limitleri.
Software Factory’nin üretim kapasitesi, kullandığım modellerin inference kapasitesine ve erişim kotalarına bağımlı hale gelmiş durumda.
Yazılım mühendisliğinde darboğazın nereden nereye taşındığına bakar mısınız? ;-)
Software Engineer ünvanı artık sadece yazılım geliştirme yetkinliğini ifade etmiyor.
Bir Software Engineer’ın aşağıdaki rolleri de üstlenebilecek yetkinliğe sahip olması gerekiyor:
– Requirements Engineer
– Software Architect
– Test / QA Engineer
– Security Engineer
– Release and Deployment Engineer
– DevOps Engineer
– Performance Engineer
– Site Reliability Engineer (SRE)
Bir yazılımcının bütün bu işleri bizzat yapması gerekmiyor, ancak yapay zekanın yaptığı işleri değerlendirebilecek ve sonuçlarının sorumluluğunu üstlenebilecek yetkinliğe sahip olması gerekiyor.
Neden Vibe Coding Engineer diye bir mühendislik disiplini yok?
Çünkü artık kod yazmıyoruz ;-)
Kod yazmak, yazılım mühendisliğinin sadece bir parçasıydı. Yapay zeka bu kısmı büyük ölçüde üstlenmiş durumda.
Vibecoder’lara selamlarımla.
Bu işin çocuk oyuncağı olduğunu düşünmeye devem edeebilirler.
Yapay zeka sizi gereksinim analisti olmaya zorluyor.
Zamanla gereksinimleri ne kadar net ifade etmeniz gerektiğini anlıyorsunuz, çünkü yapay zekanın ürettiği çıktılar her zaman beklentilerinizle örtüşmüyor.
Bu noktada kendinize şu soruyu sormaya başlıyorsunuz: “Ben ne istediğimi nasıl daha iyi anlatabilirim?”
Bu soru sizi daha detaylı, daha sistematik ve daha analitik düşünmeye zorluyor.
Eskiden yazılımcıların gereksinim analizi konusunda ciddi eksikleri vardı. Büyük projelerde genellikle bir Requirements Engineer bulunurdu. Gereksinimler bu uzmanlar tarafından analiz edilir, detaylandırılır ve yazılımcılara hazır iş paketleri olarak sunulurdu.
Yani yazılımcılardan gereksinimleri keşfetmeleri değil, kendilerine verilen gereksinimleri implemente etmeleri beklenirdi.
Şimdi ise durum değişiyor.
Yapay zeka ile çalışan bir yazılımcı, öncelikle bir Requirements Engineer olmak zorunda.
Ne istediğini, neden istediğini, sistemin nasıl davranması gerektiğini ve hangi koşullarda ne yapacağını tarif edebilmesi gerekiyor.
Ardından bir Software Architect oluyor. Sistemin mimarisini, bileşenlerini, aralarındaki ilişkileri ve teknik sınırları belirliyor.
Sonra bir Test Engineer oluyor. Ortaya çıkan ürünün gereksinimleri karşılayıp karşılamadığını, beklenen davranışları sergileyip sergilemediğini doğruluyor.
Akabinde bir Release Engineer oluyor. Ürünün sürümlenmesini, paketlenmesini ve dağıtıma hazırlanmasını yönetiyor.
Son olarak bir DevOps Engineer oluyor. Ürünü canlıya alıyor, çalışmasını izliyor ve operasyonel sürekliliğini sağlıyor.
Dikkat ederseniz bütün bu süreçte yazılımcının kod yazmasından neredeyse hiç bahsetmedim, çünkü kodu artık büyük ölçüde yapay zeka yazıyor.
Ancak yapay zekanın neyi, nasıl ve neden yapacağını belirleyen kişi hala yazılımcı.
Eskiden yazılımcı, yazılım geliştirme sürecinin bir halkasıydı. Şimdi ise bütün zinciri yönetmek zorunda.
Artık yalnızca kod yazmayı bilmek yeterli değil. Yazılım mühendisliğinin tamamını anlamak gerekiyor.
Bu sebeple eskiden sadece kod yazan ama başka bir şeye karışmak istemeyen yazılımcıların kariyeri noktalanmıştır. Buna karşın interdisiplin çalışabilen mühendislere ihtiyaç daha da artacak.
Eğer kendinize yapay zeka çağında gelişmelere nasıl adapte edebilirim sorusunu soruyorsanız bu yazıda geçen mühendislik alanlarına naçizane odakllanmanızı tavsiye ederdim. Ya tüm zincire hakimsiniz ya da oyun dışı kalırsınız.
Artık yazılım mühendisliğini gerçek anlamda bir bütün olarak yaşabileceğimiz bir safhaya geldik. Bu çok güzel bir haber, lakin bu her mühendislik alanında derinleşmeye gerektiriyor. Bunu zaten yıllarca yapmış olan senior developer’lar 10-0 öndeler.
Yapay zeka araçları ile çok hızlı proje çıkarmak mümkün.
Ancak bunun bir de karanlık tarafı var:
Maymun iştahlılık!
Bir girişimciyseniz, üstüne üstlük bir de yazılımcıysanız ve senior developer seviyesindeyseniz, yüzlerce yazılımcıdan oluşan bir ordunuz varmış gibi istediğiniz projeyi geliştirebiliyorsunuz.
Lakin bu muazzam üretim kapasitesi beraberinde ciddi bir tehlike getiriyor.
Bahsettiğim maymun iştahlılık ya bir ürüne odaklanıp onu hızlıca tamamlamanızı engelliyor ya da “Şu da olsun, bunu da ekleyeyim” diyerek ürünün gereksiz yere şişmesine ve zaman kaybetmenize neden oluyor.
Biraz önce baktım. Otuz civarında Git repository’si oluşmuş durumda. Bunların her biri ayrı bir proje. Çok geniş kapsamlı bir platform üzerinde çalışmanın getirdiği yük bu. Ama aklıma sürekli yeni fikirler gelmiyor da değil.
Peki ben bu maymun iştahlılığı nasıl kontrol etmeye çalışıyorum?
Öncelikle proje tamamlandığında nasıl bir ürünün ortaya çıkması gerektiğine dair çok net bir vizyona sahip olmak gerekiyor.
Ne pahasına olursa olsun, o vizyondan sapmamak lazım.
İkinci adımda alt projelerin öncelik sırası geliyor. “Hangi projeyi şimdi çıkarmak zorundayım, hangisini öteleyebilirim?” sorularını kendime soruyorum.
Buradan çıkan öncelik sırasına göre projeleri tamamlamaya çalışıyorum.
Genellikle aynı anda 2-3 proje üzerinde çalışıyorum. Bunların büyük bir kısmı zaten Software Factory ile otonom olarak oluşturulan uygulamalar. Yani inşa edildikleri süre boyunca onlara dokunmuyorum. Fabrikadan çıktıktan sonra ise finetuning ile gereksinimlere göre adaptasyonlarını yapmaya başlıyorum.
Bazen aklıma çok ilginç bir fikir geliyor ve onu hemen hayata geçirme dürtüsüyle baş etmekte zorlanıyorum.
Bu durumda mevcut işimi bırakıp yeni fikrin peşinden koşmak yerine, loop engineering ve prompt engineering süreçlerinde oluşan boşluklarda, bir side project olarak o fikir üzerinde çalışmaya başlıyorum.
Ama ana odağımı o projeye kaydırmıyorum.
Buradaki amacım ekran başındaki boş vakitleri değerlendirmek ve yeni fikirleri denemek. Ana projelerin önceliğini değiştirmek değil.
Eskiden en büyük problemimiz fikirlerimizi hayata geçirecek yeterli üretim kapasitesine sahip olmamaktı.
Şimdi ise üretim kapasitemiz o kadar arttı ki asıl problem hangi fikirleri hayata geçirmeyeceğimize karar vermek hâline geldi.
Yapay zeka çağında girişimcilerin en önemli becerilerinden biri de sanırım bu olacak:
Daha önce de bahsetmiştim. Ajanların parladığı tek alan kod yazmak değil.
Canlı ortamların yönetimi için yapay zeka ajanları biçilmiş kaftan. DevOps süreçlerinin çok büyük bir bölümünü, hatta zamanla neredeyse tamamını ajanlara devretmek mümkün.
Bu amaçla Agentic Operations Center (AOC) adını verdiğim bir altyapı kurgulamaya başladım.
Bir uygulama düşünün. Bu uygulama bünyesinde aşağıdaki çalışma alanları tanımlı:
– Altyapı: Sunucular, CPU, RAM, disk ve diğer sistem kaynakları.
– Uygulamalar: Canlı ortamda çalışan servisler ve uygulamalar.
– Veritabanları: Performans, erişilebilirlik, bakım ve optimizasyon.
– Sürüm ve Deployment: Release, artifact ve deployment yönetimi.
– Güvenlik: Güvenlik açıklarının, tehditlerin ve anormal aktivitelerin tespiti.
– Incident Management: Sorunların tespiti, analizi, önceliklendirilmesi ve giderilmesi.
Her çalışma alanında görevleri ve sorumlulukları önceden belirlenmiş bir veya birden fazla ajan tanımlamak mümkün.
İkinci aşamada bu ajanların canlı ortama deploy edilmesi geliyor.
Bunun için canlı ortamda ajan koordinasyonunu, onboarding süreçlerini ve görev dağılımını yöneten merkezi bir uygulama bulunuyor.
Bu uygulama üzerinden yeni ajanların işbaşı yapmasını sağlamak, mevcut ajanlara görev vermek, çalışmalarını takip etmek ve hangi ajanın nerede, ne zaman, hangi işlemi gerçekleştirdiğini görmek mümkün olacak.
Yani bir nevi yapay zeka ajanlarından oluşan otonom bir operasyon ekibi kuruyoruz.
Üstelik bu ajanlar yalnızca sistemleri izlemekle kalmayacak. Sorunları analiz edecek, birbirleriyle koordineli çalışacak ve kendilerine tanınan yetkiler çerçevesinde gerekli müdahaleleri de gerçekleştirebilecekler.
Sistem henüz fikir ve tasarım aşamasında. Ancak birkaç gün içerisinde çalışan ilk versiyonunu ortaya çıkarmayı hedefliyorum.
Bir sonraki yazımda detaylarını sizlerle paylaşacağım.
Peki, DevOps mühendislerine ne olacak?
Bana kalırsa DevOps rolü ciddi bir dönüşüm geçirecek.
Bugün DevOps mühendislerinin gerçekleştirdiği operasyonel işlerin önemli bir kısmını gelecekte ajanlar üstlenecek.
DevOps mühendisleri ise doğrudan operasyonları gerçekleştirmek yerine, bu operasyonları yürüten ajan sistemlerini tasarlayan, geliştiren, yöneten ve denetleyen kişilere dönüşecekler.
Yani DevOps ortadan kalkmayacak. DevOps’un operasyonel iş gücü insanlardan ajanlara kayacak.
Eskiden bir uygulamanın nasıl olması gerektiğini anlamak için gerçek anlamda bir araştırma yapmak, müşteriye detaylı sorular sormak, gereksinimleri çıkarmak, mockup ve prototipler hazırlamak, ardından mimariyi oluşturmak gerekiyordu.
Simdi yapay zekaya istediğiniz şeyin bir resmini vermeniz bile yeterli olabiliyor. Detaylara haftalarca kafa patlatmadan, “Şöyle bir şey istiyorum” diyorsunuz ve kısa süre içinde çalışan bir karşılığını görebiliyorsunuz.
Burada aslında çok daha hızlı bir şekilde müşterinin isteklerini aynalayan bir çözüme ulaşmanın yolu açılıyor.
Müşteri “Bu olmamış” dese bile artık bu eskisi kadar büyük bir problem değil. Çünkü gerekli değişiklikleri çok hızlı bir şekilde yapıp yeni versiyonu tekrar müşterinin önüne koyabiliyorsunuz.
Bir anlamda gereksinim analizi ürün geliştirmeden önce yapılan bir aşama olmaktan çıkıp, ürünün kendisi üzerinden yapılan sürekli bir keşif sürecine dönüşüyor.
İşin vahametini göstermek için bir analoji aktarayım.
Kalp cerrahlarını düşünün.
Şimdi de herkesin yapay zeka aracılığıyla kalp ameliyatı yapabileceğine inandığını ve gerçekten ameliyat yapmaya başladığını düşünün.
Yazılım geliştirmek, özellikle büyük ve kritik sistemlerde, her zaman açık kalp ameliyatı yapmak gibiydi.
Bir cerrahin insan vücuduna müdahale edebilecek seviyeye gelmesi yıllar süren eğitim, gözetim ve pratik gerektirirken; yazılım dünyasında yeni mezun olmuş birisinin kurumsalda ise başlayıp birkaç hafta sonra binlerce insanın kullandığı sistemlerin kodunu değiştirmesi son derece normal karşılanıyordu.
Ama şimdi ölçek değişti.
Vibe coding yapanların projelere ne kadar büyük zarar verebileceklerini artık siz düşünün.
Çok acil bir şekilde bu mesleğe yeni başlayanların adam akıllı bir eğitim sürecinden geçirilmeleri ve zarar vermeden çalışabilecek seviyeye getirilmeleri gerekiyor.
Yapay zeka dönemini daha tam olarak idrak edememiş olanlara neden sadece deneyimli bir yazılımcının ön kişinin işini artık tek başına yapabileceğini hatırlatalım.
Evet, eskiden bir yazılım ürününü çıkarmak için frontend, backend, test, product owner, devops gibi rolleri üstlenen insanlara ihtiyacınız vardı. Yani bu işleri çoğu zaman 5-10 kişilik ekipler yapmak zorundaydı.
Şimdi bu 5-10 kişilik ekibin yaptıklarına bir göz atalım.
Neden bu kadar kişiye ihtiyaç vardı? Projeler neden aylar, hatta yıllar sürerdi?
Çünkü yapılması gereken muazzam miktarda manuel iş vardı. Sonra bunların hepsinin birbiriyle koordinasyonu gerekirdi. Toplantı, sprint, sürüm, deployment, müşteri istekleri derken iş uzayıp giderdi ve birçok elden geçerdi.
Dolayısıyla klasik yazılım geliştirme metodolojilerinin önemli bir kısmı aslında sadece yazılım geliştirmek için değil, insanlar arasındaki bu koordinasyon problemini yönetebilmek için ortaya çıktı.
Şimdi denklemin temel parametrelerinden biri değişiyor.
Bir yazılımcının yanında artık kod yazabilen, test oluşturabilen, kod tabanını analiz edebilen, dokümantasyon hazırlayabilen, bug araştırabilen, refactoring yapabilen ve altyapı scriptleri oluşturabilen yapay zeka ajanları var.
Deneyimli bir yazılımcı artık tek başına eskiden on kişilik bir ekibin yaptığı işi yapabilir, daha doğrusu ekibin yerine ajanların geçmesini ve onların yönetimini sağlayabilir.
Daha önceki bir yazımda 200K maaş için adaydan beklentilerdile getirdim.
Çoğu gelen yorumda “koyunun altında buzağı arıyorsun, hiç kimsede bu kadar yetenek bir arada olamaz” dendi.
Şunun altını çizeyim. Bu hiçbir şey değil. Yapay zeka bu hızda ilerlemeye devam ettiğinde, adaylardan beklenen yetenek ve tecrübelerde o hızla artacak.
Artık ajanların neredeyse kendi başlalarına sistem kurabilecekleri safhaya gelmiş durumdayız. Yazılımcı olarak diskalilfiye olmamak için bu hızlı gidişata ayak uydurmamız gerekiyor.
Extreme Programming gibi çevik süreçlerdeki ana çalışma prensiplerinden biri, müşteriye kısa aralıklarla ürünün ne durumda olduğunu gösteren çalışan prototipler sunmaktı.
Bunun için bir ya da iki haftalık sprint’ler planlanır, bu zaman zarfında seçilen user story’ler ürünün parçası haline dönüştürülürdü.
Peki neden bir ya da iki hafta?
Çünkü yazılım geliştirmek zaman alan ve maliyetli bir işti.
Analiz yapılması, kodun yazılması, test edilmesi, code review’dan geçmesi, entegre edilmesi ve müşterinin deneyebileceği bir ortama deploy edilmesi gerekiyordu.
Yapay zeka bu sürelerin tamamını dramatik biçimde aşağıya çekiyor.
Bir user story’nin implementasyonu artık günler değil saatler sürebilir. Testleri aynı anda üretilebilir. Review ajanlar tarafından paralel yapılabilir. Cİ/CD ve deployment otomasyonu ile birkaç dakika sonra çalışan sistem müşterinin önüne konulabilir.
Bu durumda 1-2 haftalık sprint kavramının da sorgulanması gerekiyor.
Çünkü sprint aslında feedback loop’un uzunluğuydu.
Yapay zeka ile feedback loop kısaldıkça sprint de küçülmek zorunda.
User Story → Implementasyon → Test → Deploy → Feedback
Bu döngünün iki hafta sürmesi gerekmiyorsa neden iki haftalık sprint yapalım? Bu iki hafta müşteriden kopmak anlamına gelir. Bu zaman zarfında zaten istenilen ürünü oluşturmuş olabiliriz.
Bence sprint kavramını tamamen ortadan kaldırmak lazım.
Müşteri ve yazılımcı arasında artık realtime bir ilişki söz konusu.
Yazılımcı müşterinin istediği değişiklikleri hemen implemente edebilir ve akabinden bunları müşteriye gösterip, geri bildirim alabilir. Akabinde döngü yine başlar.
Çevik süreçler tamamen geri bildirim (feedback cycle) üzerine kurgulanmıştı. Pair programming, TDD, CI vb yöntemlerin hepsi hızlı bir şekilde geri bildirim almak için vardı.
Şimdi bunlara gerek kalmadan gerçek zamanlı geri bildirim döngüleri oluşturabiliyoruz.
Bu yüzden geliştirme sürecinin temel zaman birimi “sprint” değil, feedback loop olmalı.
