Per qualche mese il vibe coding è sembrato rappresentare il futuro dello sviluppo software.

L’idea era semplice e, proprio per questo, irresistibile: descrivere ciò che si vuole ottenere, lasciare che un modello generativo scriva il codice e continuare a iterare finché il risultato non “sembra funzionare”.

Il termine è diventato popolare perché descriveva perfettamente una nuova esperienza di sviluppo: meno attenzione alla sintassi, meno tempo trascorso a scrivere codice riga per riga e molta più interazione con sistemi di intelligenza artificiale capaci di generare intere funzionalità.

Ma il vero punto interessante non è il successo del vibe coding.

È ciò che è successo subito dopo.

Quando questi sistemi sono passati dai prototipi ai prodotti reali, è diventato evidente che generare software velocemente non significa necessariamente costruire software affidabile.

Ed è qui che il dibattito sta cambiando.

Oggi si parla sempre meno di vibe coding e sempre più di agentic engineering: un modello nel quale l’intelligenza artificiale può svolgere una parte crescente del lavoro di implementazione, mentre l’essere umano mantiene la responsabilità su architettura, qualità, sicurezza e decisioni.

La differenza può sembrare sottile.

In realtà è sostanziale.

Il problema del vibe coding non è l’intelligenza artificiale

Il limite del vibe coding non nasce dal fatto che il codice venga scritto da una macchina.

Nasce dal fatto che, nel suo significato più radicale, il vibe coding tende a eliminare proprio quelle attività che rendono il software ingegneria:

progettazione, revisione, verifica, testing e responsabilità.

Il ciclo è tipicamente questo:

si descrive una funzionalità, il modello genera il codice, si esegue il programma e, se qualcosa non funziona, si restituisce l’errore al modello chiedendo una correzione.

Il risultato può essere sorprendentemente efficace per prototipi, strumenti personali, esperimenti o applicazioni a basso rischio.

Il problema emerge quando lo stesso approccio viene trasferito senza modifiche in sistemi destinati alla produzione.

Perché un software che funziona oggi non è necessariamente un software che potrà essere mantenuto domani.

E un software che supera una demo non è necessariamente un software sicuro, osservabile, scalabile o comprensibile da un team.

La questione, quindi, non è stabilire se l’AI debba scrivere codice.

Probabilmente ne scriverà sempre di più.

La questione è stabilire chi mantiene la responsabilità ingegneristica del sistema.

Dal codice generato al software governato

L’agentic engineering parte da un principio diverso.

L’AI non è semplicemente un generatore di codice.

Diventa un soggetto operativo all’interno di un processo progettato e governato.

Può analizzare una codebase, modificare file, scrivere test, eseguire comandi, individuare errori, proporre refactoring e perfino sviluppare intere funzionalità.

Ma opera all’interno di vincoli definiti. L’ingegnere non scompare. Cambia ruolo.

La sua attività si sposta progressivamente dalla produzione diretta del codice alla definizione del problema, dell’architettura e dei criteri attraverso i quali valutare il risultato.

In altre parole:

l’AI può diventare l’esecutore, ma la responsabilità resta umana.

Ed è probabilmente questa la vera evoluzione dello sviluppo software assistito dall’intelligenza artificiale.

Il nuovo collo di bottiglia non è scrivere codice

Per decenni gran parte della produttività nello sviluppo software è stata legata alla capacità di trasformare rapidamente una specifica in codice funzionante.

Con i modelli generativi questo vincolo si sta riducendo drasticamente.

Produrre codice sta diventando sempre più economico.

Questo sposta il collo di bottiglia.

Il problema non è più soltanto: Quanto velocemente possiamo implementare questa funzionalità?

Diventa: Siamo sicuri di aver definito correttamente ciò che deve essere costruito?

E subito dopo: Siamo in grado di verificare che ciò che è stato prodotto sia corretto?

Queste domande rendono molto più importanti attività che in passato potevano essere considerate accessorie rispetto alla scrittura del codice.

• Specifiche.
• Architettura.
• Testing.
• Code review.
• Security review.
• Observability.
• Documentazione.

La generazione automatica del codice non riduce la necessità di queste discipline. Paradossalmente, la aumenta.

Più codice siamo in grado di produrre, più diventano importanti i sistemi con cui decidiamo quale codice accettare.

Il rischio nascosto: il debito cognitivo

Il debito tecnico è un concetto conosciuto da qualsiasi team di sviluppo.

Esiste però una nuova forma di debito che diventa particolarmente rilevante quando il software viene costruito attraverso agenti AI.

Possiamo chiamarlo debito cognitivo.

È la distanza crescente tra ciò che il sistema contiene e ciò che il team comprende realmente.

Può nascere molto velocemente.

Un agente modifica dieci file.

Poi venti.

Poi introduce nuove astrazioni, nuove dipendenze e nuovi pattern.

Il sistema continua a funzionare.

Il team approva le modifiche perché i test passano.

Ma progressivamente nessuno possiede più un modello mentale completo di ciò che sta succedendo.

Questo è uno dei rischi più importanti dello sviluppo assistito dall’AI.

Non perché l’AI produca necessariamente codice peggiore.

Ma perché può produrre codice molto più velocemente di quanto gli esseri umani riescano a comprenderlo.

Se la velocità di generazione supera sistematicamente la capacità di revisione, il risultato non è maggiore produttività.

È semplicemente maggiore quantità di software non compreso.

La specifica diventa parte del codice

In questo nuovo paradigma cambia anche il valore delle specifiche.

Nel modello tradizionale una specifica descriveva ciò che un programmatore avrebbe dovuto implementare.

Nel modello agentico la specifica diventa quasi un elemento eseguibile del processo di sviluppo.

Più è precisa, più aumenta la probabilità che un agente produca un risultato corretto.

Una richiesta come:

“Costruisci un sistema di autenticazione”

lascia all’agente una quantità enorme di decisioni implicite.

• Quale modello di autenticazione?
• Quale storage?
• Come vengono gestite le sessioni?
• Quali policy di sicurezza?
• Quale strategia di recovery?
• Quali log devono essere prodotti?
• Quali condizioni devono essere testate?

Una richiesta agentica efficace riduce invece lo spazio decisionale non controllato.

Descrive il risultato atteso. Definisce i vincoli. Indica i componenti esistenti da utilizzare.

Specifica gli edge case.

Stabilisce i criteri di accettazione.

È qui che emerge una nuova competenza fondamentale.

Non il prompt engineering inteso come capacità di trovare una formulazione magica.

Ma la capacità di formalizzare problemi in modo sufficientemente chiaro da poter essere delegati.

È una competenza profondamente ingegneristica.

Il ruolo dello sviluppatore cambia: da autore ad architetto

Se gli agenti continueranno a migliorare, gli sviluppatori scriveranno probabilmente una percentuale sempre minore del codice applicativo direttamente.

Questo non significa che la loro importanza diminuirà. Significa che il valore si sposterà.

Diventeranno centrali quattro capacità.

La prima è capire quale problema valga davvero la pena risolvere.

La seconda è progettare l’architettura all’interno della quale l’agente dovrà operare.

La terza è valutare criticamente ciò che viene prodotto.

La quarta è assumersi la responsabilità della decisione finale.

Questa trasformazione ricorda ciò che è già accaduto molte volte nella storia dell’informatica.

I linguaggi di alto livello non hanno eliminato i programmatori assembly rendendo inutile la programmazione.

Hanno semplicemente spostato il livello di astrazione.

Framework, cloud e servizi gestiti hanno fatto lo stesso.

Gli agenti AI stanno spostando nuovamente il livello di astrazione.

Il developer non deve necessariamente decidere ogni istruzione.

Deve progettare il sistema nel quale quelle istruzioni vengono prodotte.

L’AI rende l’ingegneria più importante

Questo porta a un paradosso interessante.

All’inizio dell’ondata generativa sembrava possibile immaginare uno sviluppo software sempre meno dipendente dalle competenze ingegneristiche.

Se basta descrivere un’applicazione e lasciare che l’AI la costruisca, a cosa servono architetti, senior developer, code review e metodologie?

La realtà sembra andare nella direzione opposta.

Più potente diventa l’automazione, più aumenta il costo degli errori prodotti su larga scala.

Un errore umano può generare una modifica sbagliata.

Un sistema automatizzato può replicare lo stesso errore centinaia di volte.

Per questo l’adozione degli agenti richiede governance.

Servono confini chiari.

• Permessi.
• Test automatici.
• Review.
• Controlli di sicurezza.
• Osservabilità.
• Possibilità di rollback.

In altre parole, tutto ciò che distingue un esperimento da un sistema industriale.

Vibe coding e agentic engineering non sono nemici

Sarebbe però un errore considerare il vibe coding semplicemente una pratica sbagliata.

Ha un ruolo preciso. È straordinariamente efficace per esplorare. Per prototipare. Per trasformare un’idea in qualcosa di visibile in poche ore. Per creare strumenti personali. Per verificare rapidamente un’ipotesi.

Il problema nasce quando si utilizza la stessa modalità operativa per costruire sistemi che devono essere mantenuti, protetti e utilizzati da altre persone.

Possiamo quindi vedere i due approcci come due modalità diverse.

Vibe coding per esplorare.

Agentic engineering per industrializzare.

Il primo massimizza la velocità di scoperta.

Il secondo massimizza la capacità di trasformare quella scoperta in un sistema affidabile.

La maturità consiste soprattutto nel capire quando smettere di fare il primo e iniziare a fare il secondo.

La vera competenza sarà progettare sistemi di lavoro per gli agenti

Nel breve periodo la discussione continuerà probabilmente a concentrarsi sui modelli e sugli strumenti.

• Quale agente scrive meglio codice.
• Quale IDE integra meglio l’AI.
• Quale modello risolve più benchmark.

Ma nel lungo periodo il vantaggio competitivo potrebbe trovarsi altrove.

Nella capacità di costruire processi di engineering pensati per sistemi composti da persone e agenti.

Un buon team non utilizzerà semplicemente un modello migliore.

Costruirà un ambiente nel quale gli agenti possano lavorare bene con

• Contesto strutturato.
• Specifiche chiare.
• Accesso controllato agli strumenti.
• Task piccoli e verificabili.
• Test automatici.
• Code review.
• Feedback continui.
• Metriche.
• Guardrail.

È un cambiamento importante perché significa smettere di pensare all’AI come a un assistente occasionale.

E iniziare a considerarla una nuova componente dell’organizzazione del lavoro.

La mia posizione

Il vibe coding ha un merito fondamentale: ha mostrato quanto possa essere potente l’interazione naturale con il software.

Ha abbassato drasticamente il costo della sperimentazione.

Ha permesso a molte più persone di trasformare rapidamente idee in prototipi.

Ma non rappresenta il punto di arrivo.

La prossima fase sarà caratterizzata da un’integrazione molto più profonda tra capacità generative e disciplina ingegneristica.

Non meno progettazione ma più progettazione.

Non meno controllo ma controlli migliori.

Non meno competenze tecniche ma competenze tecniche spostate verso livelli di astrazione più alti.

Il futuro dello sviluppo software non sarà quello in cui gli esseri umani scrivono ogni riga di codice.

Ma non sarà nemmeno quello in cui smettono di capire ciò che viene costruito.

Sarà un modello nel quale macchine estremamente veloci producono soluzioni all’interno di sistemi progettati, verificati e governati da persone.

Ed è forse questa la distinzione più utile da fare oggi:

vibe coding significa delegare la scrittura del codice.

Agentic engineering significa progettare il sistema attraverso cui quella delega diventa affidabile.