Yeni bir projeye başladığınızda en büyük sorunlardan biri, projenin lokalde çalışan bir versiyonunu oluşturmaktır. Bunun için kodu, testleri ve dokümantasyonu okumanız, takıldığınız yerlerde çalışma arkadaşlarınıza danışmanız gerekir.
Bunların artık neden gerekli olmadığını kendi yaşadığım bir örnekle açıklayayım.
Altı ay önce Go ile bir Remote Device Management sistemi geliştirdim. Daha doğrusu ben değil, Opus geliştirdi. :)
Altı aydır dönüp bu projeyle hiç ilgilenmedim. Neler yaptığımı bile zar zor hatırlıyorum. Biraz dokümantasyon hazırlamışım. Onları okudum ve kabaca ne yapmam gerektiğine dair bir fikir oluştu. Ama bu bilgiler hala lokalde çalışan bir sistem kurmam için yeterli değildi.
GPT’ye sadece “kokalde çalışan bir sistem istiyorum” demem yeterli oldu.
Şu anda dashboard UI lokalde çalışıyor. Agent’ın derlenmesi ve Android üzerinde çalıştırılması aşamalarını da geçtik. Kısa bir süre sonra Android cihazının ekranına bağlanıp cihazı yönetebileceğim. Üstelik bütün bunları kod okumadan, testleri incelemeden, dokümantasyona gömülmeden ve kimseye soru sormadan yaptım.
Kısaca özetleyecek olursak:
İnsan unutuyor ama yapay zeka unutmuyor.
Daha doğrusu, insanın unuttuğu bilgiyi yapay zeka mevcut sistemden yeniden çıkarabiliyor. Artık bir projeye hakim olmak için önce bütün kodu anlamak zorunda değiliz. Ne yapmak istediğimizi bilmemiz yeterli olabiliyor.
İş ilanlarında artık “sınırsız token kullanımı” gibi avantajlar görmeye başladım. :-)
İşverenler buna benzer daha birçok oltalama yöntemi geliştirmek zorunda kalacaklar, çünkü yapay zekaya gerçekten hakim, onu etkin kullanabilen senior yazılımcı bulmak hiç de kolay olmayacak.
Yapay zeka araçlarını kullanabilen yazılımcı çok olacak. Bu araçlarla uçtan uca ürün geliştirebilen, onlarca ajanı organize edebilen ve ortaya çıkan ürünün sorumluluğunu alabilen senior yazılımcı ise o kadar kolay bulunamayacak.
Üstelik bu yazılımcılar artık eskisinden çok daha fazla üretim kapasitesine sahip olacaklar.
Dolayısıyla işverenler yalnızca maaş konusunda değil, yazılımcılara sundukları yapay zeka altyapısı konusunda da rekabet etmek zorunda kalacaklar.
Yakında iş görüşmelerinde adayların işverene sorduğu sorulardan biri şu olabilir:
“Aylık maaşınızı anladım. Peki, token bütçem ne kadar?” :-)
Bunların hepsi insanların kod yazdığı, birbirlerinin kodlarını incelediği ve sınırlı bir üretim kapasitesine sahip olduğu bir dünyanın ürünleri.
Şimdi ise yazılımı insanlar değil, giderek daha fazla yapay zeka ajanları üretiyor.
İnsanlar için tasarlanmış araçlarla, insanlardan binlerce kat daha hızlı çalışabilen ajanları yönetmeye çalışıyoruz.
Doğal olarak bu araçlar ve yöntemler birer birer darboğaza dönüşmeye başlıyor.
Bence önümüzdeki dönemde yalnızca yazılım geliştirme yöntemlerinin değil, yazılım mühendisliğinin bütün araç ekosisteminin yeniden şekillendiğini göreceğiz, cünkü mesele artık mevcut araçları yapay zekaya uyarlamak değil.
Yapay zekanın çalışma biçimine uygun yeni bir yazılım mühendisliği inşa etmek.
Git bunun ilk örneklerinden biri. Sonuncusu olmayacak.
Bugün bir startup kursam, kesinlikle AI Native Company olurdu.
Böyle bir şirket kurmak için sadece GPT ya da Opus kullanıyor olmak yeterli değil.
Şirket bünyesindeki tüm süreçleri yönetebilen bir AI Operating System gerekiyor.
Bu işletim sistemi üzerinde ajanların otonom çalışabilmeleri için şirketin süreçlerine, ürünlerine, müşterilerine, kararlarına ve operasyonlarına ilişkin tüm bilgi ve verilerin merkezi bir sanal beyinde (Company Brain) toplanması gerekiyor.
Ama Company Brain sadece bir bilgi deposu degil. Şirketin nasıl çalıştığını, hangi kararların neden alındığını, süreçlerin birbirleriyle nasıl ilişkili olduğunu ve hangi kurallar çerçevesinde yürütüldüğünü de bilmeli.
Ajanlar bu ortak beyin üzerinden şirketin mevcut durumunu anlayabilmeli, birbirleriyle koordineli çalışabilmeli, karar alabilmeli ve yetkileri dahilinde aksiyona geçebilmeli.
Burada üç temel bileşen ortaya çıkıyor:
Company Brain:
Şirketin kurumsal hafızası, bilgisi ve operasyonel bağlamı.
AI Operating System:
Süreçleri, görevleri, yetkileri ve ajanlar arasındaki koordinasyonu yöneten altyapı.
AI Agents:
Kendilerine tanımlanan sorumluluklar çerçevesinde otonom çalışan dijital iş gücü.
Böyle bir yapıda insanın rolü de değişiyor.
İnsanlar artık bütün operasyonları bizzat yürüten kişiler olmaktan çıkıp, hedefleri belirleyen, politikaları tanımlayan, kritik kararları veren ve yapay zeka sistemini yöneten kişilere dönüşüyor.
AI Native Company, yapay zeka kullanan bir şirket değil aslinda. Yapay zekanın şirketin işletim modelinin merkezinde olduğu bir organizasyon.
Eskiden hata bulmak için kod içinde debug yapardık.
En son ne zaman debugger kullandığımı hatırlamıyorum.
Debug yapmak benim için hiçbir zaman iyi bir alışkanlık değildi, çünkü çoğu zaman sistemin nasıl çalıştığına dair zihinsel modeldeki eksikliklere işaret ederdi.
Yapay zeka ile birlikte debugging de bambaşka bir boyuta taşındı.
Artık kodun içinde breakpoint’ler koyup, değişkenlerin değerlerini inceleyerek hatanın kaynağını aramıyorum.
Gördüğüm hatayı yapay zekaya bildiriyorum. O da kodu analiz ediyor, hatanın kaynağını tespit ediyor ve gerekli düzeltmeleri yapıyor.
Benim rolüm ise yapılan düzeltmenin gerçekten problemi çözüp çözmediğini ve sistemin beklenen davranışlarını koruyup korumadığını doğrulamak.
Yani debugging ortadan kalkmadı. Sadece işi yapan değişti.
Eskiden hatanın nerede olduğunu bulmaya çalışırdık. Şimdi hatanın ne olduğunu doğru tarif etmeye çalışıyoruz.
Kod seviyesindeki debugging’den davranış seviyesindeki debugging’e geçiyoruz.
Otuz yıla yakın yazılımcı kariyerimde iki büyük kırılma yaşadım.
Bunlardan ilki imperatif programlamadan fonksiyonel programlamaya geçişti. Çok uzun süre imperatif kod yazmaya alışmış bir beyin, fonksiyonel programlamaya kolay adapte olamıyor. O dönemde çok zorlandığımı hatırlıyorum.
İkinci büyük kırılmayı ise üç sene önce yapay zeka ile tanıştığımda yaşadım. İlginç olan, bu sefer hiç zorlandığımı hatırlamıyorum.
Bunun nedenini düşündüm ve şöyle bir sonuca vardım:
İlk kırılmada düşünme biçimimi değiştirmek zorundaydım. İkinci kırılmada ise zaten sahip olduğum düşünme biçimini doğrudan kullanmaya başladım.
İmperatif programlamadan fonksiyonel programlamaya geçerken beynimi yeni bir programlama paradigmasına adapte etmek zorundaydım. Yıllarca edindiğim alışkanlıklar, yeni düşünme biçiminin önünde engel oluşturuyordu.
Yapay zekaya geçişte ise tam tersi bir durum yaşadım.
Artık algoritmaları adım adım ifade etmek zorunda değildim. Ne istediğimi, neden istediğimi, hangi koşulların sağlanması gerektiğini ve hangi sınırların aşılmaması gerektiğini anlatmam yeterliydi.
Aslında başka bir yazılımcıya iş verirken de böyle davranıyordum. Ona değişkenleri, döngüleri ve koşulları tarif etmiyordum. Problemi ve beklentilerimi anlatıyordum.
Yapay zeka ile de aynı şeyi yapmaya başladım.
Bir başka önemli nokta ise soyutlama seviyesi.
Otuz yıla yakın yazılım geliştirmiş biri olarak zaten uzun zamandır problemleri yalnızca kod seviyesinde düşünmüyordum. Mimari, gereksinimler, iş süreçleri ve sistem davranışları düşünce dünyamın önemli bir bölümünü oluşturuyordu.
Yapay zeka, bu düşünme biçimine doğrudan karşılık gelen bir araç sundu.
Yani yapay zekaya geçiş benim için yeni bir düşünme biçimi öğrenmekten ziyade, zaten sahip olduğum düşünme biçimini kullanabileceğim bir ortama geçmek anlamına geliyordu.
Burada çok ilginç bir paradoks var.
Fonksiyonel programlamaya geçerken beynimi makinenin anlayabileceği farklı bir modele adapte etmek zorundaydım.
Yapay zekaya geçerken ise makine benim düşünme ve ifade biçimime adapte olmaya başladı.
Birincisinde insan makineye yaklaşıyordu.
İkincisinde makine insana yaklaşıyor.
Sanırım yapay zekaya geçişte hiç zorlanmamamın temel nedeni bu.
İlk defa yazılım geliştirmek için bir programlama dilinin düşünme biçimine adapte olmak zorunda kalmadım.
Bu sefer teknoloji benim düşünme biçimime adapte oldu.
Aynen gelen bir yorumu paylaşıyorum. Sonra problemin ne olduğunu açıklamaya çalışacağım.
“ancak ai tarafindan cok kez yanlis sonuc olduguna emin oldugum cevaplar aldim eminmisin dedigimde haklisin deyip yeni bir kod verdi.. ya da verdigi koddaki guvenlik aciklari saymakla bitmez.”
Öncelikle şunu belirtelim:
Bu şekilde yapay zeka ile yazılım geliştirilmez.
Karşınızda deterministik olmayan bir yapı var. Tabii ki zaman zaman kafasına göre bir şeyler anlatacak. Tabii ki size sürekli “Haklısınız!” diyecek. Bunlar yapay zekanın bilinen davranış biçimleri.
Burada üç temel noktaya dikkat etmek gerekiyor.
Birincisi: Yapay zekayı sürekli sorgulayarak, “Emin misin?” diye sorarak doğru sonuçlara ulaşamazsınız. Çünkü verdiği cevapların doğruluğunu kendisinin teyit etmesi güvenilir bir doğrulama yöntemi değildir.
İkincisi: Yapay zeka için kontrol ve denetim mekanizmalarının oluşturulması gerekiyor.
Bu mekanizmaların önemli bir kısmını analiz yeteneği güçlü başka bir yapay zeka modeliyle oluşturabilirsiniz. Her model hem analiz hem de yazılım geliştirme konusunda aynı derecede başarılı olmayabiliyor.
Bir model gereksinimleri analiz eder, başka bir model uygulamayı geliştirir, üçüncü bir model de ortaya çıkan sonucu bağımsız olarak denetler.
Üçüncüsü: Deterministik olmayan bir yapıdan deterministik beklentilerinizi karşılayan çıktılar almak istiyorsanız, çalışma çerçevesini ve beklentilerinizi çok net ifade etmeniz gerekiyor.
Bunun için iki önemli aracımız var:
Onay/kabul kriterleri: Uygulamanın hangi koşullarda doğru çalıştığını tanımlar.
İnvariantlar: Sistemin hangi koşullarda olursa olsun ihlal etmemesi gereken kuralları tanımlar.
Kabul kriterleri olmadan uygulamanın beklenen davranışları sergilediğinden, invariantlar olmadan da sistemin temel kurallara uygun çalıştığından emin olamazsınız.
Ancak bunları tanımlamak da tek başına yeterli değildir. Bu kuralların otomatik olarak doğrulanabildiği mekanizmalar oluşturmanız gerekir. Özellikle güvenlik söz konusu olduğunda bağımsız kontroller de şarttır.
Asıl problem yapay zekanın yanlış kod üretmesi değil, yanlış kodun doğruymuş gibi kabul edilmesine izin veren geliştirme yöntemidir.
Yapay zekaya güvenerek yazılım geliştirilmez. Yapay zekanın ürettiklerini doğrulayabilen bir sistem kurarak yazılım geliştirilir.
Emin mısın diye soran birisi ne yazık ki ne yaptığının farkında bile değildir.
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? ;-)
