Adottare il modello di software factory: gattonare, camminare, correre

L'approccio della software factory (un ciclo agentico chiuso che opera nel cloud) sta guadagnando popolarità, ma adottarlo può risultare scoraggiante. In questo articolo illustrerò i passaggi "gattona, cammina, corri" per effettuare la transizione dagli agenti interattivi locali allo sviluppo automatizzato nel cloud.

Gattona

Molti leader ingegneristici e ingegneri di piattaforma con cui parlo hanno già iniziato la fase di "gattonamento" nella costruzione di una software factory creando semplici automazioni tramite agenti cloud.

Pensa a queste automazioni come a Trigger → Attività dell'Agente.

Ad esempio:

• Riproduzione e triage dei problemi: fai in modo che un agente esamini tutti i nuovi ticket segnalati, li riproduca e li etichetti.
• Code review: revisiona automaticamente le PR non appena vengono aperte e lascia commenti
• Monitoraggio: utilizza un agente che risponda agli avvisi Sentry, effettui il debug e risolva un problema
• Auto-riparazione CI: correggi una CI rotta identificando le PR da annullare o i conflitti di merge da risolvere
• Aggiornamento automatico della documentazione: aggiorna la documentazione rivolta all'utente e genera changelog
• Verifica: gli agenti browser-use e computer-use eseguono QA visivo e verificano le modifiche
• Correzioni di bug semplici: gli agenti identificano e risolvono problemi semplici segnalati dagli utenti

Ciò che accomuna tutti questi approcci è l'automazione di una parte discreta del ciclo di vita del software. Iniziare con automazioni semplici è un approccio a basso rischio e basso costo, e aiuta a sviluppare l'intuizione su come utilizzare efficacemente gli agenti in compiti più complessi e multi-stadio.

Esempio di automazione per il monitoraggio degli avvisi

Queste automazioni potrebbero essere costruite utilizzando infrastruttura interna (ad esempio, inserendo l'SDK Claude Code in un container Docker e configurando un server per attivarlo), oppure potrebbero sfruttare una piattaforma generica di automazione per agenti cloud progettata per eseguire agenti basati su trigger. Potrebbero anche utilizzare un'intera piattaforma dedicata a una singola fase del ciclo (ad esempio, un code reviewer agentico dedicato o un AI SRE).

Partire con un mosaico di automazioni puntuali va bene, ma la maggior parte dei team alla fine incontra limiti con questo approccio.

Nello specifico:

• A seconda di come sono configurate, queste automazioni potrebbero non condividere il contesto. Ciò significa che quando apporti miglioramenti a un aspetto (diciamo, la code review), questi non si trasferiscono ad altre fasi, come il triage e il QA.
• Non esiste una visione globale che indichi se tutte queste automazioni una tantum migliorino effettivamente la produttività complessiva, né un metodo sistematico per testare e migliorare le metriche di alto livello che ti interessano, come costo-per-PR, tempo di ciclo, percentuale di automazione, ecc. Per tracciare questi dati hai bisogno di un sistema che funzioni attraverso tutte le fasi dello sviluppo.
• Le soluzioni puntuali creano ciascuna il proprio carico di configurazione e manutenzione. Ampliano la superficie di sicurezza da gestire. Non dispongono di un'interfaccia unificata per l'osservabilità. I team alla fine desiderano configurazione centralizzata, auditing e governance.

Cammina

Tutti questi problemi indicano la necessità di un approccio più olistico. Le organizzazioni che hanno completato la fase di "gattonamento" si chiedono: "Qual è il sistema che vogliamo per scalare davvero lo sviluppo agentico?"

Più specificamente, si chiedono:

• Dove dovrebbe avvenire lo sviluppo? Localmente o nel cloud? Attraverso quali interfacce?
• Come appare un processo di sviluppo automatizzato di successo? Quali sono le metriche chiave?
• Qual è la nostra postura sulla sovranità dell'AI? Quanto è importante possedere i dati dei nostri coding agent? Da quanto dovremmo dipendere dai fornitori di modelli?
• Come prevediamo di migliorare il nostro processo di sviluppo nel tempo? Come controlliamo i costi accelerando al contempo la velocità di rilascio? Come facciamo a sapere che stiamo migliorando?
• Come ci prepariamo al futuro man mano che modelli e agenti migliorano? Stiamo considerando i rischi normativi che potrebbero influire sull'accesso ai modelli?
• Come dovrebbero partecipare esattamente gli ingegneri al processo di sviluppo? E designer, PM e altri creatori?
• Come mettiamo in sicurezza lo sviluppo? Qual è il piano se il nostro processo di produzione software viene compromesso?

La maggior parte dei leader ingegneristici e dei team di piattaforma che riflettono profondamente su queste domande arriva a qualcosa di simile a un approccio cloud software factory. Desiderano:

• Sviluppo nel cloud per impostazione predefinita, perché è più sicuro fornire sandbox agli agenti piuttosto che lasciarli liberi localmente
• Governance centralizzata degli agenti di coding e degli strumenti e sistemi a cui accedono
• Tracce complete di ciò che gli agenti hanno fatto, per l'auditing e la comprensione della produttività
• Opzionalità riguardo a modelli e harness, per minimizzare il rischio e ottimizzare le prestazioni
• Integrazione dello sviluppo in tutti gli strumenti che il tuo team utilizza già (ad es. Slack/Teams, Jira, Github, ecc.)
• Vie di fuga per gli umani per prendere il controllo, sia guidando gli agenti live sia portando il lavoro nel ciclo di sviluppo interno
• Un layer di contesto condiviso che funziona tra gli agenti in tutte le fasi dello sviluppo
• Un approccio che consenta test, valutazioni e benchmark così che il tuo team abbia fiducia nel fatto che il sistema stia migliorando nel tempo

Una volta che un'azienda decide per un approccio factory, la domanda diventa: come arrivarci partendo dalle tue attuali automazioni puntuali? Questo si riduce solitamente a decidere se (1) costruire più infrastruttura attorno a quelle automazioni o (2) passare a una piattaforma come Warp Factories, che fornisce l'infrastruttura factory.

Nota che non inquadrerei questa decisione come una tradizionale scelta build vs. buy. Indipendentemente dal percorso scelto, dovresti aspettarti che il tuo team interno faccia un po' di sviluppo, perché affinché un approccio factory funzioni, quella factory deve essere profondamente integrata nel contesto e nei flussi di lavoro del tuo team. È più una questione di se costruisci la tua infrastruttura di automazione completamente da zero, o se ti allei con chi ti offre un vantaggio iniziale.

Ad esempio, indipendentemente dal percorso scelto, dovresti aspettarti di costruire skill specifiche per l'organizzazione e di sintonizzarle per il tuo codebase. Dovresti aspettarti di esporre e configurare MCP specifici per l'organizzazione e fonti di contesto interne. Tuttavia, potresti non voler costruire l'infrastruttura cloud per eseguire e gestire gli agenti, guidarli, passare loro il lavoro, misurare la loro efficacia, eseguire computer use, e così via. La regola pratica è concentrarsi sulla costruzione delle parti specifiche per la tua organizzazione, non di quelle necessarie a qualsiasi organizzazione.

Qualunque approccio tu scelga, suggerisco che il traguardo più grande nella fase cammina sia distribuire una prima factory end-to-end su una superficie prodotto semplice. Potrebbe essere il tuo sito marketing o un'app interna.

Iniziare con un progetto semplice ha il vantaggio di avviare un intero ciclo con basse posta in gioco e complessità minima. Aggiungere più repo, righe di codice, dipendenze di servizi, stakeholder umani, e così via aumenta la complessità e può portare alla sensazione di non essere pronti per l'automazione. Meglio calibrare prima un ciclo semplice.

L'obiettivo è un sistema multi-agente che passi da triage → spec → implementazione → review → verifica → monitoraggio. Nel dettaglio:

1. Un nuovo problema entra nel sistema, tramite un umano o un agente di monitoraggio
2. L'agente di triage esegue e cerca di capire e riprodurre il problema. Se determina che il compito è automatizzabile → lo passa all'agente di Implementazione. Se ha bisogno di specifiche a causa dell'ambito → fa iterare l'agente di specifica con un umano per creare una spec. Se è ambiguo → ottiene input umano e riesegue, o semplicemente decide di mettere in pausa il problema per ora
3. [Se necessario] L'agente di specifica esegue, l'umano rivede le specifiche e poi passa all'agente di implementazione
4. L'agente di implementazione scrive il codice
5. L'agente di code review revisiona il codice
6. L'agente di verifica esegue computer-use o altra verifica
7. L'umano rivede il codice e l'output della verifica. Se necessario, torna al passo 2, 3, 4 o 5
8. CI / CD
9. Rilascialo
10. L'agente di monitoraggio esegue e crea problemi se necessario, completando il ciclo

Internamente presso Warp, la nostra factory cammina automatizza circa il 75% delle modifiche a warp.dev, il nostro sito marketing. A differenza di Warp Terminal (65k stelle GitHub, quasi un milione di sviluppatori attivi, 1M righe di Rust nativo), il nostro sito marketing è un'app piuttosto semplice. Nota che per "automatizzare" intendo passare dall'input umano a una funzionalità rilasciata interamente attraverso la factory, con minimi touchpoint umani oltre a descrivere la modifica che vogliamo, sia in Slack che nel nostro task tracker.

Corri

Solo quando hai il ciclo base in atto su un progetto semplice dovresti scalare verso progetti più complessi. Scalare le factory richiede un'infrastruttura più robusta.

Nello specifico, mentre scali emergono certi colli di bottiglia:

• Far funzionare gli ambienti di sviluppo remoti su grandi progetti è difficile. Più repo, righe di codice, dipendenze di servizi rendono tutto più difficile l'automazione.
• Man mano che accumuli più skill, codice, ecc., diventa più difficile sapere se le modifiche che stai apportando alle tue factory stanno avendo un impatto positivo sullo sviluppo o stanno solo causando churn
• Rischi naturalmente costi più elevati poiché gli agenti lavorano su codebase più complessi perché hai bisogno di modelli più potenti e gli agenti devono eseguire più a lungo. Il routing dei modelli e la scelta dell'harness diventano più importanti.
• Sicurezza e auditing diventano più importanti man mano che porti l'approccio factory ad app mission-critical rivolte all'utente
• Più stakeholder dell'app significano più coordinamento umano e approvazioni. Vorrai una soluzione factory che consenta input multiplayer e tracce di audit
• Inevitabilmente le PR inizieranno ad accumularsi, quindi vorrai una strategia definita per cosa viene sottoposto a code review, come usi la verifica e il QA agentico
• Vorrai strumenti più robusti per chiudere il ciclo, assicurandoti che le modifiche che vanno in produzione siano di alta qualità, non vadano in crash, ecc.

Far funzionare factory scalate sarà, secondo me, una delle sfide di ingegneria del software più interessanti nei prossimi anni; l'ingegneria del software sta diventando factory engineering. Le organizzazioni che renderanno le loro factory robuste, affidabili e auto-miglioranti saranno in grado di rilasciare di più a costi migliori e avranno un vantaggio competitivo.

Per far funzionare davvero a pieno regime le factory serve un investimento significativo. Presso Warp, pensiamo a questo come alla piena costruzione del tuo stack factory:

Copro ogni uno di questi livelli in dettaglio in questo post:

https://x.com/zachlloydtweets/status/2097739116720910619

Alcuni punti chiave da evidenziare che potrebbero non essere ovvi:

• Factories-as-code: una delle scelte chiave che puoi fare è definire le tue factory come codice. Questo consente il testing di diverse configurazioni factory per vedere quali sono più efficienti, di massima qualità, ecc.
• Multi-model & multi-harness: dovresti assicurarti che le tue factory siano in grado di usare gli ultimi modelli, sia frontier che open-weight, e usare diversi harness di coding agent come Claude Code e Codex.
• Proprietà dei dati: dovresti assicurarti di archiviare e possedere tutti i dati provenienti dalla tua factory - questa è la materia prima per migliorare le sue operazioni.

In una factory pienamente operativa, la caratteristica chiave è che si tratta di un sistema a ciclo chiuso, misurabile e migliorabile. Questo dovrebbe essere l'obiettivo. In un tale sistema, tutti lavorano dallo stesso contesto, pubblicamente, in un modo pienamente audito e osservato. Gli agenti stessi osservano le skill e la configurazione che guidano il sistema e suggeriscono miglioramenti. Gli ingegneri di piattaforma possono estendere il sistema per integrarlo in tutti i sistemi interni. I leader ingegneristici possono vedere le metriche di produttività e comprendere quali modifiche vengono apportate per migliorarle. Tutto funziona empiricamente, non a intuito.

Presso Warp, ci stiamo avvicinando a questa visione. Ogni giorno lavoriamo tutti pubblicamente, sintonizzando la nostra factory, riducendo i costi e migliorando throughput e qualità.

La nostra missione è fornire ai migliori team di ingegneria al mondo gli strumenti per costruire, misurare e ottimizzare i propri flussi di lavoro utilizzando qualsiasi modello e harness sottostante su infrastruttura aperta. Queste capacità aiuteranno i team a rilasciare software migliore più rapidamente ed efficientemente.

Warp Factories è attualmente in early access. Le aziende qualificate ricevono $10k di utilizzo factory.