Perché le Software Factory falliscono

oppure: l'imbragatura non basta

Aggiornamento – la versione talk di questo post è disponibile su YouTube: https://www.youtube.com/watch?v=Ib5GBkD555M

pare che stiamo facendo loop

Stiamo tutti correndo per mettere in produzione il coding con l'AI. Si è parlato molto di loop engineering, e la saggezza prevalente è che dovremmo probabilmente scrivere più loop.

StrongDM ha scritto della loro software factory senza luci accese dove nessun umano legge codice e nessun umano scrive codice.

La narrazione è più o meno questa:

1. Tu sei il collo di bottiglia.
2. I modelli sono abbastanza bravi.
3. Il codice è gratis.
4. Basta che spedisci più roba.

Ryan Lopopolo di OpenAI ne ha scritto a febbraio e ha tenuto un talk ad aprile sulla software factory di OpenAI, Symphony.

Queste persone sono tutte davvero intelligentissime e le rispetto molto. Ma la lettura più cinica qui sarebbe chiamarla un'altra scusa per pompare più soldi VC nel cannone della spazzatura.

va... ehm, va

Il nostro amico Mario è salito sul palco ad AI Engineer Europe e ci ha implorato di rallentare – perché aziende che non dovrebbero subire interruzioni a causa di incidenti con agenti di coding, beh... stanno subendo interruzioni a causa di incidenti con agenti di coding.

Come ha detto Matt Pocock, i codebase stanno cadendo a pezzi più velocemente che mai.

Non sono riuscito a trovare dati/conclusioni definitive da StrongDM su come sia andata quella fabbrica oscura. Il weather-report ha pochi aggiornamenti sparsi tra febbraio e giugno di quest'anno. edit – c'è una conversazione con il team su hacker news il 23 luglio – sembra che potremmo avere presto un aggiornamento più formale!

I ragazzi di Faros AI hanno pubblicato un report: da quando2 abbiamo tutti adottato questi strumenti di AI coding a gennaio e febbraio, la qualità delle revisioni delle pull request è calata drasticamente.

• Più commenti, commenti più lunghi, e un sacco di PR unite senza alcuna revisione.
• Gli incidenti sono aumentati.
• I bug per sviluppatore sono aumentati.

Questo report è più un segnale di correlazione che una pistola fumante verificabile (sì, ho scelto quella parola apposta, non fatemi iniziare sulla prosa di Claude), e il punto centrale di questo post è diffidare dei dati spazzatura, ma sembra direzionalmente valido in base a ciò che ho visto.

"Lo stai tenendo male" (non è vero)

Molti ti diranno che è un problema di skill – che se non ottieni buoni risultati, è colpa tua.

Ma comunque tu scelga di... ehm... tenerlo, ti garantisco che ti stanno dicendo che se il token-maxxing non funziona per te, è un problema di skill. Devi solo spendere più token. Lascia perdere la lettura del codice. E se ci stai arrivando ora, ti prometto che fa parte del percorso. Anch'io la pensavo così l'estate scorsa.

Purtroppo per il mio ego, alcune cose stupide che ho deciso di dire su "come tenerlo meglio" sono state registrate e ora hanno circa un milione di visualizzazioni cumulative su YouTube. Non sto cercando di vantarmi, condivido questo solo per stabilire che sto approfondendo da molto tempo i modi migliori per usare gli agenti di coding, e ho scoperto alcune cose che molti altri hanno trovato genuinamente utili.

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed – Solving Hard Problems in Complex Codebases
• Everything We Got Wrong About RPI

Comunque, La promessa di tutto questo parlare online di "spingi più token" che siamo stati costretti a sopportare è, in sintesi: con abbastanza harness engineering, possiamo ottenere il meglio di entrambi i mondi:

• da 10 a 100 volte più veloce,
• alta qualità, e
• nessuno deve mai più fare quella cosa che tutti odiamo chiamata code review

Tutto ciò che dobbiamo fare è configurare più linter e spargere alcune parole magiche come "revisione avversaria" su abbastanza bot di revisione delle PR, e il nostro software si costruirà felicemente da solo senza incidenti.

Non è un problema di skill

Quello che cercherò di convincerti è che nessuna quantità di harness engineering o loopsmaxxing può risolvere ciò che è fondamentalmente un problema di training del modello.

Per affrontare questo, ho dovuto approfondire come i modelli di coding vengono effettivamente addestrati e valutati – sia per quanto riguarda RLVR che per il lato dei benchmark.

In questo post esaminerò:

1. Le software factory risalgono al 1968, come si sono evolute e come l'AI le ha cambiate
2. Perché i modelli possono generare montagne di spazzatura nonostante eccellano nei benchmark (anche i nuovi benchmark "di frontiera")
3. Nonostante questo, puoi muoverti abbastanza velocemente senza incendiare il tuo codebase

Cercherò di tagliare attraverso l'hype di ogni plugin di skill emergente quotidianamente e la pandemia di consigli di ai-psicosi-tokenmaxxing, e parlare in termini generali dei tipi di cose che funzionano senza fare riferimento a nessuna skill o framework specifico.

Versione video: questo post è basato (e amplia) il mio keynote all'AI Engineer World's Fair 2026.

Grazie a @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, e @jeffreyhuber per il feedback su questo post.

Una parentesi: questo non ha niente a che fare con il vibe coding

Addy Osmani ha districato questa cosa che vale la pena evidenziare:

Uno sviluppatore che fa vibe coding di un progetto personale che una dozzina di persone userà mai, e un team che tiene in vita un sistema enterprise decennale per un altro trimestre, condividono quasi zero vincoli che valga la pena nominare, e la maggior parte dei consigli in circolazione è in realtà uno di quei due che dice all'altro come vivere.

Se ami il vibe coding, per favore, continua a vibrare. Io faccio ancora vibe coding di molte cose, solo che mantengo anche molto software di produzione (e tramite HumanLayer, aiuto migliaia di altri ingegneri a fare lo stesso), quindi il resto di questo è rivolto a chi risolve problemi difficili in codebase complessi.

Sento spesso la parola brownfield per parlare di questa divisione. Storicamente significava una cosa Java vecchia di dieci anni, ma al ritmo con cui possiamo spedire ora, sembra che un codebase costruito da agenti inizi ad avere difficoltà dopo forse tre o sei mesi – inizi a rallentare, e il modo in cui affronti l'aggiunta di nuove cose deve cambiare.

Una breve storia della software factory

Ho costruito e studiato software factory per tutta la mia carriera, ma l'ho scoperto solo di recente: il termine risale a una conferenza NATO del 1968 – la stessa che ci ha dato "ingegneria del software".

L'unica altra cosa che trovo super interessante da allora è che il Dipartimento della Difesa degli Stati Uniti ha scritto un PDF di 31 pagine su come il DoD debba iniziare a usare jenkins meglio o qualcosa del genere.

La software factory del 2022

Fissiamo la nostra definizione di "software factory" intorno al 2022, poco prima dell'AI. In una tipica software factory:

• Le persone decidono cosa costruire – ingegneri, PM, leadership che guidano la visione
• Finisce in un tracker – Linear, Jira, qualsiasi cosa: una macchina a stati di ciò che deve accadere
• Qualcuno prende un ticket e lo costruisce – probabilmente fa qualche test manuale/automatizzato mentre lo fa
• Pull request – controlli automatizzati, un umano rivede il codice, forse qualcuno lo scarica per testarlo
• Qualcosa non va? Torna indietro a "qualcuno costruisce la cosa"
• Spedisci in produzione – e incontra gli utenti
• Aggiungi monitoraggio – c'è un'intera industria costruita attorno al chiamare un ingegnere alle 3 di notte quando qualcosa si rompe
• Gli utenti si lamentano – chiedono cose, trovano bug, propongono funzionalità → tornano al team per aggiungerle al tracker

E così via. Non abbiamo ancora toccato l'AI, e ci sono già diversi loop in questa immagine.

allineamento precarico

C'è una cosa che i team hanno capito decenni fa: costruire richiede ore o giorni, e lo stesso vale per la revisione.

Quindi precarichiamo il lavoro – pianificazione, proposte di architettura, sprint planning – insieme, come team. Questo significa:

• meno rilavorazione, perché ci siamo allineati prima che qualcuno scrivesse codice
• meno tempo a rivedere ogni riga, se hai mai letto una PR lunga ma ben fatta, sai quanto veloce va la revisione quando è quasi perfetta

Ci torneremo più tardi – vediamo cosa succede quando introduci il coding agentico.

La software factory agentica

Ora ogni azienda e sua madre –

• Ramp
• Stripe
• WorkOS
• Brex

ha passato gran parte di quest'anno a spiegare come ha costruito una fabbrica di agenti che spedisce circa il 75% del loro codice.

La fabbrica agentica assomiglia per lo più a scambiare "qualcuno costruisce la cosa" → "un agente costruisce la cosa" – c'è roba come orchestrazione, un harness, un sandbox, un modello, uso del computer, ecc. Non entrerò nei dettagli perché francamente sono stanco di leggerne e sono sicuro che lo sei anche tu.

Quando l'agente costruisce la cosa:

• Costruire passa da ore o giorni a minuti o ore.
• La revisione richiede ancora ore o giorni. Un umano deve ancora leggere il codice e testare la modifica. Quindi la revisione è ora il collo di bottiglia.

Quindi acceleri anche la revisione:

• Revisione del codice agentica, per cogliere stile, bug, sicurezza.
• Test di regressione agentici, per colpirlo dall'esterno con browser e uso del computer e magari mandarti un video carino quando è finito

La revisione è più veloce ora, ma è probabilmente ancora il collo di bottiglia. Ma possiamo fare più loop.

Poi potresti instradare gli incidenti nella fabbrica. Invece di chiamare qualcuno alle 3 di notte, si svegliano con una PR che forse risolve già il problema.

Possiamo anche instradare il feedback degli utenti nella fabbrica. Le persone chiedono cose, vengono costruite.

A questo punto il lavoro si riduce a due domande: quanto puoi infilare nella coda, e quanto velocemente puoi revisionare e testare ciò che esce?

Il che ci porta alla software factory senza luci accese.

La software factory senza luci accese

Dan Shapiro ha coniato questo termine e Simon Willison ha scritto dell'implementazione di StrongDM – dove non leggiamo più il codice.

Guardi la tua bella software factory. È rovinata da quel fastidioso passaggio di revisione del codice e dici: sai cosa, quella cosa in cui un umano legge ogni modifica? No grazie.

Quindi lo elimini, e metti lo sforzo altrove:

• Investi nei test e lascia che l'agente testi il proprio lavoro
• Investi in sandbox e orchestrazione
• Investi nella revisione automatizzata
• Investi nel monitoraggio
• Investi nel rollout
• Investi nella raccolta di segnali di feedback dagli utenti

E ora il lavoro è davvero una sola domanda: quante cose possiamo chiedere all'agente di costruire? Quanto oceano vogliamo bollire?

Andrà alla grande (non è così)

Propongo qualcosa di potenzialmente controverso: la fabbrica senza luci accese non funziona.

Entriamo nel merito del perché le software factory falliscono.

Ci abbiamo provato

A luglio 2025 siamo andati completamente senza luci. Solo leggere le specifiche e i ticket, agenti in background per tutta la roba piccola/media, tutto quanto.

Se ci hai provato seriamente per qualche mese, sai già come finisce. Trovi almeno un problema abbastanza spinoso che l'agente non riesce a risolvere – anche con il prompting e i workflow più avanzati.

• Fai ricerca approfondita sensibile al contesto, raccogliendo tutte le parti giuste nella zona intelligente per l'analisi del modello
• Fai provare all'agente di riprodurre in 10 modi diversi

Alla fine devi rassegnarti e andare a scavare nel codebase che hai smesso di leggere tre mesi fa, cercando di capire cosa si è rotto.

E nel frattempo:

• Il tuo sito era giù.
• I tuoi utenti erano incazzati.
• E tu, se sei come me, eri infelice – a leggere tutto il codice spazzatura che hai lasciato entrare nel tuo sistema.

La prima volta che è successo, me lo sono scrollato di dosso. Anche se avevo passato quasi due settimane a scavare negli spaghetti di Claude, "il rischio di downside valeva la velocità". Verso la ~terza volta a novembre, abbiamo deciso che sarebbe stato più facile riscrivere da zero, e il mio co-fondatore ha passato due settimane intere in VS Code (neanche Cursor) a tirare fuori tutti i pattern a mano.

i modelli degradano la qualità del codebase nel tempo

Quello a cui voglio arrivare è questo: i modelli hanno una carenza. Non possono mantenere e migliorare la qualità del codebase nel tempo – non senza una discreta quantità di guida umana.4

Quando dico manutenibilità, intendo la cosa specifica in cui diventa davvero, davvero difficile cambiare una parte del codebase senza romperne un'altra. Questo è la shotgun surgery di Martin Fowler.

Non dirò molto altro sulla manutenibilità. Ci sono un sacco di libri che puoi leggere al riguardo:

• A Philosophy of Software Design di John Ousterhout
• Clean Code di Robert C. Martin
• Refactoring di Martin Fowler

Allora, perché i modelli non possono fare manutenibilità del software?

"Ma sicuramente i modelli sono migliorati da allora"

A questo punto potresti morire dalla voglia di dire: ma Dex, sicuramente i modelli sono migliorati molto da luglio

Lo sono – in alcuni aspetti. In altri sono più o meno gli stessi.

• Risolvere problemi una tantum, o fare vibe coding di un nuovo sito di marketing? Sì. Molto meglio.
• Migliorare la qualità del codebase nel tempo? Non molto meglio, per quanto posso dire.

Non posso provarlo. Nemmeno tu puoi provarlo. Non ci sono buoni benchmark per la capacità di un modello di mantenere la qualità del codebase. (Più avanti su dove sta andando.)

NON CI SONO BUONI BENCHMARK per la capacità di un modello di mantenere la qualità del codebase

Ma se hai lavorato con agenti di coding per un po' – e molte persone stanno postando esattamente questo – probabilmente hai già l'impressione: tendono a peggiorare le cose col tempo, e rendono il codebase più difficile in cui lavorare.

Quindi per capire perché questo accade, voglio allargare lo sguardo al primo grande agente di coding.

Claude Code ha vinto grazie al Reinforcement Learning dentro l'harness

Claude Code è passato da zero a ~$4 miliardi – ora qualcosa come ~$9 miliardi – di fatturato in meno di un anno.

Il che è un po' pazzesco, perché c'erano già ottimi agenti CLI. aider, cline, codebuff – tutti precedenti a Claude Code, tutti con un'ottima ingegneria del contesto integrata, tutti con lo stesso set di strumenti che potresti attribuire a Claude Code: read, write, edit, grep, bash. Li usavo. Erano buoni. Ma anche l'uso degli strumenti a volte... falliva – lo guardavi dibattersi sulla stessa modifica tre volte e riaprivi il tuo editor per farlo da solo.

Il paper SWE-Agent del 2024 delinea come piccole modifiche nella forma degli strumenti facciano differenze notevoli, ad esempio includere i numeri di riga nei risultati di ReadFile, o cambiare uno strumento Edit da trova/sostituisci a modifiche per intervallo di righe.

Poi Claude Code è stato lanciato ed è salito verticalmente abbastanza velocemente. Puoi liquidarlo come distribuzione, ma la spiegazione canonicamente accettata è che Claude Code ha vinto perché era migliore, e che era migliore perché Anthropic ha addestrato con RL il modello dentro l'harness – la prima volta che un laboratorio ha addestrato un modello contro gli strumenti esatti con cui lo avrebbero spedito. Ed è diventato davvero, davvero bravo a chiamare quegli strumenti in un loop agentico.

Una cosa è armeggiare con le definizioni degli strumenti e le eval fino a trovare la forma che il modello preferisce – ho passato settimane a farlo per vari casi d'uso. È un gioco diverso quando possiedi i pesi e puoi modificare il modello stesso per essere migliore con un particolare set di strumenti.

Il team di OpenAI ha tenuto un talk a novembre che lo ha spiegato bene: se costruisci un harness ma non possiedi i pesi e non puoi fare RL del modello al suo interno, sarai sempre in svantaggio rispetto a un team che possiede entrambi.

RL dell'agente di coding in 60 secondi

Ho fatto un sacco di ricerche su questo argomento e ho preparato un sacco di visualizzazioni per cercare di spiegare le parti che contano, ma ho scoperto che Calvin French-Owen (MTS nel team codex, fondatore di Segment) ha tenuto un talk all'AI Council che ha fatto un lavoro molto migliore e più pulito, quindi lascio qui questa animazione ispirata alle sue slide:

Per rendere un modello migliore nel coding, devi:

1. generare alcune tracce di agenti di coding per risolvere un problema (es. aggiusta i miei test)
2. valutare le tracce in base a alcuni criteri (verifier)
3. aggiornare i pesi del modello per rendere le tracce buone più probabili, e quelle cattive meno probabili

E poi fai questo milioni di volte nell'arco di settimane o mesi.

La parte di "valutazione" di queste cose può però tendere a essere banalmente unidimensionale.

Non c'è penalità per il cattivo design

Prendi SWE-bench Multilingual. I compiti sono piccoli – circa quindici minuti di lavoro ciascuno – estratti da repository open source come Redis, jq e Django. La ricompensa è uno o zero basato su:

• FAIL_TO_PASS – hai risolto la cosa che ti è stato chiesto di risolvere?
• PASS_TO_PASS – l'hai fatto senza rompere nient'altro?

Ecco uno vero, fastlane__fastlane-19304, da fastlane – un progetto Ruby. La sua azione zip prende due parametri opzionali e chiama .empty? su di essi subito, quindi nel momento in cui lasci include e exclude fuori, cade:

La correzione umana che ha chiuso questo particolare issue è di due righe (default nil a array vuoti):

Durante la valutazione, il modello

1. parte da un commit base – il repo checkout al momento prima che quella correzione arrivasse
2. il bug report – in questo caso 'zip_command': undefined method 'empty?' for nil:NilClass

L'agente parte e scrive del codice basato sull'issue. Non vede la patch d'oro o la patch di test che funge da valutatore:

Poi:

1. Manteniamo qualsiasi patch abbia prodotto, poi
2. Gettiamo via tutte le modifiche che ha fatto ai file di test (abbiamo beccato un modello che silenziosamente commentava il test fallito o inseriva un mock che rendeva il test inutile)
3. Applichiamo la patch di test del benchmark sopra, e
4. Eseguiamo l'intera suite: i test zip esistenti (PASS_TO_PASS) più quello nuovo (FAIL_TO_PASS) per vedere se passano entrambi

A parte – I benchmark non sono verificatori – anzi devono essere tenuti separati gli uni dagli altri (non addestrare sui test, eccetera eccetera) – intendo principalmente trasmettere la forma del "giudicare la qualità di una traccia di agente di coding" e i suoi limiti.

Come il modello è arrivato a una risposta corretta non importa. Se i test passano, vinciamo, ma non c'è penalità per erodere la manutenibilità del codebase.

non c'è penalità per erodere la manutenibilità del codebase

Ecco come ottieni try catch intorno a tutto:

Verificare la qualità è ordini di grandezza più difficile di "i test sono passati"

Eseguire i test ti dà un passaggio o fallimento pulito in ~secondi. Ecco perché RL può eseguire milioni di loop per ottimizzare ogni generazione di modello.

Ma la funzione di costo di una cattiva architettura si misura in settimane, mesi, forse anche anni. Succede la prima volta che qualcuno apre quel file per una modifica di una riga e si rende conto che non può farla in una riga – che qualcuno ha vibato questo un po' troppo, e ora dobbiamo fare la stessa modifica in undici posti e sperare che nulla si rompa silenziosamente in tre file più avanti.

I test ti danno feedback in secondi, ma la funzione di costo di una cattiva architettura si misura in settimane, mesi, forse anche anni

Il cattivo design è l'unica cosa che i benchmark di oggi non possono valutare. E lo so, lo so, RL != Benchmark, ma se questo fosse risolto in RL, sono abbastanza sicuro che inizierebbe a manifestarsi anche nel modo in cui sono progettati i nostri benchmark.

In ogni caso, personalmente non mi fido di nessun miglioramento sui benchmark di oggi come indicatore che i modelli siano improvvisamente bravi a non riempire di spazzatura il tuo codebase.

La frontiera sta migliorando, lentamente

Ovviamente molte persone intelligenti ci stanno lavorando. Il mio punto non è che non si possa fare, è che l'hype sta superando la disciplina.

Alcuni sforzi che penso siano nella direzione giusta:

• SWE-Marathon (Abundant AI): compiti di ~400 ore come "clona tutto Excel, ogni funzionalità" – con un canale di ricompensa composto invece di un singolo bit passa/fallisce
• DeepSWE (Datacurve): grandi compiti su repository OSS che non sono mai stati realmente costruiti nel mondo reale, quindi per costruzione non possono già essere nel set di training (risolve la contaminazione, ma non la qualità)
• Frontier Code (Cognition): compiti multi-PR, e una mossa intelligente che valuta la qualità in modo deterministico – penalizza il modello per aver scritto test che non falliscono sul codice pre-patch (se non hai mai sentito parlare di mutation testing ti aspetta un viaggio divertente5). Inoltre esegue un modello giudice sul diff che controlla le regole di qualità del codice.

Ma un modello che giudica la qualità può arrivare solo fino a un certo punto.

In effetti, non è difficile immaginare che se un modello potesse distinguere in modo affidabile il buon codice da quello cattivo, avrebbe probabilmente scritto la versione buona fin dall'inizio. Il RL ha bisogno di un oracolo veloce e affidabile, e per la manutenibilità non ce l'abbiamo ancora.

se un modello potesse distinguere in modo affidabile il buon codice da quello cattivo, avrebbe probabilmente scritto la versione buona fin dall'inizio, ma la manutenibilità non ha un oracolo veloce, quindi non possiamo premiarla durante il RL.

Certo, più agenti di revisione e più token aiutano – alzano il livello minimo, beccando le stupidaggini.

Ma non alzano il soffitto, perché il soffitto è ciò che siamo riusciti a insegnare al modello durante il RL, e il buon design è ancora qualcosa che non sappiamo come insegnargli.

Quindi ancora non scommetterei la mia codebase su nessuno di questi. Ma sono le prime valutazioni che ho visto cercare di valutare la manutenibilità invece di fermarsi al semplice passa/non passa.

Nota a margine Forse un modello futuro capirà tutto e potremo smettere. Se vuoi sparare prompt a caso finché non arriva GPT-7 e scoprirlo, fai pure – ma al diavolo la bitter lesson, abbiamo problemi da risolvere adesso, e ti spiegherò come lo facciamo.

Riaccedere le luci

Oggi ho scoperto che gli articoli di Twitter hanno un "limite multimediale", il che significa che il resto di questo va in un post della seconda parte – rimani sintonizzato