design.md Cortou Falhas em 57%. Nenhuma Página Saiu Pronta para Publicar.

A Vercel rodou três cenários de desktop no Codex sobre GPT-5.5, cada um uma vez com o arquivo de política design.md carregado e uma vez sem ele. Seis páginas. Com o arquivo, as verificações determinísticas contaram 39 falhas conhecidas. Sem ele, 91. A Vercel apresenta isso como 57% menos falhas. E o mesmo post acrescenta a frase que pesa mais do que a porcentagem: cada uma das seis páginas, com ou sem o arquivo, ainda tinha pelo menos uma falha grave o bastante para bloquear a publicação.

Os dois fatos pertencem juntos. Um arquivo de política para um agente eleva o piso. O teto, “publicar sem um humano”, continua onde estava. Quem constrói governança de agentes fora do código, em finanças, jurídico, compras ou marca, deveria ler o post da Vercel por esse par de números e pelo loop que os produziu.

O post é How our agents build on-brand pages with design.md, de John Phamous com contribuição de Kevin Corbett, publicado em 31 de agosto de 2026. Uma ressalva antes da análise: trabalhei a partir de uma renderização condensada da página, então as citações abaixo são os fragmentos como retornados, e não parágrafos completos. O 57% é aritmética da própria Vercel a partir de 39 e 91.

O que a Vercel de fato publicou

Dois artefatos públicos. O arquivo de política vive em vercel.com/design.md. A folha de estilos vive em vercel.com/geist/vercel-brand.css. A separação é nítida: o arquivo carrega o julgamento de marca como prosa que o agente lê, e a folha de estilos carrega a mecânica delimitada como CSS que o agente aplica.

Em volta desses dois artefatos existe um harness de avaliação. A Vercel construiu sete cenários a partir de uso interno real: relatório de uso e performance, proposta de renovação, relatório de benchmark, página interativa de planejamento, brief de construir ou comprar, brief de governança de segurança e deck de apresentação. Nenhum deles é landing page de marketing. São os documentos que um engenheiro de vendas ou um time de soluções produz numa terça-feira à tarde, a classe de saída que, na minha experiência, raramente passa por revisão de design.

O post reporta “mais de 200 execuções”, uma contagem que inclui rodadas completas, verificações pontuais e ensaios. A comparação pareada que produziu 39 contra 91 é mais estreita: três cenários de desktop, um modelo.

Já tratamos do design.md como arquivo de instrução para agentes e do que acontece quando agentes escrevem a própria camada de restrições. Este post é o primeiro lugar em que vi uma empresa publicar as contagens de antes e depois de um arquivo desse tipo. Essa é a razão para escrever sobre ele.

A regra de triagem é a parte reutilizável

Cada correção no loop da Vercel é encaminhada para um de três destinos.

Uma mudança de julgamento entra no design.md como prosa. Uma mecânica reutilizável entra na folha de estilos. Uma falha mecânica ganha uma verificação determinística em código. O post dá um exemplo que caiu em dois destinos ao mesmo tempo: tabelas de termos comerciais estavam sendo espremidas na largura da prosa, e a correção foi uma regra no design.md mais uma verificação em código. A regra ensina ao agente por que uma tabela de termos comerciais precisa de espaço. A verificação pega o agente quando ele esquece.

Leia a regra como artefato de governança e o contexto de design deixa de importar. Qualquer time que entrega um documento de política a um agente enfrenta as mesmas três perguntas quando o agente erra. Faltou julgamento ao agente? Escreva onde o agente lê. Era uma capacidade que o agente precisava reconstruir a cada vez? Empacote para que ele aplique em vez de improvisar. Era uma falha que uma máquina detecta? Então pare de pedir a um humano que detecte, e pare de pedir ao agente que prometa não repetir.

A terceira pergunta é onde vejo os esforços de governança de agentes travarem. Times escrevem arquivos de instrução cada vez mais longos, codificando regras que uma expressão regular aplicaria com mais confiabilidade do que qualquer modelo. A regra da Vercel empurra na direção oposta: prosa só para julgamento, código para tudo o que código consegue segurar.

A instrução que mantém o loop honesto

Uma linha do post merece citação isolada: “Atualize a orientação em vez de ajustar à mão a página gerada. Sua próxima comparação diz se as primeiras tentativas de fato melhoraram.”

Essa é a disciplina que separa um loop de avaliação de uma fila de revisão. Numa fila de revisão, um humano conserta o artefato e segue adiante. O agente produz o mesmo defeito na semana seguinte. No loop da Vercel, a instrução é não consertar a página. O movimento prescrito é mudar a orientação, e pela regra de triagem a folha de estilos ou as verificações, e depois rodar a comparação de novo para ver se a primeira tentativa melhorou.

A consequência é que toda correção humana vira uma mudança mensurável no sistema, e a melhoria do sistema é testada em vez de presumida. Um time que deixa revisores remendarem saídas diretamente nunca descobre se o arquivo de política funciona, porque o resultado publicado passa a refletir o revisor, sem dizer nada sobre a política.

O que o teto significa

De volta à frase que pesa. Seis de seis páginas continuaram bloqueadas, com ou sem design.md.

A própria Vercel diz isso, e acrescenta que seis páginas é pouco para afirmações amplas sobre qualidade. Aceite as duas declarações como estão. A amostra é pequena. A direção é clara o bastante para agir: o arquivo de política removeu uma fatia grande das falhas mecânicas que as verificações conseguiam contar e deixou intacta a classe de falha que impede uma página de ser publicada.

É para isso que serve um arquivo de política. Ele transforma a porção verificável da qualidade em algo que o agente acerta na primeira tentativa com mais frequência. O resíduo, as falhas graves o bastante para bloquear, é a porção que ainda precisa de uma pessoa. O resultado da Vercel põe um número nessa divisão, e o número diz que a pessoa continua no loop depois que o arquivo foi escrito.

Nosso texto anterior sobre agentes como detectores de drift argumentou que agentes revelam onde um design system está subespecificado. As falhas bloqueantes que sobraram nessas seis páginas são esse resíduo. Cada uma é uma regra que ninguém escreveu ainda, uma mecânica que ninguém empacotou ainda ou uma verificação que ninguém codificou ainda. O loop existe para tirá-las, uma por vez, da fila do humano.

A metade em produção

O harness de avaliação é metade da montagem da Vercel. A outra metade é um agente interno no Slack, @design-agent, que produz páginas para pedidos reais. A Vercel agrega as reclamações repetidas semanalmente e acompanha a frequência de reclamações antes e depois de cada mudança na orientação. As mudanças finais na orientação passam por revisão humana.

O pareamento é o ponto central. O harness responde “a mudança ajudou nos cenários fixos?”. O registro de reclamações responde “a mudança ajudou no que as pessoas de fato pediram?”. Um arquivo de política que melhora o benchmark e deixa as reclamações do Slack no mesmo nível foi ajustado para o teste.

Para uma função fora de design, troque os substantivos. O agente do Slack é o seu bot de redação de contratos, o seu assistente de onboarding de fornecedores, o seu resumidor de fechamento mensal. A agregação semanal de reclamações é a reunião de revisão que você já faz. O harness é a parte que você provavelmente ainda não construiu: um conjunto fixo de pedidos realistas, rodado com e sem a política, contado por uma máquina.

Por que esse padrão viaja

O loop da Vercel generaliza porque nunca trata o documento de política como o produto. O produto é a divisão entre o que uma máquina consegue verificar e o que um humano precisa julgar, e o trabalho inteiro do loop é empurrar a fronteira entre os dois, uma correção por vez, com uma rodada de comparação depois de cada empurrão. Substrato que se adapta aos agentes foi o nome que demos a tokens e restrições que se movem com o agente em vez de atrás dele. O loop da Vercel é essa ideia com um placar.

O modo de falha contra o qual ele protege é o que todo programa de governança de agentes encontra em algum momento: o arquivo de política cresce, a confiança nele cresce mais rápido, e a etapa de revisão humana é encurtada com a teoria de que o arquivo agora cobre tudo. As seis páginas da própria Vercel dizem que o arquivo não cobriu. 57% menos falhas, zero páginas publicáveis. Os dois números são verdadeiros, e o segundo é o que governa o processo de revisão.

Faça isso agora

Escolha um agente que a sua empresa roda numa função fora de código e um documento de política que ele lê. Depois construa a menor versão possível do loop da Vercel.

Anote cinco pedidos realistas que esse agente atende. Pegue os bagunçados do mês passado, os que já geraram reclamação. Rode cada um com o documento de política carregado e uma vez sem ele. Deixe uma máquina contar o que ela consegue contar: seções ausentes, formatos errados, restrições violadas que você consegue expressar como verificação. Deixe um humano marcar cada saída como publicável ou bloqueada.

Você vai ter dois números. O primeiro é quanto o documento de política reduz falhas contáveis. O segundo é quantas saídas ainda precisam de uma pessoa. Publique os dois para o time dono do agente e institua a regra da Vercel: a partir de agora, ninguém conserta uma saída. Conserta-se a orientação, a mecânica reutilizável ou a verificação, e rodam-se os cinco pedidos de novo.

O primeiro número diz se o arquivo vale a manutenção. O segundo diz onde a etapa de revisão humana ainda mora. Não deixe ninguém remover essa etapa até que o segundo número chegue a zero por conta própria.

---

Fontes

• Vercel. “How our agents build on-brand pages with design.md.” Agosto de 2026.

A Victorino ajuda times de engenharia e operações a construir loops de avaliação em torno dos arquivos de política que seus agentes leem, para que o esforço de revisão vá para as falhas que só um humano julga: contato@victorino.com.br | www.victorino.com.br