Perché il codice generato dall'AI ha ancora bisogno di occhi umani

L'idea di far scrivere il codice a un modello linguistico è allettante. L'AI si occupa della parte ripetitiva, segue le regole e dovrebbe farvi arrivare prima al risultato. L'iniziativa Modern Web Guidance di Google è nata proprio con questo obiettivo: fornire agli agenti AI le best practice per creare siti accessibili, veloci e sicuri.

Peccato che i risultati non siano ancora all'altezza delle aspettative.

L'accessibilità non è un optional

Se il tuo MVP ignora l'accessibilità fin dal primo giorno, non è un prodotto pronto. Non è un dettaglio che si aggiunge dopo. È parte della struttura stessa.

Durante la presentazione di MWG, Google ha mostrato un esempio semplice: generare un componente a fisarmonica con animazioni fluide. Il codice prodotto non funzionava su Firefox e non rispettava gli standard WCAG Level AA. Nonostante le indicazioni su "Baseline-Aware Integration" e "Progressive Enhancement", l'agente AI le ha ignorate.

Non è un errore isolato. È il modo in cui funzionano gli LLM.

Il problema della non-determinazione

La documentazione di MWG lo ammette in una nota nascosta:

"Gli LLM sono non-deterministici. Anche facendo tutto bene, non c'è garanzia che una linea guida venga applicata."

In pratica significa che non puoi fidarti ciecamente che l'AI segua le regole che le hai fornito. A differenza di un linter o di un sistema di tipi, che impongono gli standard, un modello linguistico si limita a suggerire. Anche quando le indicazioni sono presenti nei dati di addestramento, non c'è certezza che le recuperi o le applichi correttamente.

La frammentazione delle pattern complica tutto

MWG è partito con una copertura incompleta. Componenti come le notifiche toast, su cui Google aveva già avuto problemi di accessibilità, non avevano linee guida dedicate. Quando un developer chiede un toast, l'AI deve assemblare indicazioni generiche senza un riferimento specifico.

Più le indicazioni sono sparse, più diventa difficile per un LLM sintetizzarle in modo coerente. Servono pattern raccolti in un unico posto, con ridondanza integrata. Al momento non è così.

Cosa significa per i tuoi progetti

Se usi l'AI per generare codice in produzione, la realtà è questa:

L'LLM è un assistente alla scrittura, non un revisore. Ogni riga va controllata, soprattutto per:

• Accessibilità (WCAG AA è il minimo per la maggior parte dei progetti)
• Compatibilità cross-browser (le promesse di "supporto baseline" vanno verificate)
• Sicurezza (il codice generato può introdurre vulnerabilità nascoste)
• Performance (le SPA create senza vincoli tendono a essere pesanti)

Come procedere

Non significa che lo sviluppo assistito dall'AI sia inutile. Significa che serve:

1. Non fidarsi ciecamente dell'output. Va revisionato come si fa con il codice di un collega.
2. Creare cicli di feedback. Segnalare gli errori di accessibilità all'AI perché impari dalle correzioni.
3. Chiedere disclaimer chiari. Chi promette "guida moderna" deve essere trasparente sui limiti e sui possibili fallimenti.
4. Investire nei test automatici. Strumenti come axe, WAVE e Lighthouse dovrebbero far parte della pipeline CI/CD, indipendentemente da chi ha scritto il codice.

Da NameOcean crediamo nel potenziale dell'AI per velocizzare la fase iniziale e ridurre il boilerplate. Ma resta fondamentale il giudizio umano, soprattutto quando si parla di conformità e esperienza utente.

Il vero valore oggi non è più saper scrivere codice. È saperlo revisionare, correggere e assumersi la responsabilità di ciò che arriva agli utenti. Questo richiede ancora una persona che capisca cosa c'è in gioco.

MWG di Google è un passo nella direzione giusta. Ma senza un meccanismo di enforcement, resta solo un consiglio. E gli LLM non sono bravi a seguire i consigli. Fino a quando la tecnologia non maturerà, considera il codice generato dall'AI come una prima bozza, non il prodotto finale.