«Il gestionale? Ormai te lo scrive l’intelligenza artificiale in un pomeriggio.» È una frase che gira sempre più spesso, e ha un fondo di verità: oggi il codice lo scrivono in buona parte gli agenti AI. Proprio per questo sta emergendo una figura nuova, l’AI Architect: la persona che non batte più ogni riga sulla tastiera, ma decide cosa va costruito, coordina gli agenti che lo costruiscono e risponde del risultato.
Se stai per commissionare un software, questa figura ti riguarda più di quanto sembri. Perché da lei dipende la differenza fra una schermata che fa bella figura in riunione e uno strumento che regge il lavoro di tutti i giorni.
Chi è l’AI Architect e perché se ne parla adesso
Fino a poco tempo fa, chi cercava uno sviluppatore cercava uno specialista di uno strumento: quel linguaggio, quel framework, quella piattaforma. Il valore stava nel saper scrivere bene, e in fretta, in quella lingua.
Oggi la scrittura è la parte che costa meno. Un agente AI produce in pochi minuti il codice che prima richiedeva giorni. Quello che non produce è il progetto: come si incastrano i pezzi, quali dati comandano, cosa succede quando qualcosa va storto.
Chi lavora in cantiere conosce bene la distinzione. Posare un muro e progettare un edificio sono mestieri diversi, e nessuno affiderebbe il secondo a chi sa fare soltanto il primo, per quanto veloce sia. L’AI Architect è il progettista e il direttore dei lavori del software: non impasta la malta, ma sa perfettamente come si fa, e per questo si accorge subito quando un muro è storto.
Ieri
Lo specialista dello strumento
Si cercava: chi conosceva a fondo un linguaggio o una piattaforma.
Il tempo andava in: scrittura del codice, riga per riga.
Il collo di bottiglia: quante persone sapevano scrivere.
Oggi
L’AI Architect
Si cerca: chi capisce il sistema intero e il lavoro che deve servire.
Il tempo va in: analisi, istruzioni agli agenti, verifica.
Il collo di bottiglia: la qualità delle decisioni.
Come lavora un team guidato da un AI Architect
«Agente» è una parola che spaventa più del necessario. In pratica è un programma di intelligenza artificiale a cui affidi un compito preciso e che lo porta avanti da solo, passo dopo passo, finché non ha finito o non ha bisogno di te. Il lavoro dell’AI Architect è distribuire i compiti fra più agenti, ognuno con il suo ruolo. Lo schema minimo ne prevede tre.
- L’agente analista. Trasforma le esigenze raccolte in un documento di progetto: cosa deve fare il software, per chi, con quali regole. L’AI Architect lo legge, lo corregge, lo fa riscrivere finché non descrive davvero il lavoro del cliente.
- L’agente sviluppatore. Scrive il codice a partire da quel documento. È veloce, instancabile, e fa esattamente quello che gli viene chiesto. Nel bene e nel male.
- L’agente di controllo qualità. Rilegge il codice, cerca gli errori, scrive ed esegue i test. Può essere un altro agente istruito apposta, una persona, o tutti e due.
Il team minimo: una persona che decide, tre agenti che eseguono
una persona: capisce il problema, assegna i compiti, approva o rimanda indietro
Agente 1
Analista
Scrive il documento di progetto: funzioni, regole, casi particolari.
Agente 2
Sviluppatore
Scrive il codice seguendo il documento approvato.
Agente 3
Controllo qualità
Rilegge, prova, segnala ciò che non torna.
Il giro si ripete finché il risultato non regge. A ogni passaggio c’è una persona che guarda: nessun agente si approva da solo.
Nota una cosa: il primo agente non scrive codice, scrive un documento. È la parte che quasi tutti vorrebbero saltare ed è quella che decide il resto. Un agente a cui dai istruzioni vaghe costruisce in fretta, e bene, la cosa sbagliata. Per questo le specifiche di un software su misura contano oggi più di ieri, non meno.
Quando il progetto cresce, il team non si allarga aggiungendo programmatori. Si allarga per competenze: una persona che conosce a fondo il processo da gestire, un’altra forte sulla parte tecnica, ciascuna con i propri agenti. Chi conosce il problema guida il lavoro, e questa per un’azienda è una buona notizia.
| Attività | Cosa fanno bene gli agenti | Cosa resta alla persona |
|---|---|---|
| Analisi | Mettono in ordine gli appunti, propongono una struttura, trovano i buchi evidenti | Capire quale problema c’è dietro la richiesta |
| Scrittura del codice | Schermate, archivi, collegamenti, test: in fretta e con uno stile uniforme | Decidere come si incastrano le parti e cosa non va costruito |
| Verifica | Rileggono tutto, eseguono i test, segnalano gli errori | Giudicare se il risultato serve davvero al lavoro |
| Responsabilità | Nessuna | Tutta: verso il cliente e verso chi userà il software |
Dal prompt al prodotto: il salto che non si vede
Chiunque oggi può ottenere «qualcosa» scrivendo due righe a un’intelligenza artificiale. Una schermata con i campi giusti, un pulsante che salva, un elenco che si aggiorna. Ed è proprio qui che nasce l’equivoco: quel qualcosa assomiglia a un software finito.
Non lo è. Un software che usi tutti i giorni è fatto per la gran parte di cose che in una demo non compaiono mai.
Quello che si vede · arriva da un prompt
La schermata che funziona quando tutto va bene: inserisci, salvi, stampi.
Quello che non si vede · richiede un progetto
chi può vedere e modificare cosa
la connessione che cade a metà salvataggio
l’archivio di dieci anni, con i suoi doppioni
fatturazione, posta, altri programmi
cosa succede il giorno in cui si rompe qualcosa
la modifica che chiederai fra un anno
C’è poi un effetto di cui si parla poco. Scrivere il codice a mano aveva un pregio involontario: era lento. Mentre sviluppavi una cattiva idea, avevi il tempo di accorgerti che era cattiva. Oggi una cattiva idea diventa codice funzionante in un pomeriggio, completa di test, e da fuori sembra produttività. L’AI rende veloce tutto, anche l’errore.
Quasi sempre il conto arriva dopo, quando il programma ha utenti veri: ogni modifica tocca sei punti diversi, i dati non tornano, nessuno sa più spiegare perché una cosa funziona così. Sono le stesse ragioni per cui i progetti software falliscono da sempre. Con gli agenti succede solo più in fretta.
Cosa dicono i numeri: tutti usano l’AI, pochi si fidano alla cieca
Non è una nostra impressione. Nel sondaggio 2026 di Stack Overflow, il più ampio fra chi sviluppa software per mestiere, il 73% dichiara di usare assistenti e agenti di programmazione ogni giorno. Eppure, alla domanda su quando sia accettabile fidarsi dell’AI, le risposte si fanno prudenti.
Gli sviluppatori e l’AI: uso quotidiano e fiducia
Usa assistenti e agenti di programmazione ogni giorno
Si fida dell’AI quando può verificare facilmente la risposta
Estende la fiducia alla maggior parte dei compiti
Fonte: Stack Overflow Developer Survey 2026, sezione AI. Le tre domande hanno campioni diversi.
Tradotto: chi l’AI la usa tutti i giorni per lavoro si fida soprattutto di ciò che è in grado di controllare. L’anno prima, nello stesso sondaggio, due sviluppatori su tre indicavano come principale frustrazione le soluzioni «quasi giuste, ma non del tutto». È la descrizione più onesta che conosciamo del codice generato: quasi giusto. E in un gestionale il «quasi» è la fattura con l’importo sbagliato.
La base tecnica non si salta
Da qui un equivoco da sgombrare. Se l’AI Architect non scrive più il codice, allora può farlo chiunque sappia parlare con un’intelligenza artificiale? No. Per verificare bisogna saper leggere, e per saper leggere bisogna aver scritto, e sbagliato, parecchio.
Chi non ha mai programmato non ha modo di accorgersi che il codice è ordinato ma la responsabilità è finita nel posto sbagliato. Lo scopre mesi dopo, dagli effetti. È lo stesso discorso che facevamo a proposito di no-code e mentalità da programmatore: lo strumento abbassa la fatica, non la competenza richiesta per usarlo bene.
La nostra posizione è netta: gli anni passati a scrivere software non sono diventati inutili. Sono diventati il requisito per il mestiere nuovo.
Cosa cambia per te che commissioni un software
Che il tuo fornitore usi l’AI è ormai scontato, e non è né un merito né una colpa. La domanda utile è un’altra: chi c’è sopra gli agenti? Quattro domande da fare prima di firmare.
Quattro domande per il tuo fornitore
1. Chi ha capito il mio lavoro? Voglio parlare con la persona che decide come sarà fatto il software, non solo con chi me lo vende.
2. Chi rilegge il codice generato? E con quale esperienza alle spalle.
3. Cosa avete deciso di non costruire? Chi progetta davvero sa dirti anche dove ha detto di no, e perché.
4. Fra un anno chi ci mette le mani? Un programma che nessuno sa spiegare è un programma che nessuno sa modificare.
Un’ultima avvertenza sui prezzi. Lo sviluppo con gli agenti accorcia i tempi di scrittura, non quelli necessari a capire. Diffida di chi ti promette lo stesso gestionale a un decimo del costo: di solito ha tagliato proprio l’analisi e la verifica, cioè le due cose che gli agenti non fanno al posto tuo.
AI Architect: capire, orchestrare, valutare
Tre verbi riassumono il mestiere dell’AI Architect. Capire il sistema e il lavoro a cui deve servire. Orchestrare gli agenti che lo costruiscono. Valutare il risultato con l’occhio di chi ne risponde. Il primo e il terzo sono vecchi quanto il nostro mestiere; è cambiato quello in mezzo.
Per chi compra software la conseguenza è semplice. Il valore di un fornitore non sta più in quante righe sa scrivere, ma in quanto bene capisce il tuo lavoro prima di farne scrivere una. È da lì che partiamo anche noi: dal problema, non dallo strumento.
Se hai in mente un software, o ne hai uno fatto in fretta che comincia a scricchiolare, scrivici: guardiamo insieme cosa c’è da decidere prima di costruire. Senza impegno.
