Modello Fabbrica, Conduttori e Orchestratori
Inquadramento del ruolo dello sviluppatore e dell'organizzazione del lavoro nell'era degli agenti autonomi presentato da Addy Osmani, Shubham Saboo e Sokratis Kartakis nel whitepaper Google The New SDLC With Vibe Coding (maggio 2026): nel nuovo ciclo di vita del software l'output primario dell'ingegnere non è più il codice ma il sistema che produce il codice (factory model), mentre il lavoro quotidiano si divide fluidamente tra la modalità conduttore (in tempo reale nell'IDE) e la modalità orchestratore (delega asincrona multi-agente; vedi Siamo Tutti Manager Adesso e Spettro Vibe Coding e Agentic Engineering). 1
Il modello fabbrica (factory model): costruire il sistema che costruisce il software
Nel modello fabbrica, lo sviluppatore agisce come un manager di fabbrica: non assembla ogni singolo widget a mano, ma progetta la linea di montaggio e presidia il controllo qualità, fornendo agli agenti criteri di successo invece di istruzioni passo-passo e lasciandoli iterare. Il sistema che produce il codice comprende cinque elementi: 1
- Specifiche e contesto che definiscono ciò che deve essere costruito (vedi Context Engineering); 1
- Agenti che traducono le specifiche in implementazione; 1
- Test e quality gate che verificano la correttezza; 1
- Feedback loop che reindirizzano i fallimenti agli agenti affinché li correggano; 1
- Guardrail che vincolano gli agenti a un comportamento sicuro e prevedibile. 1
Se lo sviluppatore è il direttore di stabilimento, il modello AI è soltanto il motore grezzo sul pavimento della fabbrica: per costruire un'automobile servono cinghie, ingranaggi, sensori di sicurezza e una catena di montaggio, ovvero l'Harness. 1
Conduttore vs Orchestratore: le due modalità operative
Con il passaggio dell'implementazione alle macchine, gli sviluppatori si muovono tra due modalità operative complementari: 1
- Il Conduttore (Conductor: direzione in tempo reale, hands-on): lo sviluppatore lavora nell'IDE fianco a fianco con un pair-programmer AI, osserva il codice apparire, guida il modello con prompt e correzioni e mantiene un controllo fine su ogni movimento. È la modalità tipica per logica complessa, debug ostici o codebase sconosciuti in cui serve comprendere ogni singola modifica, supportata da strumenti come GitHub Copilot, Gemini Code Assist di Google, Cursor e Windsurf. Preserva il senso di controllo e comprensione, ma rischia di diventare un collo di bottiglia se l'umano dirige personalmente ogni pressione di tasto. 1
- L'Orchestratore (Orchestrator: delega asincrona e multi-agente): lo sviluppatore opera a un livello di astrazione più alto, definendo obiettivi, assegnandoli ad agenti che lavorano in background e in parallelo su parti diverse del codebase (spesso in sandbox con pieno accesso a repository, build tool e suite di test) e verificando periodicamente i risultati. È tipica dei task ben definiti (bug fix, feature su pattern consolidati, migrazioni di codebase, generazione di test) ed è supportata da Google Jules, GitHub Copilot agent mode, Cursor background agents e Claude Code (vedi anche Flotta di Agenti). 1
Operare da orchestratore richiede un set di competenze diverso dalla padronanza della sintassi: Specification (definire i task senza ambiguità), Decomposition (spezzare lavori grandi in unità dimensionate per gli agenti), Evaluation (valutare rapidamente se l'output rispetta gli standard) e System design (progettare vincoli, test e loop di feedback). 1
Il problema dell'80% e il passaggio dagli errori sintattici a quelli concettuali
Una sfida persistente dello sviluppo assistito dall'AI è il problema dell'80% (the 80% problem): gli agenti generano rapidamente circa l'80% del codice di una feature, ma il restante 20% — edge case, gestione degli errori, punti di integrazione e requisiti sottili di correttezza — richiede una conoscenza contestuale profonda che spesso manca ai modelli attuali. 1
La natura stessa degli errori è mutata da semplici sbagli sintattici a fallimenti concettuali insidiosi: assunzioni errate sulla logica di business, mancata richiesta di chiarimenti davanti a requisiti ambigui, edge case dimenticati e decisioni architetturali che creano un sottile debito manutentivo a lungo termine. Sono errori più difficili da scovare proprio perché il codice "sembra giusto" (looks right) e può persino superare i test di base (vedi anche Kent Beck). Gli sviluppatori più efficaci non cercano la velocità accettando tutto, ma usano l'AI per l'implementazione rapida di task ben specificati e riservano la propria attenzione a requisiti ambigui, trade-off architetturali e verifica della correttezza. 1
I tre posti dove vivono i coding agent nella giornata dello sviluppatore
Nella pratica quotidiana i coding agent si presentano in tre ambienti, che la maggior parte degli sviluppatori usa contemporaneamente scegliendo in base al tipo di task e non alla posizione su una scala astratta di autonomia: 1
- Nell'editor (In the editor): completamento inline, pannelli chat per spiegare o modificare codice sul posto e consapevolezza dell'intero codebase senza uscire dal flusso (flow). Esempi: GitHub Copilot, Cursor, Windsurf, JetBrains AI Assistant. 1
- Nel terminale (In the terminal): agenti lanciati da riga di comando a cui si affida un obiettivo in linguaggio naturale, con pieno accesso al file system, modifiche multi-file ed esecuzione di tool e test in loop. È qui che avviene il vibe coding serio e il lavoro multi-file o su codebase sconosciuti. Esempi: Antigravity CLI, Claude Code, Codex CLI, Open Code e Cline. 1
- In background (In the background): agenti che girano autonomamente in sandbox cloud anche per ore su task descrivibili in un paragrafo (fix di un bug noto, suite di test, migrazione di framework), producendo una pull request da revisionare in seguito. Esempi: Google Jules, GitHub Copilot agent mode, Cursor background agents e l'agente specializzato AlphaEvolve di Google per la progettazione di algoritmi avanzati. 1
Costruire agenti pronti per la produzione: Agents CLI, ADK, MCP, A2A e il compilatore C in Rust
Quando ciò che bisogna costruire è a sua volta un agente (un bot di supporto clienti per i rimborsi, un assistente di ricerca che incrocia le fonti, un tool interno di compliance), l'agente è il prodotto e necessita di propri tool, memoria persistente tra sessioni, permessi scoped, copertura eval contro le regressioni e infrastruttura di osservabilità e deploy. 1
Oggi lo stesso flusso da terminale usato per i prototipi arriva fino agli agenti di produzione senza riscritture grazie a Google Agents CLI (uvx google-agents-cli setup, o tramite i comandi diretti agents-cli create, agents-cli playground, agents-cli eval, agents-cli deploy), un tool CLI che funziona con qualunque coding agent preferito (Claude Code, Codex o altri) e gli conferisce sette skill che coprono l'intero ciclo di vita di ADK (Agent Development Kit): scaffolding del progetto da template, scrittura del codice ADK, generazione ed esecuzione dell'evalset, deploy su Agent Runtime / Agent Engine e cablaggio dell'osservabilità. 1
Il flusso scala da un singolo agente a sistemi multi-agente: ADK fornisce workflow a grafo e meccanismi di interazione (stato di sessione condiviso, delega guidata da LLM, invocazione esplicita), mentre il coordinamento avviene tramite stato di sessione condiviso per i casi semplici, Model Context Protocol (MCP) per l'accesso ai tool e protocollo Agent2Agent (A2A) per la delega tra agenti. A dimostrazione della portata di queste architetture, gli autori citano l'esperimento pubblicato dal team di ingegneria di Anthropic a inizio 2026, in cui squadre di agenti hanno costruito un compilatore C funzionante in Rust in due settimane, con gli umani impegnati a definire la direzione e revisionare l'output senza scrivere l'implementazione (mentre le pratiche a scala di team sono approfondite nel companion paper Day 5, Spec-Driven Production Grade Development in the Age of Vibe Coding). 1
Vedi anche: Spettro Vibe Coding e Agentic Engineering, Siamo Tutti Manager Adesso, Harness Engineering, Context Engineering, Flotta di Agenti, Economia dello Sviluppo AI, Addy Osmani