- Yapay zeka kodlama araçları geliştirme hızını artırıyor gibi görünse de, asıl darboğaz kod yazımı değil organizasyonun verimsiz süreçleri
- Kod üretimini artırmak, inceleme kuyruğu, dağıtım gecikmeleri, belirsiz gereksinimler gibi geliştirme dışı aşamalardaki tıkanıklığı derinleştiriyor ve gerçek çevrim süresini tersine uzatıyor
- Eli Goldratt'ın Kısıtlar Teorisi'ne (Theory of Constraints) göre, darboğaz olmayan bir aşamayı optimize etmek sistemi hızlandırmaz; aksine daha da bozar
- Yapay zeka tarafından üretilen kodu onu oluşturan kişi bile tamamen anlamaz hale geldiğinde, arıza müdahale yüzeyi genişlerken sistemi akıl yürüterek anlayabilen kişi sayısı azalıyor ve yapısal bir risk ortaya çıkıyor
- Rekabet avantajı, kodu en hızlı yazan ekibe değil, neyin yapılması gerektiğini anlayıp bunu kullanıcıya ulaştıran ekibe gidiyor
Yanlış optimizasyonun başlangıcı
- Yapay zeka kodlama asistanlarının devreye alınmasıyla kod çıktısının %40 arttığını duyuran açıklamalar ortaya çıktı
- Ancak “hangi hedefe doğru hız?” sorusu ortada yok
- Zaten hızlı olan bir aşamaya (kod yazımı) kaynak ayırmak, tüm sistemi daha yavaş hale getirir
- Darboğaz olmayan kısmı hızlandırırsanız tamamlanmamış kod envanteri birikir, kalite düşer ve karmaşa oluşur
Darboğaz olmayan yeri optimize etmek sistemi daha da bozar
- Eli Goldratt'ın 1984 tarihli romanı The Goal'da ortaya koyduğu Kısıtlar Teorisi'nin (Theory of Constraints) özü şudur: Her sistemde tam olarak bir darboğaz vardır ve toplam çıktı o darboğazın kapasitesi tarafından belirlenir
- Darboğaz olmayan bir aşamayı optimize etmek sistemi hızlandırmaz; sadece tamamlanmamış iş envanteri biriktirir, bu da teslim süresinin uzamasına, karmaşaya ve kalite kaybına yol açar
- Basit bir benzetmeyle, A istasyonu widget'ları daha hızlı üretse bile darboğaz olan B istasyonunun hızı değişmiyorsa, A ile B arasında yalnızca işlenmemiş widget yığınları birikir
“3 kat kod çıktısı” gerçekte neye yol açar
- Geliştiriciler her zamankinden daha hızlı PR üretiyor, ama inceleyici sayısı aynı kaldığı için PR'lar inceleme kuyruğunda bir gün, iki gün, bir hafta bekliyor
- Yazarı ise çoktan yapay zeka destekli bir sonraki özelliğe geçmiş durumda; bu yüzden 8 gün önce yazdığı kodla ilgili inceleme yorumlarına yanıt verirken o kodu neredeyse hiç hatırlamıyor
- İnceleme sayısı o kadar artıyor ki düzgün okunmadan verilen göstermelik onaylar ortaya çıkıyor
- CI 45 dakika sürüyor, flaky testler yüzünden hata alıp yeniden çalıştırılıyor, dağıtım hattı ise toplantıda olan sorumlunun manuel onayını bekliyor, özellik staging ortamında 3 gün boyunca bekliyor
- Geliştirici bu sırada 2 PR daha açmış oluyor, WIP (Work In Progress) hızla artıyor ve herkes aynı anda 6 iş yürütürken hiçbir şey tamamlanmıyor
- Daha çok kod üretilirken daha az yazılım yayımlanıyor; çevrim süresi kötüleşmiş durumda ama gösterge paneli üretkenliğin %40 arttığını söylüyor
- Yapay zeka üretimi kodun ek riski şu: Kodu “yazan” kişi aslında onu yazmadı; bir prompt ile üretip kabaca gözden geçirdi. Bu yüzden gece 2'de üretimde bir arıza çıktığında ne nöbetçi mühendis ne de prompt'u yazan kişi bu kodu açıklayabiliyor
- Kod artıp anlayış azaldığında bu üretkenlik artışı değil, üzerine daha şık bir gösterge paneli eklenmiş saatli bomba olur
Gerçek darboğaz 1: Ne yapılması gerektiğinin bilinmemesi
- PM iki aydır gerçek kullanıcılarla konuşmamışken, gereksinimler 3 satırlık bir Jira bileti ve bir Figma bağlantısı olarak geliyor
- Mühendisler günde 50 farklı mikro kararı (davranış, edge case, hata işleme) hiçbir net tanım olmadan tahmin ederek veriyor
- Bir ekip, satış temsilcisinin Slack'te aktardığı ve potansiyel müşterinin bir görüşmede muhtemelen söylediği şeylere dayanarak 6 hafta boyunca bir özellik geliştirdi; ama o potansiyel müşteri satın almadı ve özelliği yalnızca 11 kişi kullandı (bunların 9'u şirket içi QA idi)
- Kod yazmayı hızlandırmak yalnızca yanlış şeyi daha hızlı üretme hızını artırır; bu, tahmini otomatikleştirmekten başka bir şey değildir
- Darboğaz, doğrudan problemi anlama meselesidir; daha hızlı yazmak bunu çözmez
Gerçek darboğaz 2: Kod “tamamlandıktan” sonraki her şey
- Çoğu organizasyonda kod yazımı tüm yolculuğun yalnızca %20'sidir; kalan %80, kodun farklı kuyruklarda beklediği zamandır
- Öğleden sonranın birinde yazımı biten bir özelliğin üretime ulaşmasının 2 ay sürdüğü örnekler vardır
- PR incelemesi, CI, staging, QA, güvenlik incelemesi, ürün onayı, dağıtım penceresi, canary rollout gibi uzun devirler, beklemeler ve kuyruk zinciri söz konusudur
- Zamanın büyük bölümünde kod ilerlemez; birinin bakmasını, pipeline'ın çalışmasını, var olmasına izin verilmesini bekler
- Daha hızlı yayımlamak istiyorsanız, işin nerede beklediğini bulmanız ve gerçek çalışma süresine kıyasla kuyrukta bekleme süresinin oranını ölçmeniz gerekir
Gerçek darboğaz 3: Dağıtım güvenine dair kısır döngü
- Testler flaky, gözlemlenebilirlik berbat ve kimse canary sürecine güvenmiyorsa, ekipler dağıtımdan korkar
- Bu korku değişikliklerin daha büyük sürümlerde paketlenmesine yol açar; bu da riski artırır, dağıtımı daha korkutucu hale getirir ve yeniden daha büyük paketlemelere neden olan bir korku kısır döngüsü yaratır
- Bunun üstüne daha hızlı kod üretimini eklerseniz: kod artar ama dağıtım kültürü aynı derecede korkutucu kaldığı için batch'ler büyür, sürüm sıklığı düşer
Gerçek darboğaz 4: Yayın sonrası geri bildirim eksikliği
- Bir özellik geliştiriliyor ve yayımlanıyor; ardından ne düzgün bir analiz yapılıyor ne de yayın sonrası kullanıcı görüşmeleri düzenleniyor, yani özelliğin sorunu gerçekten çözüp çözmediğini kontrol eden kimse olmuyor
- Sonraki özellik de tahmin, ondan sonraki de tahmin; tüm ürün yol haritası geri bildirimsiz tahminler dizisine dönüşüyor
- Daha hızlı kod üretimi, sadece “yap, yayımla ve omuz silk” döngüsünü hızlandırıyor
Gerçek darboğaz 5: Takvim taşıyıcı duvar haline geldiğinde
- Bazen darboğaz teknik değil; karar almak için gereken toplantılar, bir aydır konuşmamış 3 ekip arasındaki API sözleşmesi uzlaşması ya da tüm önemli tasarımlar için tek onay noktası olan mimarın 2 haftalık birikmiş işi asıl engel oluyor
- 6 hafta süren çeyreklik planlama süreci yüzünden acil işlerin bile başlayabilmesi için 5 hafta beklemesi gerekebiliyor
- Bir özelliğin yayımlanamama nedeni gerçekten de “tatilde olan biriyle yapılacak toplantıyı bekliyoruz” olabiliyor
- Bunlar koordinasyon sorunları, insan sorunları, politik sorunlardır; kod yazma hızıyla ilgileri yoktur
Bunun yerine ne yapılmalı
- Değer akışı haritalama: Bir özelliği fikir aşamasından üretime kadar takip edin ve her aşamanın ne kadar sürdüğünü, aşamalar arasındaki bekleme süresini kaydedin
- Çevrim süresini ölçün: Kod satırı, merge edilen PR sayısı ya da story point değil; commit'ten üretime ve kullanıcının gerçekten kullanmasına kadar geçen süreyi ölçün
- Bekleme durumlarını ortadan kaldırın: PR incelemesi 2 gün sürüyorsa bunu pair programming, küçük PR'lar, ayrılmış inceleme zamanı, asenkron inceleme normları ile çözün. Dağıtım manuel onay bekliyorsa otomatikleştirin ya da en azından Slack düğmesine çevirin
- Başlatmayı bırakın, bitirmeye odaklanın: WIP limitlerinin bir nedeni vardır; ilerlemekte olan 10 iştense tamamlanmış 3 iş daha iyidir. Devam eden her iş bir bağlam değiştirme maliyetidir
- İşi yapanlarla konuşun: Geliştiriciler darboğazın nerede olduğunu zaten biliyor; bunu stand-up'larda söylüyor ve aylardır Slack'te bununla ilgili meme üretiyorlar. Sadece kimsenin onları dinlemediğini düşünüyorlar
Temel sonuç
- Bir VP'nin “kod çıktısı %40 arttı” demesi yerine, “değer akışı analizimiz, özelliklerin aşamalar arasında ortalama 9 gün beklediğini gösteriyor ve bunu yarıya indireceğiz” demesi gerekirdi
- Rekabet avantajı, kodu en hızlı yazan ekibe değil, ne yapılacağını anlayıp bunu yaparak kullanıcıya ulaştıran ekibe gider
- Darboğaz klavye değil
4 yorum
> O potansiyel müşteri satın alım yapmadı ve o özelliği yalnızca 11 kişi kullandı (bunların 9'u dahili QA idi)
lol
Pipeline aynı, sadece geliştiriciler sorumsuzlaşmış gibi görünüyor.
Yazılım ustası olasım geldi
Hacker News görüşleri
Ekibimiz ajan tabanlı geliştirmeyi ciddi biçimde benimsemeye başladığında, kodlama hızlanırken inceleme süresinin uzayıp uzamayacağını merak etmiştim
Şimdilik belirgin bir değişiklik yok ve herkes yeni iş akışına alıştığı için yeterli veri de oluşmadı
Ama hızlı kod yazmanın özellikle faydalı olduğu durumlar var — fikir denemeleri, karmaşık tekrar eden işler, basit ama emek yoğun uygulamalar, happy path sonrası edge case’leri ele alma gibi
Özellikle mevcut branch ya da PR’leri doğrudan genişletirken ajanlar çok iyi çalışıyor
En büyük verimlilik artışı, ajan kod yazarken benim başka işler yapabiliyor olmam. Örneğin PR inceleyip geri döndüğümde sonuç hazır oluyor
Başta şüpheciydim ama şimdi temkinli biçimde umutluyum. 10 kat artış zor olabilir ama 2 kat artış bile müthiş olur
Bu yaklaşım ancak hata maliyetinin düşük ya da değişiklik kapsamının küçük olduğu durumlarda işe yarar. Aksi halde kalite ve memnuniyet düşüyor, sadece takvim sıkışıyor
Sonuçta paralel çalışmayla zaman geri kazanmak yerine, ertelenen işleri biraz daha az ertelemiş oluyorsun
Ancak ajan kod yazarken başka bir işle uğraşmak garip bir yorgunluk veriyor
Yapay zeka üretken ama insan zanaatkâr olarak kod yazmaktan tamamen farklı bir emek türü bu
Kendin yapmış olsan vazgeçmesi zor gelecek bir refactoring için, yapay zeka yaptığında “bu pek iyi olmadı” diye daha dürüst karar verebiliyorsun
Sürekli multitasking yapmak tükenmişliki hızla getirir. Tartışmada insani boyutun eksik kalması üzücü
Ben her zaman ‘optimize edilmiş durumda’ çalışmak istemiyorum
Birisi “darboğaz problemi anlamakta” demişti; ben de neden hızlı yazmanın problemi anlamaya yardımcı olamayacağını sormak isterim
Yanlış şeyi hızlıca inşa etmek, doğru yönü daha hızlı bulmayı sağlamaz mı?
Ben çoğu zaman bir şeyler yaparken aslında ne istediğimi fark ediyorum. Prototip üretmek ucuzladıkça bu eğilim daha da güçleniyor
Elbette sonunda yine “kullanıcılarla daha çok konuşmalıydık” sonucuna varılıyor, ama bu başka bir mesele
Banka gibi yerlerde en iyi ihtimalle haftada bir deney yapabilirsin
Ama yazılımın büyük kısmı böyle değil. Kod yazmak, toplam işin sadece bir parçası
Nasıl cerrah sadece ‘kesme işi’ yapmıyorsa, mühendis de sadece kod yazmıyor
Tek başına sadece kodu cilalıyorsan, bu yalnızca daha büyük bir karmaşa yaratır
Bazen PM ya da müşteriyle bir saat konuşmak çok daha iyidir
Bugünkü LLM çılgınlığında, sanki çözüm problemden önce gelmiş gibi bir hava var
Gerçekten hız kazanmak istiyorsan önce “darboğaz ne?” diye sormak gerekir
Yöneticilerin bir AI sunumu izleyip “bunu kullanırsak hızlanırız” diye inanması, yalnızca vibe managementtan ibaret
Kodlama bunun içindeki en emek yoğun ve otomasyona en uygun bölüm
LLM’ler bu yükü ciddi ölçüde azaltabilir. Özellikle test kodu yazmak gibi işlerde AI başarılı
İnsan geliştiriciler hâlâ koda takıntıyı bırakamıyor
Aslında kod, çözümün yalnızca bir ara temsili (IR)
GCC assembly’ye dönüştürürken iç optimizasyonları dert etmediğimiz gibi, ajan kod ürettiğinde de yalnızca sonucun doğruluğuna bakmamız yeterli
Net bir spesifikasyon ve tekrarlı inceleme süreci varsa, insan da ajan da aynı uygulamayı çıkarabilir
LLM’ler öyle değil. Yanlış anlayabilir ya da halüsinasyon üretebilir
Bu yüzden hâlâ bir insanın incelemesi gerekiyor
Ajanlar çoğu zaman yanlış kalıpları seçiyor ya da teknik borç biriktiriyor
Bir gün programlama dilinin kendisini ortadan kaldırabiliriz belki, ama henüz o noktada değiliz
Anlam genişler, sıkışır, hatta bazen tamamen kaybolur
Birçok şirket gerçekten iyi kod istemiyor
İç değerlendirme “ne kadar çok deploy edildi” üzerinden yapılıyor ve sorunları işaret edersen “fazla ayrıntıcı” deniyor
Sonuçta iç paydaşların istediği şey sadece ‘başarılı oldu’ diyebilecekleri bir gerekçe
Teknik insanların görevi bu riski anlatmaktır
AI kullanımı sonrası kalite düşüşü gerçekten görünmeye başladı
Bizim şirkette PR onayları da özensiz, CI 45 dakika sürüyor, deploy ise günlerce gecikiyor
Üstelik AI kullanımı da yasak. Kodun çoğunun insan tarafından yazıldığı söyleniyor ama bundan şüpheliyim
Bu yazının gözden kaçırdığı iki şey var — (A) ajan kullanımı ile süreç optimizasyonu bir arada olabilir, (B) bazı ticket’larda gerçekten darboğaz kodun kendisidir
Sonuçta önemli olan AI olup olmaması değil, darboğazı ortadan kaldıran süreç iyileştirmesi
Ben tek kişilik geliştiriciyim. Kodlama hızı gerçekten bir sorun çünkü başka işlere ayırabileceğim zamanı alıyor
Bugün Claude Code’u kurdum; artık Google’da arama yapmaya ya da test yazmaya daha az zaman harcıyorum
Verimliliğim 10 kat artmayacak belki ama emek tasarrufu sağlayan bir teknoloji olarak fazlasıyla değerli. Tıpkı bulaşık makinesi gibi
Şimdi yapay zeka testleri de yazıyor ve edge case’ler için uyarıyor
Mükemmel değil ama yeni özellik çıkarma hızı arttı ve bana daha çok zaman kaldı
“AI’ye güvenilmez” sözü bana biraz “derleyiciye güvenilmez” demek gibi geliyor
Sonuçta yönü veren insan; prompt’ları iyileştirerek birlikte gelişen de yine insan
Startup ya da VC ortamlarında kodlamadan çok iş problemini çözmek asıl mesele
Kod üretiminin artması, sistemin genel sonucunun da iyileşeceğini garanti etmez
Şablonlar ya da kod üreticilerinde olduğu gibi hız artsa da, gereksinim toplama 10 kat hızlanmadıkça 10 kat verimlilik mümkün değil
O yüzden benzetme biraz yerinde değil
Yapay zekanın insanların genelde yapmadığı türde hataları yapmasını nasıl önleyebiliriz?
İnsanlar kodu adım adım ve mantıksal biçimde gözden geçirir, ama AI böyle çalışmaz
Amazon’daki gibi kıdemli mühendisler inceleme yapsa bile, inceleme zaten tüm hataları yakalama süreci değildir
Üstelik kıdem arttıkça toplantılar da artar ve kod bağlamına hâkimiyet azalır. Böyle bir inceleme ne kadar etkili olabilir?
İnsanların kusursuz olduğunu sanmak bir yanılgı
AI’den insanlardan daha yüksek bir standart bekliyoruz
Sonuçta önemli olan QA sürecini güçlendirmek. Testi geliştiricilere bırakmamak gerekir
Eskiden okuduğum The Goal kitabını hatırlattı. Sürecin bir aşamasını otomatikleştirince bir sonraki aşamanın darboğaz hâline gelmesi durumu
Yazılımda da aynı; kod üretimi hızlansa bile tüm süreç yetişemiyorsa bunun pek anlamı yok
Sonuçta her şey kâr üretme hedefinin altında yer alıyor. Kod kalitesi de bu hedefin alt kavramlarından biri sadece
Kod yazma hızı, riskin yüksek olduğu durumlarda darboğaz değildir
Bazen yavaş plan yapmak ve sonuçları dikkatle düşünmek daha iyidir
Örneğin AI endüstrisinde olduğu gibi dev sistemleri fazla hızlı kurarsan, yanlış yönde medeniyet ölçeğinde riskler doğurabilirsin
Ama hafta sonunda tek başına yaptığın küçük bir oyunsa sorun değil. Sonuçta hızı belirleyen şey riskin büyüklüğüdür