A fábrica de software esqueceu do design, e um workflow de quatro estações tenta corrigir isso

O autor, Atif Azam, saiu da Coinbase há dois anos para construir produtos por conta própria e diz ter lançado quase uma dúzia deles. Parte do que usa hoje veio de produtos que ensinaram o que não fazer. Sua crítica à "software factory" (issue vira agente, agente vira pull request) é que quase toda versão pula o design. Quando ele aparece, é como screenshots de inspiração coladas no ticket. Ou nem aparece, e o agente decide sozinho como a coisa deve parecer, com bastante confiança.

O workflow tem quatro estações. No Linear mora a intenção: toda issue precisa dizer por que está sendo feita e como é o "pronto", seja escrita por ele ou aberta por agentes (um de suporte, um de DevOps). No Paper, tudo que tem lado de design, frontend ou experiência passa antes de ser construído. O agente trabalha no canvas via MCP, olha o que já existe e puxa do design system. O autor revisa, ajusta espaçamento e texto à mão ou deixa comentários para o agente resolver. Como os designs são HTML e CSS reais, nada se perde na ida para o código. Na terceira estação, o coding agent (ele usa mais o Codex, mas serve Claude Code ou outro) constrói a partir da issue e do design. Na quarta, ele revisa o resultado contra a intenção. Se o build diverge do design, nem sempre é bug: às vezes o agente achou algo melhor e o design é atualizado.

O limite é a memória. Agentes recebem contexto do momento, mas não o histórico: por que um fluxo foi testado e retirado, o que o analytics mostrou na última mudança de uma página, as versões anteriores de uma tela e o raciocínio por trás do design system, não só os componentes. Cada sessão começa do zero. O autor diz que ainda não fechou essa lacuna e que ninguém a resolveu bem.

A cobertura anterior do CEVIU aponta a mesma tensão por outros ângulos, mas sem tratar deste workflow. Em 6 de maio de 2026, em "Workflow Lab: Expandindo o Canvas com Figma MCP", o CEVIU noticiou agentes de IA escrevendo frames editáveis direto no canvas via MCP, ideia parecida com a do Paper. Em 16 de junho de 2026, "Design System e IA: por que regras em texto não funcionam, e o que fazer no lugar" já dizia que agentes ignoram diretrizes longas e priorizam código legado. E em 25 de agosto de 2026, "Sistemas de Design: Preparando o Terreno para a IA na Criação de Interfaces" falava de equipes refinando a documentação para que agentes entendam o sistema. A lacuna de memória descrita agora é a continuação desse problema: o agente enxerga os componentes, mas não o porquê deles.

Para quem opera design em time pequeno, a leitura é que o designer sai da produção de telas e passa a ser o ponto de decisão e revisão antes do código. Isso só funciona se as decisões ficarem registradas de forma que um agente consiga consultar. Para quem mantém design system, o recado é documentar o motivo das escolhas, não só o catálogo de componentes.