- Yazılım fabrikası, bağlam toplama·eyleme geçme·doğrulama döngüsünü bir harness ile sarıp büyük ölçekte işletir; insanların karar verdiği aydınlık fabrika ile kod incelemesini bile makinelere bırakan karanlık fabrika olarak ayrılır
- Kod üretimi·test·tarama neredeyse sıfır maliyetle ölçeklenebilir, ancak insanların inceleme ve muhakemesi ölçeklenmesi zor olduğu için, üretim miktarından çok sonuçları ucuz ve güvenilir biçimde doğrulama hızı darboğaz haline gelir
- İnsanlar kodu okumazsa, kodun büyüklüğü ile insan anlayışı arasında anlama borcu(comprehension debt) birikir; testler geçmeye devam etse bile uzun süre işletilen karmaşık sistemlerde bakım sorunları sonradan ortaya çıkabilir
- Tam otomasyon yalnızca anlık, drift etmeyen ve manipüle edilmesi zor değerlendirme ölçütlerine sahip kısa döngülerde izin verilmelidir; kimlik doğrulama·ödeme·genel API gibi yanlış kararların maliyeti ve etki alanı büyük olan işlerde insan incelemesi korunmalıdır
- Mühendisin rolü, tek tek değişiklikleri doğrudan yazmaktan dış döngüyü tasarlayıp korumaya kayar; ajanların yaptığı teşhis·uygulama·test kanıtlarını doğrulamak, onaylamak ve sonuçların sorumluluğunu almak gerekir
Döngülerden yazılım fabrikasına
- Yazılımı tekrarlanabilir ve ölçülebilir bir üretim sürecine dönüştürme fikri, Bob Bemer'in 1968'de yayımladığı "The economics of program production" yazısına kadar uzanır
- Fikirleri otomobil parçaları gibi seri üretmek zor olduğu için, son yarım yüzyıldaki bu tür girişimler genel olarak beklentileri karşılayamadı
- Son 2 yıldaki değişim, eski yazılım fabrikası fikrini yeniden gözden geçirecek kadar büyük olsa da, geçmişin tuzakları yeni fırsatlar gibi paketlenebilir
- Tüm yapı döngü·harness·fabrika olmak üzere üç katmandan oluşur
- Döngü, tek bir ajanın bağlam toplaması, eyleme geçmesi, ardından sonucu kontrol etmesi ve bitiş koşulu sağlanana kadar bunu yinelemesi olan en küçük iş birimidir
- Döngü mühendisliği, insanın her seferinde prompt girmesi yerine ajana prompt sağlayan küçük bir sistem tasarlama yaklaşımıdır
- Harness; döngünün çalıştığı sandbox'ı, kullanılabilecek araçları, çalıştırmalar arasında korunan belleği ve tamamlanma durumunu değerlendiren kapıları içerir
- Harness olmadan model sonsuza kadar tekrarlayabilir; bu yüzden harness, döngüyü faydalı ve güvenli hale getirir
- Yazılım fabrikası, iş kuyruğundan öğeler alıp birden fazla harness tabanlı döngüyü eşzamanlı çalıştıran, ardından inceleme kapısından geçirip production'a gönderen yapıdır
- Daha büyük tek bir ajandan çok, döngülerden oluşan bir organizasyon şemasına benzer
- Mühendisin iş birimi de tekil kod değişikliklerinden döngülere, harness'lere ve döngüler arasındaki akışa kayar
Fabrikanın iş akışı ve darboğazları
- Mühendislik liderliğinin vizyonu, mühendislerin niyeti, arızalar ve kullanıcı taleplerinden gelen sinyaller tek bir iş kuyruğuna girer
- Harness öğeleri seçip değişiklik üretir; CI·test·statik analiz·çeşitli taramalar bu değişiklikleri eşzamanlı olarak inceler
- İnceleme kapısı onay verirse değişiklik dağıtılır ve production izleme verileri yeni işleri tetikleyen sinyaller olarak geri döner
- Üretim·test·tarama ihmal edilebilir maliyetle ölçeklenebilir, ancak inceleme kapısındaki insan muhakemesi ölçeklenmesi zordur
- Geliştirme hızını ve dağıtım sıklığını artırıp artıramayacağınız, bu muhakeme darboğazını nasıl ele aldığınıza bağlıdır
Karanlık fabrika ve anlama borcu
- Üretimdeki karanlık fabrika, makinelerin aydınlatmaya ihtiyaç duymadığı için ışıklar kapalı şekilde çalışan tesistir
- FANUC 2001'den beri bu tür fabrikalar işletiyor; Xiaomi de 2024'te yüksek düzeyde otomatikleştirilmiş bir karanlık fabrika açtı
- Karanlık yazılım fabrikasında insanlar kodu okumaz; değişiklikler, kodu üreten makinenin yaptığı doğrulama temelinde dağıtılır
- Buradaki karanlık olumsuz bir atmosferi değil, insanların diff yazma·inceleme·dağıtma sürecinden çıkmış olmasını ifade eder
- İnsan incelemesini kaldırınca dikkat dağıtıcı unsurlar yok olur ve ekibin dikey throughput'unun keskin biçimde arttığı hissi oluşur
- Ancak gizli maliyetler yüzünden böyle bir iş akışını uzun süre sürdürmek, dışarıdan göründüğünden daha zordur
- Orkestrasyon, sandbox tabanlı prototipleme ve araç çağrıları daha da güçlenecek olsa da, yalnızca harness ile uzun vadeli codebase kalitesini korumak yeterli değildir
- Anlama borcu, mevcut kod miktarı ile insanların gerçekten anladığı kod miktarı arasındaki farktır
- Karanlık fabrika, testler geçerken bile hızla anlama borcu biriktirir
- Küçük kod alanlarındaki anlık değişikliklerin veya hafta sonu projelerinin aksine, 10 yıldan uzun süredir geliştirilen karmaşık mevcut sistemlerin uzman düzeyinde sürekli bakımı gerekir
- Otomasyon projesini 3~6 ay işlettikten sonra okunmamış kod tarafından ezilebilirsiniz
- Dex Horthy, yaklaşık 4 ay boyunca insanların üretilen kodu görmediği tam otomatik bir fabrika işlettiğinde, sorunların kök nedenini bulmak için yorucu manuel debugging gerekmişti
- Token kullanımını en üst düzeye çıkardıkça, insanların sistemi anlama düzeyi sessizce azalır
- Hata, testleri geçen tüm sistemin bir anda çökmesi yerine geç ve sessizce gelebilir
Neden kısıt üretim değil doğrulama oluyor
- Back pressure, döngülere yalnızca ucuz ve güvenilir biçimde doğrulanabildiği ölçüde özerklik verme ilkesidir
- Neredeyse sınırsız üretim kapasitesi ile sınırlı insan dikkati arasındaki fark temel sorundur
- Doğrulama aralığı genişlemezse değişiklikler birikir; güvenilir kapılar olmadan yalnızca hacmi artırmak düşük kaliteli PR'lara ve üretilmiş hatalara yol açar
- Model performansındaki iyileşme, üretim ile doğrulama arasındaki farkı otomatik olarak kapatmaz
- İyi mimarinin değeri saniyeler veya dakikalar içinde değil, aylar ve yıllar boyunca ortaya çıkar
- Mimari üstünlük için temiz bir maliyet fonksiyonu ya da anlık değerlendirme sinyali hesaplamak zordur; bu nedenle karmaşık tasarım kararlarını iyi örnekler olarak eğitmek de zordur
Işıkları yeniden yakmanın yolu
- Aydınlık fabrikada da ajanlar uygulamanın çoğunu üstlenir, ancak yanlış kararın maliyetinin yüksek olduğu noktalarda ışıklar açılır ve insanlar çıktıyı okuyup sonra dağıtır
- İnsan muhakemesi yalnızca son kod incelemesine eklenmemeli; ajan döngüye başlamadan önce ürün·tasarım·mimari aşamalarına taşınmalıdır
- Önceden 1 saat boyunca 200 satırlık bir planı incelemek, uygulama sonrasında 2.000 satırlık üretilmiş kod içinde tasarım kararlarını aramayı gerektiren uzun incelemeyi azaltabilir
- Maliyeti yüksek ve etkisi uzun süren kararlar için insanlar uygulamadan önce devreye girmeli; ön inceleme yapılmış olsa bile gerekirse diff doğrudan kontrol edilmelidir
- Güvenlik ağı yeni tekniklerden değil, tanıdık mimari pratiklerden oluşur
- İyi type'lar ve method signature'larıyla hataları production yerine compiler'da yakalayın
- Davranışı sabitleyip değişiklikleri gözlemleyebilmek için test seam'leri oluşturun
- Hem insanların hem modellerin ihtiyaç duyduğu kodu kolay bulabilmesi için düzen kurun
- Call stack'i kısa ve okunabilir tutun
- Değişikliklerin etki alanını sınırlamak için component sınırlarını netleştirin
- Dependency injection ile bileşenlerin değiştirilebilir olmasını sağlayın
- Bu mimariler, otomatik kodlama ajanlarının hatalarını ucuz ve kandırılması zor biçimde engelleyen ikinci bir rol üstlenir
- Claude Code ve Codex gibi ajanlar kendi harness'leri ve araç kullanımları konusunda reinforcement learning ile eğitilmiş olsa da, uzun vadeli bakım yapılabilirliği garanti etmez
- Güvenlik ağı modelin dışında var olmalıdır; mimari yatırımı daha fazla özerkliği güvenli biçimde elde etmenin aracı olur
- Güvenli altyapıyla birleştiğinde bazı kısa ve düşük riskli döngüler insansız çalıştırılabilir
- Örneğin, her gece GitHub Actions cron'u bir antipattern'ü, bir lint ihlalini veya gereksiz yere optional olan prop'lardan tam olarak birini düzeltip commit edebilir ve küçük bir PR açabilir
- Kimlik doğrulama sistemleri, ödeme motorları ve genel API sözleşmeleri gibi hata maliyeti yüksek alanlar, sistem bilgisi ve muhakemeyle insan incelemesi gerektirir
Otomasyon yetkisi kazanan döngüler
- Bir döngünün tam otomatik olabilmesi için kontrollerin ucuz, sık çalışan ve kolayca kandırılamayan ölçütlere dayanması gerekir
- Doğru·yanlış şeklinde net sonuç döndüren değerlendiriciler, type gate'leri, özellik tabanlı testler ve gerçek değerlendirme rubriğiyle birleşen inceleme ajanları buna örnektir
- Karar anında çıkmalı ve zamanla drift etmemelidir
- Tamamlanma durumunu yalnızca insan değil makine de kanıtlayabiliyorsa otomasyon mümkündür
- Kısa döngüler, uzun döngülerden daha kolay doğrulanır
- Dex'in deneyim kuralına göre ajanlar 3~10 adımda iyi çalışır, ama 20 adımı geçince akışı kaybetmeye başlar
- Bağlam biriktikçe ajanın yoldan çıkma olasılığı artar ve uzun döngüler hataları köşelere saklar
- Yanlış cevabın maliyeti yüksekse ve bunu yalnızca insanlar fark edebiliyorsa ışıkları açmak gerekir
- Testlerin yakalayamadığı ince production bug'ları, geniş etki alanları ve 1 yıldan uzun işi yönlendiren kararlar buna dahildir
- Bu gibi durumlarda insan dikkati asıl üründür ve pahalı olsa da vazgeçilmez bir kaynaktır
- Tüm döngüleri aynı moda almak her iki tarafta da başarısızlığa yol açar
- Her şeyi karanlık çalıştırırsanız birkaç ay sonra sistemi sökmeniz gerekebilir
- Her şeyi aydınlık çalıştırırsanız inceleme devasa bir darboğaz haline gelir
- Her döngüde ışıkların hangi noktada açılacağına karar vermek temel beceridir
Döngüyü saran grafik ve durum makineleri
- Ajan işi, buna sonlu durum makinesi ya da koşullu servis çağrısı deseniz de sonuçta büyük olasılıkla yönlü bir grafikten oluşur
- Her düğüm açık bir adımdır ve düğümler arasındaki kenarlar açık koşullardır
- Tüm kod bir kontrol akışı grafiği olarak ifade edilebildiği için yapının kendisi yeni değildir
- Ajanın özerkliği grafiğin tamamına değil, her düğümün içine sınırlandırılır
- Yeni denemeler, akış şemasını kaldırıp modelin her araç çağrısında yolu seçmesine ve sonunda kendi kendine tamamlandığını ilan etmesine dayanıyordu
- Eski codebase'lerle çarpıştıktan sonra kontrol akışını yeniden sahiplenme eğilimi, döngünün etrafında mevcut grafiği geri yüklemek gibidir
- Bug düzeltme işi, saf döngü ile grafik yapısında farklı ilerler
- Saf döngüde sorun araştırması, kod değişikliği, test seçimi ve çalıştırma sırası, yeniden deneme ve tamamlanma kararı yürürlükteyken belirlenir
- Grafikte ise bug'ı yeniden üretme veya ek bilgi isteme, kök nedeni bulma, düzeltme, test ve inceleme yolları önceden tanımlanır
- Test başarısız olursa düzeltme aşamasına dönülür, başarılı olursa incelemeye geçilir ve yalnızca onaylanırsa tamamlanır
- Ajan her düğüm içinde akıllıca davranır ama izin verilmeyen yollara sapamaz
- Grafik, back pressure'ı görselleştiren bir biçimdir
- Ajanın özgürlüğünün bir kısmından vazgeçme karşılığında zorunlu kontroller ve okunabilir başarısızlık noktaları elde edilir
- Çalıştırma başarısız olursa hangi düğümün durdurduğunu belirleyebilirsiniz
- 12-factor agents yaklaşımında olduğu gibi birçok ajan sistemi, “uygun noktalarda LLM adımları serpiştirilmiş çoğunlukla deterministik kod”a daha yakındır
- Aynı desen LangGraph ve LlamaIndex Workflows'ta, Jerry Liu'nun ajan üstü hibrit iş akışı grafiğinde ve David Khourshid'in ilişkilendirdiği durum makinesi ile actor model'de de görülür
- Buradaki grafik, bir bilgi grafiğini değil; iş akışını ve koşullu kenarları önceden tanımlayan yönlü grafiği ifade eder
İnsan dış döngünün sahibidir
- İnsanlar fabrikadan kaybolmaz; yürütme hattından dış döngüye geçer
- Ajanlar bug araştırma, teşhis yazma, düzeltme uygulama, test çalıştırma ve sonuç raporlama gibi iç döngüleri yürütür
- Mühendis ise sorunun doğru biçimde çözülüp çözülmediğine karar verir, teşhisi ve uygulamayı doğrular, değişikliği onaylar ve yanlış sonuçların sorumluluğunu alır
- İç döngü ile dış döngü arasındaki sınırda diff'ler, testler, log'lar ve bunları bağlayan kısa açıklamalar gibi kanıtlar bulunur
- Type'lar, test seam'leri ve değerlendirme rubrikleri hazırsa, her değişiklikte çok sayıda manuel iş yapmadan ajan çalıştırmalarını denetleyebilirsiniz
- Mühendisin konumu, üretim hattında değişiklikleri doğrudan yazan kişiden hattı tasarlayıp kapıları koruyan kişiye doğru kayar
- Modeller ve harness'ler geliştirilebilir, ancak uzun vadede pahalı sorunları tespit eden insan muhakemesini otomatikleştirmek zordur
- En tehlikeli durum, tüm çalışma alanlarını karanlık hale getirip insanların ne olup bittiğini göremediği, hatta ışık düğmesini bile bulamadığı durumdur
Henüz yorum yok.