Dove entra la UX in una pipeline con agenti AI: i sei interventi proposti da NN/g

Se un agente AI scrive il piano, il codice e i test, chi si assicura che il prodotto serva a qualcuno? È la domanda da cui parte un articolo di Tanner Kohler per Nielsen Norman Group, The Role of UX in Agentic Software Factories, pubblicato il 30 ottobre 2026.

Va letto per quello che è: un'analisi e un'opinione, senza dati originali. Offre però una lista di punti d'intervento concreti, utile a chi progetta o sviluppa con strumenti di questo tipo.

Il modello che NN/g mette sotto esame

Kohler confronta tre visioni di ciclo di sviluppo "AI-native": quella di OpenAI (novembre 2025, "Building an AI-native engineering team"), quella di Google (maggio 2026, un whitepaper su Kaggle) e quella di Anthropic (agosto 2026, "The AI-Native SDLC Playbook"), che è il bersaglio principale della critica. L'autore nota che le tre visioni differiscono nei dettagli, ma tutte trattano la UX come contesto e non come fase o punto di approvazione.

Nella versione di Anthropic le sei fasi tradizionali restano (Plan, Design, Build, Test, Deploy, Maintain), ma l'AI esegue la maggior parte del lavoro e le persone approvano ai gate. Il lavoro passa attraverso file Markdown sotto controllo di versione:

• Plan: intent.md, che chiunque può scrivere con l'AI; lo approva il product owner;
• Design: spec.md più mockup generati dall'AI; il product owner li itera e approva la specifica;
• Build: plan.md, le istruzioni per l'agente di coding; lo approva un ingegnere;
• Test: l'AI verifica il proprio lavoro rispetto a intent, spec, plan e mockup;
• Deploy: l'AI controlla bug, sicurezza e conformità; il responsabile tecnico approva ogni rilascio;
• Maintain: controlli di salute automatici; l'AI diagnostica i problemi e scrive un nuovo intent.md.

Le indicazioni che guidano l'AI, come convenzioni di codice, linee guida del brand, regole di sicurezza e standard UX, sono il "contesto". È qui che, secondo il playbook, entra la UX.

Dove la UX resta fuori, secondo NN/g

Le critiche dell'articolo seguono le fasi. Nel Plan, niente obbliga un intent.md a collegarsi a un bisogno reale degli utenti, e chi lo scrive in isolamento rischia poca condivisione nel team e pregiudizi mai messi in discussione. Nel Design, il playbook non dice chi mantiene il contesto del design system; i mockup generati sono per lo più lavoro di UI, cioè estetica, e non di UX, e la ricerca con gli utenti non viene menzionata. Nel Test, l'AI giudica il risultato rispetto ad artefatti creati dal team senza ricerca: i punti ciechi introdotti all'inizio passano indisturbati, e corrispondere a un mockup non garantisce usabilità o accessibilità. Nel Maintain, il monitoraggio riguarda la salute tecnica e non l'usabilità.

L'autore descrive uno scenario di fallimento, esplicitamente ipotetico: un'azienda rilascia funzioni costruite con questo processo, l'adozione è scarsa e gli utenti le abbandonano, ma il monitoraggio non segnala nulla perché il codice funziona. La causa reale sarebbe nelle etichette poco chiare e nella confusione degli utenti, mai testati prima del lancio.

Tre ruoli e sei azioni

Per NN/g la UX ha tre ruoli: decidere che cosa vale la pena costruire, valutare ciò che viene costruito, e fornire contesto al processo di generazione. Il playbook copre solo il terzo. Le sei azioni proposte sono raggruppate di conseguenza.

Decidere cosa costruire

1. Orientare il template di intent.md sui bisogni degli utenti. L'articolo suggerisce un agente che faccia a chi scrive domande da ricercatore, per esempio cosa sta cercando di fare l'utente e come cambia la sua vita se il problema viene risolto, e di far documentare ai ricercatori un problema in un intent.md prima che esista una soluzione.
2. Contribuire a criteri di accettazione centrati sull'utente, come l'evidenza che il problema sia reale, la prova che risolverlo massimizzi il beneficio per l'utente e la comprensione del perché il problema si verifica.

Valutare cosa viene costruito

3. Definire quando serve una revisione UX. Ad esempio nei cambi di navigazione o di architettura dell'informazione, o nei flussi che si discostano dalle convenzioni. In quei casi servono la revisione di un esperto sul mockup o un rapido test con pochi utenti. Kohler lo paragona all'escalation al responsabile dell'architettura per le decisioni ad alto rischio.
4. Inserire segnali sugli utenti nel ciclo di monitoraggio. Con l'ingegneria si definiscono segnali di allarme e valori di partenza, come l'abbandono dei task, il calo delle conversioni o i picchi di ticket di supporto, da indagare con la ricerca prima che rientrino nella pipeline.

Fornire contesto alla generazione

5. Prendersi la responsabilità del contesto UX. Scrivere le "skill" UX dell'organizzazione e firmarle, anche se imperfette, altrimenti lo farà qualcun altro o nessuno.
6. Rendere leggibili dalle macchine gli insight di ricerca e il design system. Gli agenti che non trovano questi materiali creano percorsi propri; con formati leggibili possono portare prove a favore o contro fin dalla scrittura degli intent.md.

Cosa se ne ricava in pratica

L'articolo parla di aziende con un processo AI-native strutturato. Per chi lavora da solo o in un team piccolo, con un agente di coding e qualche mockup generato, il ragionamento si può ridurre a poche domande: prima di far scrivere un piano all'agente, chi ha detto che questo problema esiste? Quali schermate cambiano navigazione o flusso e meritano un test con tre persone? Quale segnale di abbandono guardi dopo il rilascio? Questa traduzione è una mia lettura, non una raccomandazione dell'autore.

Un secondo spunto riguarda il contesto che dai all'agente. Se il design system e le linee guida stanno in un PDF o nella testa di una persona, l'agente non li vede. Mettere regole di componenti, token e tono in file di testo versionati è il passo più vicino alla sesta azione, e si può fare senza cambiare il processo del team.

Sul tema delle persone e degli agenti che agiscono sullo stesso sistema c'è un altro articolo NN/g dello stesso giorno, Experience Design: Dropping the "User" from "User Experience" di Raluca Budiu. Anche questo è concettuale: segnala che i problemi emergono nei passaggi di consegna tra persona e agente (continuità, autorizzazione, trasparenza, recupero), con un esempio ipotetico di agente di prenotazione bloccato dal password manager.

I limiti dichiarati dall'autore

Kohler stesso mette in guardia su alcuni punti. È presto per dire quanto il ciclo AI-native si adatti ad aziende di ogni tipo, perché è molto orientato alla produzione di software. C'è un conflitto di interessi: i laboratori di AI traggono vantaggio dall'adozione di questo modello. Che il contesto UX aiuti l'AI a prevedere le difficoltà degli utenti è "un'ipotesi ancora da verificare", e il contesto può codificare solo ciò che sappiamo già. Evitare l'AI, conclude, non è la risposta: la questione è capire come la UX resta coinvolta.

Le tre domande finali dell'articolo valgono come test per il tuo processo: come decide l'intero team cosa vale la pena costruire dal punto di vista dell'utente? Come si valuta la UX di prodotti generati dall'AI alla stessa velocità con cui gli agenti li costruiscono? Quale conoscenza UX può diventare contesto e quale richiede ancora giudizio umano?

Limiti di questo articolo

Non ho letto i playbook di Anthropic, Google e OpenAI: ciò che ne scrivo viene dalla descrizione di NN/g. Le date dei playbook sono quelle riportate da NN/g. Le applicazioni per team piccoli sono interpretazioni mie.

Fonti

1. Nielsen Norman Group, Tanner Kohler, “The Role of UX in Agentic Software Factories”, 30/10/2026
2. Nielsen Norman Group, Raluca Budiu, “Experience Design: Dropping the "User" from "User Experience"”, 30/10/2026