Você pede uma tela pro agente. O resultado chega em segundos, bonito, e errado. Você ajusta o pedido, ele erra pra outra direção. Na quinta tentativa você desiste e faz na mão, com a sensação de que a ferramenta é superestimada.
A ferramenta não é o problema. O pedido é.
Um agente de IA executa a intenção que recebeu. Tudo que você não especificou, ele decide sozinho: o tom, o estado de erro, o comportamento no vazio, o que acontece no mobile. O resultado parece aleatório porque a parte que faltou foi preenchida por estatística, não por você.
É por isso que a especificação virou o centro do trabalho. Quando executar fica barato, o valor migra pra quem sabe dizer o que construir e como verificar se ficou certo. Esse é o conceito de Specification Literacy: a capacidade de transformar intenção em especificação que uma máquina executa e um humano audita. É o conceito investigado no artigo que recebeu o Best Paper Award na AIMEDIA 2026, e é a primeira etapa do ciclo de sete etapas da escola.
As cinco partes de uma especificação executável
Uma especificação que funciona tem cinco partes, nesta ordem:
- Intenção. O problema do usuário em uma frase, com o resultado esperado. Não é a solução, é o porquê.
- Contexto. Quem usa, em que situação, com que restrição real: dispositivo, acessibilidade, idioma, estado de erro.
- Decisões já tomadas. O que NÃO está em aberto: design system, tom de voz, padrões do produto. Tudo que você não fixar aqui, o agente decide por você.
- Critérios de aceite. Como você vai verificar que ficou pronto. Cada critério precisa ser checável (um teste, um screenshot, um número), não uma opinião.
- Fora de escopo. O que este pedido explicitamente não cobre. É a parte que mais evita retrabalho.
O protocolo dos buracos
Escrever as cinco partes é metade do trabalho. A outra metade: antes de autorizar qualquer construção, peça ao agente que devolva a especificação preenchida e aponte os buracos, toda pergunta que ele faria antes de construir. Responda os buracos, atualize a especificação, e só então libere.
Esse passo inverte a dinâmica. Em vez de descobrir o que faltou olhando um resultado errado, você descobre antes de gastar uma linha de código.
O teste de qualidade
Quer saber se a sua especificação está boa? Entregue a mesma especificação duas vezes, em conversas separadas. Se os dois resultados divergem no que importa, ela está subespecificada exatamente onde divergiu. O teste custa dez minutos e mostra onde está o buraco.
Como praticar essa semana
- Pegue o próximo pedido real do seu trabalho e escreva as cinco partes antes de abrir o agente. Vai doer; a dor é o diagnóstico.
- Passe o checklist de brief antes de enviar. Ele pega o que o pedido vago esconde.
- Se quiser rodar com o agente conduzindo, conecte os métodos via MCP e peça: "roda o método de especificação executável no meu brief".
O capítulo 1 do handbook desce mais fundo no argumento. Este guia é a versão pra usar hoje.