UX perde lugar fixo no ciclo de software guiado por agentes de IA

O problema que a fábrica de software agêntica ainda não resolve

Em agosto de 2026, a Anthropic publicou um roteiro de ciclo de desenvolvimento de software (SDLC) pensado para equipes em que agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → escrevem a maior parte do código. Google havia publicado algo parecido, porém menos prescritivo, em maio de 2026, e a OpenAI fizera o mesmo em novembro de 2025. Os três documentos concordam num ponto: se escrever código fica rápido e barato, as outras etapas do processo (planejar, decidir, testar, aprovar) precisam acompanhar esse ritmo.

O Nielsen Norman Group, em artigo publicado em 30 de outubro de 2026 assinado por Tanner Kohler, foi direto ao ponto que falta nesses três roteiros: UX↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX → vira contexto para a IA consultar, não uma etapa com dono. A pesquisa de usuário, a decisão sobre o que vale construir e a avaliação do que foi construído ficam sem lugar formal no processo.

Como funciona o SDLC nativo de IA da Anthropic

O roteiro da Anthropic mantém as seis etapas clássicas do SDLC (planejar, desenhar, construir, testar, lançar, manter), mas troca quem executa cada uma. Agentes de IA geram uma cadeia de artefatos em markdown, versionados como código, e humanos aprovam cada um num portão de controle. O que guia a IA é o que a Anthropic chama de contexto: convenções de código, diretrizes de marca, regras de segurança e padrões de UX documentados.

A tabela abaixo resume a diferença entre o ciclo tradicional e o proposto:

Nenhuma dessas seis etapas tem UX como responsável pelo portão de aprovação. A expectativa é que o conhecimento de UX, transformado em contexto e regras, já esteja embutido no que a IA produz.

Onde o modelo assume o que ainda não existe

O artigo do NN/G desmonta essa expectativa etapa por etapa, e é aqui que o ângulo interessa a quem desenha produto: o roteiro assume capacidades que simplesmente não estão no processo descrito.

No estágio de Plan

Qualquer pessoa pode gerar um intent.md, mas nada no processo garante que esse arquivo nasça de uma necessidade real de usuário em vez de uma solução favorita de quem o escreveu. A criação individual do intent.md também favorece silos: sem a perspectiva de outras pessoas do time, o product owner vira o único filtro, decidindo sozinho com base no que já sabe. Product owner, engenharia e UX historicamente equilibravam viabilidade de negócio, viabilidade técnica e desejabilidade do usuário; se a engenharia deixa de ser restrição e UX vira linha de markdown, sobra só o critério de negócio no portão de aprovação.

No estágio de Design

O spec.md e o mockup gerados por IA dependem de alguém curar, manter e atualizar o contexto de design, exatamente como os responsáveis por design systems sempre fizeram. O roteiro da Anthropic não diz quem faz esse trabalho. Pior: ele coloca o product owner para iterar o mockup, e um mockup gerado por IA sem teste com usuário é, na prática, trabalho de interface (UI), não de experiência (UX).

Resolver a necessidade exata da pessoa de forma simples e elegante ainda exige pesquisa exploratória para entender o que as pessoas precisam fazer e pesquisa avaliativa para checar se a solução entrega isso. O roteiro não menciona pesquisa de usuário em nenhum momento.

Nos estágios de Test e Maintain

No Test, a IA compara telas prontas com o mockup aprovado na etapa de Design. Isso garante consistência visual, não usabilidade nem acessibilidade: o time que constrói o produto costuma ter o mesmo ponto cego de quem o desenhou, e nenhuma pesquisa externa entra para quebrar esse viés. No Maintain, o monitoramento é de saúde técnica (erros, falhas de segurança), não de sucesso de uso.

O NN/G ilustra com um cenário plausível: um recurso lançado por esse processo tem baixa adoção e é abandonado rápido, mas os sinais automatizados não acusam nada porque o código funciona perfeitamente. O problema real era rotulagem confusa, e não havia sinal de usabilidade monitorado para capturar isso antes do lançamento.

A frase que resume a aposta dos laboratórios de IA

O artigo da NN/G cita a publicação do Google como síntese do argumento comum aos três roteiros:

A mudança mais profunda na engenharia de software não é uma nova linguagem, framework ou serviço de nuvem. É a transição de escrever código para expressar intenção, confiando que sistemas inteligentes vão traduzir essa intenção em software funcional.

Google, publicação sobre SDLC nativo de IA (maio de 2026)The most profound shift in software engineering isn't a new language, framework, or cloud service. It's the transition from writing code to expressing intent, and trusting intelligent systems to translate that intent into working software.

O problema, aponta o NN/G, é que "expressar intenção" presume que quem escreve já sabe qual é a intenção certa. Descobrir isso é trabalho de pesquisa, não de prompt.

Os três papéis que o UX ainda precisa ocupar

O NN/G já havia defendido em artigo anterior que UX cumpre três funções à medida que a IA acelera a produção de software: decidir o que vale construir e fortalecer o julgamento coletivo do time, avaliar o que foi construído, e alimentar o processo de geração de IA com contexto. O roteiro da Anthropic cobre bem só a terceira função.

Para as outras duas, o artigo propõe ações concretas, organizadas por responsabilidade:

• Decidir o que vale construir: o template do intent.md deveria obrigar respostas sobre o que a pessoa está tentando fazer e como ficaria a vida dela se o problema fosse resolvido, não só capturar a solução já pronta. Pesquisadores deveriam poder submeter um intent.md documentando um problema antes mesmo de alguém propor solução.
• Compartilhar critério de aprovação: design e produto dividirem a responsabilidade de aprovar o que entra no pipeline, com critérios como evidência de que o problema é real e de que resolvê-lo maximiza benefício para quem usa.
• Avaliar o que foi construído: definir previamente quando um mockup ou spec exige revisão humana de UX ou teste rápido com usuários, do mesmo jeito que mudanças de arquitetura escalam para um arquiteto sênior.
• Monitorar sinais de uso, não só de sistema: queda em taxa de sucesso de tarefa deveria disparar alerta com a mesma prioridade que um pico de erro de servidor, com abandono de tarefa, queda de conversão e aumento de chamados de suporte como sinais formais.
• Assumir a curadoria do contexto de UX: alguém precisa ser dono das regras de UX documentadas, redigindo a primeira versão mesmo sabendo que ela será imperfeita, porque se não for a pessoa de UX a fazer isso, outra área vai fazer no seu lugar.
• Tornar pesquisa e design system legíveis por máquina: se os agentes não encontram facilmente os insights de pesquisa já existentes, eles vão simplesmente ignorá-los e seguir caminho próprio.

O que fica em aberto

O próprio NN/G admite que não tem resposta pronta para perguntas como quais conhecimentos de UX podem virar contexto codificado e quais exigem julgamento humano caso a caso. O que fica claro é que produção mais rápida não elimina a necessidade de descobrir o problema certo nem de checar se o resultado funciona para quem vai usar.

Para quem desenha produto hoje, o recado prático não é rejeitar esses roteiros nem adotá-los sem questionar. É entrar na conversa agora, enquanto as empresas ainda estão decidindo como adaptar esse modelo, e reivindicar um lugar formal nas etapas de Plan, Test e Maintain antes que elas se consolidem sem UX dentro.

Fonte: Nielsen Norman Group