Negli ultimi mesi sto osservando una cosa curiosa: il mondo dello sviluppo software si sta spaccando in due fazioni opposte e radicali, e nessuna delle due mi convince del tutto.
Da un lato ci sono gli entusiasti dell’automazione totale: hanno abbracciato gli agenti IA, sognano la software factory che si governa da sola e dichiarano di poter fare tutto da soli. L’idea stessa di squadra, per loro, è un orpello del passato.
Dall’altro ci sono i puristi: demonizzano ogni riga di codice generata da un modello, la considerano incomprensibile, impossibile da mantenere e destinata a far saltare i sistemi sul lungo periodo.
Io scrivo software dal 1981: sono 45 anni, tra codice scritto e team guidati. La mia risposta è quella di sempre: la verità sta nel mezzo, ma con una spinta decisa verso il futuro. Dopo il keynote di DHH ne avevo già scritto in Da chi scrive codice a chi risolve problemi. Qui entro nel merito delle paure, e vi racconto come lavoro davvero.
In due righe
- Le paure dei detrattori sono in gran parte fondate, ma riguardano il metodo, non lo strumento.
- L’IA non uccide il team: lo rende più snello e più veloce. Il ruolo di chi guida resta lo stesso: chiedere bene, progettare, verificare.
- Il processo si ribalta: prima il prototipo funzionante, poi la rifinitura e l’ingegnerizzazione insieme al team.
Le paure dei detrattori: allarme reale o resistenza al cambiamento?
Capisco i dubbi di chi frena. La perdita di controllo sul codice, l’accumulo di debito tecnico e la proliferazione di “sviluppatori improvvisati” che non conoscono le basi del system design o della sicurezza sono rischi concreti. Se non capisci come funziona ciò che l’IA ti suggerisce, prima o poi il sistema ti esploderà in mano.
Simon Willison, che ha scritto più di chiunque altro sull’uso serio di questi strumenti, mette il confine esattamente lì: il vibe coding è costruire software con un LLM senza rivedere il codice che scrive. E la sua regola vale anche per chi non fa vibe coding:
“I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”
“Non faccio commit di codice che non saprei spiegare esattamente a qualcun altro.”
Detto questo, il problema non è un’esclusiva dell’intelligenza artificiale. Chi si improvvisa fa danni in qualsiasi settore: nell’informatica, nel marketing, in cucina, nell’idraulica. Non basta un manuale delle istruzioni o un prompt azzeccato per sostituire esperienza e competenza. La qualità del software non è mai nata per caso: è processo, test, review. Su F.technology ne avevamo parlato in Quality Assurance e il successo del software, e con l’IA è più vero di prima.
La vera criticità, quindi, non è lo strumento ma la pretesa di usarlo senza metodo. E giudicare l’impatto dell’IA guardando solo ai limiti di oggi è un errore miope: gli strumenti cambiano ogni pochi mesi. Fermarsi a criticare le imperfezioni di ieri significa restare ancorati a un passato che, piaccia o no, verrà superato.
L’IA non uccide il team: lo potenzia
Perché io, che dirigo team da decenni, guardo con favore questa rivoluzione agentica? Perché quel modello lo conosco già.
Guidare un team di sviluppo umano non è poi così diverso dal guidare una squadra di agenti IA specializzati. In entrambi i casi il mio ruolo è formulare le richieste giuste, definire l’architettura generale e verificare che gli output siano fatti a regola d’arte. Non devo scrivere ogni riga di codice perché un progetto funzioni: devo saper orchestrare le competenze. Da product owner della nostra software factory (siamo circa quindici persone) lo so bene: il software lo controllo dagli ingressi e dalle uscite, non da dentro.
Per questo non credo allo sviluppatore del tutto solitario. Il team resta indispensabile per il confronto, per i problemi complessi, per coprire i rischi. È una posizione che non nasce con l’IA: sul blog di F.technology avevamo già scritto perché la specializzazione profonda batte il generalismo superficiale. Quello che cambia è la dimensione e il ritmo: squadre più snelle, ma molto più rapide. Come la vedo oggi, e dove sto ancora ragionando, lo trovate in questo articolo.
Come cambia il flusso: dal prototipo alla finitura
Il vantaggio che vivo ogni giorno è l’abbattimento degli intermediari e dei tempi morti.
Lavoro di notte o la mattina presto? Ho un’idea mentre sono in giro? Prendo il telefono, parlo con l’IA, imposto la struttura e ritrovo tutto pronto nel sistema quando torno alla scrivania.
Questo ha ribaltato il classico processo di sviluppo:
- Prima: il tempo degli sviluppatori costava troppo per rischiare. Si partiva da specifiche rigide, mock-up definiti e flussi approvati prima di toccare una riga di codice. È la logica della nostra fase di Discovery & Design.
- Oggi: le fasi si invertono. Posso creare e testare un prototipo funzionante in poche ore direttamente con l’IA, per poi rifinirlo, ottimizzarlo e ingegnerizzarlo insieme al team in un secondo momento.
La fase di progetto non sparisce: cambia il momento in cui la facciamo, perché discutere su qualcosa che funziona è molto più concreto che discutere su un documento. È lo stesso approccio con cui sto avviando i miei progetti interni, quelli di cui parlo in Da chi scrive codice a chi risolve problemi.
L’intelligenza artificiale non è la fine della programmazione: è la fine della burocrazia nel codice e l’inizio di una nuova era di prototipazione rapida.
E voi, da che parte state: entusiasti, puristi o nel mezzo? Raccontatemelo nei commenti o scrivetemi direttamente.
Per approfondire
- Francamente.tech, Da chi scrive codice a chi risolve problemi: il mestiere cambia, non sparisce
- Francamente.tech, Intelligenza Artificiale: che fastidio!
- Francamente.tech, AI ucciderà il business di internet?
- Francamente.tech, Oltre la Comfort Zone dell’AI: il mio diario per automatizzare l’impossibile
- F.technology, Lo sviluppo software custom
- F.technology, Processo di sviluppo di un’applicazione custom
- F.technology, Quality Assurance e il successo del software
- F.technology, La falsa promessa del programmatore tuttofare
- Simon Willison, Not all AI-assisted programming is vibe coding (2025)
Questo articolo è stato pubblicato in precedenza su francamente.tech.
