Dal rumore mediatico al cambiamento reale

La trasformazione dello sviluppo prodotto con AI può essere letta come una sequenza di “ondate” (waves). Non si tratta di una semplice evoluzione degli strumenti di programmazione, ma di un cambiamento progressivo nel modo in cui i team pensano, progettano, realizzano e controllano i prodotti digitali.

All’inizio l’AI è entrata nei team come supporto alla scrittura del codice. Poi ha iniziato ad assumere capacità operative, trasformandosi in agente. Successivamente è diventato evidente che non bastava più “chiedere bene”: servivano contesto, specifiche, architetture e vincoli. Oggi il tema si sta spostando ancora più avanti: non solo usare agenti AI, ma costruire l’ambiente in cui quegli agenti possano lavorare in modo affidabile, controllato e coerente.

Il dibattito pubblico sull’AI nello sviluppo software è pieno di affermazioni radicali: l’AI sostituirà i programmatori, il SaaS è morto, il vibe coding è il futuro, il vibe coding non è il futuro, programmare non servirà più, programmare sarà più importante di prima. Questi titoli raccontano bene il clima del momento, ma rischiano di confondere più che chiarire.

Cambiare prospettiva

La questione non è stabilire se l’AI “ucciderà” la programmazione. La questione più interessante è capire come cambia il lavoro di chi sviluppa prodotti digitali. L’AI non elimina automaticamente il bisogno di competenza: rende più visibile la differenza tra chi sa governare il sistema e chi si limita a produrre output.

Il cambiamento, però, non è più teorico. L’adozione di strumenti AI-assisted è ormai entrata nel lavoro quotidiano di molti sviluppatori. In alcune organizzazioni una parte significativa del codice viene già generata con supporto AI. Anche attività che un tempo sembravano lontane dalla generazione automatica — pianificazione, analisi dei requisiti, backlog management, test, sintesi delle riunioni — iniziano a essere supportate da agenti e strumenti intelligenti.

Questo modifica il ritmo del lavoro. Le attività si comprimono, i clienti si aspettano soluzioni più rapide e personalizzate, i ruoli tradizionali iniziano a cambiare. Nascono nuove professionalità e, soprattutto, cambia il mindset richiesto ai team di prodotto.

 

Wave 0: code completion e chatbot

La prima wave può essere collocata intorno al 2022, quando l’AI entra nello sviluppo prodotto sotto forma di code completion e chatbot. È la fase in cui strumenti come GitHub Copilot e ChatGPT mostrano per la prima volta un potenziale concreto nel lavoro quotidiano.

 

Copilot porta l’AI dentro l’editor. Anticipa la riga successiva, suggerisce frammenti di codice, rende più fluida la scrittura. È un cambiamento semplice ma potente: per la prima volta la macchina non si limita a eseguire istruzioni, ma partecipa alla produzione del codice.

ChatGPT allarga il campo. Non si parla più solo di completare codice, ma di scrivere storie, analizzare requisiti, generare test, spiegare frammenti complessi, ragionare su possibili soluzioni. L’AI diventa un interlocutore cognitivo, uno strumento con cui esplorare problemi e produrre materiale di lavoro.

In questa fase, però, l’umano resta saldamente al centro dell’operatività. Il chatbot risponde, suggerisce, spiega. Ma interpretare, copiare, adattare, integrare ed eseguire resta responsabilità della persona. L’AI è un assistente, non ancora un collaboratore operativo.

 

Wave 1: agenti di codifica e vibecoding

La wave successiva arriva quando l’AI smette di limitarsi alla conversazione e comincia ad agire sugli artefatti di lavoro. Gli agenti di codifica non rispondono soltanto a una domanda: leggono e scrivono file, usano strumenti, modificano una codebase, interagiscono con l’ambiente esterno.

 

Questo passaggio cambia profondamente il rapporto tra sviluppatore e AI. Con un chatbot si conversa, con un agente si lavora insieme. L’agente diventa una sorta di collaboratore operativo a cui si può affidare una parte del processo di realizzazione.

È in questo contesto che nasce il vibecoding: un modo di programmare in cui si descrive in linguaggio naturale cosa si vuole ottenere e si lascia che l’AI generi o modifichi il codice. L’esperienza iniziale è spesso euforica. Si ha la sensazione di procedere a una velocità prima impensabile, quasi di avere dei superpoteri. In poche ore si possono ottenere prototipi che, fino a poco tempo prima, avrebbero richiesto giorni se non settimane.

Questa accelerazione è reale, soprattutto nei progetti nuovi, nei prototipi e nei contesti a bassa complessità. Quando non esiste ancora una codebase stratificata, quando le dipendenze sono limitate e quando il dominio è abbastanza circoscritto, l’AI può produrre rapidamente risultati sorprendenti.

 

Ma dopo l’euforia arriva la riflessione. Il codice generato può contenere scorciatoie, scelte non richieste, duplicazioni, allucinazioni, soluzioni plausibili ma fragili. Più cresce la codebase, più aumentano le dipendenze e più diventano importanti le decisioni pregresse, più il vibecoding mostra i suoi limiti.

Nei sistemi legacy, in particolare, il problema non è soltanto scrivere codice che funzioni in astratto. Il problema è scrivere codice coerente con una storia. Ogni sistema reale porta con sé convenzioni, eccezioni, compromessi tecnici, vincoli architetturali, dipendenze organizzative e ragioni spesso implicite dietro le scelte fatte nel tempo.

È qui che emerge il tema del contesto. L’AI vede spesso solo una piccola parte del sistema: alcune righe di codice, qualche file, una descrizione parziale del problema. Ma sotto la superficie ci sono dominio, utenti, architettura, vincoli, dipendenze storiche e razionali decisionali. Senza questo contesto, l’AI può produrre codice formalmente plausibile ma sostanzialmente sbagliato.

 

Per questo la fase del vibecoding richiede un’etica professionale molto chiara. Anche se il codice viene generato da un’AI, la responsabilità resta umana. Non si dovrebbe mettere in produzione nulla che non si comprende. L’AI non è una scusa per abbassare la qualità: al contrario, dovrebbe spingere verso codice più pulito, testato e manutenibile. L’AI amplifica la capacità dello sviluppatore, ma non sostituisce la sua responsabilità.

 

Wave 2: dal prompt al context engineering

La seconda ondata nasce proprio dai limiti del vibecoding. Diventa evidente che non basta trovare il prompt giusto. Non si può governare un sistema complesso affidandosi a una sequenza di richieste estemporanee, anche se formulate bene.

Il passaggio decisivo è dal prompt engineering al context engineering. Non si cerca più soltanto la frase perfetta da dare all’AI, ma si costruisce un ambiente informativo in cui l’AI possa lavorare meglio. Questo ambiente è fatto di requisiti, vincoli, architettura, decisioni, esempi, test, regole di dominio e criteri di accettazione.

 

Qui entra in gioco lo Specification Driven Development. L’idea di fondo è che la specifica diventi il ponte tra intenzione di prodotto e implementazione. Prima si chiarisce il bisogno, poi si esplicitano le scelte architetturali, infine si scompone il lavoro in task eseguibili. L’AI non viene lasciata libera di interpretare genericamente una richiesta, ma viene guidata attraverso artefatti più solidi e coerenti.

 

Questo approccio cambia il ruolo della documentazione. La specifica non è più un documento morto, scritto per adempiere a un processo. Diventa un artefatto operativo: serve a orientare l’agente, a ridurre ambiguità, a mantenere coerenza e a rendere verificabile il lavoro prodotto.

 

In questa prospettiva, il ciclo di sviluppo assistito dall’AI può essere ripensato come un workflow articolato. Si parte dall’envisioning e dal brainstorming, si passa al design e alla prototipazione, si arriva alla pianificazione e poi all’implementazione. Gli agenti non intervengono solo nella scrittura del codice, ma lungo tutto il percorso.

Fase 1

Nella fase di envisioning, gli agenti possono aiutare a definire la vision, esplorare i bisogni degli utenti, analizzare mercato e concorrenti, mettere in discussione assunzioni deboli. Possono agire come consulenti sempre disponibili, capaci di fare domande, proporre alternative e rendere più robusta la strategia iniziale.

Fase 2

Nella fase di design, l’AI può contribuire sia all’esperienza utente sia al system design. Può aiutare a ragionare su flussi, wireframe, struttura dell’interfaccia, architettura logica, pattern tecnologici e scelte di base. Il valore sta nel collegare più rapidamente prospettive che spesso restano separate: prodotto, UX, architettura e tecnologia.

Fase 3

Nella fase di pianificazione, l’AI può trasformare l’intenzione in lavoro organizzato: user stories, specifiche di dettaglio, criteri di accettazione, dipendenze, priorità, backlog. Il punto non è automatizzare il Product Owner o l’analista, ma rendere più veloce e più coerente la traduzione tra idea e piano di esecuzione.

Fase 4

Nella fase di implementazione, gli agenti possono scrivere task, generare codice, produrre test automatici e supportare la code review. Ma anche qui l’umano resta il regista. Deve osservare, chiedere spiegazioni, separare la scrittura dei test dalla logica di business, controllare che il codice rispetti standard, intenzioni e vincoli del progetto.

 

Con specifiche migliori e workflow più strutturati, gli agenti diventano più efficaci. Producono più codice, più rapidamente e con maggiore autonomia. Ma proprio questa efficacia genera un nuovo problema: come si controlla che tutto questo output sia davvero affidabile, sicuro, manutenibile e coerente?

 

Wave 3: Harness Engineering

La wave successiva nasce da questo interrogativo: se gli agenti diventano sempre più potenti e autonomi, allora il punto non è soltanto istruirli meglio. Il punto è costruire l’“imbracatura” che permette di governarne la potenza.

 

La metafora del cavallo, dell’imbracatura e del cavaliere aiuta a chiarire il concetto. Il cavallo è il modello di intelligenza artificiale: potente, veloce, capace di generare enormi quantità di output, ma privo di una direzione intrinseca. L’imbracatura è l’insieme di infrastruttura, vincoli, guardrail, sistemi di test e orchestrazione che incanalano quella potenza. Il cavaliere è l’ingegnere umano, il cui compito non è più soltanto scrivere codice, ma costruire l’ambiente in cui l’agente può lavorare bene.

 

Questo è il terreno dell’Harness Engineering. Non si governa l’AI solo con prompt migliori o specifiche più dettagliate, ma con un sistema complessivo che renda possibile l’autonomia controllata.

Servono contesti strutturati e single source of truth, in modo che gli agenti sappiano dove trovare le informazioni corrette. Servono regole e guardrail, per definire confini, convenzioni, limiti e comportamenti ammessi. Servono sensori e sistemi di verifica, per osservare ciò che gli agenti producono, raccogliere feedback e attivare meccanismi di correzione.

Serve anche una guida nel tempo. Gli agenti devono poter lavorare con memoria: non una memoria generica, ma una memoria utile delle decisioni prese, degli errori corretti, delle scelte architetturali e dei vincoli emersi. Senza questa continuità, ogni interazione rischia di ripartire da zero.

Un altro tema è la gestione dell’entropia. Più gli agenti producono codice, più aumenta il rischio di accumulare codice morto, documentazione incoerente, duplicazioni, soluzioni ridondanti e complessità non necessaria. L’Harness Engineering deve quindi includere pratiche e strumenti per mantenere il sistema comprensibile e sano nel tempo.

Infine c’è l’affidabilità. Se gli agenti operano con maggiore autonomia, devono esistere controlli di sistema, verifiche continue, patrol automatici, meccanismi di audit e segnali che permettano di intercettare i problemi prima che diventino danni reali.

 

Il nuovo ruolo dello sviluppatore

Man mano che si attraversano queste waves, il ruolo dello sviluppatore cambia. Nella prima fase usa l’AI come assistente. Nella seconda la guida come agente operativo. Nella terza costruisce contesto e specifiche per orientarla. Nella quarta progetta l’ambiente in cui l’agente può lavorare con autonomia controllata.

Lo sviluppatore non sparisce. Anzi, il suo ruolo diventa più esigente. Deve comprendere il dominio, progettare sistemi di controllo, definire guardrail, verificare qualità, mantenere coerenza architetturale, costruire feedback loop e prevenire l’accumulo di complessità inutile.

Il passaggio è da fare ad abilitare. Non significa che lo sviluppatore non scriverà più codice, ma che il valore professionale si sposterà sempre più dalla produzione diretta di righe di codice alla capacità di creare le condizioni perché il codice prodotto dagli agenti sia utile, sicuro, comprensibile e manutenibile.

 

Cosa cambia per lo sviluppo prodotto

Questa evoluzione riguarda tutti, non solo gli sviluppatori. Product Manager, Product Owner, Designer, Analyst, Architect, Tester, Engineering Manager e Stakeholder di business dovranno ripensare il proprio modo di lavorare.

Se l’AI accelera la produzione, allora diventano ancora più importanti la qualità delle decisioni, la chiarezza del contesto, la capacità di prioritizzare e la responsabilità del controllo. Produrre più velocemente non basta. Anzi, produrre più velocemente senza un sistema di governo può aumentare il rischio di generare soluzioni sbagliate, fragili o difficili da mantenere.

Il vero rischio, quindi, non è che l’AI cambi troppo le nostre pratiche. Il vero rischio è restare fermi mentre il sistema cambia intorno a noi. C’è una finestra in cui sperimentare, imparare e costruire nuovi standard. Non è detto che resti aperta a lungo.

 

Una possibile conclusione

La direzione che emerge è chiara: l’AI non elimina la necessità di metodo, disciplina e responsabilità. Le rende più importanti.

Nelle prime wave sembrava che il vantaggio competitivo fosse saper usare bene i prompt o generare codice più rapidamente. Oggi appare più probabile che il vantaggio stia nella capacità di costruire contesto, specifiche, workflow, guardrail e sistemi di controllo.

Lo sviluppo prodotto con AI non sarà semplicemente più veloce. Sarà diverso. Meno centrato sulla scrittura manuale del codice, più centrato sull’orchestrazione di competenze, agenti, artefatti e vincoli. Meno improvvisazione, più progettazione del sistema di lavoro. Meno attenzione alla singola richiesta, più attenzione all’ambiente in cui le richieste vengono interpretate ed eseguite.

Cosa succede ad Agile e Scrum?

In questo scenario, Agile non viene necessariamente superato. Viene spinto a evolvere. I suoi principi di collaborazione, feedback, adattamento e responsabilità restano validi, ma devono essere riletti dentro un contesto in cui la velocità di produzione aumenta e la capacità di controllo diventa decisiva.

Scrum, al tempo stesso, non deve essere difeso come insieme di cerimonie immutabili. Può diventare un sistema più leggero e più intelligente di coordinamento, ispezione e adattamento. Ma per farlo deve spostare l’attenzione dai rituali alla qualità del flusso decisionale, dal backlog come lista di cose da fare alla specifica come artefatto vivo, dalla delivery come produzione di output alla supervisione continua di un sistema sociotecnico in cui umani e agenti lavorano insieme.

La responsabilità resta all’essere umano

La responsabilità finale resta umana. Non si dovrebbe mettere in produzione ciò che non si comprende. Non si dovrebbe accettare codice scadente solo perché prodotto rapidamente. Non si dovrebbe confondere l’autonomia degli agenti con la delega cieca.

L’AI è un amplificatore. Per questo diventa ancora più importante sapere che cosa si vuole amplificare.