De Screenshot A Interface Editável: O Que O /Design Do Claude Code Promete Entregar

Toda vez que preciso validar uma tela nova, o fluxo é sempre o mesmo incômodo: saio do terminal, abro alguma ferramenta de design ou um sandbox de componente, monto algo tosco só pra ter uma referência visual, volto pro editor e começo a traduzir aquilo em código. Três ferramentas, três contextos, e o meio do caminho — a etapa em que a ideia ainda não é código nem é design de verdade — é sempre a mais mal resolvida. Não é um problema exclusivo meu; é a costura clássica entre produto, design e engenharia que toda equipe pequena sente quando não tem designer dedicado em cada squad.

Foi por isso que uma nota de changelog do Claude Code me chamou atenção nesta semana. Em 17 de agosto de 2026 a Anthropic lançou, como pré-visualização de pesquisa, uma skill chamada /design: você dá uma ideia descrita em texto, um print de tela ou um design já existente, e ela devolve artboards editáveis dentro do Claude Design — construído sobre o mecanismo de artifacts e disponível tanto na CLI quanto no aplicativo desktop. Pelo que a cobertura descreve, o ciclo inteiro fica num único lugar: descrever a tela, receber algumas opções, escolher uma, ajustar, e só depois pedir que o Claude escreva o código que implementa aquilo.

Não testei a skill — ela ainda está em pré-visualização de pesquisa e a fonte que encontrei é uma cobertura de changelog, não a documentação oficial completa da Anthropic. Este post é um estudo do que foi anunciado e do que esse tipo de recurso historicamente entrega versus promete, não um review de uso. Vou explicar o mecanismo, propor cenários hipotéticos de uso — sempre marcados como tal — e colocar ao lado a lista de onde a geração de UI por IA costuma travar, já bem conhecida de quem acompanha a categoria desde os primeiros geradores de tela a partir de prompt.

O /design chegou junto com outras três mudanças na mesma leva de agosto: o modo automático (auto mode) virando padrão para novas sessões, com regras de permissão escritas em linguagem natural; um estilo de resposta chamado "Concise", que corta preâmbulo e vai direto ao resultado; e o auto-continue, que retoma a sessão sozinho assim que o limite de uso é liberado. O pacote todo sugere uma direção clara: o Claude Code está deixando de ser só um assistente de código no terminal e virando um espaço de trabalho mais amplo. O /design é a peça mais visível dessa mudança, porque é a que sai do domínio estritamente técnico e entra em território que, até pouco tempo atrás, pertencia apenas a ferramentas de design.

O Que A Skill Design Faz E Como Se Encaixa No Modelo De Skills

Antes de falar do /design especificamente, vale lembrar como o Claude Code entende o conceito de skill, porque isso muda a leitura do que foi anunciado. Segundo a documentação oficial, uma skill é um diretório com um arquivo SKILL.md — frontmatter YAML com nome e descrição, seguido de instruções em Markdown, mais scripts, referências e assets opcionais. Skills ficam em ~/.claude/skills/ (pessoal) ou .claude/skills/ (projeto); quando o modelo identifica que uma tarefa combina com o propósito declarado de uma skill, ele carrega o SKILL.md e segue os passos descritos ali. Na prática, uma skill é um pacote de instrução reutilizável que modifica o contexto de execução — ferramentas permitidas, às vezes até seleção de modelo — sem exigir plugin ou integração customizada. Já escrevi sobre esse modelo em context engineering como a skill mais importante para agentes e em como montar as skills prioritárias de um time, então não repito a mecânica geral aqui — o ponto é que o /design não é um recurso separado, é uma skill dentro desse mesmo modelo, só que oficial e mais ambiciosa do que a maioria das skills de time.

O que ela promete, segundo a cobertura da Origami sobre o changelog de agosto, é receber três tipos de entrada — uma ideia descrita em texto, um print de tela, ou um design já existente — e devolver "artboards editáveis" no Claude Design. A diferença central em relação a pedir "gere uma tela de login em React" direto no chat é que a saída não é um bloco de código solto: é um arquivo de design de verdade, construído sobre o mecanismo de artifacts que o Claude já usa para conteúdo interativo. Isso importa porque um artifact pode ser compartilhado, reaberto e editado — nos planos Team e Enterprise, qualquer pessoa que você tornar editora consegue alterar o artboard e publicar uma nova versão, sem precisar reabrir sessão nenhuma do Claude Code. Em outras palavras: o output não morre no terminal de quem pediu.

O fluxo sugerido pela cobertura é iterativo por desenho, não por acidente. Primeiro você pede várias opções de uma tela antes de comprometer com uma — o recurso mais recomendado, segundo o material, é justamente pedir múltiplas variações cedo, antes de escrever qualquer linha de código. Depois você escolhe, ajusta o que não gostou, e só então pede que o Claude implemente. É o mesmo padrão que qualquer designer júnior aprende cedo — divergir antes de convergir — só que comprimido para dentro de um ciclo que, teoricamente, não exige alternar de ferramenta.

Vale registrar o que não está confirmado. Não encontrei, nas fontes disponíveis, detalhe técnico sobre qual formato interno o Claude Design usa para representar os artboards, nem que framework de front-end o código gerado assume por padrão. A cobertura descreve o comportamento observável — texto ou print entra, artboard editável sai, depois vira código — mas não abre a caixa preta de como a tradução visual→estrutura acontece. É exatamente nessa caixa preta que moram os problemas de fidelidade que vou tratar mais adiante.

Um detalhe da mesma leva de mudanças reforça a leitura de que agosto foi o mês em que "Claude Code sai do escopo estritamente código": o modo automático virou padrão para sessões novas nos planos Pro, Max e Team a partir de 14 de agosto, com um segundo modelo — o "classificador" — decidindo o que passa e o que é barrado, guiado por regras escritas como frases comuns. Não é o assunto central deste post, mas é sintomático: o mesmo mês em que o Claude Code ganhou uma skill de design também foi o mês em que passou a operar, por padrão, com menos revisão humana por ação individual. As duas mudanças puxam na mesma direção — mais autonomia, mais escopo, menos fricção — e merecem a mesma pergunta: o que essa autonomia troca por velocidade, e quem absorve a diferença quando ela erra.

Cenários Hipotéticos De Uso No Dia A Dia

Nenhum dos cenários abaixo é relato de uso real — são exemplos hipotéticos para ilustrar onde esse tipo de fluxo plausivelmente encaixa, dado o que a skill promete tecnicamente.

Imagine um dev de produto numa startup pequena, sem designer dedicado, que recebe do fundador uma foto de tela de um concorrente com a legenda "algo parecido com isso, mas com a nossa marca". Hoje esse dev provavelmente abriria uma ferramenta de design, recriaria a estrutura à mão, ajustaria cores, exportaria para código e só então integraria no projeto — horas de trabalho para uma tela que talvez nem sobreviva à primeira rodada de feedback. Com o /design, o fluxo hipotético seria: colar o print, pedir "recrie isso com a nossa paleta e tipografia", receber duas ou três variações de artboard, escolher a mais próxima, ajustar dentro do próprio Claude Design, e só depois pedir a implementação em React. O ganho, se a promessa se sustentar, não é qualidade final — é a distância entre "recebi o pedido" e "tenho algo clicável pra mostrar", comprimida de horas para minutos.

Um segundo cenário hipotético: um time de backend sem front-end forte, que precisa entregar um painel administrativo interno — nada bonito, só funcional, mas que hoje ainda exige alguém pensar em layout, estados vazios, tabela responsiva. Nesse caso, o dev descreveria em texto o que o painel precisa mostrar ("lista de pedidos com filtro por status, botão de exportar, paginação"), pediria opções de artboard, e a vantagem seria menos sobre velocidade e mais sobre reduzir a barreira de "ninguém aqui sabe organizar uma tela".

Um terceiro cenário, mais próximo do que a cobertura sugere como uso ideal: um tech lead validando uma feature nova antes de envolver o time de design de verdade. Em vez de escrever uma especificação pedindo para o designer imaginar a tela, ele gera três variações rápidas de artboard e leva isso como ponto de partida para a conversa — não como entrega final, mas como artefato de discussão. O valor aqui não é substituir o trabalho de design, é acelerar a primeira rodada de alinhamento.

Nos três casos, o padrão que se repete é o mesmo: o /design parece mais forte em prototipagem descartável e em reduzir a distância entre intenção e primeiro rascunho visível, e mais fraco — ou pelo menos não comprovado — em qualquer cenário onde a tela final precisa nascer dentro de um sistema de design consolidado, com componentes reutilizáveis e consistência garantida entre telas diferentes. Essa distinção entre "primeiro rascunho" e "produto final" é o fio que puxa a próxima seção.

Onde A Promessa Provavelmente Esbarra Em Limite Conhecido

Geração de UI por IA não é território novo — só a embalagem terminal-first é nova. Ferramentas de texto-para-tela vêm evoluindo desde os primeiros geradores baseados em prompt, e a categoria inteira converge, historicamente, para os mesmos três pontos de atrito. Vale olhar cada um com o que se sabe sobre o /design, admitindo onde a informação disponível simplesmente não chega.

O primeiro é fidelidade visual em relação a um sistema de design existente. Um modelo generativo, quando recebe "recrie este print", tende a produzir algo que se parece com a intenção do print, não uma réplica pixel-perfect de espaçamento, grid e hierarquia tipográfica exata. Isso é aceitável — às vezes até desejável — num protótipo de exploração, e é um problema real quando a tela precisa se encaixar visualmente ao lado de outras cinquenta telas já existentes num produto maduro. A cobertura que encontrei não detalha se o /design consegue ingerir tokens de um design system existente e respeitá-los de forma consistente entre gerações sucessivas, ou se cada nova sessão parte de uma interpretação nova do que "parece bom". Sem essa informação, a leitura prudente é assumir que a skill resolve bem o primeiro rascunho e não resolve, sozinha, o problema de manter um sistema de design coeso — trabalho contínuo que ferramentas de design system tratam como disciplina própria, não como output de um prompt único.

O segundo é acessibilidade. Gerar uma tela que parece correta visualmente é tarefa bem diferente de gerar uma tela que funciona com leitor de tela, tem contraste de cor adequado, ordem de foco de teclado sensata e semântica HTML correta por baixo. Esse é um dos pontos mais consistentemente fracos de qualquer geração de UI puramente visual — o modelo otimiza pelo que "parece certo" numa captura de tela, não pelo que uma árvore de acessibilidade exige. Nenhuma das fontes sobre o /design menciona auditoria de acessibilidade como parte do fluxo, o que não significa que ela esteja ausente, mas significa que, na falta de confirmação, times que dependem de conformidade — WCAG, Section 508, ou equivalente local — deveriam tratar qualquer saída do /design como ponto de partida a auditar, não como entrega pronta.

O terceiro, e talvez o mais estrutural, é a distinção entre código reaproveitável e código descartável. Existe diferença enorme entre gerar componentes que se integram à arquitetura já existente do projeto — reaproveitando o design system, os hooks, os padrões de estado que o time já usa — e gerar uma página isolada, estilizada inline, que funciona sozinha mas não conversa com o resto da base. Ferramentas de geração de UI historicamente pendem para o segundo caso, porque é mais fácil de fazer parecer bonito rápido: sem dependência externa para gerenciar, sem convenção de projeto para respeitar, o modelo tem mais liberdade para produzir algo visualmente coerente. O risco prático, se isso se repetir aqui, é que o ganho de velocidade na etapa de design vire dívida técnica na integração — alguém precisa reescrever boa parte do que foi gerado para caber na arquitetura real, retrabalho raramente contabilizado quando alguém mede "quanto tempo o /design economizou".

Nenhum desses três pontos é motivo para descartar a skill — são o tipo de limite que qualquer ferramenta nova de geração assistida carrega, e que só fica claro com uso real e comparação direta, coisa que ainda não existe publicamente para o /design em pré-visualização de pesquisa. O ponto é calibrar expectativa: tratar como acelerador de rascunho, não como substituto de revisão de design, acessibilidade e arquitetura.

Há ainda uma pergunta que a cobertura disponível não responde e que interessa a qualquer tech lead avaliando adoção: quem é responsável pelo artboard depois que ele vira código? Se qualquer editor num plano Team ou Enterprise pode alterar o artboard e publicar nova versão, isso implica um ciclo de vida do artefato que precisa de dono — alguém decidindo quando aquele artboard está "congelado" o suficiente para servir de fonte de verdade, e quando uma edição nova invalida o código já implementado a partir de versão anterior. É o mesmo problema de sincronização entre design e código que já existe entre Figma e engenharia, só que comprimido para dentro do mesmo produto — o que resolve parte do atrito de troca de ferramenta, mas não resolve, por si só, o problema de governança sobre qual versão é a verdade.

Como Isso Se Conecta Com A Discussão Mais Ampla De Skills E Ferramentas Agênticas

O /design não existe isolado — é sintoma de uma tendência maior que venho acompanhando neste blog desde maio: skills como unidade de extensão de capacidade em ferramentas agênticas, em vez de plugin tradicional ou integração hardcoded. Escrevi sobre isso em como montar a lista de skills prioritárias para um time adotar — o argumento central era que a skill certa, bem escrita, vale mais que uma dúzia de prompts soltos, porque encapsula contexto reutilizável de um jeito que qualquer membro do time consegue acionar sem reconstruir a lógica do zero. O /design, sendo skill oficial da própria Anthropic em vez de skill de time, é uma validação pública desse modelo: se a empresa que constrói a ferramenta usa o mesmo mecanismo de skill para lançar recurso novo, isso sugere que o modelo de extensão amadureceu o suficiente para carregar funcionalidade de primeira classe, não só automação de nicho.

Isso conversa diretamente com a portabilidade que comecei a ver ganhar tração em agosto. Escrevi sobre o padrão emergente de agent plugins como formato portátil de skills e MCP — a ideia de que skills e servidores MCP deixam de ser algo amarrado a uma ferramenta específica e passam a ser empacotados de um jeito que funciona em múltiplos ambientes. Uma skill como /design, hoje exclusiva do Claude Code e do Claude Design, é exatamente o tipo de capacidade que ganharia mais valor se pudesse ser portada — imagine o mesmo fluxo de "print vira artboard editável" disponível dentro de outro ambiente agêntico que seu time já usa, sem reescrever a lógica do zero. Não sei se a Anthropic vai empacotar o /design nesse formato portátil; é uma hipótese razoável dado o momentum do padrão, não um fato confirmado por nenhuma das fontes que consultei.

Também vale colocar o /design ao lado da discussão sobre até onde vale confiar em ferramenta de IA sem verificação própria. Já escrevi sobre o preço alto do Claude Code e a confiança que isso exige das ferramentas de IA — o argumento ali era que, à medida que essas ferramentas cobram mais e prometem fazer mais sozinhas, a régua de verificação humana não pode cair, precisa subir junto. O /design é exemplo direto disso: quanto mais etapas do ciclo design→código ele absorve sem intervenção humana intermediária, maior a chance de um erro de fidelidade, acessibilidade ou arquitetura passar despercebido até tarde demais. Um recurso que tira você do "sair do terminal para prototipar" só é vantagem líquida se a etapa de revisão que elimina for substituída por uma equivalente — não por nenhuma revisão.

E há a conexão, mais estrutural, com o argumento sobre skills como o insumo mais importante da era dos agentes. O que muda com o /design não é que a IA passou a "saber" fazer design — é que o encapsulamento do fluxo de design ficou bom o suficiente para virar produto de primeira classe dentro de uma ferramenta que, até seis meses atrás, era vendida estritamente como "assistente de código". Essa é a mesma lógica de composição que já vinha se desenhando: cada skill nova expande o que "usar o Claude Code" significa, e o limite deixa de ser a capacidade bruta do modelo e passa a ser quão bem a equipe sabe orquestrar, revisar e integrar o que cada skill devolve.

Conclusão

O que fica claro depois de ler a cobertura disponível sobre o /design é que ele resolve um problema real e específico — a distância entre "tenho uma ideia de tela" e "tenho algo que dá pra mostrar" — comprimindo isso para dentro de um único ambiente. Isso tem valor genuíno para o tipo de cenário que descrevi, hipoteticamente, ao longo do post: prototipagem rápida, telas internas sem front-end dedicado, primeira rodada de alinhamento antes de envolver design de verdade. Não é hype vazio — é a mesma lógica de compressão de ciclo que já vimos em quase todo recurso recente do Claude Code, aplicada agora a uma etapa que historicamente ficava fora do terminal.

Ao mesmo tempo, não tenho como afirmar, com a informação pública disponível hoje, que o /design resolve os três pontos que historicamente travam geração de UI por IA — fidelidade a sistema de design existente, acessibilidade, e código reaproveitável versus descartável. A cobertura que encontrei descreve o comportamento observável do recurso, não os detalhes técnicos que responderiam essas perguntas, e o próprio rótulo de "pré-visualização de pesquisa" já sinaliza que a Anthropic trata isso como algo ainda não maduro o suficiente para promessa de produção. Tratar a saída do /design como rascunho a revisar, não como entrega final, parece a postura mais honesta até que apareça uso real e comparação documentada.

Fico com uma leitura mais ampla, talvez a parte mais interessante deste lançamento: o modelo de skills do Claude Code amadureceu o suficiente para que a própria empresa que o construiu use esse mecanismo para lançar capacidade de primeira classe, em vez de hardcodar um recurso novo direto no produto. Isso diz algo sobre para onde ferramentas agênticas em geral estão indo — menos "produto com lista fixa de funcionalidades", mais "núcleo mais ecossistema de skills que expandem o que o núcleo sabe fazer". Se essa leitura estiver certa, o /design não é o fim da lacuna entre design e código dentro do terminal. É um primeiro exemplo público de quanto essa lacuna pode encolher quando alguém trata a skill certa como produto, não como acessório.

Fontes:

De Screenshot A Interface Editável: O Que O /Design Do Claude Code Promete Entregar

De Screenshot A Interface Editável: O Que O /Design Do Claude Code Promete Entregar

O Que A Skill Design Faz E Como Se Encaixa No Modelo De Skills

Cenários Hipotéticos De Uso No Dia A Dia

Onde A Promessa Provavelmente Esbarra Em Limite Conhecido

Como Isso Se Conecta Com A Discussão Mais Ampla De Skills E Ferramentas Agênticas

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose