Fundamentos
Especificação por Exemplo: o eval que você já sabe escrever
Gojko Adzic descreveu em 2011 o método que resolve o problema de 2026: transformar conversa sobre requisito em exemplo executável que a máquina verifica.
Em 2011, Gojko Adzic publicou um livro depois de entrevistar mais de 50 times que tinham conseguido fazer software complexo dar certo com processo iterativo. Ele estava atrás do padrão comum. Achou um, e chamou de Especificação por Exemplo.
Quinze anos depois, todo mundo está redescobrindo esse padrão com outro nome e achando que é novidade. Chamamos de eval. De critério de aceite para agente. De rubrica. De harness. É o mesmo problema: como uma pessoa comunica o que quer para algo que vai executar rápido demais e literal demais, e como ela confere depois.
Se você lidera um time colocando IA em produção, esse é provavelmente o método mais barato que existe hoje na sua mesa. E você já sabe metade dele.
O problema que ele resolve
A prosa mente. Não por má fé: por economia.
Quando alguém escreve "o sistema deve calcular o desconto do cliente premium", essa frase carrega dez suposições que ninguém enunciou. Premium desde quando? Desconto sobre o valor cheio ou sobre o já promocional? E se o cliente virou premium no meio do mês? E se o pedido for cancelado parcialmente?
Ninguém está escondendo essas respostas. Elas simplesmente não estão na cabeça de ninguém ainda. Vão nascer no momento em que alguém tentar executar a frase. E se quem executa é um agente, elas nascem em produção, às três da manhã, na forma de um número errado numa nota fiscal.
Adzic percebeu que os times bem-sucedidos não resolviam isso escrevendo requisitos melhores. Resolviam abandonando a prosa e falando por exemplo.
Cliente virou premium em 10 de março. Pedido de R$ 1.000 em 15 de março, com promoção de 10% já aplicada. Desconto premium de 5%. Total esperado: R$ 855.
Essa linha não tem ambiguidade. Ou ela está certa ou está errada, e as duas pessoas na sala descobrem qual em cinco segundos. É isso. O método inteiro sai daí.
O ciclo, em cinco passos
Adzic organiza a coisa assim:
1. Derive o escopo de um objetivo. Não comece pela feature, comece pelo resultado de negócio que ela deveria produzir. É a mesma raiz do Impact Mapping, que ele também criou. Se ninguém sabe dizer qual número muda, não vale exemplificar nada ainda.
2. Ilustre com exemplos, numa conversa. É a parte que ninguém pula impunemente. Junte três pessoas: alguém que entende o negócio, alguém que vai construir, alguém que vai testar. A literatura chama de "três amigos". Cada um traz exemplos, e a mágica acontece quando um exemplo de um deixa outro sem resposta.
3. Refine a especificação. Corte o exemplo redundante, mantenha o exemplo-chave. Um bom conjunto tem o caso feliz, os casos de borda e os casos que definem a fronteira. Se você tem 40 exemplos e 35 provam a mesma coisa, você tem ruído, não cobertura.
4. Automatize a verificação sem mudar a especificação. A regra é sutil e é o coração da coisa. Você não reescreve o exemplo em linguagem de teste. Você escreve uma cola que faz o exemplo, do jeito que o pessoal de negócio o escreveu, rodar contra o sistema. Se você precisou reescrever, você quebrou o vínculo entre o que foi combinado e o que é verificado.
5. Evolua uma documentação viva. O conjunto de exemplos automatizados vira a fonte da verdade sobre o que o sistema faz. Ele não apodrece igual wiki porque, quando o comportamento muda e o exemplo não, o build quebra.
A tradução direta para IA
Agora troque as palavras e veja o que acontece.
| Especificação por Exemplo (2011) | Operação de IA (2026) |
|---|---|
| Objetivo de negócio | A métrica que a IA deveria mover |
| Exemplo-chave | Caso do dataset de avaliação |
| Oficina dos três amigos | Sessão de curadoria do eval, com negócio na sala |
| Automatizar sem mudar a especificação | Rodar o eval contra a saída real, não contra a saída que você reescreveu para caber |
| Documentação viva | Suíte que roda a cada troca de modelo, prompt ou ferramenta |
O encaixe é constrangedoramente bom. Quando Addy Osmani diz para colocar a régua no eval e não na demo, ele está dizendo o passo 4. Quando Martin Fowler diz que você não terceiriza o critério de aceite, ele está dizendo o passo 2. Quando a UnitedHealth decide que o modelo só pode aprovar e que negativa passa por humano, ela está codificando um exemplo-chave sobre em qual direção o erro é aceitável.
A diferença entre 2011 e 2026 é uma só, e é a que faz o método valer mais agora: antes, o custo de descobrir a suposição implícita tarde era um sprint. Agora é um agente rodando dez mil vezes com a suposição errada antes de alguém olhar.
Como começar na segunda-feira
Escolha um comportamento de IA que já está em produção e que você não confia totalmente. Um só.
Marque uma hora com três pessoas. Alguém do negócio, alguém que construiu, alguém que testa. Se você não tem os três, o método não funciona, e essa é uma informação sobre o seu time, não sobre o método.
Peça exemplos, não regras. A pergunta é "me dá um caso em que a resposta certa é X". Não é "qual é a regra". Regra vira prosa, e prosa mente.
Anote os que travarem a sala. Quando alguém der um exemplo e ninguém souber a resposta certa, você achou ouro. Esse é o caso que ia quebrar em produção. Marque-o e leve para quem decide.
Escolha de 8 a 15 exemplos-chave. Caso feliz, bordas, fronteiras, e pelo menos dois casos do que não deve acontecer. Este último grupo é o mais difícil e o mais valioso com IA, porque é onde mora o comportamento emergente.
Faça rodar automático. Não precisa de framework caro. Precisa de um script que pegue os exemplos, chame o sistema e compare. Se demorar mais que meio dia, você está complicando.
Rode a cada mudança. Modelo novo, prompt novo, ferramenta nova, roda. É esse hábito que transforma o conjunto em documentação viva em vez de arquivo morto.
A armadilha, que é a mesma de 2011
Adzic avisou disso no livro e o aviso envelheceu bem demais: times que começam pela ferramenta fracassam.
A tentação é comprar a plataforma de eval, popular com 500 casos gerados por LLM, ver o dashboard verde e declarar vitória. O que você tem aí é uma suíte cara que ninguém escreveu, ninguém entende e ninguém confia. Quando ela ficar vermelha, o time vai ajustar o teste em vez de investigar o sistema, porque ninguém sabe por que aquele caso existe.
O valor do método nunca esteve no artefato. Está na hora em que três pessoas com contextos diferentes descobrem, na frente umas das outras, que não concordavam sobre o que era certo. A ferramenta preserva essa descoberta. Ela não a produz.
Comece pela conversa. O resto é encanamento.
Se quiser rodar essa primeira oficina de exemplos com o seu time e sair dela com um eval de verdade, fala com a gente no WhatsApp.
Perguntas frequentes
Qual a diferença entre Especificação por Exemplo, ATDD e BDD?
São primos com ênfases diferentes. ATDD, ou desenvolvimento guiado por teste de aceite, foca em escrever o critério de aceite antes do código. BDD, cunhado por Dan North, foca na linguagem compartilhada entre negócio e técnica. Especificação por Exemplo, nome que Gojko Adzic escolheu no livro de 2011 justamente para escapar do ruído dos outros dois termos, foca no exemplo concreto como unidade de entendimento e no ciclo que transforma exemplo em documentação viva. Na prática, times maduros usam os três de forma indistinguível.
Isso não é só escrever teste antes?
Não. Teste antes é uma prática de quem já entendeu o requisito. Especificação por Exemplo é uma prática para descobrir o requisito, e o teste é o subproduto. A diferença aparece na oficina: quando o pessoal de negócio dá um exemplo e o desenvolvedor responde e se acontecer isto, e ninguém sabe responder, você acabou de encontrar a lacuna que ia virar bug em produção. Nenhum teste escrito por uma pessoa sozinha acha isso.
Vale a pena com IA, se o modelo muda a cada dois meses?
Vale mais justamente por isso. Se o seu critério de correto está na cabeça de alguém, cada troca de modelo é um recomeço. Se ele está numa suíte de exemplos executáveis, trocar de modelo vira um comando e uma tabela de resultado. O ativo que sobrevive à troca de modelo não é o prompt, é o conjunto de exemplos que define o que é certo.