Otonom yazılım üreten bir sistem: beş haftalık hata listesi

2018'de bir test konferansında "yapay zeka gelecek elbette, ama ne zaman acaba?" diye tweet atmışım. Ondan birkaç ay önce de LinkedIn'de birine "qa, exploratory testing yapabilecek bir ai gelene kadar ölmez hocam" demişim. Sekiz sene sonra AI'ın hayatımızın içine girdiği bir dönemdeyiz artık. Ben de merak ettim: bugün bu ajanlarla tek başıma bir yazılım şirketi kurabilir miyim? Bunu kendi bilgisayarımda denedim ve ortaya otonom çalışan bir şirket simülasyonu çıktı. Benden başka insan çalışanı yok, geri kalan herkes ajan.

Bu yazı o sistemin ilk beş haftası. Ama bir başarı hikayesi değil, daha çok bir hata ve optimizasyon listesi. Çünkü ilk iki haftayı ürün yazmak yerine ürün yazacak sistemi yazmakla geçirdim ve bunu fark etmem bir haftamı aldı.

5 hafta · 15 subagent · 1.100+ merge edilmiş PR · 9 runner, 3 makine

Bu arada bu yazıyı ben yazdım 🙂 Yapay zekaya sadece ufak düzenlemeler yaptırıp rakamları ve grafikleri ona çıkarttırdım. Elbette tamamını kendi başına da yazabilirdi, ama en azından bunu ben yapmak istedim.

Neden başladım

Son çalıştığım yerde kodun neredeyse tamamını AI araçlarıyla yazıyorduk. Ama hızlı release çıkarmanız gereken, deadline'ları katı projelerde çok fazla Ar-Ge yapmaya vaktiniz olmuyor. Sistemi yine hızlı bir yardımcı olarak kullanıyorsunuz, sınırlarını zorlamaya fırsat kalmıyor. Ben de şimdi bu sınırları zorlamak istedim.

Amaç basitti: yapay zekanın gerçekte neler yapabildiğini denemek ve kendi kendine ürün çıkaran bir yapı kurmak. Öncesinde de Claude Code ile tek tek projeler yapıyordum zaten. İlk projem, kendi ihtiyaç duyduğum ama pratik bir uygulamasını bulamadığım bir araçtı. Ama her projede aynı döngüyü tekrarlıyordum: oturumu aç, ne istediğini anlat, kontrol et, düzelt. Yani elimde bir ajan değil, çok hızlı yazan bir stajyer vardı.

Benim kafamdaki şey başkaydı. Ben sadece fikri vereyim, product manager ürün dokümanını yazsın, business developer ürünü geliştirecek fikirler ortaya atsın, architect tasarımı çıkarsın, geliştirici kodu yazsın, reviewer incelesin, QA test etsin. CEO olarak da kararları ben vereyim. 15 yıl test, yazılım ve platform ekiplerinde çalıştım ve bu ekiplere liderlik ettim. Bu yapıyı zaten ezbere biliyordum, ajanlara da öğretirim diye düşündüm.

Kurulum

İlk commit'i 1 Eylül 2026'da attım. İçinde 1.885 kelimelik bir anayasa (CLAUDE.md), 14 ajan tanımı ve bir başlangıç prompt'u vardı. Her ajanın rolü, kullanacağı model ve karar yetkisi yazılıydı. Kim mimari kararı yazar, kim kodu onaylar, kim yayına karar verir, hepsi bir tablodaydı.

Sistemin bugünkü kadrosu: CEO olarak ben, işleri dağıtan team lead ve 15 subagent. acting-ceo da bunlardan biri ama team lead’den iş beklemiyor, 30 dakikada bir kendi başına çalışıyor. Mavi kutular kod derleyip test koşturan ajanlar.

Teknoloji tarafı da baştan belliydi: backend'de Go, web'de Next.js, mobilde Kotlin ve Swift, veritabanında PostgreSQL. Fanboyluk seviyesinde sevdiğim Java'yı listeye almadım. Kodu ben yazmayacaksam, kaynak kullanımı yüzünden ona gerek olmadığını düşündüm. İleride Rust'ı da deneyebiliriz, iki platformda birden çıkacak ürünlerde de Flutter ile ilerleyebiliriz. Hosting için Google Cloud Run, PostgreSQL için de Neon kullanıyorum, web hosting için de Firebase. Bunların hepsi belli bir istek sayısına kadar ücretsiz.

Bir de iş takibi var. Her ürünün kendi reposu ve kendi GitHub board'u var. Ajanlar issue açıyor, ADR ve RFC gibi dokümanlar yazıyor, branch açıyor, PR açıyor ve ayrı bir bot hesabıyla birbirlerinin PR'larını onaylıyor. Kağıt üstünde gayet profesyonel.

1- Yedi quality gate yazdık, hiçbiri çalışmadı

Ajanlar ilk iki günde yedi tane quality gate yazdı: branch adı kontrolü, migration koruması, linting, hızlı testler, oturum başında durum özeti, iş bitti denmeden önce son kontrol ve merge gate. Bunlar için 508 test senaryosu yazıldı ve hepsi yeşildi. Üstelik altı review turundan geçtiler.

0 / 7 gate gerçekten çalışıyordu. Oysa 508 test senaryosu yeşildi ve hepsi altı review turundan geçmişti.

Sonra ilk retro'da ortaya çıktı ki bu gate'leri devreye sokan ayar satırı hiç yokmuş. Yani yedi gate'in yedisi de iki gün boyunca bir kere bile çalışmamış. Metrik tablosuna "Gates live: 0/7" diye geçti.

Açıkçası test otomasyonundan gelen biri olarak en çok bu canımı sıktı, çünkü bu klasik bir hata. Testler gate'lerin kendisini doğruluyordu, gerçekten devrede olup olmadıklarını değil. Retro bunu çok güzel özetlemişti: "absence reads as success". Yani bir şeyin seni durdurmaması, onun çalıştığı anlamına gelmiyor. Ertesi gün gate'lerin gerçekten açık olup olmadığını canlı ayardan okuyan bir script geldi. Günlük standup'a da "kaç gate canlı" satırı eklendi.

2- Ürün yerine süreç ürettik

Gate'ler çalışmaya başlayınca bu sefer tam tersi oldu. 7 Eylül'e geldiğimizde 50 altyapı PR'ı merge edilmişti, ürün tarafında ise sadece 28. Merge gate tek başına 13.251 satır olmuştu ve 635 test senaryosu vardı. Peki ne yapıyordu? GitHub'ın branch protection özelliğini bash ile baştan yazıyordu, çünkü ücretsiz planda private repolarda bu özellik yok. GitHub'a para vermemek için 13 bin satır bash yazdırmışım, hey gidi.

Bu gate her gün 2 ile 7 arası meşru işi engelliyordu. En komiği, bu sorunu anlatan retro'yu da engellemişti.

13.251 satır bash ve 635 test senaryosu. GitHub'ın ücretli planındaki branch protection özelliğini kendimiz yazmışız.

Bir de review turları vardı. 3 Eylül'de baktım, her PR 3 ile 5 tur dönüyor. Turların çoğu da davranışı değil, metni düzeltiyor. Güvenlik onayı 28 ürün PR'ının 17'sinde zorunlu olmuş, çünkü ajanlar "para" kuralını uygulamanın içindeki para diye okumuş. Finansla alakalı bir projede de tabii her PR parayla ilgili. Benim kastettiğim ise bu sistemin harcadığı paraydı. O 17 güvenlik onayı toplamda bir kere bile işe yarar bir engel çıkarmamış.

Bunu standup'ları okurken fark ettim. Her gün "dün ne yapıldı" bölümünde hep gate'ler, testler, kontroller vardı. Ürün ise hep "yarın". 6 Eylül'de ajanlara kelimesi kelimesine şunu yazdım: "security kontrolü ve review check yaparken daha geçirgen ol, mvp sonrası da düzeltilebilecek şeyler kalabilir, şunu unutma sadece ben localimde kullanacağım bu uygulamayı uzun süre."

Ertesi gün büyük bir temizlik yapıldı. Merge gate tamamen silindi, tek günde 11,7 bin satır gitti ve gate sayısı yediden dörde indi. Review tek tura düştü, reviewer artık sadece blocking bulguları yazmaya başladı. Altyapı PR'ları da ikinci bir onay beklemeden merge edilmeye başladı. Anayasaya da bir madde eklendi: code freeze. Sistemin kendi kuralları artık sadece aktif bir ürün engeli olduğunda ya da ben doğrudan karar verdiğimde değişebiliyor.

Sonucu grafikte görüyorsunuz. İlk hafta altyapı işleri üründen fazla, sonrasında ürün açık ara öne geçiyor.

Haftalık merge edilen PR sayısı. Turuncu şirket altyapısı, mavi ürün repoları. Son sütun 3 günlük yarım hafta.

3- Her ajan anayasanın tamamını okuyordu

Anayasa ilk gün 1.885 kelimeydi. Her retro ona birkaç madde ekledi ve 8 Eylül'de 2.972 kelimeye çıktı. Sorun şuydu: bu dosya her ajan çalıştığında baştan okunuyordu. Sekiz ajan çalışıyorsa sekiz kere okunuyordu. Örneğin product manager'ın iPhone simülatörüyle ilgili kuralı bilmesine gerek yoktu, ama yine de okuyordu.

11 Eylül'de anayasayı ikiye böldüm. Herkesin her işte bilmesi gereken kurallar ana dosyada kaldı, gerisi sadece ihtiyaç olunca okunan bir handbook'a taşındı. Kelime sayısı 1.119'a indi.

Ajan tanımlarını da aynı mantıkla baştan yazdık. Önceden her ajanın dosyası, işinin bütün ayrıntılarını anlatan uzun bir talimat metniydi. Şimdi her biri kısa bir rol kartı: neyin sahibi, ne zaman çağrılır, neye karar verir, neyi yapmaz ve işi teslim ederken ne yazar. Ayrıntılar, sadece gerektiğinde okunan skill dosyalarına taşındı.

Aynı gün iki kural daha geldi. Birincisi, team lead ajanlara iş verirken geçmişin tamamını değil, sadece beklenen sonucu, dokunacağı dosyaları ve işin ne zaman bitmiş sayılacağını veriyor. İkincisi, ajanlar işi teslim ederken en fazla sekiz satır yazıyor.

Anayasanın her değişiklikten sonraki kelime sayısı. 11 Eylül'deki düşüş handbook'a taşıma.

Grafiğin sağ tarafına bakınca ne olduğunu zaten görüyorsunuz: sayı yeniden 1.993'e çıkmış. Kural eklemek kolay, silmek zor. İnsanlardan oluşan şirketlerde de aynı pattern var. Tek fark, orada kural silmenin zor değil, imkansıza yakın olması :)

4- Token'ı yazmaya değil, okumaya harcıyormuşuz

Bu benim en pahalı dersim oldu. Eylül ortasında 5 saatlik limit 2 saat dolmadan, haftalık kullanım limitim de 3-4 günde bitmeye başladı. Sonrasında da haftanın kalanında oturup bekliyorsunuz ya da kredi kartınızı verip kredilerinizin hızlıca erimesini izliyorsunuz.

Eylül'ün ikinci yarısında süreçte pek bir değişiklik yok, çünkü bu dönemin bir kısmında tatildeydim ve süreçle ilgili pek bir şey değiştirtmedim. Döndüğümde ajanlara kendi konuşma kayıtlarını analiz ettirdim. 13 ile 27 Eylül arasında 34,6 bin model çağrısı çıktı ve tablo şaşırtıcıydı. Harcamanın %78'i, modelin önceki konuşmayı her seferinde baştan okumasına gidiyormuş. Modelin yazdığı kısım ise sadece %4. Konuşmalar çok uzayınca harcamanın yarısından fazlası oraya gidiyordu, çünkü auto-compact çok geç devreye girecek şekilde ayarlıydı.

13–27 Eylül arası token harcamasının dağılımı. Dilimler örtüşüyor, toplanmaz.

Detaylar daha da komik. Team lead bir oturumda 867 kere "yeni mesaj var mı" diye bakmış, 867'sinde de cevap "yok". Linting hook'u, ajan daha dosyayı yazarken araya 1.700 kere lint çıktısı sokmuş. Kodu yazan ajanlar da bir işi testler ve review dahil baştan sona tek bir uzun konuşmada taşıyordu. Bir iş bitene kadar 300 ile 1.000 arası tur dönüyordu.

27 Eylül'de şu düzeltmeleri yaptık:

1. Auto-compact çok daha erken devreye giriyor.
2. Geliştirici ajanın işi PR'ı açınca bitiyor. CI'ın bitmesini team lead bekliyor, review'dan dönen bulguları da sıfırdan başlayan yeni bir ajan alıyor.
3. Her ajanın kaç tur dönebileceğine bir sınır kondu.
4. Boş yere tekrar tekrar "mesaj var mı" diye bakmak engellendi.
5. Testlerin ve araçların çıktıları uzun uzun değil, özet olarak okunuyor.

Team lead hâlâ en güçlü modelde çalışıyor, onu değiştirmedim. Maliyeti modelden değil, konuşmaların uzunluğundan ve ömründen kestik. Sonuç beni de şaşırttı. Önceden limit 3-4 günde bitiyordu, şimdi çok daha fazla iş yapmamıza rağmen 6-6,5 gün yetiyor. Bu yazıdan önceki son haftayı da limiti tamamen tüketmeden, %99'da bitirdim. 5 saatlik limit de artık hiç dolmuyor.

Aynı plan, aynı model. Fark konuşmaların boyunda.

5- Bütün ajanlar tek bir 32 GB makinede

Ajanların hepsi evdeki 32 GB DDR5 RAM'li Windows makinemde çalışıyor. Aynı makinede CI işlerini koşturan dört tane de GitHub runner var. Aslında toplamda üç makinede dokuz runner var. 32 GB DDR4 RAM'li 2019 model bir MacBook Pro ve Linux kurduğum, 16 GB ama DDR3 RAM'li 2011 model bir MacBook Pro da bunlara dahil. Ama ajanları diğer makinelerde de açıp çalıştıracak bir yapıyı henüz kuramadım, şu an onun üzerinde çalışıyorum.

Ajanlar tek makinede, CI işleri üç makineye dağılıyor.

Önce "aynı anda en fazla beş ajan" diye tek bir kural koymuştum. Sonra fark ettim ki reviewer, architect, product manager gibi ajanlar bilgisayarda neredeyse hiç kaynak harcamıyor, çünkü işleri modelin tarafında dönüyor. 28 Eylül'de sınırı ikiye ayırdım: kod derleyip test koşturan en fazla beş ajan (Android emülatörü açıkken üç), bunun dışında da en fazla üç ajan. Lint gibi hafif CI işleri de 2011 MacBook'a gitti.

6- Hatalar review'da değil, daha önce önlenmeliydi

Sistemin en çok iş yaptırılan ürününde MVP'nin tamamı çıktı ve 514 PR merge edildi. Ama bir şey canımı sıkıyordu: her işten sonra review'da ve QA'de bir sürü hata çıkıyordu. 29 Eylül'de bunu derinlemesine incelemelerini istedim.

Çıkan tablo şu: son 300 PR'ın 100'ü en az bir kere "changes requested" almış. Blocking bulguların yaklaşık %45'i kodla ilgili bile değil. Kod değişmiş ama tasarım dokümanı, ADR ya da bir kod yorumu hâlâ eski halini anlatıyor. QA tarafında 76 gerçek ürün hatası var. Testler de ne gerçek veriyle ne de küçük bir telefon ekranında yapılmış.

29 Eylül analizi. Turuncu kareler en az bir kere geri dönen PR'lar.

İşin asıl ironik tarafı başka. Retro ajanı da vardı, retro rehberi de, ama bu uygulama için bir kere bile ürün retro'su yapılmamıştı. Beş tane tekrar eden hata çıktı, yani aynı hata farklı bir yerde yeniden düzeltilmiş. Bunu yıllarca ekiplere anlatmış biri olarak ajanlara anlatmayı unutmuşum.

Bundan önce bir de issue enflasyonu yaşadık. Günde açılan issue sayısı sekiz günde 4'ten 31'e çıktı. Bir issue açmak bir dakika sürüyor, ama kapatmak için ayrı bir çalışma alanı, bir branch, bir PR, bir review ve bir CI koşusu gerekiyor. 14 Eylül'den beri hata olmayan bulgular ayrı issue açmıyor. Hepsi o işin tek bir "follow-ups" issue'suna birer satır olarak giriyor.

7- Her karar bana geliyordu

İlk iki günde ajanlar bana 15 karar sorusu açtı. Çoğu da benim düşünmeme gerek olmayan teknik ayrıntılardı.

Kuyruk zamanla azaldı ama hiç bitmedi. 5 Ekim'de bir de "vekil CEO" (acting-ceo) ajanı ekledim. Harcama, production deploy ve anayasa bende kaldı, gerisine o karar veriyor. Kendi tanımını, anayasayı ve ayarları değiştiremiyor, yoksa bende kalan yetkileri de kendine alabilirdi. Bir de 2 Ekim'den beri bildirimler Telegram'a geliyor. Claude'un mobil uygulamasına da normalde bildirim geliyor ama tam istediğim gibi değil. Telegram sayesinde artık bilgisayar başında oturmama gerek kalmadı.

Yine de acting-ceo tam olarak istediğim gibi çalışmıyor. Çünkü farklı oturumlardaki ajanlar birbiriyle doğrudan konuşamıyor, ya da ben henüz bunu sağlayamadım. Bu yüzden ajanlar karar gereken yerde GitHub'da bir "decision" issue'su açıyor, acting-ceo da 30 dakikada bir açık issue'lara bakıp karar veriyor. Yani polling ile çalışan bir yapı.

10 / 10 acting-ceo geldikten sonra açılan karar issue'larının hepsi aynı gün kapandı. Toplamda 75 karar issue'su açıldı, şu an açık olan yok.

8- Ajanın göremediği tek şey

Son hikaye küçük ama canımı sıkanlardan biri. Çünkü ana amacım her şeyi ajanların ilerletmesi, benim de mümkün olduğunca az müdahil olmam. Elle yapmak zorunda kaldığım her iş canımı sıkıyor ve onu aşmanın bir yolunu arıyorum.

Chrome'daki yeni sekme sayfam için bir eklenti yaptırdım, sayfanın bir yerinde Untappd ve Letterboxd istatistiklerimi de gösteriyor. 6 Ekim'de Untappd kartında "Okunamadı" yazmaya başladı. Cloudflare eklentinin isteğini geri çeviriyor, araya "Just a moment..." sayfasını sokuyordu.

Architect güzel bir ADR yazdı, dokümantasyonu taradı, bir sürü seçenek çıkardı. İlk önerisi, Cloudflare doğrulamasını eklentinin içinde gizli bir sayfada (iframe) çalıştırmaktı. Ama bir noktada şunu söyledi: tarayıcının Cloudflare doğrulama çerezi isteğe gidiyor mu, gitmiyor mu, bunu hiçbir ajan göremez. O çerez kod tarafından okunamıyor. Bunu ancak benim kendi Chrome'umda DevTools'u açıp bakmam söyleyebilir.

Açtım, baktım. Çerez gönderilmiyordu. Yani iframe önerisi zaten çalışamazdı, Cloudflare'in kendi dokümanı da bunu söylüyordu. Çözüm daha basit oldu: ben Untappd'ye girdiğimde eklenti sayfadaki sayıları yakalıyor, kart da son değeri ne zaman alındığıyla birlikte gösteriyor. Okuyamadığında da artık nedenini yazıyor.

Ajan dokümanı benden iyi okuyor, seçenekleri benden hızlı çıkarıyor. Gerçek dünyaya dokunan son adımı yapamadığında da bunu açıkça söyledi. Ajanların henüz yapamadığı işlerden biri de bu oldu: Chrome gibi bir uygulamanın içinde DevTools'u kullanmak. Bildiğim kadarıyla bunu yapamıyorlar, gerçi çok da zorlamadım. Belki DevTools'un kendi API'siyle yapabilirler, onu da henüz denemedim. Elle yaptığım işler listesinde şimdilik bu da duruyor.

İlk beş haftada fark ettiğim sorunlar ve yerine konan düzeltmeler.

Bugün nasıl çalışıyor

Her iş başlamadan önce üç yoldan birine ayrılıyor. Küçük bir hata için product manager, architect ve tasarımcı çağrılmıyor, sadece geliştirici ve reviewer yeterli. Mimariyi etkileyen bir değişiklikte architect devreye giriyor, gerekiyorsa bir ADR ya da RFC yazıyor. QA da her PR'ı değil, bitmiş bir özelliği gerçek sistem üzerinde test ediyor.

Üç çalışma yolu ve her birinin gerektirdiği roller.

1 Eylül'den bu yana 11 repoda 1.109 PR merge edildi, bunların 833'ü son üç haftada.

Baştan başlasam ne yapardım

1. Süreci yine önce kurardım, çünkü bence her zaman önce süreç kurulmalı. Ama kurarken daha fazla kafa yorar, onu farklı modellere de inceletirdim. Bu sistemi kurarken bazı modeller bana tam tersini önerdi: önce ürünü çıkar, süreci ihtiyaç doğdukça ekle. Aslında çoğu firma bunu daha agile bulur. Ama ben yapının en baştan kurulması gerektiği felsefesini daha çok benimsiyorum.
2. Bir kontrolün çalıştığına, onu yazan ajan "çalışıyor" dedi diye değil, farklı bir ajan canlı ayara bakıp doğruladığında inanırdım.
3. Kullanımı ilk günden ölçerdim. Limiti asıl tüketen şey yazılan kod değil, uzadıkça her seferinde baştan okunan konuşmalar.
4. Ajanlara retro'yu zorunlu kılardım. Retro yoksa aynı hatayı farklı bir işte yeniden düzeltiyorsunuz.
5. Dokümanın kodla aynı PR'da güncellenmesini ilk günden kural yapardım. Blocking bulguların neredeyse yarısı, kod değişip dokümanın eski halinde kalmasından çıktı.
6. QA testlerini en baştan gerçek veriyle ve küçük bir telefon ekranında yaptırırdım. İlk testler ikisini de atlıyordu.
7. Her bulgu için ayrı issue açtırmazdım. Issue açmak bir dakika, kapatmak bir PR, bir review ve bir CI koşusu.
8. Yeni bir kural eklemeden önce mevcut kuralların bunu zaten karşılayıp karşılamadığına bakardım, anayasayı da düzenli aralıklarla gözden geçirirdim. 1.119 kelimeye indirdiğimiz anayasa birkaç hafta içinde tekrar 1.993'e çıktı.
9. Elle yaptığım her işi ilk günden bir listeye yazardım. O liste, sistemin henüz kendi başına yapamadığı işlerin listesi ve sıradaki hedefim de o.
10. Hangi kararların bana gelmesi gerektiğini ilk gün yazardım. Şimdilik üç tane: harcama, yayın, anayasa. Gerisi bir ajanın işi. İleride amacım bu üçünü de sisteme bırakmak.

Özetle, bence ajanlar kod yazmayı çoktan öğrenmiş. Onlara beraber çalışmayı öğretmesi gereken bendim. Hedefim de hâlâ aynı: işi baştan sona onlar yürütsün, ben sadece gerçekten bana ait kararları vereyim. Beş hafta sonunda bu noktaya ilk günkünden çok daha yakınım, ama elle yaptığım her iş hâlâ aşmam gereken bir engel.

Yazılım mühendisliğinin geleceği

Çalıştığım ekiplerde zaman zaman yazılım mühendisliğinin geleceğini tartışırdık ve pek anlaşamazdık. Beraber çalıştığım çoğu kişi mesleğin bitmeyeceğini düşünüyordu. Onlara göre kodu artık AI araçları yazacaktı, ama mimari kararları ve sistem tasarımını yine yazılımcılar verecekti. Hatta mühendislik bu yüzden eskisinden de önemli hale gelecekti.

Bugün geldiğimiz noktada bence bu sorunun cevabı büyük ölçüde belli oldu. Bu yazıda anlattığım sistemde mimari kararları da bir ajan veriyor, ADR'ları da o yazıyor. Beş haftada tek başıma 1.100'den fazla PR çıkarırken beni en çok yavaşlatan şey kod yazmak olmadı. Ne yapılacağına karar vermek ve yapılanın gerçekten çalıştığını doğrulamak oldu.

Bunu sadece ben görmüyorum. Andrew Ng geçen yıl ekiplerinden birinin hayatında ilk kez mühendisten çok product manager istediğini anlattı: bir mühendise iki PM. Gartner'ın Temmuz'da yayımladığı tahmine göre küçük yazılım ekipleriyle çalışan şirketlerin oranı bugün %15, 2029'da %60 olacak. Shopify'da ekiplerin yeni kişi istemeden önce o işin neden AI ile yapılamadığını göstermesi gerekiyor. Stanford'un maaş verisiyle yaptığı çalışmaya göre 22-25 yaş arası yazılımcıların istihdamı 2022 sonundaki zirvesinin %20 altında. Kısacası bir product owner'a düşen developer sayısı sektördeki birçok şirkette şimdiden azalmaya başladı, Türkiye de buna dahil.

Önümüzdeki dönemde bir PO ve bir developer'dan oluşan takımlarla çalışan yazılım şirketleri göreceğimizi düşünüyorum. Bu yüzden iki rolün birbirine yaklaştığı bir döneme doğru gidiyoruz: developer'ların daha çok product mindset'iyle, PO'ların da daha çok development mindset'iyle çalışması gerekecek. Kod yazmak ucuzladıkça değerli olan şey, neyin yazılmaya değer olduğunu bilmek ve bir şeyin gerçekten çalıştığını kanıtlayabilmek oluyor. Bu sistemde en pahalı hatam da kodda değil burada çıktı: "çalışıyor" denen yedi kontrolün hiçbiri çalışmıyordu.

Cevabını bilmediğim bir soru ise şu: junior pozisyonlar azalırsa yarının senior'ları nereden gelecek? Ben bugün ajanların işini 15 yılda edindiğim tecrübeyle kontrol edebiliyorum. O tecrübeyi kazanacak yer daralırsa, ajanları denetleyecek insanı bulmak da zorlaşacak.

Ama buna gerçekten ihtiyaç olacak mı, o da ayrı bir soru. Bugün ajanların işini hâlâ kontrol etmem gerekiyor. Bir yıl sonra ise modellerin bu denetimi de kendi başına yapabilecek kadar iyileşeceğine inanıyorum. O zaman bir PO ve bir developer'lı takımların da yerini tek kişilik scrum ekiplerine bırakacağını düşünüyorum. Simülasyonu biraz daha ileri götürünce tek kişilik tribe'lara, oradan da tek kişilik şirketlere varıyorsunuz. Bugün kulağa hâlâ uzak gelebilir. Ama Ekim 2025 ile Ekim 2026 arasında gelinen yola bakınca, beklediğimiz kadar uzak olmayabilir.