Spettro Vibe Coding e Agentic Engineering
Framework metodologico presentato nel maggio 2026 da Addy Osmani, Shubham Saboo e Sokratis Kartakis (Google) nel whitepaper The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering: l'ingegneria del software sta attraversando la sua trasformazione più profonda dall'introduzione dei linguaggi ad alto livello — il passaggio dalla scrittura della sintassi all'espressione dell'intento — e le pratiche di sviluppo assistite dall'AI non vanno lette come un'alternativa binaria, ma lungo uno spettro continuo che va dal vibe coding informale all'agentic engineering disciplinato, il cui vero discriminante è la verifica sistematica tramite test deterministici ed evaluation (eval) non deterministiche. 1
Dalla sintassi all'intento e il ripasso sugli agenti
Per decenni l'interfaccia primaria tra sviluppatore e macchina è stata la sintassi; oggi la macchina gestisce l'implementazione mentre l'umano fornisce intento, architettura e giudizio (vedi anche Non Determinismo del Software). A inizio 2026, l'85% degli sviluppatori professionisti utilizza regolarmente agenti di coding, il 51% li usa ogni giorno e circa il 41% di tutto il nuovo codice è generato dall'AI. Questa evoluzione è passata in pochi anni dall'autocomplete nel testo ai suggerimenti inline di intere funzioni, poi alle interfacce chat in linguaggio naturale e infine agli agenti autonomi capaci di clonare repository, pianificare modifiche multi-file, eseguirle in ambienti sandbox, lanciare i test e aprire pull request senza che un umano digiti una riga di codice. 1
Richiamando il whitepaper Google Introduction to Agents (novembre 2025), gli autori ricordano che, a differenza di un chatbot che risponde e attende il prompt successivo, un agente esegue un proprio ciclo continuo (perceive, plan, act, observe, iterate) ed è costruito da cinque parti: Model (il motore di ragionamento), Tools (API, esecuzione codice, database e altri agenti a cui delegare), Memory (lo stato che ricorda interazioni passate e regole di progetto tra sessioni), Orchestration (il codice che governa il loop, assembla il contesto e smista le chiamate ai tool) e Deployment (hosting, identità, osservabilità e infrastruttura di produzione). 1
Che cos'è il vibe coding e perché è nato il termine agentic engineering
Nel febbraio 2025, Andrej Karpathy ha descritto un nuovo modo di programmare basato sull'"abbandonarsi completamente alle vibes, abbracciare gli esponenziali e dimenticare che il codice esista" (fully give in to the vibes, embrace exponentials, and forget that the code even exists): lo sviluppatore descrive ciò che vuole in linguaggio naturale, accetta l'output dell'AI e, quando qualcosa si rompe, copia e incolla il messaggio di errore nel prompt chiedendo al modello di ripararlo (vedi anche Slice Sottili e Ciclo di Feedback per la lettura datane da Martin Fowler). 1
Nel giro di pochi mesi l'espressione vibe coding è diventata virale ma è stata applicata a qualunque flusso assistito dall'AI — inclusi ingegneri senior che implementano feature ben specificate o team che eseguono architetture pianificate con rigore — fino a perdere significato. All'inizio del 2026, lo stesso Karpathy ha riconosciuto che l'inquadramento originario era troppo ristretto e ha introdotto il termine agentic engineering per indicare l'estremo disciplinato dello spettro, in cui l'AI agisce come motore di implementazione dentro sistemi progettati dall'uomo fatti di vincoli, test e cicli di feedback. 1
Le tre posizioni e le sei dimensioni dello spettro
La differenza tra gli estremi non dipende dall'uso o meno dell'AI, ma da quanta struttura, verifica e giudizio umano circondano il suo output lungo sei dimensioni: 1
| Dimensione | Vibe Coding | Structured AI-Assisted Coding | Agentic Engineering |
|---|---|---|---|
| Specifica dell'intento | Prompt informali in linguaggio naturale | Prompt dettagliati con esempi e vincoli | Specifiche formali, doc architetturali, file di memoria |
| Verifica | "Sembra funzionare?" | Test manuali, controlli a campione (spot-checking) | Suite di test automatizzate, gate CI/CD, LM judges |
| Comprensione del codebase | Minima; lo sviluppatore può non leggere il codice generato | Revisione selettiva dei percorsi critici | Revisione completa dell'architettura; l'AI gestisce i dettagli implementativi |
| Gestione degli errori | Copia-incolla dei messaggi di errore verso l'AI | Lo sviluppatore diagnostica la causa radice, l'AI implementa il fix | Gli agenti si auto-diagnosticano entro confini definiti; gli umani gestiscono i problemi architetturali |
| Scope appropriato | Prototipi, script, progetti personali, hackathon | Feature all'interno di codebase consolidati | Sistemi di produzione, sviluppo su scala di team |
| Profilo di rischio | Alto; accettabile per codice usa-e-getta (disposable) | Moderato; giudizio umano nei checkpoint chiave | Basso; verifica sistematica in ogni fase |
La posizione giusta sullo spettro dipende dalla posta in gioco (stakes): un prototipo del weekend può essere puro vibe coding, mentre un'API di produzione che gestisce transazioni finanziarie o i pagamenti aziendali esige l'agentic engineering (vedi Cerimonia Proporzionata al Rischio). 1
Il discriminante della verifica: test per il deterministico, eval per il non deterministico
Il singolo fattore che più separa i due estremi è come viene verificato l'output. Nell'agentic engineering lavorano insieme due meccanismi complementari: 1
- Test (per le parti deterministiche): verificati dal codice, controllano che una funzione, dato un certo input, produca l'output atteso. 1
- Evaluations o eval (per le parti non deterministiche): verificate tramite dataset etichettati (labelled datasets), rubriche di punteggio (scoring rubrics) e giudici basati su modelli linguistici (LM judges), controllano se l'agente ha seguito la giusta traiettoria di passi, ha scelto i tool corretti e ha prodotto una risposta finale all'altezza della barra di qualità. 1
La regola formulata dagli autori è netta: senza entrambi (test ed eval), la pratica resta sempre vibe coding, indipendentemente da quanto siano sofisticati i prompt. 1
Il nuovo SDLC: compressione non uniforme e trasformazione fase per fase
Dopo il passaggio storico dal waterfall ai cicli iterativi (Agile, CI, DevOps), l'AI comprime drasticamente l'SDLC ma in modo non uniforme: l'implementazione che richiedeva settimane ora richiede ore, mentre requisiti, architettura e verifica restano ancorati ai tempi umani. Il risultato non è il vecchio SDLC più veloce, ma un flusso diverso in cui i confini tra le fasi sfumano, le iterazioni scendono da settimane a minuti e lo sviluppatore diventa system designer e arbitro della qualità (con team che a metà 2026 già sperimentano il passaggio diretto dalle specifiche alla review): 1
- Requisiti e pianificazione: l'AI genera user story da product brief, individua edge case trascurati dagli umani, produce schemi API da descrizioni in linguaggio naturale e crea prototipi interattivi in pochi minuti, azzerando il feedback loop tra requisito e prototipo; i requisiti cessano di essere un documento passato tra team e diventano una conversazione che produce simultaneamente specifica e prima implementazione. 1
- Design e architettura: resta la fase più ostinatamente umana, perché i trade-off (consistency vs. availability, complexity vs. flexibility, build vs. buy) dipendono dal contesto di business, dai vincoli organizzativi e dalla strategia di lungo periodo; una volta documentate le decisioni strutturali, gli agenti eccellono nello scaffolding e nell'applicare pattern coerenti tra i moduli. 1
- Implementazione (e il paradosso dello studio METR): i sondaggi di settore riportano miglioramenti di produttività tra il 25% e il 39%, ma uno studio di METR (febbraio 2026) ha rilevato che sviluppatori esperti assistiti dall'AI hanno impiegato il 19% di tempo in più su determinati task, proprio per il tempo speso a verificare, debuggare e correggere l'output generato; l'AI non elimina il lavoro di implementazione, ma lo trasforma da scrittura a revisione, guida e verifica. 1
- Testing, QA e il volano della qualità (quality flywheel): oltre a distinguere tra output evaluation (il codice compila e passa i test?) e trajectory evaluation (la sequenza di tool call e ragionamenti intermedi è corretta, evitando output fluenti che hanno saltato i passi di verifica?), test ed eval diventano il mezzo principale per comunicare l'intento agli agenti, alimentando un volano continuo: valutare su una suite di benchmark, diagnosticare i fallimenti clusterizzando le cause radice, ottimizzare prompt o tool, verificare i fix su una regression suite e monitorare il traffico di produzione per nuove modalità di fallimento. 1
- Code review e deployment: l'AI agisce come revisore di primo passaggio (bug, violazioni di stile, vulnerabilità di sicurezza, problemi di performance) alleggerendo il carico cognitivo umano, mentre le pipeline diventano AI-aware (monitoraggio della salute del deploy, rollback automatici delle release problematiche, previsione del rischio in base allo scope delle modifiche). 1
- Manutenzione ed evoluzione: è forse la trasformazione più sottovalutata; i codebase legacy e il codice considerato "troppo rischioso da toccare" (too risky to touch) perché compreso solo dagli autori originali possono essere esplorati, rifattorizzati, migrati tra framework, aggiornati nelle API deprecate e dotati di test moderni in sicurezza. 1
Vedi anche: Slice Sottili e Ciclo di Feedback, Harness Engineering, Non Determinismo del Software, Context Engineering, Modello Fabbrica, Conduttori e Orchestratori, Economia dello Sviluppo AI, Addy Osmani