Cosa significa davvero "agentic engineering" per chi commissiona software

Nel giro di un paio d’anni il modo in cui si parla di sviluppo assistito da AI è cambiato radicalmente. Prima il termine di moda era “vibe coding”: si descrive un modo di programmare guidato dall’istinto e dall’iterazione rapida con un modello, spesso senza leggere con attenzione il codice generato, purché “funzioni”. Poi il vento è girato, e con buone ragioni: quel modo di lavorare, applicato a software che deve reggere nel tempo, produce sistemi che nessuno capisce davvero — nemmeno chi li ha “scritti”.

Il termine che si è affermato al suo posto, “agentic engineering”, descrive qualcosa di diverso nella sostanza, non solo nel nome. Non è “lascio che l’AI scriva, poi guardo se gira”. È orchestrare strumenti automatizzati dentro un processo ingegneristico che resta sotto controllo umano esplicito: chi decide l’architettura, chi definisce i contratti tra i moduli, chi rivede ogni pull request, chi si prende la responsabilità di quello che va in produzione.

Perché la differenza conta per chi paga il progetto

Se sei un’azienda che commissiona software, la domanda giusta da fare a chi te lo costruisce non è “usi l’AI?” — nel 2026 quasi tutti la usano, in un modo o nell’altro, ed è una domanda che non ti dice nulla di utile. La domanda giusta è: chi è responsabile del codice che mi consegni, e come lo verifichi?

Un fornitore che lavora in modalità “agentic engineering” seria ti sa rispondere con dettagli concreti: test automatizzati che girano prima di ogni deploy, code review sistematica (anche quando il codice è stato generato con assistenza AI), documentazione delle decisioni architetturali, un processo per capire cosa succede se il sistema si comporta in modo inatteso tra sei mesi, quando magari il fornitore non è più lo stesso.

Un fornitore in modalità “vibe coding” spesso non ha una risposta strutturata a queste domande, perché il suo processo non le prevede: il criterio di successo è “il demo funziona”, non “il sistema è mantenibile”.

Il rischio silenzioso: il debito tecnico che non si vede al collaudo

La parte insidiosa è che, al momento della consegna, i due approcci possono produrre risultati visivamente identici. La differenza emerge sei, dodici, diciotto mesi dopo: quando serve aggiungere una funzionalità e nessuno capisce più perché una certa scelta era stata fatta in un certo modo, quando un bug in produzione richiede giorni invece di ore perché il codice non è mai stato pensato per essere letto da un altro essere umano, quando cambiare fornitore significa ripartire quasi da zero perché non esiste documentazione reale.

Uso strumenti AI nel mio lavoro, in modo mirato e sotto controllo — sarebbe assurdo il contrario, oggi. Ma il criterio con cui giudico se un pezzo di codice è pronto per la produzione non cambia di una virgola rispetto a dieci anni fa: deve essere leggibile, testato, e io devo poter spiegare ogni riga a chi me lo chiede. Se non riesco a farlo, quel codice non è finito, indipendentemente da come è stato scritto. È il criterio che applico nel metodo di lavoro che uso con ogni cliente.