**Bir yazılım fabrikası, ölçekte koşumlanmış döngülerdir. Döngüyü içinde insanlarla çalıştırabilirsiniz (hafif fabrika): muhakeme ve konsantrasyonu hız ve kırılmaya karşı takas edersiniz. Veya insanları görmezden gelebilirsiniz (karanlık fabrika) ve bu ajanların, kimsenin ayrıntıları gerçekten okumasına gerek kalmadan kodu kapsamlandırmasına, oluşturmasına ve göndermesine izin verebilirsiniz. Ancak insanlar okumayı bırakırsa, yazılımınızı anlamayı da bırakacaklardır. Şimdi en zor işiniz, hangi kontrolleri oluşturacağınızı ve ne kadar özerklik devredeceğinizi bilmek.
Yazılım fabrikası fikri, Bob Bemer'in 1968'de sunduğu "Program üretiminin ekonomisi" başlıklı makalesine kadar uzanır. Yarım yüzyıl boyunca birçok kişi, yazılımın bireylerin izole zanaatinden ziyade tekrarlanabilir ve ölçülebilir bir üretim süreci (tıpkı bir fabrikada araba parçalarının damgalanmasına benzer) olduğu bir dünyanın hayalini kurdu. Tarihsel olarak bu hayal, genel olarak (her yerde olmasa da) başarısız oldu, kısmen fikirleri damgalamanın zorluğu nedeniyle.
Ancak son iki yılda işler o kadar çarpıcı biçimde değişti ki, artık eski hayale yeni bir gözle bakmak mantıklı geliyor. Ve bazı incelikler kolayca gözden kaçabileceğinden, gerçekten yeni ve farklı olanın ne olduğu ve yeni fırsatlar gibi giyinmiş yinelenen tuzakların neler olabileceği konusunda biraz kesin olmakta fayda var.
@dexhorthy, HumanLayer'ın kurucu ortağı, yakın zamanda AI Engineer World's Fair'de "Koşum Mühendisliği Yeterli Değil: Yazılım Fabrikaları Neden Başarısız Oluyor." başlıklı harika bir konuşma yaptı. Bu konu hakkında izlemeye değer.
Döngü atomdur. Fabrika, ölçekteki döngüdür.
Yapı her şeydir ve her şey küçük birimlerle başlar. Tüm yığın aslında birbirinin üzerine katmanlanmış üç kavramdır: döngü, koşum ve fabrika.
Bir döngü, tek bir işi tekrarlayan bir ajandır: bağlam topla, bir eylem gerçekleştir, sonucu kontrol et ve belirli bir koşul karşılanana kadar tekrar et. Ajan işinin en küçük birimidir ve onun üzerindeki her şey, döngüler üzerine istiflenmiş döngülerdir.
Döngü mühendisliğinin amacı, ajana sırayla istemde bulunmayı bırakıp bunun yerine sizin için istemde bulunan küçük sistemi tasarlamanızdır.
Bir koşum, bir döngünün etrafındaki duvarlardır: çalıştığı kum havuzu, ulaşabileceği araçlar, çalıştırmalar arasında hayatta kalan bellek ve "bitti"nin ne anlama geldiğine karar veren geçitler. Döngü davranıştır; koşum, bu davranışın içinde çalıştığı ortamdır.
Çıplak bir modele koşum vermeyin, mutlu mesut sonsuza kadar döner durur. Koşum, onu çalıştırmayı kullanışlı ve güvenli kılan her şeydir.
Bir yazılım fabrikası, aynı anda çalışan, bir iş kuyruğu tarafından beslenen ve bir inceleme geçidinden üretime boşaltılan, insanların her şeye yukarıdan sahip olduğu birçok koşumlanmış döngüdür. Daha büyük bir ajan değildir; döngülerden oluşan bir organizasyon şemasıdır.
Nihai paradigma değişimi, kod yazmaktan, onu yazan fabrikayı oluşturmaya ve çalıştırmaya geçmektir. Çalışma birimi, bireysel kod farkı yerine döngü, koşum ve aralarındaki akışa doğru bir seviye yukarı kayar.
Döngü → koşum → fabrika. Bir fabrika daha zeki bir ajan değildir; tek bir inceleme geçidini besleyen, dış döngüye bir insanın sahip olduğu birçok koşumlanmış döngüdür. Fabrika, çizilmiş hali
Dex'in üzerinde en çok durduğu ana slayt, aksi takdirde bariz olan bir döngüyü görselleştiren aydınlatıcı bir bağlantı şeması olduğu için harikaydı. İşte benim yorumum:
Fabrika kapalı bir döngüdür: niyet ve üretim sinyalleri bir kuyruğu besler, koşum oluşturur, otomatik kontroller ve inceleme geçidi onu geçer, dağıtım gönderir, izleme üretimi tekrar sinyallere dönüştürür. Niyet, mühendislik liderliğinin vizyonundan ve doğrudan mühendislerden, yapılacak işlerin kuyruğuna akar. Olaylar ve kullanıcı taleplerinden kaynaklanan sinyaller aynı kuyruğu yönlendirir.
Koşum, kuyruktan bir öğeyi seçen ve onun için bir değişiklik oluşturan şeydir. Koşumun ötesinde, değişiklikleri üretime alınacak kadar güvenli kılmak için gereken tüm otomatik kontrolleri görebiliriz. Bu otomatik kontroller, CI, testler, statik analiz ve her türlü tarama sayesinde mühendislerin bilinçli katılımı olmadan zahmetsizce aynı anda çalışır. Buradaki tek karar noktası inceleme geçididir. Onaydan sonra değişiklikler dağıtılır ve üretimde izlenir; izleme verileri, döngüyü harekete geçiren sinyallere geri beslenir.
Genel olarak, bu diyagramdaki her kutu neredeyse sıfır maliyetlidir: üretim, testler, tarama. Hepsi ihmal edilebilir maliyetle ölçekte çalışır. Ölçeklendirmeye inatla direnen ve pahalı olan yalnızca bir kutu vardır, o da inceleme geçididir. O parlak kehribar kutusu "muhakeme"dir ve geliştirmeyi daha hızlı ve daha sık hale getirip getiremeyeceğimize dair tartışmanın özü burada yatar.
Neden "karanlık" olarak adlandırıyoruz
Karanlık bir fabrika, fiziksel olarak ışıklar kapalı çalışır çünkü yerde sadece makineler vardır ve makinelerin görmek için ışığa ihtiyacı yoktur. Karanlık bir yazılım fabrikası da aynı hamledir: hiçbir insanın okumadığı, yalnızca diğer makineler tarafından doğrulanan kod gönderilir.
Bu imge imalattan ödünç alınmıştır. Kökenleri fizikseldir, dijital değildir; ışıkların kapatıldığı ve işin robotlar tarafından yürütüldüğü tesislere dayanır. Japonya'daki FANUC, 2001'den beri bu tür insansız fabrikaları işletmektedir; Xiaomi, 2024'te kendi son derece otomatik karanlık fabrikasını açtı. Bunların ortak noktası, tek bir insanın herhangi birini okumamış olduğu bir ürünün montajı ve sevkiyatıdır. "Karanlık", bu okuma eylemi süreçten kaldırıldığında ortaya çıkar.
Konsepti havası için veya bir hakaret olarak ödünç almıyorum. Tüm ürkütücü vızıltısına rağmen, buradaki "karanlık" basit bir fiziksel iddiadır: orijinal fabrika zemini, ancak ışıksız. Yazılımda, zemin diff'tir. Diff'i kim yazdıysa, kim incelediyse, kim gönderdiyse, o insanlar gitti ve geriye kalan, yalnızca onu oluşturan makineler tarafından doğrulanmış bir diff'tir.
Bu, en azından ilk başta, şaşırtıcı derecede kolay bir şeydir. Kolaydır çünkü eksik olan inceleme adımı her şeyin önüne geçer. Yokluğu, ekibinizin dikey verimliliğine ilişkin algınızı aniden ve radikal bir şekilde daha yüksek hissettirir. Ses bariyerini kırmış gibi hissettirir. Tüm görünen kolaylığına rağmen, tüm gömülü maliyetleriyle bu karanlık iş akışlarında hayatta kalmak göründüğünden daha zordur.
Koşum mühendisliği yeterli değil
Orkestrasyonun, kum havuzunda prototip oluşturmanın ve modellerin dünyayla ve birbirleriyle etkileşime girerken araç çağrılarının koşumu giderek daha güçlü ve etkili hale gelecektir. Bununla birlikte, uzun vadede ve kümülatif değişiklikler yoluyla kod tabanı kalitesine ayak uydurmaya çalışırken modelin içsel bir başarısızlığı vardır ve bence modellerin tek başına sonuçta anlama borcuna karşı bu savaşı kaybedeceğine inanmak için iyi nedenler var.
Anlama borcu, var olan kod miktarı ile herhangi bir insanın hala anladığı kod miktarı arasındaki büyüyen boşluktur. Karanlık bir fabrika bunu ödemez; testler boyunca yeşil kalarak mümkün olduğunca hızlı bir şekilde üstlenir.
Bu önemli bir ayrımdır çünkü modeller bazı görevlerde iyi iş çıkarır. Ancak bir kod tabanının küçük bir bölümünde anında yapılan bir değişiklik olmayan herhangi bir şey için, özellikle karmaşık bir kahverengi alan sisteminde, yalnızca modele dayalı otomatik kodlama aşılmaz bir engelle karşı karşıyadır. Yeşil alan uygulamaları, hafta sonu oyuncakları ve yan projeler, birkaç aylık geliştirme döngüsünün genellikle işleri çalışır duruma getirmek için yeterli olması veya en azından yeterince yaklaşması bakımından benzerdir.
Ancak on yıl veya daha uzun süredir geliştirilmekte olan bir kurumsal sistem farklı bir canavardır; profesyonel bir ortamda, profesyonel bir tempoda bakımı yapılmalıdır. Bir projeye başladıktan üç ila altı ay sonra, zaten okunmamış kodda boğuluyorsunuzdur. Bu tür bir ortam ve özellikle üretim kodu tarafından uygulanan kısıtlamalar, güçlü bir ajanın bile kötü performans göstermesine neden olur; bunların tümü, hafta sonu oyuncakları üzerinde çalışan geliştiricilerin keyfini çıkardığı vibe coding'in aksinedir.
Dex, deneyimlerinden bunun büyük bir başarısızlık olduğunu ve o kadar ki, tespit etmek için özenli manuel hata ayıklama gerektirdiğini bildiriyor. Bu, yaklaşık dört ay boyunca tam otomatik bir kod fabrikası çalıştırmaktan kaynaklandı ve bu süre zarfında hiçbir insan yazılan koda bakmadı. Deneyimin altında, birbiriyle çelişen iki metrik arasında bir ödünleşim yatıyor. Biri, şu anda ilerleme olarak ele aldığımız sayı olan token kullanımını en üst düzeye çıkarmaktır. Diğeri ise sessizce en aza indirdiği, herhangi bir insan katılımcının herhangi bir anda hala anladığı sistem miktarıdır.
Karanlık fabrikanın gerçekten parladığı yer, testler yeşil kalırken bozulmamış kodu tüketme yeteneğidir. Nihai hesaplaşma, geldiğinde, dramatik bir "her şey ters gidiyor" anı olmayacaktır. Sessiz ve geç olacaktır.
Karanlık ve aydınlık, ışıkların farklı yerlerde olduğu aynı boru hattıdır. Aydınlık versiyon, incelemeyi sadece sona eklemekle kalmaz - insan muhakemesini aynı zamanda tasarım ve mimariye de yukarı taşır. Darboğaz hiçbir zaman üretim olmadı
Bir yazılım fabrikasındaki temel kısıtlama, ne kadar kod üretebileceğimiz değildir: ne kadar hızlı doğrulayabileceğimizdir.
Geri basınç kuralıdır: Bir döngüye ancak ucuz ve güvenilir bir şekilde doğrulayabildiğiniz kadar özerklik verebilirsiniz, bir santim fazlasını değil. Doğrulama, üretim değil, bir fabrikanın gerçek kısıtlamasıdır.
Çünkü sınırsız üretim kapasitesi, sonlu ve ölçeklenemeyen insan dikkati kaynağıyla sürekli bir gerilim içindedir; temel sorun, ucuz üretim ile sınırlı inceleme arasındaki boşluktur. Huniye bakın: Doğrulamayı temsil eden boyun genişlemediği sürece, geriye doğru birikmeye devam edecektir. Dex'in işaret ettiği gibi, tek başına hacim sorun değildir: asıl çektiğimiz şey, fazla sayıda kötü PR'dır. Yüksek hacimli, güvenilir geçitler olmadan, üretilmiş kusurlar kaçınılmazdır. Bu yine geri basınçtır: özerklik, ucuz ve güvenilir bir şekilde doğrulanabilenin ötesine genişleyemez.
İkinci dereceden sorun, modelin iyileştirilmesinin, üretebildiği ile doğrulanabilen arasındaki boşluğu neden otomatik olarak kapatmaması gerektiğidir. İyi mimariye sahip sistemler üzerinde eğitim, basit testleri geçmekten tartışmasız daha zor bir önermedir: unutmayın, mimari mükemmelliği ölçen maliyet fonksiyonları saniyeler veya dakikalarla değil, aylar ve yıllarla ölçülür. Düzenli gradyanları hesaplamak işlevsel olarak imkansızdır, bu nedenle karmaşık tasarım kararlarının net, anlık değerlendirmesini bekleyen bir sistem iyi örnekler üzerinde eğitilmeyecektir.
Üretim geniş bir ağızdır; doğrulama dar bir boyundur. Ağzı hızlandırmak, boyundaki yığını derinleştirir.
Işıkları tekrar açmak
Aydınlık bir fabrika, muhakemenin olduğu yerde ışıkların açık bırakıldığı aynı boru hattıdır. Ajanlar yine de inşaatın çoğunu yapar, ancak bir insan gönderilmeden önce çıkanı okur ve yanlış bir kararın pahalı olduğu her yerde ışıklar açık kalır.
Aydınlık versiyon, incelemeyi sona eklemekle kalmaz, insan muhakemesinin noktasını bir ajan bir döngü başlatmadan önce ürüne, tasarıma ve mimariye doğru yukarı taşır.
Bu ön saatle ilgili harika olan şey, daha az uygulama saatine yol açmasıdır. Uzun, sinir bozucu bir kod incelemesini, iki yüz satırlık bir planın hızlı bir okumasına dönüştürür. Bir kararı inşa edilmeden önce inceleme şansınız olur, böylece daha sonra kararın ne olduğunu bulmak için iki bin satırlık üretilmiş kodun peşinden koşmazsınız. Bazı kararlar, maliyet birikmeden önce bir kişinin işin içinde olmasını isteyeceğiniz kadar pahalı ve uzun ömürlüdür. Tabii ki, önceden zaman harcamış olsanız bile, yine de diff'lere baktığınız zamanlar olacaktır.
Tüm bunların havalı görünmediğini düşünüyor olabilirsiniz. Haklısınız. Güvenlik ağı, her zaman bildiğimiz ve çoğunlukla görmezden geldiğimiz son derece sıradan mimari uygulamalardan oluşur: hataların üretim yerine derleyici tarafından yakalanması için iyi tipler ve metod imzaları; davranışı sabitleyebileceğimiz ve değişikliği gözlemlenebilir kılabileceğimiz test dikişleri; bir sonraki okuyucunun, ister insan ister model olsun, önemsediği şeyi nerede bulacağını bilmesi için kodu düzenlemek; çağrı yığınlarını kısa ve okunaklı tutmak; bir değişikliğin büyük bir etki yarıçapına sahip olmaması için bileşen sınırlarını iyi tanımlanmış tutmak; ve bir parçayı diğeriyle değiştirebilmemiz için bağımlılık enjeksiyonu. Bunların hiçbiri yeni değil. Her zaman iyi mimariyi önemsediğimizi söyledik. Ancak şimdi otomatik kodlama ajanları kullandığımıza göre, bu mimari nihayet ajanın yapacağı hatalara karşı ucuz ve taklit edilmesi zor bir güvenlik ağı olarak ikinci bir iş görüyor.
Bu güvenlik ağı modelin dışında yaşamalıdır, çünkü model onu sağlamayacaktır. En yetenekli hisseden kodlama ajanları, aralarında Claude Code ve Codex'in de bulunduğu, kendi koşumlarına ve araçlarına karşı pekiştirmeli eğitim almıştır: ticaretin tüm araçlarına ve deyimlerine hakimdir, ancak uzun vadeli sürdürülebilirlik gibi şeylere değil. Her zaman bahsettiğimiz kasıtlı mimari, bu borcu yakalayan araçtır ve ona yaptığımız yatırım, özerkliğimizi geri satın almamızdır.
Bunu güvenli altyapı ile birleştirin ve gözetimsiz çalıştırabileceğiniz bazı sıkı, düşük riskli döngüler vardır. Horthy bunu yakın tarihli bir yazısında anlattı: tamamen kendi başına, tam olarak bir anti-kalıbı düzelten, bir lint ihlalini veya gereksiz yere isteğe bağlı bir prop'u düzelten, commit atan ve küçük bir pull request açan bir gece GitHub Actions cron'u; böylece ekip biraz daha iyi bir kod tabanına ve okunacak kadar kısa bir diff'e uyanır. Ancak yeterince yüksek riskli döngüler için, kırık bir kimlik doğrulama sistemi, fatura motoru veya genel API sözleşmesi ile uyanma riskini almak istemezsiniz. Orada ışıkları açık tutun ve muhakemeye ve sistem hakkında gerçek bir çalışma bilgisine sahip bir kişinin hatayı yakalayacağına güvenin.
Bir döngüye karanlığı kazandıran şey
Bu kural, ister geri basınç, ister doğrulama veya ışık anahtarı deyin, geçerlidir.
Bir döngü, yalnızca kontrol ucuzsa, yüksek frekansta çalışıyorsa ve kolayca taklit edilemeyecek bir şeye dayanıyorsa tam otomatik statü kazanabilir. Yeşil-kırmızı kahinler, tip geçitleri, özellik testleri ve gerçek bir rubrikle eşleştirilmiş bir inceleme ajanı bunlara uyar. Ayrıca kahinin hemen cevap vermesi ve zamanla kaymaması gerekir. Bitti'nin yalnızca sizin tarafınızdan değil, bir makine tarafından da kanıtlanabildiği zaman otomasyona ulaşmışsınızdır.
Kısa döngüleri doğrulamak, uzun olanlardan daha kolaydır. Dex'in temel kuralı: bir ajan üç ila on adım boyunca iyi tutunur, ardından yirmiyi geçtikten sonra ipliği kaybetmeye başlar. Bunun nedeni bağlam birikimidir; ajan ne kadar çok sürüklerse, başıboş dolaşma olasılığı o kadar artar. Bir döngü kısa olduğunda, onu doğrulamak ucuzdur. Yayılan döngüler, hataları köşelerde gizler, bu da başka bir deyişle hiçbir zaman ışıklar kapalı statüsünü kazanmadıkları anlamına gelir.
Işıkları açık tutmak tam tersi durumdur. Yanlış bir cevap pahalıysa ve bunu yalnızca bir kişi yakalayabiliyorsa, bir döngünün gözden geçirilmesi gerekir. Testlerle yakalanamayan ince üretim hataları, büyük etki yarıçapları ve bir yıl veya daha uzun süreli çalışmayı şekillendirecek bir kararın tümü buna girer. Bu durumlarda, dikkatiniz asıl üründür, maliyetli, temel olan.
Tehlike, her anahtarı çevirmeyi unutup hepsini aynı moda ayarlamaktır. Hepsi karanlık: dört ay sonra her şeyi yıkıp atmak zorunda kalırsınız. Hepsi aydınlık: kimse incelemeleri zamanında tamamlayamaz ve dev bir darboğazda sıkışıp kalırsınız. Zor ve beceri gerektiren iş, her anahtarı nereye koyacağınıza karar vermektir.
Döngüler, grafikler veya durum makineleri?
"Devlet makineleri 2 dakikada" yazısını okumalısınız @DavidKPiano
Bir ajana bir görev verdiğinizde, muhtemelen etrafında bir grafik oluşturacaksınız, ister bu grafiğe sonlu durum makinesi ister koşullu olarak bağlı hizmet çağrıları seti deyin. Bu, yazılımın sadece bazı soyut kuralları değil, yapılandırılmış bir iş akışını takip ettiği bir çerçevedir: her düğüm açık bir adımdır ve düğümler arasındaki her kenar açık bir koşuldur.
Bu çok fazla yapı gibi görünüyor, ancak çoğu zaten herhangi bir yazılımda mevcuttur, çünkü herhangi bir kod bir kontrol akışı grafiği olarak ifade edilebilir. Yani tek gerçek yenilik, özerklik konusunda ısrar eden bir ajanın aslında belirli bir grafikte dolaşması ve özgürlüğünün bir düğümün içiyle sınırlı olmasıdır. Ve işte insanların unuttuğu ve Dex'in bir yıl önce yazdığı kısım: yazılım her zaman bu yapıya sahip olacaktı. Programları akış şemaları olarak çizmemizin bir nedeni vardı.
Gerçekten yeni olan hamle, diyagramı atmaya çalışmak, modelin kendini bitmiş ilan edene kadar araç çağrısı üstüne araç çağrısı yaparak yolu seçtiği bir döngüye yaslanmaktı. Bu, on yıllık bir kod tabanıyla karşılaşana kadar özgürleşme gibi hissettirdi ve şimdi herkesin yeniden keşfettiği disiplin, yani kontrol akışınıza sahip çıkmak, aslında grafiği döngünün etrafında geri yürümektir. Dolayısıyla, döngülerden grafiklere geri dönmeli miyiz sorusu, neredeyse akış şemasına en başından ihtiyacımız olduğunun bir itirafıdır.
Pratikte böyle görünüyor. Düzeltilecek bir hata alın. Saf bir döngü olarak, oturur ve düşünürsünüz: neyin yanlış olduğunu bul, biraz kod değiştir, testleri çalıştır, ne olduğunu gör ve eğer bu tur çalışmayı bitirmezse, geri dön ve yeniden başla. Tüm yolculuk, hangi sorunu kovalayacağınız, tam olarak hangi kodu değiştireceğiniz, hangi testleri hangi sırayla çalıştıracağınız, testleri hiç çalıştırıp çalıştırmayacağınız ve tekrar deneyip denemeyeceğiniz veya zafer ilan edip etmeyeceğiniz yol boyunca kararlaştırılır.
Bir grafik olarak, yapmanız gereken ilk şey, ne olması gerektiğini haritalamaktır. Hatayı yeniden üretin veya daha fazla bilgi isteyin, nedeni bulun, bir düzeltme deneyin, testleri çalıştırın ve başarısız bir çalışmanın düzeltmeye geri yönlendirilmesine izin verirken, başarılı bir çalışmanın, yalnızca bir onayın "bitti"ye ulaştığı incelemeye gitmesine izin verin. Ajan hala her kutunun içinde zekidir; sadece onayladığınız yollardan sapamaz. Santi bunu, farkı açıkça ortaya koyan bir diyagramla ortaya koydu.
Bu grafiğin gerçek çekiciliği, elbette, bir diyagram olarak çizilmiş geri basınç olmasıdır. Ajanın özgürlüğünün bir kısmından vazgeçer ve karşılığında zorunlu kontroller ve okunabilir başarısızlık noktaları alırsınız, böylece bir çalışma öldüğünde, onu öldüren düğümü işaret edebilirsiniz. Bu, Dex'in çoğu sözde ajanın hiç de ajan gibi olmadığı, "çoğunlukla deterministik kod, doğru noktalara serpiştirilmiş LLM adımları" yönündeki keskin çizgisinin arkasındaki aynı içgüdüdür. Ve bu sadece insanların şu anda bir şeyleri inşa etme şeklinin bir yapay ürünü değil: bu örüntüyü LangGraph ve LlamaIndex Workflows'da, Jerry Liu'nun çalışırken grafiğin parçalarını büyüten bir dış döngüye sahip hibrit çalışma-akışı-grafik-üzeri-ajanlar'ında ve David Khourshid'in bunun aslında sadece durum makineleri ve aktör modelinin yeni kıyafetlerle ortaya çıkması olduğu yönündeki hatırlatmasında görebilirsiniz.
Bir açıklama, çünkü terim aşırı yüklendi: buna sürekli grafik derken, bir bilgi grafiğini kastetmiyorum. İşin nasıl akması gerektiğine dair, koşullu kenarları ve her şeyiyle önceden tanımlanmış bir yönlendirilmiş grafiği, döngüye gerçekten güvenebileceğiniz bir şekil veriyorum.
İnsan aslında nereye gidiyor
Kişinin fabrikadan asla ayrılmadığını fark edin. Taşındılar.
Bence mühendislerin giderek artan bir şekilde dış döngüye sahip olmaları gerekiyor. Ajanlar bir hatayı araştırabilir, teşhisi yazabilir, bir düzeltme uygulayabilir, testleri çalıştırabilir ve bir rapor yazabilir. Bu, iç döngünün yürütülmesidir ve bunu herkes kadar verimli bir şekilde yapabilirler. Ama iş hiçbir zaman bu olmadı. Sahip olduğunuz parçalar, dış döngü olarak adlandırdığım şeylerdir: sorunu ele almanın doğru yolu olup olmadığına karar verin, teşhis ve uygulamanın sağlam olduğunu doğrulayın, değişikliği onaylayın ve yanlış olmanın sonuçlarını taşıyın. İki döngü arasındaki sınır, kanıtlar, diff'ler, testler, günlükler ve bunları birbirine bağlayan kısa bir açıklamadır. Tipler, dikişler ve rubrikler, her değişiklik için çok fazla iş yapmadan tüm bunları denetlemeyi mümkün kılar.
Bunu şu şekilde ifade etmek faydalıdır: artık değişiklikleri yazmak için hattın aşağısında değilsiniz; üretim hattının sonunda, onu tasarlıyor ve geçidi koruyorsunuz. Modeli daha iyi ve koşumu daha yetenekli kılmak için yapabileceğiniz çok şey var, ancak uzun vadede pahalı olan sorunları belirlemenin genellikle otomatikleştirebileceğiniz bir şey olmadığını gözlemledim. Hala iş olan temel şey, insan muhakemesini herhangi bir kağıt ve bilgi işlem gücü akışından daha iyi kullanmaktır.
Robotlar karanlıkta çalışmakta iyidir, ancak insanların ne yaptıklarını görmeleri gerekir. Fabrika katındaki her şey karanlıksa, hiçbir şey göremiyorsanız ve ışık anahtarını bile bulamıyorsanız, tehlike buradadır.
Pangram, bu makaleyi %100 insan yazımı olarak puanladı.
