Fabbriche software, luci e ombre

Una software factory è un ciclo di lavoro sfruttato su larga scala. Puoi eseguire il ciclo con esseri umani all'interno (light factory): scambiando giudizio e concentrazione con velocità e rotture. Oppure puoi ignorare gli umani (dark factory) e lasciare che quegli agenti definiscano l'ambito, costruiscano e distribuiscano codice, senza che nessuno legga davvero i dettagli. Ma se le persone smettono di leggere, smetteranno di capire il tuo software. Il tuo compito più difficile ora è sapere quali controlli costruire e quanta autonomia delegare.

Questa idea di software factory è un termine che risale al documento di Bob Bemer, "The economics of program production", presentato nel 1968. Per mezzo secolo, molti hanno sognato un mondo in cui il software sia un processo di produzione ripetibile e strumentabile (analogo allo stampaggio di parti di auto in una fabbrica) piuttosto che l'artigianato isolato di individui. Storicamente, questo sogno è generalmente (anche se non universalmente) fallito, in parte a causa della difficoltà di stampare idee.

Ma negli ultimi due anni, le cose sono cambiate così drasticamente che ora ha senso dare un'occhiata nuova al vecchio sogno. E poiché alcune sottigliezze possono essere facilmente trascurate, vale la pena essere un po' precisi su cosa sia veramente nuovo e diverso, e cosa possano essere trappole ricorrenti, vestite da nuove opportunità.

@dexhorthy, co-fondatore di HumanLayer, ha recentemente tenuto un grande intervento all'AI Engineer World's Fair intitolato "Harness Engineering is not Enough: Why Software Factories Fail." che vale la pena vedere su questo argomento.

Il ciclo è l'atomo. La fabbrica è il ciclo su larga scala.

La struttura è tutto, e tutto inizia con piccole unità. L'intero stack è in realtà tre concetti sovrapposti: il ciclo, l'harness e la fabbrica.

Un ciclo è un agente che esegue un singolo lavoro in modo ripetitivo: raccogliere il contesto, compiere un'azione, controllare il risultato e ripetere fino a quando una condizione è soddisfatta. È l'unità più piccola di lavoro agentico, e tutto ciò che sta sopra sono solo cicli impilati su altri cicli.

Lo scopo del loop engineering è smettere di dare istruzioni all'agente turno per turno e invece progettare il piccolo sistema che lo istruisce per te.

Un harness è il perimetro attorno a un ciclo: la sandbox in cui viene eseguito, gli strumenti a cui può accedere, la memoria che sopravvive tra le esecuzioni e i cancelli che decidono cosa significhi "fatto". Il ciclo è il comportamento; l'harness è l'ambiente in cui quel comportamento viene eseguito.

Dai a un modello grezzo nessun harness e girerà felicemente all'infinito. L'harness è tutto ciò che lo circonda e lo rende utile e sicuro da eseguire.

Una software factory è molti cicli harnessati eseguiti contemporaneamente, alimentati da una coda di lavoro e drenati attraverso un cancello di revisione in produzione, con gli umani che possiedono il tutto dall'alto. Non è un agente più grande; è un organigramma fatto di cicli.

Il cambiamento di paradigma finale è passare dallo scrivere codice al costruire e gestire la fabbrica che lo scrive. L'unità di lavoro si sposta a un livello superiore, sul ciclo, l'harness e il flusso tra di loro, piuttosto che sul singolo diff di codice.

Ciclo → harness → fabbrica. Una fabbrica non è un agente più intelligente; sono molti cicli harnessati che alimentano un unico cancello di revisione, con un umano che possiede il ciclo esterno. La fabbrica, disegnata

La diapositiva centrale su cui Dex ha passato più tempo era brillante perché è un diagramma di cablaggio chiarificatore che visualizza ciò che altrimenti è un ciclo ovvio. Ecco la mia interpretazione:

La fabbrica è un ciclo chiuso: l'intento e i segnali di produzione alimentano una coda, l'harness costruisce, i controlli automatizzati e il cancello di revisione la esaminano, il deploy la distribuisce, il monitoraggio trasforma la produzione in segnali. L'intento fluisce dalla visione della leadership ingegneristica e direttamente dagli ingegneri, in una coda di cose da fare. I segnali guidati da incidenti e richieste degli utenti alimentano la stessa coda.

L'harness è semplicemente la cosa che prende un elemento dalla coda e costruisce una modifica per esso. Oltre l'harness, possiamo vedere tutti i controlli automatizzati necessari per rendere le modifiche sufficientemente sicure da essere inserite in produzione. Questi controlli automatizzati vengono eseguiti contemporaneamente, senza sforzo, senza alcun coinvolgimento cosciente degli ingegneri, grazie a CI, test, analisi statica e scansione di ogni tipo. L'unico punto decisionale qui è il cancello di revisione. Dopo l'approvazione, le modifiche vengono distribuite e monitorate in produzione, con i dati di monitoraggio che retroalimentano i segnali che hanno avviato il ciclo.

In generale, ogni riquadro in questo diagramma ha un costo quasi zero: generazione, test, scansione. Tutti girano su larga scala a un costo trascurabile. C'è solo un riquadro costoso che si dimostra ostinatamente resistente al ridimensionamento, ed è il cancello di revisione. Quel lucido riquadro ambrato è "giudizio", e qui risiede il punto cruciale del dibattito su se possiamo rendere lo sviluppo più veloce e frequente.

Perché lo chiamiamo "oscuro"

Una fabbrica oscura funziona con le luci fisicamente spente, perché le uniche cose sul pavimento sono macchine e le macchine non hanno bisogno di luce per vedere. Una software factory oscura è la stessa mossa: codice distribuito che nessun umano ha letto, verificato solo da altre macchine.

L'immagine è presa in prestito dalla produzione manifatturiera. Le sue origini sono fisiche piuttosto che digitali, radicate in impianti dove le luci sono spente e il lavoro è svolto da robot. FANUC in Giappone gestisce fabbriche lights-out di questo tipo dal 2001; Xiaomi, nel 2024, ha aperto una sua fabbrica oscura pesantemente automatizzata. Ciò che hanno in comune è un prodotto assemblato e spedito senza che un singolo umano ne abbia letto nulla. L'"oscuro" arriva quando quell'atto di lettura viene rimosso dal processo.

Non prendo in prestito il concetto per la sua atmosfera o come insulto. Nonostante tutto il suo fascino inquietante, "oscuro" qui è una semplice affermazione fisica: il pavimento originale della fabbrica, ma senza luce. Nel software, il pavimento è il diff. Chiunque abbia scritto il diff, chiunque lo abbia revisionato, chiunque lo abbia distribuito, quegli umani sono spariti, e ciò che rimane è un diff verificato solo dalle macchine che lo hanno costruito.

Questa è una cosa sorprendentemente facile da fare, almeno all'inizio. È facile perché quel passaggio di revisione mancante intralcia tutto. La sua assenza fa sembrare la percezione della produttività verticale del tuo team improvvisamente e radicalmente più alta. Sembra di aver superato la barriera del suono. Nonostante tutta la sua apparente facilità, è più difficile di quanto sembri sopravvivere a quei flussi di lavoro oscuri, con tutti i loro costi nascosti.

L'ingegneria dell'harness non è sufficiente

L'harness di orchestrazione, prototipazione in sandbox e chiamate a strumenti mentre i modelli interagiscono con il mondo e tra loro diventerà sempre più potente ed efficace. Tuttavia, c'è un fallimento intrinseco al modello nel cercare di tenere il passo con la qualità del codebase nel lungo termine e attraverso modifiche aggiuntive, e penso ci siano buone ragioni per credere che i soli modelli perderanno alla fine quella battaglia contro il debito di comprensione.

Il debito di comprensione è il divario crescente tra quanto codice esiste e quanto un essere umano ne capisce ancora. Una fabbrica oscura non lo ripaga; lo contrae il più velocemente possibile, con i test che rimangono verdi per tutto il tempo.

Questa è una distinzione importante perché i modelli sono bravi in alcuni compiti. Ma per tutto ciò che non è una modifica immediata a una piccola parte di un codebase, specialmente in un sistema brownfield complesso, la codifica automatizzata basata solo su modelli affronta un ostacolo insormontabile. Le app greenfield, i giocattoli del fine settimana e i progetti secondari sono simili in quanto pochi mesi di cicli di sviluppo sono solitamente sufficienti per mettere le cose in ordine di funzionamento, o almeno abbastanza vicine.

Ma un sistema aziendale che è stato in sviluppo per un decennio o più è una bestia diversa; deve essere mantenuto, in un ambiente professionale a un ritmo professionale. Da tre a sei mesi dall'inizio di un progetto, stai già annegando in codice non letto. Quel tipo di ambiente, e specialmente i vincoli imposti dal codice di produzione, farebbero male anche a un agente potente, tutto in contrasto con la vibe-coding di cui godono gli sviluppatori che lavorano su giocattoli del fine settimana.

Dex riferisce per esperienza che questo è un grave fallimento, tanto da richiedere un meticoloso debugging manuale per essere individuato. Questo è derivato dalla gestione di una fabbrica di codice completamente automatizzata per circa quattro mesi, durante i quali nessun umano ha guardato il codice scritto. Alla base dell'esperienza c'è un compromesso tra due metriche contrastanti. Una è massimizzare l'utilizzo dei token, il numero che attualmente trattiamo come progresso. L'altra, che minimizza silenziosamente, è la quantità di sistema che qualsiasi partecipante umano ancora capisce in un dato momento.

Dove la fabbrica oscura brilla davvero è nella sua capacità di bruciare codice pulito mentre i test rimangono verdi. La resa dei conti finale, quando arriva, non sarà un momento drammatico di "tutto va a rotoli". Sarà silenziosa e tardiva.

Oscuro e illuminato sono la stessa pipeline con le luci in posti diversi. La versione illuminata non si limita a riaggiungere la revisione alla fine: sposta il giudizio umano a monte, anche nella progettazione e nell'architettura. Il collo di bottiglia non è mai stato la generazione

Il vincolo fondamentale in una software factory non è quanto codice possiamo sfornare: è quanto velocemente possiamo verificarlo.

La contropressione è la regola per cui puoi dare a un ciclo solo tanta autonomia quanta puoi verificare in modo economico e affidabile, e non un centimetro di più. La verifica, non la generazione, è il vero vincolo di una fabbrica.

Poiché la capacità illimitata di generazione è in perpetua tensione con la risorsa finita e non scalabile dell'attenzione umana, il problema centrale è il divario tra generazione a basso costo e revisione limitata. Guarda l'imbuto: fintanto che il collo che rappresenta la verifica non si allarga, si formerà un ingorgo. Come sottolinea Dex, il volume da solo non è il problema: ciò di cui soffriamo realmente è un surplus di PR scadenti. Quando hai volume elevato senza cancelli affidabili, i difetti di fabbricazione sono inevitabili. Questo è ancora contropressione: l'autonomia non può espandersi oltre ciò che può essere verificato in modo economico e affidabile.

Il problema di secondo ordine è perché migliorare il modello non dovrebbe automaticamente chiudere il divario tra ciò che può generare e ciò che può essere verificato. Addestrare su sistemi ben architettati è una proposta presumibilmente più difficile che superare semplici test: ricorda, le funzioni di costo che misurano l'eccellenza architettonica non si misurano in secondi o addirittura minuti, ma in mesi e anni. Gradienti puliti sono funzionalmente impossibili da calcolare, quindi un sistema che si aspetta una valutazione nitida e istantanea di decisioni di progettazione complesse non verrà addestrato su buoni esempi.

La generazione è una bocca larga; la verifica è il collo stretto. Accelerare la bocca approfondisce solo il mucchio al collo.

Riaccendere le luci

Una fabbrica illuminata è la stessa pipeline con le luci accese dove risiede il giudizio. Gli agenti fanno ancora la maggior parte della costruzione, ma un umano legge ciò che esce prima che venga distribuito, e le luci rimangono accese ovunque una decisione sbagliata sia costosa.

La versione illuminata non aggiunge la revisione alla fine, ma sposta il punto del giudizio umano a monte, sul prodotto, la progettazione e l'architettura prima che un agente inizi un ciclo.

Una cosa grandiosa di quell'ora iniziale è che porta a meno ore di implementazione. Trasforma una lunga e frustrante revisione del codice in una rapida lettura di un piano di duecento righe. Puoi rivedere una decisione prima che venga costruita, così dopo non devi rincorrere duemila righe di codice generato per scoprire quale fosse la decisione. Alcune decisioni sono costose e di lunga durata, tanto da volere una persona coinvolta presto, prima che il costo si accumuli. Naturalmente, ci sono ancora momenti in cui guardi i diff, anche quando hai speso tempo in anticipo.

Potresti pensare che tutto ciò suoni poco affascinante. Hai ragione. La rete di sicurezza è composta da pratiche architettoniche perfettamente ordinarie che abbiamo sempre conosciuto e per lo più ignorato: buoni tipi e firme di metodo in modo che gli errori vengano catturati dal compilatore invece che in produzione; punti di sutura per i test dove possiamo bloccare il comportamento e rendere il cambiamento osservabile; disporre il codice in modo che il prossimo lettore, umano o modello, sappia dove trovare ciò che gli interessa; mantenere gli stack di chiamate brevi e leggibili; mantenere i confini dei componenti ben definiti in modo che una modifica non abbia un enorme raggio d'esplosione; e l'iniezione di dipendenze in modo da poter sostituire un pezzo con un altro. Niente di tutto ciò è nuovo. Abbiamo sempre detto che ci importa della buona architettura. Ma ora che stiamo usando agenti di codifica automatizzati, quell'architettura sta finalmente svolgendo un secondo lavoro come rete di sicurezza economica e difficile da falsificare contro gli errori che l'agente commetterà.

Quella rete di sicurezza deve vivere al di fuori del modello, perché il modello non la fornirà. Gli agenti di codifica che sembrano più capaci, tra cui Claude Code e Codex, sono addestrati con rinforzo contro il proprio harness e i propri strumenti: fluenti con tutti gli strumenti e gli idiomi del mestiere, ma non con cose come la manutenibilità a lungo termine. L'architettura deliberata di cui abbiamo sempre parlato è lo strumento che cattura quel debito, e l'investimento che facciamo in essa è il nostro modo di ricomprare la nostra autonomia.

Metti tutto insieme a un'infrastruttura sicura, e ci sono alcuni cicli stretti e a basso rischio che puoi eseguire senza supervisione. Horthy ne ha descritto uno in un post recente: un cron notturno di GitHub Actions che corregge esattamente un anti-pattern, una violazione di lint o una prop inutilmente opzionale, fa il commit e apre una piccola pull request, tutto da solo, così il team si sveglia con un codebase leggermente migliore e un diff abbastanza corto da leggere. Ma per cicli con posta in gioco abbastanza alta, non vuoi rischiare di svegliarti con un sistema di autenticazione rotto, un motore di fatturazione o un contratto API pubblico. Tieni le luci accese lì, e fidati che una persona con giudizio e una reale conoscenza operativa del sistema catturerà l'errore.

Cosa guadagna a un ciclo l'essere oscuro

Questa regola si applica sia che tu la chiami contropressione, verifica o interruttore della luce.

Un ciclo può guadagnarsi lo stato completamente automatizzato solo se il controllo è economico, viene eseguito ad alta frequenza e si basa su qualcosa che non può essere facilmente falsificato. Oracoli verde/rosso, cancelli di tipo, test di proprietà e un agente di revisione accoppiato con una rubrica reale sono tutti adatti. Hai anche bisogno che l'oracolo risponda immediatamente e non si sposti nel tempo. Quando "fatto" può essere dimostrato non solo da te ma da una macchina, hai raggiunto l'automazione.

I cicli brevi sono più facili da verificare di quelli lunghi. La regola pratica di Dex: un agente regge per tre-dieci passi, poi inizia a perdere il filo oltre venti. Il motivo è l'accumulo di contesto: più l'agente trascina, più è probabile che si allontani. Quando un ciclo è breve, verificarlo è economico. I cicli estesi nascondono errori negli angoli, il che è un altro modo per dire che non hanno mai guadagnato lo status lights-out.

Tenere le luci accese è il caso opposto. Un ciclo deve essere revisionato se una risposta sbagliata è costosa e solo una persona può individuarla. Bug di produzione sottili che non possono essere catturati dai test, grandi raggi d'esplosione e una decisione che darà forma al lavoro di un anno o più sono tutti qualificanti. In questi casi, la tua attenzione è il prodotto reale, quello costoso ed essenziale.

Il pericolo è dimenticare di azionare ogni interruttore e impostarli tutti sulla stessa modalità. Tutto oscuro, e sei bloccato a smantellare tutto quattro mesi dopo. Tutto illuminato, e nessuno riesce a fare le revisioni in tempo e sei bloccato in un gigantesco collo di bottiglia. Il lavoro difficile e qualificato è decidere dove mettere ogni interruttore.

Cicli, grafi o macchine a stati?

Dovresti leggere "State machines in 2 minutes" di @DavidKPiano

Quando affidi un compito a un agente, probabilmente costruirai un grafo attorno ad esso, sia che tu chiami quel grafo una macchina a stati finiti o un insieme di chiamate di servizio collegate condizionalmente. È una cornice in cui il software non segue solo regole astratte, ma un flusso di lavoro strutturato: ogni nodo è un passo esplicito, e ogni bordo tra nodi è una condizione esplicita.

Sembra molta struttura, ma la maggior parte è già presente in qualsiasi software, poiché qualsiasi codice può essere espresso come un grafo di flusso di controllo. Quindi l'unica vera novità è che un agente che insiste sull'autonomia sta in realtà solo camminando all'interno di un particolare grafo, e la sua libertà è limitata all'interno di un nodo. Ed ecco la parte che la gente dimentica, che Dex ha scritto un anno fa: il software ha sempre avuto quella struttura. C'è un motivo per cui un tempo disegnavamo i programmi come diagrammi di flusso.

La mossa veramente nuova è stata cercare di buttare via il diagramma, affidandosi a un ciclo in cui il modello sceglie il percorso chiamata di strumento dopo chiamata di strumento, finché non si dichiara finito. Sembrava una liberazione, fino a quando non ha incontrato un codebase di dieci anni, e la disciplina che tutti stanno riscoprendo ora, possedere il proprio flusso di controllo, è in realtà solo riportare il grafo attorno al ciclo. Quindi la domanda se dovremmo passare dai cicli ai grafi è quasi un'ammissione che avevamo bisogno del diagramma di flusso fin dall'inizio.

Ecco come appare in pratica. Prendi un bug da correggere. Come ciclo puro, ti siedi e pensi: capire cosa c'è che non va, modificare un po' di codice, eseguire i test, vedere cosa succede, e se quel round non risolve il problema, ripetere e ricominciare. L'intero percorso è deciso strada facendo: quale problema inseguire, il codice esatto da modificare, quali test eseguire e in quale ordine, se eseguire i test o meno, e se riprovare o dichiarare vittoria.

Come grafo, la prima cosa che fai è mappare cosa dovrebbe succedere. Riprodurre il bug o chiedere maggiori informazioni, trovare la causa, provare una correzione, eseguire i test, e lasciare che un'esecuzione fallita torni alla correzione mentre una superata proceda alla revisione, dove solo un'approvazione raggiunge lo stato "fatto". L'agente è ancora intelligente all'interno di ogni riquadro; semplicemente non può allontanarsi dai percorsi che hai sanzionato. Santi ha illustrato questo con un diagramma che rende la differenza ovvia.

Il vero fascino di quel grafo, ovviamente, è che è contropressione disegnata come diagramma. Rinunci a un po' della libertà dell'agente e ottieni in cambio controlli obbligatori e punti di fallimento leggibili, così quando un'esecuzione muore, puoi puntare al nodo che l'ha uccisa. È lo stesso istinto dietro l'osservazione schietta di Dex che la maggior parte dei cosiddetti agenti non sono affatto molto agentici, "codice per lo più deterministico, con passaggi LLM spruzzati nei punti giusti". E questo non è solo un artefatto di come le persone stanno costruendo le cose in questo momento: puoi vedere lo schema in LangGraph e LlamaIndex Workflows, nel flusso di lavoro ibrido grafo-su-agenti di Jerry Liu con un ciclo esterno che fa crescere parti del grafo mentre viene eseguito, e nel promemoria di David Khourshid che questa è in realtà solo macchine a stati e il modello attore che si ripresentano con nuovi vestiti.

Una precisazione, perché il termine è pesantemente sovraccarico: quando continuo a chiamarlo grafo, non intendo un grafo della conoscenza. Intendo un grafo diretto predefinito di come il lavoro dovrebbe fluire, bordi condizionali inclusi, dando al ciclo una forma di cui puoi effettivamente fidarti.

Dove va effettivamente l'umano

Nota che la persona non ha mai lasciato la fabbrica. Si è spostata.

Penso che gli ingegneri debbano sempre più possedere il ciclo esterno. Gli agenti possono investigare un bug, scrivere la diagnosi, implementare una correzione, eseguire i test e scrivere un rapporto. Questa è l'esecuzione del ciclo interno, e possono farlo in modo efficiente come chiunque altro. Ma quello non è mai stato il lavoro. I pezzi che possiedi sono ciò che chiamerei il ciclo esterno: decidere se è il modo giusto di affrontare il problema, verificare che la diagnosi e l'implementazione siano valide, approvare la modifica e portare le conseguenze di essere in errore. Il confine tra i due cicli è l'evidenza, i diff, i test, i log e una breve spiegazione che li collega. Tipi, punti di sutura e rubriche rendono possibile supervisionare tutto questo senza fare molto lavoro per ogni modifica.

È utile metterla così: non sei più giù sulla linea a scrivere modifiche; sei su alla fine della linea di produzione a progettarla e a custodire il cancello. C'è molto che puoi fare per migliorare il modello e rendere l'harness più capace, ma ho osservato che identificare problemi costosi a lungo termine non è tipicamente qualcosa che puoi automatizzare. La cosa centrale che è ancora il lavoro è esercitare il giudizio umano meglio di qualsiasi flusso di carta e potenza di calcolo.

I robot funzionano bene nell'oscurità, ma gli umani hanno bisogno di vedere cosa stanno facendo. Se tutto sul pavimento della fabbrica è oscuro, e non puoi vedere nulla, e non riesci nemmeno a trovare l'interruttore della luce, è lì che sta il pericolo.

Pangram ha valutato questo articolo come scritto al 100% da umani.