AI software factory: come organizzare lo sviluppo con agenti, dal ticket al rilascio

Il 16 ottobre Cole Medin ha pubblicato un video dal titolo sincero: “My AI Dark Factory Dream Is Dead”. Per mesi aveva provato a costruire una dark factory, una fabbrica a luci spente in cui gli agenti ricevono un’applicazione da costruire e la portano in produzione senza intervento umano. La conclusione: non funzionerebbe nemmeno con un’intelligenza artificiale generale, perché i modelli non possono leggere nella mente di chi li usa. Al suo posto ha costruito una software factory, in cui pianifica ogni rilascio, gli agenti lavorano in parallelo sui ticket e lui verifica tutto in staging prima del rilascio.

Nello stesso mese David Ondrej ha intitolato un video “Stop coding, build Software Factories instead”, Matthew Berman ne ha raccontato l’evoluzione “dalle schede perforate alle software factory” e Anthropic ha spiegato di essere passata da 2.500 a oltre 30.000 merge al giorno in cinque mesi. Il tema è diventato centrale per chi sviluppa software con gli agenti.

In questa guida vediamo cos’è una software factory, come sono organizzate le sue fasi, cosa resta alle persone, dove si formano i colli di bottiglia e come iniziare in piccolo.

Per un’azienda la software factory cambia il modo di commissionare e gestire il software. Il costo di produrre codice scende, mentre crescono il peso della definizione dei requisiti, della revisione e dei controlli. Chi lo capisce per primo ottiene rilasci più frequenti senza aumentare il team, e smaltisce un arretrato di miglioramenti rimandato da anni.

In breve

• Una AI software factory è un processo ripetibile in cui gli agenti gestiscono parti del ciclo di sviluppo, dal ticket al rilascio, dentro un flusso condiviso dal team.
• Le fasi tipiche sono: raccolta, triage, pianificazione, implementazione, revisione, rilascio.
• Le persone passano dal fare ogni passo al supervisionare e migliorare il processo: approvano piani, decidono i merge, definiscono le regole.
• La fabbrica completamente autonoma non funziona: servono intenzione, priorità e giudizio umano nei punti giusti.
• Quando la generazione del codice accelera, il collo di bottiglia si sposta su revisione, CI e infrastruttura.
• Si comincia in piccolo: una categoria di task ben definita, un flusso semplice, metriche chiare.
• Per chi decide: una software factory sposta il costo dello sviluppo dalla scrittura del codice alla definizione, alla revisione e ai controlli. Budget e ruoli vanno riorganizzati di conseguenza.

Che cos’è una AI software factory

Una AI software factory è un sistema che organizza il lavoro degli agenti come una linea di produzione: le richieste entrano da fonti note (ticket, segnalazioni di errore, messaggi), vengono trasformate in task, attraversano fasi definite e producono modifiche verificate e rilasciabili.

La differenza con l’uso individuale degli agenti è la stessa che c’è tra un artigiano bravo e un’officina organizzata. Uno sviluppatore che lavora con un agente in chat può essere molto produttivo, ma il suo metodo resta nella sua testa e nelle sue sessioni. Una software factory rende il processo esplicito, condiviso e migliorabile: tutti sanno dove si trova un task, perché è stato fatto in un certo modo e chi ha approvato cosa.

L’idea di “fabbrica del software” non è nuova. Mastra, in un articolo dedicato, ricorda i precedenti: le linee di prodotto del Software Engineering Institute a metà anni 2000, le Software Factory di Microsoft, le pratiche condivise dei team di sviluppo della difesa americana. La novità è che oggi una parte del lavoro in ogni fase può essere svolta da agenti.

Cosa significa per le aziende e per chi compra software

L’arretrato diventa smaltibile

Ogni azienda ha una lista di piccoli miglioramenti mai fatti perché “non c’è tempo”: un report che manca, un campo da aggiungere, una schermata scomoda, un’integrazione manuale. Sono esattamente il tipo di lavoro ben definito e a basso rischio su cui una software factory dà il meglio. Quello che prima non valeva la pena di sviluppare, ora può valerla.

Il collo di bottiglia diventa decidere

Quando il codice si scrive in fretta, il limite diventa la capacità dell’azienda di dire cosa vuole, dare priorità e approvare. La figura di chi rappresenta il business nel progetto, che sia un product owner o un responsabile di reparto, diventa più importante, non meno. Serve tempo dedicato per scrivere richieste chiare e verificare i risultati.

Rilasci più frequenti richiedono un processo di approvazione

Se arrivano modifiche ogni settimana invece che ogni trimestre, l’azienda deve sapere chi le prova, chi le approva e come informa gli utenti. Altrimenti la velocità tecnica si scontra con i tempi dell’organizzazione, come racconta il caso GEICO.

Come cambiano i contratti

Se la scrittura del codice costa meno, i contratti a giornate perdono senso come misura del valore. Iniziano a diffondersi modelli legati ai risultati, come quello descritto da Tenex. Per un’azienda cliente significa poter chiedere offerte basate su funzionalità consegnate e verificate, con criteri di accettazione chiari.

Domande da fare a un fornitore che usa agenti

• Quali parti del lavoro sono svolte dagli agenti e quali dalle persone?
• Chi rivede il codice prima del rilascio, e con quali criteri?
• Ogni modifica è tracciabile, dalla richiesta al rilascio?
• Come si riflette l’uso degli agenti su prezzi e tempi?
• Il codice, le specifiche e le istruzioni per gli agenti restano di nostra proprietà?

Perché la dark factory non funziona

La promessa della fabbrica a luci spente è seducente: descrivi un prodotto, gli agenti lo costruiscono, lo testano e lo rilasciano. Nessuna persona nel ciclo.

Il problema non è la capacità dei modelli di scrivere codice. È che il software risponde a intenzioni, priorità e compromessi che non sono scritti da nessuna parte. Quale funzionalità viene prima? Quanto deve essere veloce questa pagina? Questo comportamento strano è un bug o una scelta voluta? Chi decide quando un compromesso è accettabile? Come dice Cole Medin nel video My AI Dark Factory Dream Is Dead, i modelli non leggono nella mente.

La sua soluzione rinuncia a meno autonomia di quanto sembri: la pianificazione di ogni rilascio resta umana, l’esecuzione dei task avviene in parallelo con gli agenti, la verifica finale in staging resta umana. Il grosso del lavoro meccanico è automatizzato; le decisioni no.

Le fasi di una software factory

I nomi cambiano da un’organizzazione all’altra, ma le fasi sono quasi sempre queste sei.

Fase	Cosa succede	Ruolo dell’agente	Ruolo della persona
1. Raccolta	Le richieste arrivano da ticket, monitoraggio errori, chat	Trasforma segnalazioni in task strutturati	Decide quali richieste accettare
2. Triage	Classificazione, priorità, raccolta del contesto	Indaga, riproduce, segnala informazioni mancanti	Conferma priorità e risponde alle domande aperte
3. Pianificazione	Approccio, ambito, controlli da eseguire	Propone il piano tecnico	Approva o corregge il piano
4. Implementazione	Modifica del codice e verifiche	Scrive codice, esegue test, documenta la sessione	Interviene solo se bloccato
5. Revisione	Valutazione di modifica, test, rischi	Revisione automatica in una sessione separata	Rivede l’intenzione e le parti critiche, decide il merge
6. Rilascio	Deploy e verifica in produzione	Prepara il rilascio e monitora	Decide quando e cosa rilasciare

Due dettagli fanno la differenza. Primo: la revisione automatica avviene in una sessione diversa da quella che ha scritto il codice, così l’agente revisore non eredita le stesse ipotesi. Secondo: un task è completato quando sono soddisfatti i criteri di accettazione, non quando la pull request è stata unita. Un task può richiedere più pull request.

La fase di pianificazione beneficia molto di specifiche scritte, come abbiamo visto nella guida allo spec-driven development: una specifica chiara è il miglior input per una fabbrica.

Cosa fanno le persone in una software factory

Il cambiamento più profondo non è tecnico ma di ruolo. Le persone smettono di essere il motore di ogni passo e diventano:

• Chi decide cosa costruire: accettano le richieste, stabiliscono priorità, scrivono o approvano specifiche.
• Chi approva i punti critici: piani, merge, rilasci.
• Chi dice di no: Anthropic, raccontando la propria esperienza, osserva che spesso il compito degli ingegneri era proprio rifiutare proposte dell’agente che violavano vincoli fondamentali o aggiungevano complessità per problemi ipotetici.
• Chi migliora la fabbrica: osservano dove il lavoro si blocca, quali errori si ripetono, quali decisioni possono essere automatizzate e quali devono restare umane. È lo stesso lavoro descritto nella guida all’harness engineering, applicato all’intero processo.

Latent Space ha intervistato il team di Tenex, un’azienda che organizza il lavoro di ingegneria attorno agli agenti, nell’episodio How Tenex Builds an AI-Native Engineering Team. Tra i punti emersi: piani, contesto del progetto e decisioni vengono conservati nel sistema di versionamento, insieme al codice, e gli ingegneri vengono valutati sui risultati più che sulle ore.

Cosa succede quando la fabbrica funziona: i casi reali

Spotify

Spotify ha raccontato nel blog di ingegneria il percorso del suo agente di coding in background, con oltre 1.500 pull request generate dall’agente e unite già nel 2025, soprattutto per migrazioni e aggiornamenti su larga scala. Secondo la copertura di InfoQ di un intervento a QCon London 2026, il ritmo è poi cresciuto molto, e il nuovo collo di bottiglia è diventato la revisione delle pull request, non la generazione del codice.

Monzo

Alla conferenza AI Engineer di New York, due ingegneri della banca digitale Monzo hanno raccontato nel talk A Bank Built Its Own Coding Agent che il loro agente interno, nato come una reazione emoji in Slack, è arrivato a scrivere oltre il 10% delle pull request unite nei team tecnici, con più di 1.800 task al giorno. Un caso interessante perché viene da un settore regolato, dove controlli e tracciabilità non sono opzionali.

Anthropic

Nel post Redesigning source control Anthropic spiega che i merge giornalieri nel suo monorepo sono passati da circa 2.500 a maggio a oltre 30.000 a settembre. L’infrastruttura pensata per persone (versionamento, build, CI) è diventata il collo di bottiglia, al punto che un team di sette persone ha costruito un nuovo sistema di controllo versione, Scion, con uno strumento di revisione che applica regole di approvazione diverse a seconda del tipo di modifica. Theo lo ha commentato nel video Anthropic Rebuilt Git. La stessa Anthropic avverte che Scion è troppo specifico per essere adottato da altri: la lezione è il problema, non la soluzione.

Questi numeri riguardano aziende con migliaia di ingegneri e infrastrutture enormi. Per un’azienda italiana di medie dimensioni la scala è diversa, ma le dinamiche sono le stesse: quando la scrittura del codice accelera, tutto il resto deve tenere il passo.

Dove si inceppa una software factory

La revisione

Se gli agenti producono dieci volte più pull request, chi le rivede? È il collo di bottiglia più citato da tutti i casi. Le soluzioni che funzionano: revisione automatica preliminare in una sessione separata, regole che distinguono modifiche banali da modifiche critiche, revisione umana concentrata sull’intenzione e sulle parti a rischio invece che su ogni riga.

La CI

Una suite di test da venti minuti va bene per dieci merge al giorno, non per cento. Test veloci, esecuzione selettiva dei test pertinenti e controlli progressivi (rapidi prima, completi dopo) diventano indispensabili. Ne parleremo in un articolo dedicato ai controlli di qualità con gli agenti.

I conflitti

Più agenti in parallelo sullo stesso codice significano più conflitti. Task piccoli e ben separati li riducono; ambienti isolati per ogni agente (per esempio un worktree git per sessione) evitano che si pestino i piedi durante il lavoro.

Le decisioni

Al talk An AI War Room for Legacy Code, Ford Prior di GEICO ha descritto una situazione comune: il codice si scrive in fretta, ma decisioni, approvazioni e contesto restano lenti. La sua risposta è stata una “stanza di guerra” con le persone che decidono, un conducente e una flotta di agenti, per comprimere in un giorno ciò che richiedeva settimane di passaggi.

Il contesto

Un agente che riceve un ticket di due righe produce un risultato mediocre, che la fabbrica sia sofisticata o no. La qualità dell’input resta il fattore principale.

Come iniziare in piccolo

Non serve una piattaforma dedicata per costruire una prima software factory. Questo è un percorso realistico per un team di poche persone.

1. Scegli una categoria di lavoro

Parti da task ripetitivi, ben definiti e a basso rischio: aggiornamenti di dipendenze, correzione di errori segnalati dal monitoraggio, piccole modifiche all’interfaccia, migrazioni meccaniche. Spotify ha iniziato proprio dalle migrazioni su larga scala.

2. Definisci il flusso

Un’etichetta sul ticket (per esempio “agente”) avvia il processo. L’agente produce un piano come commento al ticket. Una persona lo approva. L’agente implementa in un ramo dedicato e apre una pull request con la descrizione di cosa ha fatto e come lo ha verificato. Una seconda sessione dell’agente fa una prima revisione. Una persona decide il merge.

3. Rendi i controlli automatici

Lint, tipi, test e build devono girare su ogni pull request senza intervento umano. Se un controllo fallisce, l’agente riceve l’errore e corregge.

4. Misura

Tre metriche bastano all’inizio: quanti task completati dalla fabbrica, quanti richiedono correzioni umane dopo la revisione, quanto tempo passa dal ticket al merge.

5. Allarga gradualmente

Quando la prima categoria funziona, aggiungine un’altra. Ogni nuova categoria richiede di aggiornare istruzioni, skill e controlli.

Esempio di flusso minimo

[Ticket con etichetta "agente"]
        |
        v
[Agente: triage + piano nel ticket] --> [Persona: approva / corregge]
        |
        v
[Agente: ramo dedicato, implementazione, test]
        |
        v
[Pull request con descrizione e prove di verifica]
        |
        v
[Seconda sessione agente: revisione] --> [Persona: merge]
        |
        v
[Rilascio in staging, verifica, produzione]

Strumenti: costruire o comprare

Il mercato degli strumenti per software factory è nato da pochi mesi e cambia ogni settimana. Esistono piattaforme che orchestrano ticket, agenti e revisione, agenti di coding che girano nel cloud in ambienti isolati, e componenti che si possono comporre da soli con le API degli agenti e la CI esistente.

Il nostro consiglio per un team piccolo o medio: partire dagli strumenti che già usate (gestione ticket, repository, CI) e aggiungere gli agenti come partecipanti al flusso, invece di adottare subito una piattaforma che impone un processo. Quando il flusso è stabile e i limiti degli strumenti esistenti sono chiari, la scelta di una piattaforma diventa molto più facile. TrueFoundry propone una guida per le organizzazioni enterprise utile per capire le opzioni.

Errori comuni

Partire dai task più difficili

La fabbrica dà il meglio su lavoro ripetitivo e ben definito. Partire da funzionalità complesse e ambigue porta a frustrazione e a conclusioni sbagliate sull’intero approccio.

Automatizzare la revisione senza criterio

Una revisione solo automatica su modifiche critiche è un rischio. Una revisione solo umana su modifiche banali è uno spreco. Servono regole che distinguano.

Ignorare il costo

Agenti in parallelo su molti task consumano molti token. Senza misurare il costo per task completato, la fabbrica può costare più del lavoro che sostituisce. Ne abbiamo parlato nella guida al consumo di token.

Processo nella testa di una persona

Se il flusso funziona solo perché uno sviluppatore sa come guidarlo, non è una fabbrica. Deve essere documentato e replicabile.

Nessun ritorno al processo

Gli errori ricorrenti devono tornare indietro come miglioramenti a istruzioni, skill e controlli. Una fabbrica che non impara ripete gli stessi difetti.

Portarlo in produzione

• Tracciabilità: ogni modifica deve collegare ticket, piano approvato, sessione dell’agente, revisione e rilascio. È fondamentale in settori regolati e utile ovunque.
• Permessi: gli agenti della fabbrica lavorano con account dedicati, senza accesso alla produzione e senza possibilità di fare merge sui rami protetti.
• Ambienti isolati: ogni task in un ambiente separato, per evitare interferenze e limitare i danni in caso di errore.
• Staging obbligatorio: nessun rilascio senza una verifica in un ambiente che riproduce la produzione.
• Responsabilità chiare: per ogni modifica in produzione c’è una persona che l’ha approvata. L’agente non è responsabile di nulla.

Vuoi introdurre una software factory nel tuo team o nella tua agenzia senza stravolgere il modo di lavorare? Come partner tecnico progettiamo flussi con agenti su progetti reali, e nello sviluppo di web app usiamo questi metodi per accelerare i rilasci mantenendo il controllo.

Da dove partire questa settimana

1. Elenca i task degli ultimi due mesi e individua una categoria ripetitiva e a basso rischio.
2. Scrivi il flusso in una pagina: chi avvia, cosa fa l’agente, cosa approva una persona, quando un task è completato.
3. Verifica che lint, tipi, test e build girino automaticamente su ogni pull request.
4. Avvia il flusso su cinque task reali e annota dove si blocca.
5. Dopo due settimane misura task completati, correzioni necessarie e tempo dal ticket al merge.

Checklist di una software factory sana

• Le richieste entrano da fonti note e diventano task strutturati.
• Ogni task ha criteri di accettazione verificabili.
• I piani vengono approvati da una persona prima dell’implementazione.
• Gli agenti lavorano in ambienti isolati con permessi limitati.
• Lint, tipi, test e build girano automaticamente su ogni modifica.
• La revisione automatica avviene in una sessione separata.
• Le regole di revisione distinguono modifiche banali da modifiche critiche.
• Ogni rilascio passa da staging ed è approvato da una persona.
• Ticket, piano, sessione, revisione e rilascio sono collegati e tracciabili.
• Gli errori ricorrenti diventano miglioramenti del processo.

Domande frequenti

Fonti e approfondimenti

• Mastra: What is an AI software factory?
• Anthropic Engineering: Redesigning source control
• Spotify Engineering: 1,500+ PRs later, il nostro agente di coding in background
• InfoQ: Spotify Honk a QCon London 2026
• David Ondrej: Stop coding, build Software Factories instead
• Matthew Berman: From Punch Cards to AI Software Factories

Vuoi capire se una software factory ha senso per il tuo team? Parliamone: partiamo dai task che ripetete ogni settimana.