Yazılım Fabrikaları Neden Başarısız Olur: Işıkları yeniden açmak

Bu, Yazılım Fabrikaları Neden Başarısız Oluyor başlıklı yazının ikinci bölümüdür.

Bu yazının konuşma versiyonu YouTube'da yayında: https://www.youtube.com/watch?v=Ib5GBkD555M

Işıkları Geri Açmak

Bölüm 1'de, modellere kod tabanı kalitesini zaman içinde koruma konusunda neden güvenilemeyeceğini derinlemesine inceledim. Neden hiçbir mühendislik çabası veya token maksimizasyonunun bir model eğitimi ve kıyaslama sorununu çözmeyeceğini. Kod kalitesi için "modelin yargıç olması" fikrinin, bazılarının size anlatmak istediği kadar iyi çalışmadığını.

Şimdilik, yargıç sizsiniz -- bu yüzden kod incelemesini geri getireceğiz.

Yapay zekadan önce de yaptığımız şeyi benimseyeceğiz: uzun ve zorlu bir inceleme olasılığını azaltmak için baştan biraz planlama yapmak.

Kaldıraç bulacağız ve bunu 4 aşamada yapay zekayı kullanarak yapacağız:

• Ürün Gereksinimleri
• Sistem Mimarisi
• Program Tasarımı
• Dikey Dilimler

Ürün İncelemesi

Her şey bir ürün incelemesiyle başlar: ne inşa ettiğimizi ve neden inşa ettiğimizi belirleyen kısa bir belge. Amaç, iki cümlelik bir notu veya uzun bir sesli notu alıp yarı yapılandırılmış bir şeye dönüştürebilmektir.

İlk olarak, çözülmesi gereken sorun üzerinde anlaşırız -- kullanıcının kendi ifadeleriyle ifade ettiği gerçek kullanıcı acısı. İkinci olarak, başarının neye benzediği -- özellik yayınlandıktan sonra, o şeyi inşa etmeye değip değmediğine karar vermek için ne okuyabiliriz? İdeal olarak bu, "XYZ iş akışını daha kısa sürede yapabilmek" veya "ABC'ye daha erken ulaşmak" gibi bir kullanıcı sonucudur. Bazen daha alt düzeyde, bir hata oranı veya gecikme süresi gibi, bazen de sadece "X hakkındaki destek biletleri kesilir."

Bunu ürün alanında oldukça temel tutmaya çalışıyoruz, teknik alanda değil. Bir ayağı ürün dünyasında, bir ayağı teknolojide olan biri olarak, burada sık sık teknik detaylara kaydığımı fark ediyorum. Bu olduğunda, sadece not alıp daha sonraki aşamalar için bir kenara koymaya ve kullanıcının gerçekte ne deneyimlediğine geri dönmeye çalışıyorum. Teknik kararlar ürün kararlarını bloke ediyorsa, elimizde olanı taahhüt eder ve mimariye geçer veya nelerin mümkün olduğu konusunda daha fazla prototip araştırması yaparız.

Ve bunun çoğu kullanıcının gördüğü şeyle ilgili olduğu için, onu anlatmıyorum -- bir maketini yapıyorum. Gerçek ekranın kaba bir HTML maketi, üç paragrafın ancak uzatacağı bir tartışmayı çözer.

İşte devam eden gerçek bir örnek -- belge, özelliği bir JSON taslağıyla belirliyor, ardından gerçek ekranların iki kaba HTML maketi geliyor:

https://x.com/dexhorthy/status/2078592010852982977

Elbette, her şey bir ürün incelemesi almaz. Bir metin düzeltmesi, tek seferlik bir komut dosyası, bariz bir tekrarlama yolu olan bir hata -- bunları hala doğrudan ajana tek atışta gönderiyoruz. Bu inceleme, bir ajanın niyetimizi yanlış anlamasının maliyetli olduğu değişiklikler içindir.

Bu ve serideki tüm belgeler için, yazarın isteğe bağlı olarak katıldığı incelemeler yapıyoruz. İnceleme sırasında zamandan tasarruf etmek istiyorsanız, PR'ı inceleyecek kişiyi seçer ve ürün/teknik şartnameleri, belge yorumları üzerinden eşzamansız olarak onunla birlikte gözden geçirirsiniz (bunun için humanlayer'ı kullanıyoruz, ancak bunu github/notion/plannotator/vb. içinde de kolayca yapabilirsiniz).

Sistem Mimarisi

Ürün incelemesi tamamlandıktan sonra, sistem mimarisini yaparız. Bu özellikle yeni bir şey değil ve vibe kodu yazanların bile yemin etmeye başladığı bir şey.

İnceleme sırasında zamandan tasarruf etmek istiyorsanız, PR'ı inceleyecek kişiyi seçer ve kodlama kısmına geçmeden önce ürün/teknik şartnameleri onunla birlikte gözden geçirirsiniz.

Bu aşamada, servislerin, uç noktaların, şemaların, kuyrukların ve depoların birbirleriyle nasıl iletişim kurduğu üzerinde anlaşırız, program tasarımının detaylarına girmeden. İnsan<>ajan iletişim bant genişliğini en üst düzeye çıkarmak için burada görselleştirmelerden yoğun bir şekilde yararlanıyoruz - örneğin sıra diyagramları:

Sözleşme / uç nokta şekilleri:

Veri modelleri ve dönüşümler:

Mermaid burada iyidir ancak bazen aşırıya kaçabilir ve bazen de sizi uyumlu olduğunuza dair yanlış bir güvene sürükleyebilir. Mimari oldukça yüksek kaldıraçlıdır ve bu aşamada önleyebileceğiniz potansiyel olarak kötü model tikleri vardır. Ancak yüksek kaliteli kod üretmek için yetersizdir. Bunun için program tasarımına ihtiyacımız var.

Program Tasarımı

Mimariden sonra, aracılı kodlamada suç derecesinde az vurgulandığını düşündüğüm bir şey yapıyoruz: program tasarımı.

Çoğu insan, mimari doğru olduğunda modelin sadece pişirebileceğini varsayar. Devam edip bunu yapabilirsiniz, ancak geri aldığınız şeyi beğenmeyebilirsiniz.

Ancak iyi çalıştığını gördüğüm şey, herhangi birinin (insan veya ajan) uygulamayı yazmasından önce, mimariden bir seviye aşağı inip kodun şekline bakmamızdır: türler, metot imzaları, program düzeni ve çağrı yığınları.

Program tasarımı becerimizin ilk versiyonu berbattı. Okuması zordu, yorucuydu. Mermaid'i denedik, yerini buldu, ama asıl sevdiğimiz şey, sözde kodda hafif görselleştirmeler:

Çağrı yığını ağaçları, herhangi bir orkestrasyon veya kontrol akışı değişikliği için. Değişen kısım ilginç olduğunda fark sözdizimini kullanın:

Dillon Mulroy, planlama sürecinin bir parçası olarak çağrı grafiklerini kullanmaktan bahsediyor ve bence bu kesinlikle doğru.

Dosya ağacı farkları - kod tabanınızın düzeni ve bir şeylerin nerede olduğuyla bağlantıda kalmanız için

Anahtar yeni fonksiyonlar için türler ve metot imzaları -- bir mimari belgesi için çok dahili olan ancak bir ajanın yine de yanlış anlayabileceği şeyler

Bunların hiçbirini üretmesi uzun sürmez (model taslakları çıkarır, siz onunla tartışırsınız) ve her biri, aksi takdirde kod incelemesi sırasında -- fikrinizi değiştirmenin en pahalı olduğu zamanda -- üstü kapalı olarak alacağınız bir karardır.

Dikey Dilimler

Daha sonra, "dikey dilimler" dediğim şeyi yapmayı seviyoruz - Matt Pocock ve ben

Ocak 2026'da bir canlı yayında dikey dilimler veya "işaret fişeği mermileri" hakkında sohbet ettik - buna ayrıca işaret fişeği mermileri de denir.

Modeller, "yatay planlar" dediğim şeyi sever - işleri yığın sırasına göre yapmak:

1. Veritabanı Geçişleri
2. Servis Katmanı
3. API
4. Ön Uç

Pratikte bunun anlamı, ilerlerken çözüme "dokunmanın" gerçek bir yolu olmadığıdır. Kodla şeyleri test edebilirsiniz, ancak şimdiye kadar inşa ettiğim hemen hemen her özellik için, testleri okumak bir başlangıçtı, ancak çalışırken bir tarayıcıda bir şeyler açmak veya curl ile vurmak her zaman iş akışının sık bir parçasıydı.

Yapay zekadan önce, herhangi birinin yol boyunca bir şeyi kontrol etmeden 2000+ satır kod veya hatta 500 satır kod yazması nadirdi.

Alışkın olduğum şeydeki farkı fark etmem biraz zaman aldı - yapay zekadan önce kod yazdığımda, her zaman ortadan başlar ve dışarı doğru çalışırdım. Kabaca:

1. API sözleşmesi oluştur ve sahte veri sun, curl ile test et
2. Sahte veriyi tüketmek için ön uç oluştur, tarayıcıda yinele+cilala
3. API'yi servis katmanına bağla (servisler sahte veri/davranış sunar)
4. Veritabanı geçişlerini ekle, servisleri veritabanına bağla
5. Bir sürü iş mantığı ekle
6. Bir sürü hata işleme ekle

Ve her adımda test ediyor/yineliyor/cilalıyor olurdum.

Kodu çok umursuyorsam veya modelin kod tabanının bu bölümünde iyi iş çıkarma yeteneğinden şüpheliysem, her adımda kodu da inceliyorum. 100-200 satırı kontrol etmek ve yeniden yönlendirmek çok daha ucuzdur.

Burada yapardım. Çoğu sınır modeli, insan yönlendirmesi olmadan böyle bir plan tasarlamaz ve bunu kod tabanına ve hatta göreve göre genellemek zordur, bu yüzden burada döngüde kalmayı tercih ederim. Güven bana. Keşke düşünme işini dışarıya verebilseydim.

30 dakikalık planlama, saatlerce süren incelemeden kurtarır

Ve bu nedenle, insanların, daha sonra temizlemeye çalışmak için dağlar kadar slop kod üzerinde didinmeden, insana yakın bir kalite seviyesini korumak istiyorsanız, döngüde olması gerektiğini savunduğum bazı adımlarımız var. (yani gerçekten hızlı gitmek istiyorsunuz)

1. Ürün Tasarımı
2. Sistem Mimarisi
3. Program Tasarımı
4. Dikey Dilimler

Açıkçası, gönderdiğimiz her şey için bu sürecin tamamını yapmıyoruz (aşağıdaki yan göreve bakın). Dağılımın kabaca şöyle olduğunu tahmin ediyorum:

• Görevlerin ~%40'ı tek atış veya 1-2 tur hafif geri bildirimle tek atış olarak yapılır
• orta büyüklükteki görevler için, ürün/sistem tasarımını tek bir plan belgesinde yaparız ve işi aşamalara ayırmayız
• büyük şeyler için, tüm adımları yaparız. Büyük yeniden düzenlemeler gibi anlamlı olmadığı durumlarda ürün kısmını atlarız.

Ve çoğu durumda, bir modeli bir seferde 1-3 dilim yapması için gönderirim ve yol boyunca kodu incelerim. İster iç işleyiş ister gerçek işlevsellik olsun, 2k+ satır kodun diğer tarafında neyin bozuk olduğuna dair hiçbir fikriniz olmadan bitirmektense, erken yönlendirmek çok daha kolaydır.

Muhtemelen çok fazla çekme isteğiniz olduğunu düşünüyorsunuz

Çok fazla PR'ınız yok. Çok fazla kötü PR'ınız var.

Hepimiz, yapay zekadan çok önce, yeniden çalışma gerektiren birçok PR'ı inceledik.

Ancak harika bir PR'ı incelemek bir zevktir. Her dosyada gezinirsiniz, kod temizdir, yazılımın nasıl olması gerektiğine dair tüm kararlarınızı/tartışmalarınızı/zor kazanılmış görüşlerinizi takip eder.

Öte yandan, bir Çekme İsteğinin %20 bile yeniden çalışmaya ihtiyacı varsa (ve bu cömertçe, çoğu AI tek atış PR'ının %50'ye yakın olduğunu söyleyebilirim), bu hem gönderen hem de inceleyen için entelektüel bir yük ve duygusal bir yük oluşturur. (Gönderen bir AI olsa bile, muhtemelen birisi bu işi başlatmış veya AI sonucunu vibe ile cilalamıştır veya en azından sonuçla ilgilenmektedir.)

Size zaman kazandırmak için (neredeyse sona geldik), bir yan görevde bunun hakkında daha fazla konuştum:

"zaman nereye gidiyor"

bir kısıtlamalar teorisi (2026 baskısı)

Buradaki ana tez biraz üzücü: "şimdilik kodu okumaya mahkumuz".

Sadece bir şeyler isteyebileceğimiz, modellerin pişirmesine izin verebileceğimiz, kodu okumayabileceğimiz ve zaman içinde gelişen, boktan bir hal almayan güzel bir üretim yazılımı elde edebileceğimiz bir dünya için oldukça heyecanlıydım.

Ama burada elimden gelenin en iyisini yaparak ortaya koymaya çalıştığım şey, kısıtlamalardan başka bir şey değil. Modeller bazı şeylerde iyidir, bazılarında o kadar iyi değildir. Bu kısıtlamalar ışığında sürecinizi nasıl optimize edersiniz?

Modeller bazı şeylerde iyidir, bazılarında o kadar iyi değildir. Bu kısıtlamalar ışığında sürecinizi nasıl optimize edersiniz?

10-100 kat daha hızlı hareket etmeye çalışmakla ve kod kalitesinin artık önemli olmadığına kendinizi inandırmakla çok meşgul olmanız mümkündür, oysa kısıtlamaları benimseyip güvenli bir şekilde 2-3 kat daha hızlı hareket edebilirsiniz.

Kapanış tavsiyem kabaca şöyle:

1. Kısıtlamaları iyi öğrenin, modellerle çok çalışarak sezgi geliştirin
2. Bu kısıtlamaların arenasındaki sistemleri optimize edin
3. Kaldıraç arayın
4. Lanet olası kodu okuyun

Bu kadar. Kalmak ve satış konuşmasını dinlemek isterseniz, sanırım kaydırmaya devam edin. Bunun bir felaketi önlemenize yardımcı olacağını ya da en azından bazı sevimli küçük animasyonları izlerken eğlendiğinizi umarım.

Okuduğunuz için teşekkürler

-dex

PS Buna takıntılıyız

İnsana (veya insana oldukça yakın) bir kod kalitesi seviyesini korurken 2-3 kat daha hızlı hareket etmenize yardımcı olmak için humanlayer.com, aracılı bir IDE ve işbirliği platformu inşa ediyoruz.

İki fikre doğru ilerliyoruz: "yazılım fabrikanız için yapı taşları" ve "yazılım sürdürülebilirliği için daha iyi doğrulayıcılar" (belki daha iyi modeller bile).

HumanLayer, en fazla 3 kişilik küçük ekipler için ücretsizdir ve başlamak için yardım isterseniz, discord'umuza gelebilir veya bize founders@humanlayer.dev adresinden bir mesaj gönderebilirsiniz.

İlham için @calvinfo'ya, kurucu ortağım @0xBlacklight'e, bana bu fikirleri keşfetmem için bir arena verdiği için @swyx'e ve @aiDotEngineer'daki ekibe ve bizi tezahürat yapan tüm inanılmaz müşterilerimize, yatırımcılarımıza, arkadaşlarımıza ve ailemize hızlı bir teşekkür.

Daha fazlasını öğrenmek isterseniz, bu konuda çenemi tutamam, bu yüzden bu yazıdaki tüm bağlantıları ve ayrıca materyalin podcast'lere, uzun metrajlı beyaz tahtaya vb. diğer yansımalarını aşağıda bulabilirsiniz.

PPS Diğer kaynaklar

Podcast'ler ve Makaleler:

• Dex ve Gergely, The Pragmatic Engineer'da bağlam mühendisliği ve yazılım fabrikaları hakkında konuşuyor - Temmuz 2026
• Dex ve Matt Pocock, her daim geçerli yapay zeka kodlama tavsiyeleri (ve ralph döngüleri) hakkında konuşuyor - Ocak 2026

İşe Yarayan Yapay Zeka Bölümleri:

• Kıyaslamalar hiçbir şeyi kanıtlamaz
• Yapay Zeka Kodlaması İçin Ürün Şartnameleri
• Daha iyi geri basınç için Öğrenme Testleri
• 12 faktörlü ajan ilkelerini yapay zeka kodlamasına uygulamak

Bu yazıdaki bağlantılar:

• Yazılım Fabrikaları Neden Başarısız Oluyor açılış konuşması — AI Engineer World's Fair 2026
• StrongDM'nin ışıkları söndürülmüş yazılım fabrikası
• OpenAI: Donanım Mühendisliği (Şubat 2026)
• Ryan Lopopolo, Symphony hakkında (konuşma, Nisan 2026)
• AI Engineer Europe'da Mario: "Bir slop dünyasında pi inşa etmek"
• FT: Kodlama ajanı kazalarından kaynaklanan Amazon kesintileri
• Matt Pocock: dağılan kod tabanları
• Faros AI: yapay zeka hızlanması kamçı etkisi raporu
• Kodlama Ajanları için Gelişmiş Bağlam Mühendisliği (konuşma 8/25)
• Vibe Yasak (konuşma 11/25)
• RPI Hakkında Yanlış Bildiğimiz Her Şey (konuşma 3/26)
• Awesome-RLVR - Pekiştirmeli Öğrenme kaynakları
• Kodlama Ajanları için Gelişmiş Bağlam Mühendisliği (yazı)
• 12 Faktörlü Ajanlar
• Addy Osmani, vibe kodlama vs. bakım hakkında
• NATO Yazılım Mühendisliği Konferansı, 1968
• DoD DevSecOps Referans Tasarımı (PDF)
• Ramp'in kodlama ajanı platformu
• Stripe: Minions, tek atış uçtan uca kodlama ajanları
• WorkOS: Project Horizon
• Brex (Latent Space)
• Dan Shapiro: yazılım fabrikasına giden beş seviye
• Simon Willison, StrongDM'nin yazılım fabrikası hakkında
• "Okyanusu kaynatmak"
• Av tüfeği ameliyatı (refactoring.guru)
• John Ousterhout — Bir Yazılım Tasarımı Felsefesi
• Robert C. Martin — Temiz Kod
• Martin Fowler — Yeniden Düzenleme
• aider
• cline
• codebuff
• SWE-Agent makalesi (2024)
• OpenAI Codex konuşması (Kasım)
• Calvin French-Owen — AI Council konuşması
• SWE-bench Çok Dilli (veri seti)
• AIE Worlds Fair 2026 - Büyük Döngü Tartışması ("abartı disiplini geride bırakıyor")
• SWE-Marathon (Abundant AI)
• DeepSWE (Datacurve)
• Frontier Code (Cognition)
• Mutasyon testi (Wikipedia)
• Dillon Mulroy, planlamada çağrı grafikleri hakkında
• Dex × Matt Pocock: dikey dilimler / işaret fişeği mermileri (canlı yayın, Ocak 2026)
• "Düşünmenin zor işi dışarıya verilemez" (Jake Nations)