Siamo a un punto di svolta nello sviluppo software. La discussione spesso riguarda quale se l'AI scrive il codice migliore (Claude vs. ChatGPT) o dove dove deve risiedere quell'AI (IDE o CLI). Ma non è questa la domanda giusta.
Il problema non è il generazione del codice. È la validazione di esso.
Se abbracciamo l'AI come “Vibe Coders” – dove indichiamo l'intento e l'AI esegue – creiamo un'enorme ondata di nuovo software. Uno sciame di agenti AI può generare in un minuto più codice di quanto un developer senior possa revisionare in una settimana. L'essere umano è diventato il collo di bottiglia.
La soluzione non è di più le persone. La soluzione è una Autorità di progettazione AI.
Tradizionalmente la “Design Authority” è un gruppo di architetti che si riunisce una volta alla settimana o al mese per approvare o rifiutare un progetto. In un mondo di sviluppo AI ad alta velocità quel modello è irrimediabilmente obsoleto. È troppo lento e reattivo.
Se passiamo al “Disposable Code” — software che non refattorizziamo all’infinito, ma buttiamo via e rigeneriamo quando cambiano i requisiti — allora il nostro ruolo cambia radicalmente. Non siamo più muratori che posano mattoni uno a uno. Siamo gli architetti della fabbrica che stampa i muri.
Ma chi controlla che quei muri siano dritti?
Una AI Design Authority non è una persona, ma una pipeline. Un “Guanto di Sfida” attraverso cui ogni riga di codice generato deve passare per arrivare in produzione. Questo processo non sostituisce la code review umana con niente, ma con qualcosa di migliore.
Funziona su tre livelli:
1. Il Potere Esecutivo (La Generazione)
Non chiediamo a una sola AI di trovare una soluzione, ne chiediamo tre. Facciamo lavorare in parallelo Gemini 3, GPT-5 e un modello open-source (come Llama) sullo stesso problema. Questo evita la visione a tunnel e rompe la “pigrizia” di cui a volte soffrono gli LLM. Questo approccio è anche scientificamente studiato e dimostra che si possono prevenire le allucinazioni dell’AI e costruire catene molto lunghe senza errori
2. Il Filtro Duro (La Legge)
Qui non ci sono discussioni possibili. Il codice deve compilare. I linter non devono lamentarsi. E, cosa cruciale: il Test a scatola nera devono passare. Non testiamo se la funzione funziona internamente (ciò potrebbe essere manipolato dall’IA), testiamo se il sistema dall’esterno fa ciò che deve fare. Il test fallisce? Diretto nel cestino.
3. Il Filtro Morbido (La Giuria AI)
Questa è la vera innovazione. Le soluzioni rimanenti vengono sottoposte a una “Voting AI” specializzata. Questo agente non scrive codice, ma legge codice. È addestrato sui nostri principi di architettura, requisiti di sicurezza (OWASP, ISO) e regole di conformità (EU AI Act).
Esprime il suo voto: “La Soluzione A è più veloce, ma la Soluzione B è più sicura e segue meglio la nostra architettura a microservizi.”
Il vincitore va in produzione.
Questo modello impone una separazione dei poteri che in molti team manca.
project-description.md, rules.md, skills.md en principles.md), i requisiti vincolanti. L'architetto determina cosa cosa costruiamo, chi lo costruisce, come e perché.
Ci libera dalla tirannia degli errori di sintassi e ci permette di concentrarci su ciò in cui siamo bravi: pensiero sistemico. Ricerca della verità. Struttura e processo decisionale.
La domanda non è se l’IA possa scrivere il nostro codice. Quella discussione è già chiusa. Il codice diventerà in gran parte un prodotto usa e getta.
La domanda è: Hai il coraggio di lasciare andare il controllo sul codice per lasciar prendere il controllo su qualità recuperare?
fammi sapere