Bir yazılım fabrikası, yazılım işi etrafında tekrarlanabilir bir döngüdür. Bir yazılım fabrikası kuruyorsanız, göndermeye yeterli kod yine de insan zevki ve sahiplenmesi gerektirir. Buna, henüz bir fabrikaya ihtiyacınız olup olmadığını da dahil ederek tartışacağız.
Eğer öyleyse:
- Ürün amacına, sistem tasarımına (eğer umursuyorsanız) ve kalite çıtanıza karar vermek için muhtemelen başlangıçta insanları döngüye dahil etmeniz gerekecek.
- Kodu inceleyin (ışıkları açık fabrika) ancak en çok ihtiyaç duyulan yerde kasıtlı olun. Otomatik arka basıncın nerede kırıldığına dikkat etmek istediğinizi gördüm. Veya bakım kolaylığı ödünleşimlerinin yapılması gereken yerlerde.
- Kalite kontrollerinin mümkün olduğunca erken ve sürekli olarak gerçekleşmesini hedefleyin. Hepsinin olması gerekmez, ancak bu, tip sistemlerini, otomatik testleri, mutasyon testlerini, güvenlik tarayıcılarını ve mimari kurallar için linting'i içerir.
- Kontrol sayısı != kalite. Muhtemelen size en iyi sinyal-gürültü oranını veren kontrolleri bulmak için denemeler yapmanız gerekecek. Kısıtlamalarınızı kasıtlı olarak sıkılaştırmaya veya gevşetmeye hazır olun.
Fabrikanızı, insan zevkinin bazı yönlerinin ortama kodlanacağı, ajanın size çalışmasının doğru olduğuna dair kanıt vereceği ve bir insanın hala üretime gönderilene "sahip olduğu" şekilde kurmak istersiniz.
Gerçekten bir yazılım fabrikasına ihtiyacınız var mı?
Deneyimlerime göre, mevcut kodlama düzeneğinizle şaşırtıcı derecede ileri gidebilirsiniz! Yani Claude Code veya Codex, birden çok oturum, doğrulama ve kısıtlamalar içeren iyi spesifikasyonlar. Hatta onlara uygulama ve insan katılımı kriterleriyle bir grup GitHub sorunu atabilirsiniz. Claude Code rutinleri ve Copilot/Codex bulut ajanları, özel bir altyapı olmadan size zaten planlanmış veya olay odaklı bir döngü sağlar.
Bir fabrika, tekrarlanabilir tutarlı çalıştırmalara, ajanlar arasında iş devrine, iki oturumun aynı sorunu üstlenmesini engellemeye, kanıtları saklamaya ve incelemeler geride kaldığında üretimi duraklatmaya ihtiyacınız varsa değerlidir.
Bu yüzden, bir yazılım fabrikasının yazılım işi etrafında tekrarlanabilir bir döngü olduğunu söyleyerek başladım. Aslında burada çok küçük bir fabrika döngüsünü gösteren bir istem görebiliriz:
Kodu değiştirmeden önce GitHub sorunu #123'ü ve depo talimatlarını okuyun.
Yalnızca belirtilen kabul kriterlerini uygulayın. Kimlik doğrulamayı, faturalandırmayı, geçişleri veya mevcut test iddialarını değiştirmeyin. Bir dalda çalışın ve farkın incelenebilir kalmasını sağlayın.
npm run lint, npm test ve npm run build komutlarını çalıştırın. Gerekli bir kontrol çalıştırılamazsa, durun ve nedenini açıklayın. Çalıştırdığınız kontroller, kalan riskler ve bir insanın hala vermesi gereken herhangi bir kararla birlikte bir taslak çekme isteği açın. Birleştirmeyin.
Bir hedef, kontroller geçene kadar bunu hareket halinde tutabilir ve her sabah belirli etiketler için GitHub sorunlarını sorgulayabilir veya açık çekme isteklerini inceleyebiliriz. Dal koruması bir birleştirme sınırı uygulayabilir ve insan, neyin hazır hale geldiğini seçerek, inceleyerek ve nihai birleştirme çağrılarını yaparak vb. döngüde kalabilir.
İzole bir bulut ortamında çalışacak, triyaj, uygulama ve bazı açık insan bakıcılığı ile test yapmak için olay odaklı bir iş kuyruğuna (ör. Slack tetikleyicileri, GitHub sorunları, Linear, bir backlog) ihtiyacınız olduğunda bir yazılım fabrikası ekleyin. Bazıları, döngülerini üretimi izleyen ve tekrar triyaj yapan sorunlar oluşturan bir monitör ajanıyla bitirir.
Deneyimlerime göre fabrika, farklı çalıştırmalarınızı tutarlı hale getirmek, ajanlar arasında iş devretmek ve farklı oturumların aynı sorunu talep etmesini önlemek, kanıtları korumak ve insan incelemesi geride kaldığında üretimi durdurmak zor olduğunda kullanışlı hale gelir.
Bunu çözen şey kulağa biraz sıkıcı gelebilir. Örneğin, Warp, gelen her sorunu dört durumdan birine ayırmaktan bahsediyor: uygulamaya hazır, spesifikasyona hazır, bilgiye ihtiyaç var, uygulamayı bekle - ve etiket bir sonraki ajanı ateşleyen şeydir.
Bu etiket aynı anda birkaç işi yapar: kuyruktur, kilittir ve bir oturum yalnızca hazır olarak işaretlenmiş olanı aldığından, bir insanın kalıcı olarak hayır demeden bir şeyleri park edebileceği yerdir.
İş akışı açısından, yalnızca Claude/Codex kullanmaya göre birkaç benzerlik ve farklılık vardır:
- Yönlendirme: ajanın rota düzeltmesine ihtiyacı vardır, girdi sağlayabilir ve onu yeniden yönlendirebilirsiniz
- Bildirimler: fabrikanın nasıl engellendiğini söylemesi. Bunun nedeni bir gereksinimin belirsiz olması, riskli bir şey başlatması veya insan girdisine (yönlendirme) ihtiyaç duyması olabilir.
- Devir: görevi, durumunu ve bağlamını bulut fabrikası/başka bir ajan/insan incelemecisi arasında taşıyın. İyi devirler, ne olduğunu, yapılması gerekenleri ve devrin neden gerekli olduğunu takip edecektir.
İyi bir fabrikada insan, yalnızca en sonda nihai farkı incelemek ve onaylamakla sınırlı değildir. Çalışmayı erken şekillendirebilir, uygulama sırasında yönlendirebilir, bir devirden geçirebilir veya üretime gönderilmesini durdurabilir.
Doğrulama, sorumlu bir fabrikanın zamanının çoğunu harcadığı yerdir. Bunu daha sonra daha ayrıntılı olarak ele alacağız.
Bir yazılım fabrikasına ihtiyacınız olduğuna karar verirseniz, onu inşa etmek tek seçenek değildir. Bir fabrikayı ölçeklendirmek için altyapı kurmak çok fazla iş olabilir ve satın alma ile inşa etme arasında düşünmek isteyebilirsiniz. Factory.ai, Devin, Warp ve HumanLayer bu döngünün bir kısmını satıyor.
Dikkatimi Gerçekten Nereye Veriyorum
Yazılım geliştirmeyle ilgili günlük deneyimim son bir yılda çok değişti. Ajanlarla giderek daha fazla paralel çalışma yapmaktan, ışıkları açık bir yazılım fabrikasına sahip olmaya doğru ilerlemekten bahsediyorum. Ve birçok insan bana, peki, bunlar gerçekte ne anlama geliyor? Ne inşa ediyorsun? Bunları ne tür projelerde kullanıyorsun? diye soruyor. Çoğunlukla şöyle:
Bu yüzden, çok ortalama bir günde, daha basit, ışıkları açık bir yazılım fabrikam var. Bulutta çalışan görevlerim olabilir. Bu görevlerin yarısı, birlikte çalıştığım daha küçük şirketlerin üretim istemci uygulamaları üzerinde çalışıyor olabilir. Gerçek kullanıcıları olacak. Gerçek kimlik doğrulamaları, ödemeleri, abonelikleri, dikkatli olmanız gereken gerçekten büyük riskleri olacak. Sadece "ajan, git şunları yap" deyip testler, kısıtlamalar ve kalite kontrolleri olmadan işi yapamazsınız.
Açık kaynak projelerim üzerinde çalışabilirim. Kitaplarım için yardımcı siteler oluşturuyor olabilirim. Araçlar üzerinde çalışıyor olabilirim. Kendi uygulamalarımı oluşturuyor olabilirim. Ve bunların hepsi üzerinde çalıştığım çok ama çok farklı türde uygulamalar. Ve bazen tek ortak noktaları, üzerlerinde çalışmak için kullandığım araçtır, değil mi? Belki bir geçiş üzerinde çalışıyorumdur. Diğer zamanlarda, gerçekten büyük özellik çalışmaları yapıyor olabilirim. Ve çalışmanın etki alanı da çok ama çok farklı olabilir.
Bu nedenle, giderek daha fazla paralel çalışma yaptığımız, hızı ve üretkenliği artırmaya çalıştığımız ve aynı zamanda özerkliği artırmaya çalıştığımız bir yere gelmeyi düşünmeye başladığınızda, bu, sisteme daha fazla güvendiğimiz bir yere gelmek anlamına gelir, kesinlikle insan kod incelemesi, insan girdisi gerektiren yerlerin neler olduğunu düşünmeniz gerekir.
Ve bunun büyük bir kısmı başlangıçta gerekli olacaktır, değil mi? Spesifikasyonunuzu, gereksinimlerinizi tanımlarken, ürünün tasarımı nasıl görünecek? Ürünün amacı ne olacak? Ve sonra ajanların işi gerçekten doğru yapıp yapmadığını nasıl doğruluyorsunuz? Mevcut sistemi bozmadıklarından nasıl emin oluyorsunuz? Kalite çıtanızı karşıladıklarından nasıl emin oluyorsunuz?
Ve bu nedenle, kod oluşturmak, en çok endişelenmeniz gereken kısım olmayabilir. Yeterli bağlam verildiğinde, ajanlar uygulamayı yazabilir, testleri çalıştırabilir, başarısızlığı inceleyebilir ve bizim için kodu revize edebilir. İnşa edilene güvenebilmemiz için, ortamda yeterince insan zevkinin kodlandığını hissettiğimiz bir yere gelmemiz gerekiyor, böylece insan dikkatimiz en çok ihtiyaç duyulan yerlere odaklanabilir.
Şimdi, bazı insanlardan, "bunların çoğunu otomatikleştirebileceğine inanmıyorum" diyen bir geri itme var. Hepsini otomatikleştirdiğimiz anlamına gelmiyor, değil mi? Ancak üretilen kod hacmi göz önüne alındığında, insanların hepsini okumasının gerçekçi olduğunu düşünmüyorum, özellikle de çoğu zaman roket inşa etmiyorken, değil mi? UI, full-stack uygulamalar inşa ediyoruz.
Muhakememiz, zevkimiz en çok ihtiyaç duyulan yerlere odaklanmak için en iyisidir. Sistemin en riskli kısımları nelerdir? İnsan zevkini nerede uygulamamız gerekiyor? Bu ön uçta olabilir. Sistemin nasıl çalıştığında olabilir. %100'ü olmak zorunda değil.
Bilişsel Bant Genişliğim Ajanlarla Ölçeklenmiyor
Gerçek şu ki, evet, şimdi düzinelerce, yüzlerce, binlerce ajantı paralel olarak başlatabiliriz, ancak kendi bilişsel bant genişliğiniz aynı şekilde ölçeklenmez. Bu, daha önce bahsettiğim bilişsel veya anlama borcuna yol açabilir.
Sadece beş, on yıl öncesini hatırlarsanız, mühendislik topluluğunda bağlam değiştirme ve bunun maliyeti hakkında çok fazla tartışma vardı. İnsanların, bir görevin ortasındayken bir meslektaşının veya birinin masanıza gelmesinden nasıl nefret ettiğinden bahsederdik. Akış durumunuza geri dönmeniz çok uzun sürerdi çünkü nerede kaldım? Ne yapıyordum? diye yetişmeniz gerekirdi. Biraz kalıntı olsa bile, yine de zaman alırdı.
Şimdi eskisinden daha fazla bağlam değiştiriyoruz. Herhangi bir günde, bir yazılım fabrikasının dışında çalışıyorsam, aynı anda beş veya on farklı projede ajanlarla çalışıyor olabilirim veya tek bir projede aynı anda beş veya on farklı özellik üzerinde çalışıyor olabilirim. Etkili bir şekilde beş veya on farklı oturumum olabilir.
Bu, bunlardan en az birkaçının üstünde kalmam gerektiği anlamına geliyor. Görevi yeterince iyi tanımladığıma, sonucu ve işin yeterince iyi yapıldığını nasıl doğrulayacağını tanımladığıma güveniyorsam, bazı görevlere verdiğim özerkliği artırmam mümkün. Ancak o zaman belki de aynı şekilde hissetmediğim ve daha fazla risk veya daha fazla nüans içeren görevler olacak. Dikkat etmem gerekecek.
Yazılım fabrikasını incelemeciniz için optimize etmeyi düşünün. Bu yaklaşımların her biri çıktısını hala bir kişinin dikkatine yönlendirdiğinden, fabrikanın hala vermeniz gereken kararları ne kadar daha ucuza getirdiğini sormalısınız.
Yanlış Proje Hatası
Ajanlarımla birden çok paralel proje üzerinde çalışırken, yanlışlıkla şöyle şeyler yaptığım zamanlar oldu: belki karanlık bir mod eklemek istediğim bir web uygulaması üzerinde çalışıyordum ve kafamda bunun şeklinin nasıl olması gerektiğini biliyordum. Ama yanlışlıkla farklı bir projenin oturumuna gittim ve aynı istemi koymaya başladım.
Bu yüzden kesinlikle ihtiyacı olmayan bir şey için karanlık mod uygulamaya başladım. Ve bu hatayı yapabilirim. Yazılım fabrikamın bu tür bir hata yapmasını istemiyorum.
Bunu gerçekten bir sistem açısından düşünmeniz gerekiyor. Etkili bir şekilde bir yazılım mühendisliği kültürünü, bir ekip kültürünü bir sisteme kodlamaya çalışıyorsunuz, böylece aynı tür davranışlara sahip olsun, bir yere ait bir sahiplenme olsun, olanlardan hala birinin sorumlu olması ve bu şeyler hakkında nasıl düşündüğünüz konusunda çok açık olmanız.
Yeşil Yanıltıcı Olduğunda
Bu sistemlerde bile çok dikkatli olmak istersiniz, değil mi? Birçoğumuz, bir testi geçmenize yardımcı olması için AI'dan istediğinizde, bir programlama testinden, bir birim testinden bahsediyoruz, bu koşulu karşılamak için birim testini değiştirebileceğini veya bu koşulu geçmek için kodun mantığını değiştirebileceğini gördük. Bu, aslında hem işlevsel davranışı hem de testin neyi test etmesi gerektiğini hizalamak için niyetinizi takip ettiği anlamına gelmez, değil mi?
Bir yazılım fabrikasının her şeyin yeşil olduğunu göstermesi, özellikle bunları ilk kurarken, gerçekten yeşil olduğu anlamına gelmez. Kontrollerinizin, doğrulamalarınızın hepsinin doğru şekilde şekillendirildiğinden emin olmak için çok dikkat etmeniz gerekir. Yapmalarını beklediğiniz şeyi yapıyorlar. Yanıltıcı olmalarını istemezsiniz.
"Hey, aslında hangi kimlik doğrulama sağlayıcılarının desteklendiğini değiştirdim" diyen testlerinizin olduğu bir durum istemezsiniz. Benden örneğin GitHub'ı bir kimlik doğrulama sağlayıcısı olarak eklememi istediniz, ancak UI'ımda yalnızca üç kişilik yer vardı, bu yüzden gittim ve diğerlerinden birini düşürdüm. Ve bu arada, bu, müşterilerinizin gerçekten istediği kişiydi. Bu yüzden, bu sistemlerin nasıl çalışmasını istediğiniz konusunda çok açık olmanız gerekiyor.
Bu arada güvenlik de çok önemlidir ve fabrikanız bir GitHub sorunu/Slack mesajı gibi güvenilmeyen girdileri okursa, düşmanca olabilir ve tedarik zinciri saldırıları gibi sorunlar içerebilir. Vercel Sandbox/AI ADK Factory gibi yazılım fabrikaları etrafındaki bazı ürünler, ajanlarını yalnızca bir görevin ihtiyaç duyduğu sırları tutan izole sanal alanlarda çalıştırır. Bu şekilde, tehlikeye atılmış bir çalıştırma, işin ihtiyaç duymadığı şeye ulaşamaz. Savunmanız katmanlı hale gelir.
Hangi Eski Projeler Başka Bir Hayatı Hak Ediyor?
Ayrıca bugünlerde nasıl çalıştığımızın büyük bir bölümünün neyin var olması gerektiğine karar vermek olduğunu düşünüyorum. Yapay zekadan önceki yılları hatırlarsanız, o kadar çok terk edilmiş yazılım mühendisliği projesi, o kadar çok terk edilmiş hafta sonu projesi, kişisel proje vardı ki, onları bitirmek için zamanımız olmadığı için başlatılamazdı. Onları çıkışa götürmeye öncelik verecek bant genişliğimiz yoktu çünkü bizim için o kadar önemli değillerdi ya da zaman bulamıyorduk.
Artık bu projeleri tamamlamak bizim için oldukça önemsiz, ancak aynı insan muhakemesi sorusu ortaya çıkıyor. Bu projeler var olmayı hak ediyor mu? Başlatılmalı mı? Çünkü onları dünyaya salıyorsunuz ve sadece beş kullanıcısı olsa bile, belki onu korumak zorundasınız. Belki şimdi korumak istediğiniz bir kalite çıtanız var.
Yıllar boyunca o kadar çok GitHub projem olduğunu biliyorum ki, şimdi bir ajanım olduğunda yaptığım ilk şey, şeyi derlenebilir hale getirmek. Çünkü, elbette, onu klonluyorsunuz ve şimdi tüm bağımlılıklar değiştiği için derlenmiyor. Yarısı güncel değil veya her yerde güvenlik açıkları var, bu yüzden onu güncellemeniz gerekiyor.
Ardından, projeyi bir şekilde yükseltiyorsanız veya daha modern bir dile veya çerçeveye veya benzer bir şeye geçiriyorsanız, davranışın en azından orada olacağını bilmek için testleriniz yoksa testler eklemeniz gerekir.
Sonra kendinize sormaya başlıyorsunuz, belki, aptalca bir örnek, ama belki bunun için geçmişte Twitter Bootstrap kullandım, ama şimdi herkes Tailwind ve shadcn kullanıyor, bu yüzden UI'ı yeniden uygulamam gerekiyor. Ve fark edeceğiniz şey, bunun aniden size daha fazla zaman aldığıdır, değil mi? Evet, ajan bunun çoğunu daha hızlı halledebilir, ancak şimdi ürün anlayışını, zevki ve tüm bu şeyleri hesaba katmak zorundasınız.
Hala sorguluyorsunuz, peki, bu kimin için? Bir pazarı var mı? Kendim için mi? Başkaları için mi? Eğer onu dünyaya salıyorsam, artık herkes bunları bu kadar hızlı bir şekilde döndürebildiğine göre, hala aynı derecede ilginç olacak mı?
Bu yüzden, bu şeylerin var olmayı hak edip etmediği sorusunun insani olduğunu düşünüyorum. Zevkimizi ve muhakememizi nasıl dahil ederiz? Bunların son derece önemli olmaya devam ettiğini hissediyorum. İnsan dikkatinin bu kıt kaynağının gerçekten devreye girdiği yer burasıdır. Geçmişte, günde yalnızca sınırlı sayıda saatimiz vardı. Toplantılarımız vardı. Tasarım, kodlama vb. için zaman ayırmamız gerekiyordu.
Artık bize yardımcı olacak ajanlarımız olduğuna göre, zamanınızı nerede ve neden harcadığınız konusunda gerçekten çok açık olmanız gerektiğini düşünüyorum.
Örnek Bir Tane İnşa Ettiğimde Ne Oldu
Bu yüzden 82 dakikalık fabrika çalıştırmasından bahsedeceğim. İnsanlar bana uzun zamandır "Bir yazılım fabrikasını nasıl inşa ederim?" veya "Claude Code veya Codex kullanmaya alışkınım. Kurulumumu bir yazılım fabrikası kullanmaya nasıl geliştiririm?" diye soruyorlar.
Bu yüzden söylediğim ilk şey, "İyi olabilirsin. İşin aslında bir fabrikaya ihtiyaç duymadan tamamen iyi olabilir." Ama insanlara inceleyebilecekleri bir referans kurulumu vermek istedim. Bu yüzden bir araya getirdiğim şey, gidip inceleyebileceğiniz Factory adlı bir depo. Ayrıca bir demo uygulaması ve atölye çalışması da hazırladım.
Şimdi, son birkaç yıldır, birçok şey için başvurduğum demo uygulamam bir film uygulaması oldu. Ben büyük bir film hayranıyım. Film izlemeyi severim. Her zaman film izlerim ve bu yüzden gerçekten çok basit bir film uygulaması olarak başlayan bir demo uygulamam var. Ve fabrikanın yapabilmesini istediğim şey, bir dizi özelliği uygulamaya devam etmesi. Birkaç farklı özellik var. Bir favoriler özelliği istiyorum. Belki arama yapabilmesini ve belki de karanlık bir tema eklemesini istiyorum, bu tür şeyler.
Bu yüzden fabrikam gidip bunlarla çalışmaya başlıyor. Uygulamayı inceleyebilirsiniz. Bunun faydalarından biri, gerçek sorunları yakalamasıydı. Bu sorunlar, sadece tek seferlik bir uygulama yapmasını istemiş olsaydım yakalayamayacağım şeyler olabilirdi.
Belki 60. dakika civarında, "Vay canına, bu alışılmadık derecede yavaş gidiyor" gibi hissediyordum. Fabrikayı kullanarak düzeneğime "Neden işler yavaş gidiyor?" diye sordum. "Bu aslında tamamen normal. Tüm doğrulayıcılar hala çalışıyor." dedi.
Bireysel görevlerin 10 dakika, 15 dakika, 20 dakika sürmesini bekleyebilirsiniz, ancak doğrulama, yeniden denemeler, tarayıcı kontrolleri, insan incelemesi, bu ekstra gecikmelerden herhangi birini dahil etmeye başladığınızda iki ila dört kat daha uzun sürebilir.
Bunların daha iyi kaliteye ve sisteme daha fazla güvene yol açabileceğini düşünüyorum. Ölçüm perspektifinden, birleştirilmiş PR başına maliyet ve kod raf ömrü gibi metrikleri anlama borcu metrikleri olarak inceleyebilirsiniz.
Ayrıca yararlı gecikme ile fabrika yükü arasındaki farkı da düşünmeniz gerekir. Doğrulayıcılar, benim durumumda, bazı gerçek sorunları yakaladı. Zamanın birazı, istediğim kanıtları üretmek için harcanmış olabilir. Bir kısmı da fabrikanın çalışmasındaki yüktü. Optimize etmek için gerçekten zaman harcamadım, ancak değerli bulmadığınız bir sürü kontrolü çalıştıran bir fabrika, yüksek kaliteli olduğu anlamına gelmez.
Tekrarlanan kontroller için, alakasız mı? Gürültülü mü? Sistemi gerçekten daha güvenli hale getiriyorlar mı? Bunu incelemek istersiniz.
Doğrulamanın Bir Bütçeye İhtiyacı Var
Doğrulama bütçesi hakkında düşünme şeklim, temelde bahsettiğimiz şey bu. Bir doğrulama bütçesinden bahsediyoruz. Bunu, tarihsel olarak performans bütçeleri hakkında düşündüğüm gibi düşünüyorum.
Yazılım geliştirme yaşam döngünüzün başlarında çalıştırabileceğiniz belirli türde kontroller olacak ve o kadar ağır olan ancak o kadar çok değer sunan bazı şeyler olacak ki onları daha sonra çalıştırmak isteyeceksiniz. Bazı hızlı kontroller vardır, örneğin linting, tip kontrolü. Bunlar, başlangıçta çalıştırabileceğiniz nispeten hızlı kontrollerdir.
Tam test paketimiz, bir taslak PR bir araya getirilmeden hemen önce veya sonra çalıştırılabilir. Bu, mutasyon testini, tarayıcı testini, güvenlik kontrollerini ve bunun gibi her şeyi içerebilir.
Bunları sadece özetlerle değiştirmek istemeyebileceğinizi düşünüyorum. Gerçek testler istersiniz, ancak geliştirme döngünüzü yavaşlatmak istemediğiniz için bunları doğru yerlere ayırdığınızdan emin olmanız gerekir. Geliştirme döngümü asla yavaşlatmak istemem. Hızlı bir yineleme döngüsüne sahip olmak benim için önemlidir, ancak yine de bu kontrol ve dengelere sahip olmak isterim.
Bir Çalıştırma Gönderilmediğinde
Yukarıda yazdıklarımın çoğu kontrollerle ilgili.
Vercel, yazılım fabrikalarında her ajan çalıştırmasını "başarılı", "kusurlu", "engellenmiş" veya "manuel" olarak işaretler ve yalnızca "başarılı" olanlar üretime gönderilir. Geri kalanı sisteme yeniden girer. Ben de çalıştırmaları benzer terimlerle düşünüyordum.
Burada "kusurlu", yanlış şeyin uygulandığı veya belki tam bağlama sahip olmadığı anlamına gelir, bu yüzden düzeltilmesi gerekir. Engellenmiş, ortamda bir kimlik bilgisinin eksik olabileceği, bu yüzden onu sağlamanız gerektiği anlamına gelir. Manuel, fabrikanın henüz geçmesine izin verilmeyen bir sınırdır.
Buradaki üç şeyden ikisinin mekanik düzeltmeleri olabilir ve sonuncusu güvenle ilgilidir.
Bu harika olsa da, sıralamanın size göstermediği şey maliyettir. TMDB uygulamasıyla fabrika uygulamama dönecek olursak, reddedilme olmadan hızlı bulucu 7 dakika sürdü. İki reddetme ve ortada bir insan kararı ile Favoriler 56 dakika sürdü. Aynı fabrika. Bu yüzden taksonomiyi aşama bazında zamanlama ile eşleştirirdim, aksi takdirde bir çalıştırmanın kusurlu olarak geri geldiğini bilirsiniz, ancak bunu öğrenmenin size ne kadara mal olduğunu bilmezsiniz. Düzelteceğim diğer şey, sınırdaki devirdir: örnek fabrikam ilk sorunu durdurdu ve onu factory:needs-info'ya taşıdı, bu doğruydu, ancak cevabımı nereye koyacağımı bilmiyordum. Manuel bir çalıştırma, fabrika durduğunda değil, insan bir sonraki adımda ne yapacağını bildiğinde biter.
Özerklik Tek Bir Ayar Değildir
Birkaç hafta önce ajan özerkliği ve özerklik hakkında nasıl düşünülmesi gerektiği hakkında bir makale yazdım çünkü özerklik her proje için tek bir ayar olmayacak.
Doğrulama size güven satın alır ve ajanlarınıza daha fazla özerklik verme yeteneği satın alır. Örneğin, önemsiz olmayan bir değişiklik üzerinde çalışıyorsam, ancak yerinde bir dizi kontrolüm varsa, her şey doğru bir şekilde doğrulanırsa ve belki de kendim elle kontrol etmişsem. Bir dahaki sefere aynı projede bunun gibi bir görev yapacağım zaman, belki ajana biraz daha fazla özerklik vermek konusunda rahat hissedeceğim.
Bu yazılım fabrikalarını inşa ederken düşündüğünüz şey budur. Doğrulamanız riskle değişecektir. Amacınız en iyi sinyal-gürültü oranıdır. Sadece çalıştırdığınız büyük bir kontrol listesine sahip olmak istemezsiniz.
Yeniden Öğrenmek Zorunda Kaldığım Özellik
Claude ile birden çok oturum kullandığım ve aynı anda birkaç farklı proje, proje başına birkaç farklı özellik üzerinde çalıştığım bir günde ertelediğim bir özellik vardı. Ve böylece Claude üzerinde çalıştığım özelliği uygulamıştı. Testler geçiyor gibi görünüyordu. Doğrulama hakkında çok fazla düşünmemiştim, ancak testler geçti ve bu yüzden çalıştığını düşündüm. Birleştirdim.
Ve bu bir favorileme özelliğiydi. Bunun aslında oldukça iyi olduğunu düşündüm. Tarayıcıda kontrol etmeye çalıştım. Sorun yok gibi görünüyordu, ancak birkaç gün sonra, bu konuda yapabileceğimi düşündüğüm bazı düzenlemeler olduğu için aslında koda geri döndüm.
Sadece ajandan değişiklikleri yapmasını istemek istemedim, çünkü çalışma şekli ince bir detaydı. Simgeye dokunuyordunuz ve dokununca doğru efekti göstermiyordu, ben de sadece küçük bir ayar yapmak istedim. Nasıl çalıştığını anlamak istedim ki ajandama doğru şekilde yön verebileyim.
Koda geri döndüm ve size bu özelliğin nasıl çalıştığını anlatamazdım. Bu depo benimdi, değil mi? Değişikliği onaylamıştım. Deponun büyük bir kısmının nasıl çalıştığını anlıyordum, ama anlayışım biriken tüm koda yetişememişti.
Anlayamadığım şey, eklenen bu özelliğin gerçekte nasıl çalıştığı, kullanıcı arayüzünün nasıl işlediği, üzerindeki efektin nasıl çalıştığıydı. Bu özelliği yeniden yapmak ve adım adım ilerlemek zorunda kaldım: "Bu nasıl çalışıyor? Bunu nasıl anlayabilirim?"
Paralel çalışmanın anlayışa etkisi
Paralel çalışma yaptığınızda, bu genel sorunu daha da büyütür ve bunu bir yazılım fabrikasında yaptığınızda işler daha da karmaşık hale gelir. Beş veya on oturum yaptığınızda, bu sadece bir inceleme hacmi sorunu yaratmaz. Başka yerlerde çalışırken soğuyabilecek birkaç zihinsel model oluşturur.
Tarihsel olarak bağlam değiştirmenin zorluklarından bahsettik ve sohbet daraldığında, bazı yaklaşımları reddedersiniz, farklı şeyler denersiniz, ajanla eşleşirsiniz ve oturumunuzda olan her şeyi hatırlamakta zorlanırsınız.
Yukarı kaydırabilirsiniz, ancak daralma devam ederken her şey orada olmayacak ve hepsini kafanızda tutamayacaksınız. Kod genellikle alınan bir kararı korur, ancak kararın neden alındığını korumaz.
Bence bu sizin için faydalı bir ders olabilir; ajandanızdan, izlediği yörünge hakkında veya bir soruna nasıl yaklaştığına dair ilginç dersler hakkında bilgi depolamasını istemeyi düşünmeniz önemlidir, böylece daha sonra geri dönebilirsiniz.
Bu, depoya işlemeyi seçebileceğiniz veya seçmeyebileceğiniz bir şey olabilir. İsterseniz yerel olarak tutabilir, isterseniz bir ekiple paylaşabilirsiniz, ancak bu daha sonra başvurulabilecek bir şey olabilir. Bir oturumda olmasına veya daha sonra hatırlamanıza güvenmektense.
Peki gerçekte ne üretiyor?
@threepointone ve @bentlegen, yazılım fabrikaları hakkında şiddetle katıldığım bazı görüşler paylaştılar:
Yapma makinesine hayran olmak, makineyi optimize etmek ve ne üretmesi gerektiğini unutmak kolaydır. Fabrikanız çoğunlukla daha iyi bir fabrika üretiyorsa, ürünü kendisi olan bir yazılım inşa etmişsinizdir.
Döngüye yatırım yapmanın iyi olduğunu ve bileşik getiri sağladığını düşünüyorum. Başarısızlık, döngü kapandığında, fabrikanın ürettiği her şey fabrika tarafından tüketildiğinde ve onu kapatsanız dışarıdaki hiç kimse fark etmeyeceğinde ortaya çıkar. Uygulayacağım test çekme olurdu. Dışarıdan bir şeyin iyileştirmeyi talep etmesi gerekir. Kimin çektiğini söyleyemiyorsanız, cilalıyorsunuz demektir.
Sahiplik ortadan kalkmaz
Tüm bunların altında daha geniş bir ilke yatıyor.
Fiziksel olarak insanlar tarafından yazılan kodun yüzdesi önemli ölçüde düşebilir. İnsan sahipliğinin de bununla birlikte düşmesi gerektiğini düşünmüyorum.
- Birisi hâlâ sorunu seçiyor.
- Birisi hâlâ mimariyi seçiyor.
- Birisi hâlâ kalite çıtasını belirliyor.
- Birisi hangi doğrulama sinyallerinin güveni hak ettiğine karar veriyor.
- Birisi, kanıtların yayınlamak için yeterli olduğuna karar veriyor.
Ve ortaya çıkan sistem başarısız olduğunda, "ajan yazdı" mazereti geçerli değil. Bu nedenle yazılım mühendisliğinin geleceğinin en iyi şekilde insanların döngüden çıkması olarak tanımlandığını düşünmüyorum. Bunun yerine, insan yargısı yeniden konumlandırılıyor.
İnsanları, makinelerin daha güçlü, daha hızlı, daha deterministik sinyaller üretebildiği döngü bölümlerinden çıkarmalıyız. Aynı zamanda, insanları bağlam, zevk, risk ve uzun vadeli sahipliğin en önemli olduğu yerlere yoğunlaştırmalıyız.
En iyi yazılım fabrikaları, insan katılımını ne kadar tamamen ortadan kaldırdıklarıyla tanımlanmayacak.
İnsan yargısını, niyet, sistem şekli ve kalite çıtası konusunda yukarı akışta tutun. Otomatik geri basıncın zayıfladığı veya sonuçların öznel hale geldiği yerlerde kodu inceleyin. Her deterministik sinyali mümkün olduğunca erken ve sürekli olarak döngüye itin. Sistem güven kazandıkça veya kaybettikça kısıtlamaları bilinçli olarak sıkılaştırın ve gevşetin.
Bir insan, sonuçta hangi kodun yayınlanacağına sahip olmak zorundadır. Yayınlanacak kadar iyi kod, hâlâ var olup olmaması gerektiğini önemseyen biriyle başlar.
