- Bir organizasyonda onay ve inceleme aşamaları arttıkça işlerin üstel olarak yavaşladığını anlatıyor; pratikte her ek onay aşamasının yaklaşık 10 kat gecikme yarattığını örneklerle gösteriyor
- Yapay zeka kodlama araçları kod yazma hızını dramatik biçimde artırsa bile, sonrasındaki inceleme hattındaki bekleme süresi (latency) azalmadığı için toplam hız kazanımı sınırlı kalıyor
- W. E. Deming’in üretimdeki kalite felsefesini yazılıma uygulayarak, QA aşamaları eklemenin aslında hem kaliteyi hem de hızı kötüleştirdiğini savunuyor
- İncelemeleri azaltırken bunun yerini aynı anda modülerlik ve güvene dayalı bir kalite kültürüyle doldurmak gerektiğini; asıl önemli olanın incelemeyi gereksiz kılan yapısal iyileştirmeler olduğunu söylüyor
- Küçük ekiplerin yapay zeka çağında daha avantajlı olduğunu, küçük ve güzel bileşenleri birleştirme yaklaşımıyla organizasyon ve sistemlerin yeniden tasarlanması gerektiğini öne sürüyor
İnceleme aşamalarının 10 kat gecikme yarattığı kural
- Ağ etkisi yasalarında olduğu gibi ekip büyüdükçe koordinasyon ek yükü ortaya çıkar; ekibi iki katına çıkarmak hızı iki katına çıkarmaz
- On yıllar önce duyduğu bir pratik kural: Her ek inceleme aşaması süreci 10 kat yavaşlatır
- Teorik temeli yok, ama gerçek hayatta tekrar tekrar gözlenen bir durum
- Burada ölçülen şey emek (effort) değil, gerçek geçen süre (wall clock time); ek sürenin büyük kısmı da bekleme süresi
- Somut örnekler:
- Basit bir bug düzeltmesini kodlamak: 30 dakika
- Yan masadaki iş arkadaşının kod incelemesi: 300 dakika (yaklaşık 5 saat, yarım gün)
- Mimar ekibinden tasarım dokümanı onayı: 50 saat (yaklaşık 1 hafta)
- Başka bir ekibin takvimine girmek (ör. müşteri özellik talebi): 500 saat (12 hafta, 1 mali çeyrek)
- Sonraki aşama olan 10 çeyrek (yaklaşık 2,5 yıl) da gerçek dışı değil; Tailscale gibi nispeten küçük bir şirkette bile ürün yönü değişikliklerinde bu düzeyde gecikme yaşanabiliyor
Yapay zeka bunu çözemiyor
- Claude 30 dakikalık kodlamayı 3 dakikada yapsa bile, kazanılan 27 dakika ya doğrudan yapay zekayla yinelemeli inceleme için harcanıyor ya da doğrulanmamış kod gözden geçirmesi için başka birine gönderiliyor
- İnceleyen kişi için iş hâlâ 5 saat sürüyor; üstelik kendinizin bile okumadığı kodu ona gönderirseniz inceleyen kişi bundan hoşlanmıyor
- Ajanik kodlamanın asıl değerinin 1 haftalık büyük projeleri birkaç saatte bitirmek olduğu söyleniyor, ama ortaya çıkan çıktı bir kişinin tek seferde inceleyemeyeceği kadar büyük oluyor
- Küçük parçalara bölmek gerekiyor ve her biri için 5 saatlik inceleme döngüsü oluşuyor
- Tasarım dokümanı olmadan kasıtlı bir mimari de oluşmadığı için iş sonunda yine tasarım inceleme toplantısına dönüyor
- Sonuçta 2 saatte tamamlanan proje yeniden 1 haftaya çıkıyor
Tek yol incelemeleri azaltmak
- Tekillik (Singularity) teorisinin öncülü şu: sistemler giderek daha akıllı sistemler üretir ve bir iyileştirme birimi başına gereken süre sıfıra yaklaşırsa patlayıcı büyüme olur
- Buna inanmamasının nedeni, bir işi tamamlamak için geçen sürenin büyük kısmının gerçek çalışma süresi değil gerçek geçen süre, yani bekleme ve gecikme olması
- Gecikme brute force ile aşılamaz
İnceleme yapmadan olmaz mı?
- Hattın ilk aşaması olan yapay zeka üretimli kod hızlandı, ama sonrasındaki inceleme aşamalarının darboğaz olduğu gerçeğini artık birçok kişi görüyor
- Sezgisel çözüm: incelemeyi bırakalım → sonuç kaba saba olsa bile 100 kat ucuzsa yalnızca %1 değer üretmesi bile başa baş noktasına yetebilir mantığı
- Ama bu mantığın temelinde epeyce saçma bir varsayım yatıyor
- AI Developer's Descent Into Madness:
- Prototip şaşırtıcı derecede hızlı çıkar → insan kendini süper güçlü hisseder
- Prototipte bug çıkar → yapay zekadan düzeltmesini ister
- Her değişiklikte düzelttiği kadar yeni bug üretir
- Yapay zeka ajanı kendi kodunu incelerse kendi bug’larını bulur sanılır
- Kişi kendini ajanlar arasında veriyi doğrudan aktarırken bulur
- Bir ajan framework’üne ihtiyaç olduğu anlaşılır
- Ajan framework’ü yine ajanlarla yazılır
- Yeniden 1. adıma dönülür
- Claude Code ancak birkaç ay önce gerçekten kullanılabilir hale geldiği için bu döngü de ancak yakın zamanda başladı; pek çok meslektaş ve saygın kişi şu anda bu döngünün içinde
Neden inceleme yapıyoruz?
- Şirket büyüdükçe işbirliği, inceleme ve yönetim aşamaları artıyor; amaç hataları önlemek, çünkü ölçek büyüdükçe hata maliyeti yükseliyor
- Bir noktada yeni özelliğin ortalama katma değeri, onun yaratacağı yeni bug’ların ortalama kaybının altına düşüyor
- Özelliğin değerini artırmanın kolay bir yolu olmadığı için yön zararı azaltmaya kayıyor
- Denetim ve kontrol arttıkça hız yavaşlıyor ama kalite tekdüze artan (monotonically increasing) bir eğilim gösteriyor gibi görünüyor; bu da sürekli iyileştirmenin temeli gibi algılanıyor
- Ancak "daha fazla denetim ve kontrol", kaliteyi artırmanın tek yolu değil; üstelik tehlikeli bir yol
"Kalite Güvencesi (QA)" aslında kaliteyi düşürüyor
- W. E. Deming’in Japon otomotiv üretiminde yaygınlaştırdığı kalite felsefesine atıf yapıyor
- Fabrikada QA aşamasının sorunu: parça üretimi → inceleme/QA → hatalıların ayıklanması → eksik kalmasın diye ikinci QA aşaması eklenmesi
- Basit matematik modelinde bu mantıklı görünür (her QA aşaması kusurların %90’ını yakalıyorsa, 2 aşama ile 100 kat azalma)
- Ancak özerk insan aktörlerin (agentic humans) olduğu ortamda teşvikler bozulur:
- İkinci QA ekibi birinci QA ekibini fiilen değerlendirmiş olur → iş arkadaşının işten çıkarılmasına yol açabilecek sonuçları hevesle aramak için teşvik yoktur
- Birinci QA ekibi, ikinci ekibin nasılsa bulacağını düşünerek daha az çaba harcar
- Parçayı üreten ekip de nasıl olsa QA var diye kendi iç kontrolünü gevşetir → %20 yavaşlamak yerine %10 hurda oranı daha kabul edilebilir görünür
- Kaliteyi kökten artıracak kapsamlı mühendislik yeniden tasarımları çok pahalı görüldüğü için kaçınılır
- Toyota Production System, QA aşamalarını tamamen kaldırıp herkese "hattı durdur" düğmesi verdi
- ABD’li otomobil üreticileri aynı düğmeyi koydu ama kimse basmadı → işten çıkarılma korkusu
Güven
- Japon sisteminin başarılı, Amerikan sisteminin başarısız olmasının farkı güven
- Kişiler arası güven: yöneticinin gerçekten tüm kusurları bilmek istediğine ve biri bulunduğunda hattın durdurulması gerektiğine inanmak
- Yöneticiler arası güven: üst yönetimin kalite konusunda gerçekten ciddi olduğuna inanmak
- Yönetim içi güven: doğru sistem ve teşvikler verildiğinde insanların yüksek kaliteli iş çıkaracağına ve kendi kusurlarını bulacağına inanmak
- Ek koşul: sistemin gerçekten çalıştığına duyulan güven → bunun için önce çalışan bir sistem gerekir
Hata yapabilirlik
- Yapay zeka kodlayıcılar sık sık kötü kod yazar; bu açıdan insan programcılardan farklı değiller
- Deming yaklaşımında sihirli bir çözüm yok; mühendislerin sistem genelinde kaliteyi aşağıdan yukarı tasarlaması gerekiyor
- Her sorun çıktığında "Bu nasıl oldu?" diye sorup postmortem ve Five Whys ile kök nedeni bulmak ve düzeltmek gerekiyor
- "Kodlayıcı hata yaptı" kök neden değil, sadece bir semptom; asıl aranması gereken, o hatayı mümkün kılan yapısal nedenler
- Kod inceleyicisinin gerçek görevi kod incelemek değil, kendi inceleme yorumlarını zamanla gereksiz hale getirmek
- Aynı tür yorumların gelecekte hiç gerekmemesi için sistemi iyileştirmek
- Hedef, incelemeye ihtiyaç duyulmayan bir durum olmalı
- Örnek:
go fmtyi yapan kişiler → boşluklarla ilgili kod inceleme yorumlarını kalıcı olarak ortadan kaldırdı → gerçek mühendislik budur
- İnceleme bir hatayı fark ettiğinde hata zaten çoktan yapılmıştır; yani kök neden artık geride kalmıştır
Modülerlik
- İnceleme hattı (QA aşamaları) işe yaramaz; yalnızca hızı düşürür ve kök nedenleri gizler, böylece onları çözmeyi daha da zorlaştırır
- Yapay zeka ile kodlamanın cazibesi, hattın ilk aşamasının ezici biçimde hızlı olması; bu da insana süper güç hissi verir
- Belki de 20 yıllık kod inceleme kültürünün örttüğü sorunları çözmek ve bunun yerine gerçek bir kalite kültürü koymak için artık yeterli motivasyon var
- İyimserlerin yarısı haklı: inceleme aşamalarını küçültmek gerekiyor, ama yerine bir şey koymadan küçültmek Ford Pinto ya da yakın dönem Boeing uçakları benzeri sonuçlara götürür
- Deming’in üretime getirdiği gibi bütünlüklü bir paket değişimi (table flip) gerekiyor; "toplam kalite" sistemi yarım yamalak benimsenemez
- İncelemeler kaldırılırken aynı anda gereksiz hale de getirilmelidir
- Yeni sistemi küçük ölçekte tamamen uygulamak mümkün:
- Eski tarz Amerikan otomobil üreticilerinin Japon tedarikçilerden yüksek kaliteli parçalar satın almasına benzetiliyor
- Parça iyi üretilmişse başka yerlerdeki QA aşamaları kaldırılabilir → "parça montajı" işinin karmaşıklığı ciddi biçimde azalır
- Küçük ve güzel şeyler birleştirilerek büyük ve güzel bir şey yapılabilir
- Birbirine güvenen küçük ekipler, kendileri için kalitenin ne anlama geldiğini bilerek tek tek bileşenler üretir
- Müşteri ekipleri de kendileri için kalitenin ne anlama geldiğini net biçimde ifade eder → kalite aşağıdan yukarı yayılır
Küçük ekipler ve yapay zeka çağında organizasyon tasarımı
- Küçük startup’lar yeni dünyada daha avantajlı olabilir; çünkü insan sayısı az olduğu için inceleme aşamaları da baştan beri daha azdır
- Bazı startup’lar yüksek kaliteli bileşenleri hızlı üretmenin yolunu bulacak, diğerleri başarısız olacak → doğal seçilim yoluyla kalite
- Büyük şirketlerde yavaş inceleme sistemi kemikleştiği için bunu kaldırmak tam bir kaos yaratabilir
- Şirket büyüklüğünden bağımsız olarak, mühendislik ekipleri küçülebilir ve ekipler arası arayüzler daha net tanımlanabilir
- Tek bir şirket içinde birden fazla ekibin aynı bileşeni rekabetçi biçimde geliştirmesi modeli mümkün olabilir
- Her ekip az sayıda insan ve kodlama botlarından oluşur
- 100 farklı yol denenir, en iyisi seçilir → evrim yoluyla kalite
- Kod ucuzdur ama iyi fikirler hâlâ pahalıdır → yeni fikirler eskisine göre çok daha hızlı denenebilir
- Monolit-mikroservis sürekliliğinde yeni bir optimum nokta ortaya çıkabilir
- Mikroservisler fazla küçük oldukları için kötü bir ün kazandı, ama kavramın asıl anlamında "mikro" servis, "iki pizzalık ekip" tarafından kurulup işletilebilecek boyuttadır
- Yapay zeka çağında bu ölçek "bir pizza ve biraz token" seviyesine inebilir
- Yeni hızlı kodlama ile modül sınırlarının kendisi de daha hızlı denenebilir
- Özellik geliştirmek hâlâ zor, ama refactoring ve otomatik entegrasyon testleri yapay zekanın iyi olduğu alanlar
- Eskiden ayırmaya korkulan modüller artık ayrılabilir; satır sayısı artsa da, bunu büyük ekiplerin iki tarafı da sürdürmesi için gereken koordinasyon ek yüküyle kıyaslayınca maliyet düşüktür
- Her ekipte fazla büyük bir monolit ve fazla sayıda inceleme aşaması vardır
- Tekilliğe ulaşamasak bile, çok daha iyi bir dünyayı mühendislikle kurabiliriz → bu problem çözülebilir
- Anahtar kelime güven
2 yorum
go fmt’i ilk gördüğümde ben: Hayır ya, neden formatlamayı kendi zevkime göre yapamıyorum..!Şimdi: Formatlamada zevke neden ihtiyaç var ki?
Hacker News yorumları
İnceleme hiç yapılmayabilir
İncelemeyi sola kaydırıp kod tasarım oturumuna dönüştürür, sorunları daily’de gündeme getirir ve zor kısımları pair programming ile çözersek, incelemenin çoğu amacı ortadan kalkar
Geriye kalan değişken adları, boşluklar, pattern’ler gibi %10’luk kısım ise linter ile otomatikleştirilebilir
Sonuçta önemli olan, ekibin üzerinde uzlaştığı koda güvenip yazabildiği güvene dayalı bir ekip kültürü oluşturmaktır
Sorunlar ancak gerçek implementasyon sırasında fark edilir
Her şeyin kusursuz biçimde plana göre gittiği durum neredeyse hiç olmadı. Sonuçta iteratif mimari toplantıları gerekir ama bu da yine haftalık toplantı bataklığına dönüşür
Kendi yazdıkları kodu bile incelememeye başladıklarında, biriktirilmiş güven anında çöker
Toyota Production System’de olduğu gibi QA aşamasını kaldırmak için, herkesin bir kusur gördüğünde anında durdurabileceği bir güven gerekir
İnceleme pipeline’ı sadece sorunları gizler ve hızı düşürür
Bu tek cümle başlı başına cehennemin tanımı gibi
Bu epey iyi işliyor. İnsanlar kendi testlerini yazıyor ve manuel doğrulamayı da birlikte yapıyor
Ayrıca hatalı deploy’u 10 dakika içinde geri alabilecek bir emniyet ağı da kurduk
Kod incelemesi bir gönüllü ikilemi
Çünkü performans değerlendirmesinde “çok PR inceledi” değil, “çok özellik yayınladı” öne çıkıyor
Sonuçta insanlar ancak inceleme kendi işlerini doğrudan etkilediğinde aktif davranıyor
Ancak kod esnek olduğu için, hızlı merge ve sonradan düzeltme bazen daha hızlı yakınsama sağlayabilir
Özellikle bug’ları önceden yakalayıp on-call stresini azaltma motivasyonu büyük
Anlamasalar bile soru bırakmaları öğrenme açısından çok yardımcı oluyor
Lider olmak istiyorlarsa kod ve tasarım dokümanı incelemelerini bolca yapmaları gerekir
Bu yazı benim sezgilerimi ve deneyimimi net biçimde toparlayan bir yazıydı
Tailscale ürününü zaten seviyordum ama artık CEO’nun da hayranı olacağım gibi
Yazarı Avery’ye teşekkür ediyorum; bu yazıyı geniş biçimde paylaşacağım
Valve, iletişim bant genişliği sınırlarını anlayan az sayıdaki şirketten biri
Organizasyon büyüdükçe iletişim yükü üstel olarak artıyor
Diğer şirketlerin de artık anlamış olması gerekirdi ama hâlâ öyle değil
İncelemenin 5 saat içinde tamamlanması şaşırtıcı
Çoğu yerde süreç günler sürüyor
Ama tüm geliştiricilerin bug gördüğünde anında durdurabildiği bir kültür varsa, incelemeye gerek kalmayabilir
Gerçekte ise release hedefi kaçarsa bunun bedelini bireyler ödüyor
Şimdiki şirketimde incelemeler birkaç dakikada bitiyor ama teknik borç patlıyor
Belirli bir süre geçince otomatik olarak “inceleme bekleniyor” mesajı gelirdi
Her şey ölçülürdü ve performans baskısı çok yüksekti
Ekip boyutu makulse bu alışkanlık öğrenilebilir ve yayılabilir
Ne iş tarafı ne de geliştiriciler pek umursamıyor
İncelemenin değere karşı emek oranı çoğu zaman göz ardı ediliyor
İnceleme gerçekten kaliteyi artırmıyorsa, o zaman bu süre boşa gidiyor demektir
İnce ayrıntılar üzerindeki tartışmalar yerine sadece “çalışıyor mu” diye bakıp hızlıca merge etmek daha verimli olabilir
Sonraki commit’lerle iyileştirme yapılabilir
İnceleme, kısa tutulmuş ve sadece yönü doğrulayan bir kontrol noktası olmalıdır
“Reviewer’ın işi incelemeyi ortadan kaldırmaktır” sözüne tamamen katılıyorum
Yazı serileştirilmiş bir süreç varsayıyor ama gerçekte işler paralel ilerliyor
Birden çok bug aynı anda ele alınıyorsa, inceleme gecikmesi büyük sorun değil
Esas mesele eşzamanlı iş sayısını (N) ayarlamak
bağlantı
PR inceleme hızı düştükçe context switching maliyeti büyüyor
Hesap sonucunda, inceleme hızını artırmanın üretkenliği ciddi biçimde yükselttiği görülüyor
“Reviewer’ın hedefi incelemeyi gereksiz kılmak” fikrine katılıyorum ama
güvenin kapsamı şirket dışına uzandığında durum değişiyor
Örneğin
npm updateile kötü amaçlı kod deploy edilirse, sonradan müdahale etmek çok geç olurGüvene dayalı bir yapıda bile, bazen insan doğrulamasının gerekli olduğu noktalar vardır
Yöneticiler üretkenliği vurgularken aynı anda hızı düşüren süreçleri de sürdürüyor
Bu karmaşık bir mesele; basitçe iyi ya da kötü demek zor
Operatörler hem üretkenlikten hem de güvenlikten aynı anda sorumludur
Kaza öncesinde üretkenlik, kaza sonrasında ise güvenlik öne çıkar
Dışarıdan bakanlar bu ikili rolün dengesini pek anlamaz
ilgili bağlantı