Ci troviamo a un punto di svolta nello sviluppo software. La discussione verte spesso su quale se l'IA scriva il codice migliore (Claude vs. ChatGPT) o dove dove risieda l'IA (IDE o CLI). Ma questa è la discussione sbagliata.
Il vero problema non è la generazione del codice. Il vero problema è la validazione di questo.
Se abbracciamo l'IA come "Vibe Coders" – dove indichiamo l'intenzione e l'IA esegue – creiamo un enorme flusso di nuovo software. Uno sciame di agenti IA può generare in un minuto più codice di quanto uno sviluppatore senior possa revisionare in una settimana. L'essere umano è diventato il collo di bottiglia.
La soluzione non è altro le persone. La soluzione è un Autorità di Progettazione AI.
Tradizionalmente, la "Design Authority" è un piccolo gruppo di architetti che si riunisce una volta alla settimana o al mese per approvare o respingere un progetto. In un mondo di sviluppo AI ad alta velocità questo modello è irrimediabilmente obsoleto. È troppo lento e troppo reattivo.
Se passiamo al "Codice Usa e Getta" – software che non rifattorizziamo all'infinito, ma buttiamo via e rigeneriamo quando le esigenze cambiano – il nostro ruolo cambia radicalmente. Non siamo più muratori che posano pietra su pietra. Siamo gli architetti della fabbrica che stampa i muri.
Ma chi controlla se quei muri sono dritti?
Un'Autorità di Progettazione AI non è una persona, ma una pipeline. Un "Guanto di Sfida" (Gauntlet) attraverso il quale ogni riga di codice generato deve farsi strada per arrivare in produzione. Questo processo non sostituisce la revisione umana del codice niente, ma con qualcosa di migliore.
Funziona su tre livelli:
1. Il Potere Esecutivo (La Generazione)
Non chiediamo a una singola IA di fornire una soluzione, ne chiediamo tre. Facciamo lavorare in parallelo Gemini 3, GPT-5 e un modello open-source (come Llama) sullo stesso problema. Questo previene la visione a tunnel e supera la "pigrizia" di cui a volte soffrono gli LLM. Questo approccio è anche studiato scientificamente e dimostra che è possibile prevenire le allucinazioni dell'IA e costruire catene molto lunghe senza errori
2. Il Filtro Rigido (La Legge)
Qui non è ammissibile alcuna discussione. Il codice deve compilare. I linter non devono lamentarsi. E, cosa fondamentale: i Test Black Box devono avere successo. Non testiamo se la funzione funziona internamente (l'IA potrebbe manipolarlo), testiamo se il sistema fa ciò che deve fare dall'esterno. Il test fallisce? Direttamente nel cestino.
3. Il Filtro Morbido (La Giuria AI)
Questa è la vera innovazione. Le soluzioni rimanenti vengono sottoposte a una "AI di Voto" specializzata. Questo agente non scrive codice, ma legge codice. È addestrato sui nostri principi architetturali, requisiti di sicurezza (OWASP, ISO) e norme di conformità (EU AI Act).
Esprime il suo voto: “L'opzione A è più veloce, ma l'opzione B è più sicura e si adatta meglio alla nostra architettura a microservizi.”
Il vincitore passa alla produzione.
Questo modello impone una separazione dei poteri che manca in molti team.
project-description.md, rules.md en principles.md), i requisiti stringenti. L'architetto decide cosa cosa costruiamo e perché.
Ci libera dalla tirannia degli errori di sintassi e ci permette di concentrarci su ciò in cui eccelliamo: pensiero sistemico, ricerca della verità, struttura e processo decisionale.
La domanda non è se l'IA possa scrivere il nostro codice. Questo è già deciso. Il codice è in gran parte usa e getta.
La domanda è: hai il coraggio di lasciare andare il controllo sul esecuzione per riconquistare il controllo sul qualità ?