O que significa, afinal, um design system estar pronto para IA?

O texto de Sean Voisen parte de uma crítica: a maioria dos times de design system tratou "prontidão para IA" como um conjunto de táticas. Documentação legível por máquina, tokens com semântica clara, skills, arquivos llms.txt e servidores MCP. Até padrões concorrentes surgiram, como o Design System Doc Spec, o DESIGN.md do Google e a Design Data Specification da Adobe. Para ele, nada disso diz o que a prontidão deve entregar.

O autor propõe virar a pergunta do avesso: em vez de medir quão bem a IA usa o sistema, medir quão bem a IA consegue ser parte do sistema. Ele usa a cibernética para explicar. Pelo princípio POSIWID, o propósito de um sistema é o que ele faz, e entregar os mesmos artefatos a um LLM tende a gerar "desvio plausível de design, em escala". Pela Lei de Ashby, o regulador precisa de variedade equivalente à dos problemas que absorve, e um designer humano tem muito mais variedade que um LLM com arquivos Markdown. Restam duas saídas: reduzir a variedade que o regulador enfrenta (restringir a geração) ou ampliar a dele (avaliações e ciclos de crítica). O conhecimento tácito, porém, não se escreve por inteiro. Como alternativa ainda não testada, o autor cita o "ledger de design" de David Hoang, que registraria decisões e contexto enquanto o trabalho acontece, com os riscos de vigilância e de repetir decisões passadas.

A cobertura do CEVIU vinha tratando o tema pelo lado das táticas. Em 8 de junho de 2026, em "Como tornar seu design system compatível com IA", e em 12 de junho de 2026, em "Como preparar seu design system para IA", o foco era documentar decisões, evitar valores hard-coded e dar clareza às diretrizes. Em 1 de outubro de 2026, "Sistemas de Design: Preparando o Terreno para a Era da IA" apontou os fundamentos de engenharia como prioridade, acima das ferramentas de agente.

O texto de agora desloca a pergunta. Em vez de listar o que preparar, define o critério: a IA participa sem derrubar a qualidade mínima, e o time decide de propósito onde o humano continua. Também reconhece o limite do que a documentação cobre, tema que já aparecia em 20 de abril de 2026, em "Seu agente de IA pode ler sua base de código, mas não conhece seu produto", sobre o contexto de design que falta aos agentes.

Para quem opera um design system, a leitura é prática: checklist de artefatos não prova prontidão. Vale testar com prompts variados, como fez PJ Onori, e olhar o resultado com olhos de designer. Para o usuário final, a diferença está nos detalhes que nenhuma regra escrita pega, mas que ele sente. Decidir onde o humano revisa passa a ser parte do desenho do sistema.