We staan op een kantelpunt in softwareontwikkeling. De discussie gaat vaak over welke AI de beste code schrijft (Claude vs. ChatGPT) of dove die AI moet wonen (IDE of CLI). Maar dat is de niet de juiste vraagstelling.
Il problema non è generare di codice. È il validazione di esso.
Se abbracciamo l'IA come "Vibe Coders" – indicando l'intento e lasciando che l'IA esegua – creiamo un'enorme quantità di nuovo software. Uno sciame di agenti IA può generare in un minuto più codice di quanto un senior developer possa revisionare in una settimana. L'uomo è diventato il collo di bottiglia.
La soluzione non è più le persone. La soluzione è un AI Design Authority.
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à quel modello è ormai disperatamente obsoleto. È troppo lento e troppo reattivo.
Se passiamo a “Disposable Code” – software che non rifattorizziamo all'infinito, ma scartiamo 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 stampano le pareti.
Ma chi controlla se quelle pareti sono dritte?
Un'AI Design Authority non è una persona, ma una pipeline. Un “Gauntlet” attraverso cui ogni riga di codice generato deve combattere per arrivare in produzione. Questo processo non sostituisce la revisione del codice umano con nulla, ma con qualcosa migliori.
Funziona in tre livelli:
1. Il Potere Esecutivo (La Generazione)
Non chiediamo a una sola IA 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 i 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 c'è spazio per discussioni. Il codice deve compilare. I linters non devono lamentarsi. E fondamentale: il Test Black Box devono riuscire. Non testiamo se la funzione funziona internamente (ciò potrebbe manipolare l'AI), testiamo se il sistema dall'esterno fa quello che deve fare. Il test fallisce? Direttamente nel cestino.
3. Il Filtro Morbido (La Giuria AI)
Questa è la vera innovazione. Le soluzioni rimanenti vengono sottoposte a un'AI “Voting” specializzata. Questo agente non scrive codice, ma legge codice. È addestrato sui nostri principi architetturali, requisiti di sicurezza (OWASP, ISO) e regole di conformità (EU AI Act).
Vota: “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 rigidi. L'architetto determina wat we bouwen, wie het bouwt, hoe en perché.
Ci libera dalla tirannia degli errori di sintassi e ci permette di concentrarci su ciò in cui siamo bravi: il pensiero sistemico. La ricerca della verità. Struttura e decisione.
La domanda non è se l'AI possa scrivere il nostro codice. Questo argomento è già chiuso. Il codice diventa in gran parte un prodotto usa e getta.
La domanda è: Hai il coraggio di cedere il controllo su codice lasciarlo andare, per così prendere il controllo su qualità riottenere?
fammi sapere