I 10 errori più comuni dell'AI nello sviluppo web

Philip Walton

Data di pubblicazione: 11 novembre 2026

Questa settimana abbiamo rilasciato la versione 1.0 di Modern Web Guidance, un insieme di competenze che incorporano l'esperienza della piattaforma web, le best practice e i dati di compatibilità del browser direttamente nei tuoi agenti di programmazione. Il nostro obiettivo con Modern Web Guidance è aiutare gli sviluppatori che utilizzano agenti di programmazione AI a sfruttare appieno la potenza e le funzionalità della piattaforma web moderna e, in ultima analisi, a migliorare le esperienze web per gli utenti.

Da quando abbiamo introdotto l'anteprima di Modern Web Guidance a maggio, gli agenti di programmazione sono migliorati sempre di più e sono stati rilasciati molti nuovi modelli pionieristici straordinari. Una delle domande che ci vengono poste più spesso è: questi nuovi modelli pionieristici non seguono già le best practice per lo sviluppo web?

Purtroppo la risposta è "no" e lo sappiamo perché lo abbiamo testato.

Ogni guida di Modern Web Guidance definisce un insieme di aspettative che devono essere soddisfatte se le best practice della guida sono state seguite correttamente. La nostra suite di valutazione testa poi queste guide fornendo lo stesso prompt a un agente in esecuzione con Modern Web Guidance installato (l'agente guidato) e a un altro agente in esecuzione senza Modern Web Guidance installato (l'agente non guidato). L'output di entrambe le esecuzioni viene confrontato con le aspettative definite dalla guida.

Se confronti i tassi di superamento guidati e non guidati, puoi notare che i modelli di AI, anche i modelli pionieristici più recenti, non seguono in modo affidabile le best practice di sviluppo web moderne da soli.

In media, gli agenti di programmazione non guidati superano solo circa il 50% dei controlli nella nostra suite di valutazione, rispetto a circa il 90% quando viene utilizzato Modern Web Guidance.

Puoi consultare la nostra dashboard di valutazione per visualizzare l'elenco completo dei controlli specifici che eseguiamo per ogni guida e il punteggio di ogni modello.

Per una panoramica di alto livello, questo post illustra 10 delle aree più problematiche in cui i modelli di AI sbagliano costantemente, in discipline chiave che gli sviluppatori web hanno maggiori probabilità di incontrare nel loro lavoro quotidiano, come accessibilità, esperienza utente, prestazioni e sicurezza.

1. Accessibilità: selezione della tastiera e gestione di inert

Per le persone che navigano con una tastiera o uno screen reader, l'ordine di selezione prevedibile è ciò che rende utilizzabili le UI interattive. Senza questo attributo, lo stato attivo può spostarsi su contenuti nascosti in background o rimanere bloccato in decine di tabulazioni aggiuntive.

La gestione dello stato attivo e di inert è una delle maggiori lacune di accessibilità nelle nostre valutazioni e una delle aree che migliora di più con Modern Web Guidance. Gli errori più comuni includono:

• Mancato spostamento dello stato attivo nelle visualizzazioni appena aperte e mancato ripristino dello stato attivo sull'elemento di attivazione durante la navigazione a ritroso.
• Affidarsi a trappole di tabulazione JavaScript manuali e aria-modal="true" su finestre modali personalizzate, anziché utilizzare una finestra modale <dialog> o contrassegnare i contenuti di sfondo inert.
• Esposizione di ogni elemento di una barra degli strumenti o di una griglia direzionale come punto di tabulazione separato anziché utilizzare un unico punto di tabulazione con tabindex mobile.
• Creazione di contorni :focus-visible personalizzati che non hanno un rapporto di contrasto di 3:1 rispetto agli sfondi adiacenti.

2. Accessibilità: supporto per il movimento ridotto

I movimenti imprevisti delle pagine e le animazioni su larga scala non sono solo fonte di distrazione, ma per gli utenti con disturbi vestibolari o sensibilità al movimento possono causare vertigini, nausea o mal di testa.

I modelli di AI di solito ricordano di verificare la presenza di prefers-reduced-motion quando aggiungono transizioni CSS standard o animazioni di keyframe. Tuttavia, quando utilizzano funzionalità più recenti come lo scorrimento fluido, le transizioni di visualizzazione o le animazioni basate sullo scorrimento, spesso dimenticano il movimento ridotto o commettono errori durante l'implementazione:

• Impostazione di scroll-behavior:smooth a livello globale e incondizionato sull'elemento root.
• Utilizzo di animazioni CSS basate sullo scorrimento senza controllo del movimento ridotto.
• Rimozione delle durate di transition sugli elementi del carosello per attivare il movimento ridotto durante lo scorrimento, ma dimenticando di rimuovere anche le proprietà di trasformazione, il che causa un salto di dimensioni degli elementi durante lo scorrimento.
• Applicazione di un reset generale della durata di 0.01ms su *, *::before e *::after quando è attiva la modalità Movimento ridotto, eliminando anche tutte le transizioni essenziali non di movimento (necessarie per comunicare le modifiche dello stato della UI).
• Attivazione incondizionata delle transizioni di visualizzazione tra documenti e override delle animazioni ::view-transition-* quando è attivo il movimento ridotto, anziché limitarsi a bloccare la regola @view-transition dietro un controllo del movimento ridotto.

3. Accessibilità: convalida dei moduli, suggerimenti per la formattazione e stati di compilazione automatica

I moduli sono un elemento fondamentale della maggior parte dei Critical User Journey sul web. Un piccolo intoppo in un modulo di pagamento può avere un impatto significativo sui profitti di un'attività.

Quando creano moduli, i modelli di AI eseguono correttamente molte delle operazioni di base. Tuttavia, spesso non riescono a gestire dettagli piccoli ma critici, come gli errori di convalida, il posizionamento corretto dei segnaposto e dei suggerimenti di formato e l'integrazione corretta con i gestori delle password e le funzionalità di compilazione automatica:

• Reimplementazione di CSS :user-invalid con convalida JavaScript blur personalizzata, che spesso contrassegna i campi required non modificati non appena gli utenti li superano con il tasto Tab.
• Lasciare che aria-invalid non sia sincronizzato con errori visibili, impostando aria-invalid="true" prematuramente su blur o applicando lo stile :user-invalid in CSS senza sincronizzare aria-invalid in JavaScript.
• Affidarsi al testo placeholder che scompare per mostrare i formati richiesti (ad esempio MM/YY in un input di scadenza della carta) anziché eseguire il rendering di un suggerimento persistente collegato a aria-describedby.
• Posizionamento dei suggerimenti per il formato e delle regole per le password sotto il campo <input> (anziché sopra), dove possono essere oscurati dalle tastiere dei dispositivi mobili e dai popover di compilazione automatica proprio quando l'utente deve leggerli.
• Evidenziare gli input :autofill modificando solo il colore del bordo anziché abbinare il colore a un indicatore non cromatico che non modifica il layout (ad esempio un box-shadow inserito).

4. Esperienza utente: gesti di scorrimento e tocco

Gli agenti sono bravi a implementare i gesti di tocco utilizzando JavaScript imperativo e a scrivere la propria logica fisica personalizzata. Queste implementazioni funzionano, ma le interazioni touch basate su JavaScript raramente risultano fluide come gli utenti si aspettano dalle loro controparti delle app native.

Molte di queste interazioni possono essere implementate con CSS e API di scorrimento native, consentendo al browser di eseguire la fisica dei gesti al di fuori del thread principale. Tuttavia, nelle nostre valutazioni, i modelli di AI spesso trascurano queste funzionalità:

• Implementazione di gesti di scorrimento per chiudere o scorrimento per mostrare con listener pointermove o touchmove anziché utilizzare l'allineamento dello scorrimento CSS.
• Omettere overscroll-behavior-x:none nelle interfacce con scorrimento delle schede, che possono attivare accidentalmente la navigazione avanti o indietro del browser durante uno scorrimento eccessivo.
• Gestione degli effetti di avanzamento dello scorrimento sul thread principale nei callback JavaScript anziché utilizzare animazioni basate sullo scorrimento.
• Mancato supporto corretto della selezione della tastiera sui riquadri di scorrimento con azioni di scorrimento.

5. Esperienza utente: finestre di dialogo, popover e transizioni del livello superiore

Nelle nostre valutazioni, i modelli spesso ricorrono a soluzioni alternative JavaScript imperative per l'animazione, la chiusura o il contenimento dello scorrimento intorno alle finestre di dialogo modali e ai popover.

Anziché affidarsi alle moderne funzionalità HTML e CSS create per gli overlay di livello superiore, gli agenti spesso creano manualmente macchine a stati di entrata e uscita, hook della cronologia e blocchi dello scorrimento del corpo, che sono più difficili da gestire e soggetti a bug dell'interfaccia utente impercettibili.

Se queste interazioni vengono gestite correttamente, un'esperienza che sembra fragile può trasformarsi in un'esperienza raffinata di cui gli utenti si fidano. Ecco gli errori più comuni che riscontriamo:

• Creazione di overlay position:fixed personalizzati con gestori di clic esterni manuali per la chiusura semplice, anziché utilizzare semplicemente popover.
• Creare animazioni di entrata e uscita attivando e disattivando le classi di transizione CSS e coordinandole con i listener requestAnimationFrame() e transitionend (con i fallback setTimeout()), anziché farlo in CSS puro con @starting-style e transition-behavior.
• Blocco dello scorrimento della pagina dietro una finestra modale aperta impostando overflow:hidden su <html> anziché utilizzare un elemento <dialog> per contenere l'overscroll.
• Aggiunta di listener popstate per rilevare i gesti Indietro di Android e chiudere i modali aperti, anziché utilizzare la funzionalità di chiusura nativa del pulsante Indietro di un elemento modale <dialog>.

6. Esperienza utente: modalità Buio e controlli adattivi al tema

Gli utenti attivano la modalità Buio per ridurre l'affaticamento degli occhi e i riflessi, quindi un flash bianco luminoso al caricamento della pagina, controlli dei moduli senza tema o un pulsante di attivazione/disattivazione che non si sincronizza con le preferenze del sistema operativo compromettono immediatamente l'esperienza.

Un pulsante di attivazione/disattivazione della modalità Buio può sembrare semplice, ma i modelli non guidati nelle nostre valutazioni non riescono sistematicamente a cogliere i dettagli chiave della piattaforma necessari per ottenere un cambio di tema e controlli dei moduli nativi corretti:

• Manca <meta name="color-scheme" content="light dark"> in <head>, il che fa sì che gli utenti della modalità Buio vedano un flash bianco mentre vengono caricati i fogli di stile esterni.
• Stilizzazione di temi scuri o componenti con superficie scura con colori personalizzati senza impostare color-scheme, lasciando le barre di scorrimento native e i controlli dei moduli bloccati in modalità Luce.
• Trascurare la funzione CSS light-dark() quando si definiscono i token di colore adattabili al tema che seguono automaticamente l'color-scheme attivo.
• Fornire solo un pulsante di attivazione/disattivazione binario per la modalità Luce o Buio che imposta un override esplicito in localStorage senza l'opzione per tornare all'impostazione predefinita del sistema operativo.
• Dimenticare di aggiungere un listener di eventi storage, lasciando le altre schede aperte non sincronizzate quando l'utente cambia tema.

7. Prestazioni: reattività e fluidità del runtime

Gli utenti trascorrono la maggior parte del tempo su una pagina web dopo che è stata caricata, quindi interazioni lente e transizioni instabili possono danneggiare l'esperienza utente tanto quanto un caricamento iniziale lento.

Nelle nostre valutazioni, i modelli generalmente seguono le best practice classiche per il tempo di caricamento che sono state promosse in strumenti come Lighthouse per anni e di solito sanno come delegare i loop pesanti ovvi a un Web Worker. La loro difficoltà principale è la reattività del thread principale, che è essenziale per ottimizzare l'INP: isolare il lavoro di layout, pianificare le attività in base alla priorità e sfruttare le nuove funzionalità HTML e CSS che eseguono il lavoro di rendering al di fuori del thread principale.

Ad esempio, spesso vediamo agenti:

• Implementazione di code setTimeout() personalizzate per il lavoro in background o con priorità bassa anziché dare la priorità alle attività visibili all'utente con scheduler.postTask() o sfruttare la continuazione delle attività con scheduler.yield() quando il browser lo supporta.
• Creazione di layout complessi (come griglie di dati fitte) senza applicare content-visibility:auto e contain-intrinsic-size, il che significa che gli aggiornamenti dopo le interazioni dell'utente attivano un reflow della pagina intera.
• Nascondere le visualizzazioni SPA non attive con display:none (o eliminarle) anziché utilizzare content-visibility:hidden (abbinato a inert). Il primo distrugge lo stato di rendering memorizzato nella cache, quindi il ritorno attiva il layout e il paint completi.
• Messa in pausa delle animazioni <canvas> fuori schermo e dei loop in background con i callback di Intersection Observer anziché l'accoppiamento di content-visibility:auto con l'evento contentvisibilityautostatechange (dove disponibile), senza il margine di prerendering del browser prima che gli elementi vengano visualizzati.
• Creazione di suggerimenti UI per l'affordance di scorrimento utilizzando listener di eventi scroll che forzano calcoli continui del layout, anziché utilizzare query sullo stato di scorrimento CSS quando disponibili (con fallback di Intersection Observer).

8. Prestazioni: variazioni del layout e sfarfallio visivo

Le variazioni di layout impreviste interrompono la concentrazione del lettore e possono indurre gli utenti a fare clic su pulsanti imprevisti, a volte con conseguenze irreversibili.

I modelli aggiungono in modo affidabile gli attributi width e height agli elementi <img> standard per proteggersi dalle variazioni del layout, ma non rilevano costantemente altre fonti comuni di variazioni del layout e flash di pre-paint da elementi <video>, scambi di caratteri web, barre degli strumenti del browser mobile ed esperimenti lato client, tutti fattori che possono influire su CLS.

• Omettere gli attributi espliciti width e height negli elementi <video> (in modo che i player non caricati abbiano come valore predefinito 300×150 e cambino layout una volta caricati i metadati) o applicare uno stile agli elementi wrapper multimediali anziché impostare aspect-ratio e object-fit direttamente sugli elementi multimediali.
• Abbinamento di caratteri web con caratteri di sistema di riserva senza font-size-adjust, che causa un evidente ridisposizione di paragrafi e intestazioni quando i caratteri web vengono scambiati.
• Dimensionamento delle sezioni hero e dei layout a schermo intero con unità vh statiche anziché unità viewport dinamiche o piccole (dvh, svh), il che causa il salto dei contenuti quando le barre degli strumenti del browser mobile si espandono e si ritraggono.
• Nascondere i contenuti con snippet anti-sfarfallio opacity:0 o visibility:hidden legacy e timeout di più secondi per i test A/B lato client (ritardando l'LCP e lasciando cliccabili gli elementi invisibili), anziché utilizzare script con blocking="render" quando disponibili.
• Attivazione delle transizioni di visualizzazione tra documenti prima che il markup above the fold critico sia stato analizzato, anziché trattenere il primo rendering con rel="expect" e blocking="render", causando la comparsa di elementi analizzati a metà durante la transizione.

9. Sicurezza: difese contro gli attacchi XSS (cross-site scripting) basati su DOM e sanitizzazione HTML

Un singolo difetto di cross-site scripting (XSS) consente a un malintenzionato di eseguire codice arbitrario nei browser degli utenti, rubando i dati della sessione o intraprendendo azioni per loro conto. Ecco perché le difese applicate dal browser, come la sanitizzazione sicura dell'HTML, i Trusted Types e i CSP rigidi, sono così importanti.

I modelli raramente affrontano questi problemi di sicurezza in modo proattivo. Ad esempio, in tutte le attività della nostra suite di valutazione completa, i modelli non hanno aggiunto un'intestazione Content Security Policy (CSP) o con isolamento multiorigine senza un prompt esplicito.

Anche quando i prompt richiedono direttamente la sicurezza, i modelli non guidati continuano a non superare più della metà dei nostri controlli di sicurezza, ricorrendo a fragili fallback personalizzati o a policy incomplete. Questo è evidente quando ci si difende dagli attacchi DOM XSS:

• Scrittura di sanitizer per la lista consentita DOMParser personalizzati, come opzione di riserva di setHTML() o all'interno di una policy di Trusted Types, anziché utilizzare una libreria verificata come DOMPurify quando la sanitizzazione nativa non è disponibile.
• Eseguire il bundle di DOMPurify in modo eager a ogni caricamento pagina anziché utilizzare setHTML() nativo quando supportato e il caricamento lento di DOMPurify solo come opzione di riserva.
• Registrazione di policy Trusted Types permissive di passthrough (input) => input che compromettono l'applicazione dei sink.
• Abbinamento di Trusted Types su pagine statiche con CSP script-src 'self' con lista consentita di host anziché bloccare gli script incorporati con hash SHA-256.
• Omissione di 'strict-dynamic' e 'report-sample' durante la configurazione delle Content Security Policy script-src basate su nonce.

10. Sicurezza: accesso con passkey, nuova autenticazione e ciclo di vita delle credenziali

Le passkey migliorano la sicurezza per gli utenti e le conversioni di accesso per le attività, ma la loro implementazione (anche con l'aiuto degli agenti) è difficile.

WebAuthn ha API specifiche di serializzazione, rilevamento delle funzionalità e segnalazione che i modelli non guidati non riescono quasi mai a rilevare nelle nostre valutazioni. Se chiedi a un modello di AI di aggiungere l'accesso, la gestione o la riautenticazione step-up con passkey, spesso scrive helper di codifica manuale dei byte, salta i controlli delle funzionalità nell'interfaccia utente di gestione o lascia le credenziali non sincronizzate con i gestori delle password:

• Creazione manuale di helper di conversione Base64URL atob() e btoa(), come percorso principale o come boilerplate di riserva ridondante, anziché fare affidamento su metodi di serializzazione integrati come parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() e credential.toJSON().
• Omettere PublicKeyCredential.signalUnknownCredential() durante l'accesso quando il server segnala un ID credenziale sconosciuto, lasciando le passkey eliminate o revocate nei gestori delle password degli utenti.
• Salto di PublicKeyCredential.getClientCapabilities() prima del rendering della UI di creazione e gestione delle passkey.
• Omissione di AbortController e AbortSignal all'avvio delle richieste di riautenticazione con passkey di step-up.
• Passaggio dell'opzione origin trial mediation:"immediate" anziché uiMode:"immediate" per le richieste di accesso semplificato.

Colma queste lacune

Queste 10 aree non sono affatto un elenco esaustivo e prevediamo che le lacune specifiche nelle conoscenze cambieranno nel tempo. I modelli si aggiorneranno e la piattaforma web continuerà a evolversi.

La buona notizia è che Modern Web Guidance colma tutte queste lacune e continuerà a evolversi di pari passo con la piattaforma.

Per iniziare a utilizzare Modern Web Guidance, esegui il comando seguente o cercalo nel marketplace dei plug-in dell'agente:

npx modern-web-guidance@latest install

Hai notato che i modelli sbagliano altre attività di sviluppo web? Segnalacelo. Segnala un problema nel repository GitHub di Modern Web Guidance o aiutaci a colmare queste lacune per altri sviluppatori contribuendo al progetto.