IA testa contra o próprio prompt. Teste com personas.

Quando uma IA termina de codificar uma feature, ela "testa". Mas o que ela chama de teste é: roda o fluxo que eu descrevi no prompt, com os dados que eu dei, no cenário que eu imaginei. Se funcionou, declara pronto.

Isso não é teste. É confirmação de que a IA entendeu o prompt. E confirmar que entendeu o prompt não é o mesmo que confirmar que o software funciona.

IA testa o código contra a intenção do prompt. Não contra a realidade do usuário. A diferença é onde os projetos morrem.

O que a IA não testa

A IA tem pontos cegos previsíveis:

Cenário	O que a IA faz	O que deveria fazer
Input vazio	Não testa: o prompt não mencionou	Verificar se o empty state orienta
Duplo clique	Não considera: o prompt descreveu um clique	Verificar se debounce ou disabled state existe
Sem internet	Não simula: a IA assume conexão	Verificar se error state aparece com ação de retry
Usuário voltando depois de 2 semanas	Não pensa nisso: a IA pensa no fluxo linear	Verificar se o contexto é reapresentado
Campo com 8000 caracteres	Não testa limites: o prompt disse "texto"	Verificar se validação existe

Cada um desses é um cenário que um usuário real vai encontrar. A IA não os testa porque meu prompt não os descreveu. E meu prompt não os descreveu porque eu não pensei neles, que é exatamente o problema que o princípio resolve.

Os 3 perfis que eu codifiquei

Isso é o princípio 5 do Taste Loop: "anda o caminho do usuário, não o happy path do código". E virou a régua mais importante no dev757: antes de declarar pronto, o agente precisa simular três perfis distintos passando pela feature.

Especialista impaciente. Conhece o domínio, quer entrar e sair. Nota cada clique desperdiçado, cada loading desnecessário, cada confirmação que podia ser pulada. Se ele perde tempo, a feature falhou.

Recém-chegado hesitante. Não conhece o domínio. Precisa de labels, confirmações, orientação. Abandona se confuso por mais de 10 segundos. Se ele não sabe o que fazer, a feature falhou.

Usuário recorrente. Usou uma vez semana passada. Esqueceu o contexto. Precisa se reorientar rápido. Se ele não consegue retomar de onde parou, a feature falhou.

Se um dos três não consegue completar a tarefa, não tá pronto. Não é recomendação: é regra. E tá codificada no AGENTS.md que o agente lê antes de começar.

Por que 3 e não 1

Porque o happy path é o perfil 1: o que o autor imaginou. Se você só testa com esse perfil, vai encontrar zero bugs. Se você testa com os 3, encontra os problemas que o usuário real vai encontrar antes que ele encontre.

No Study Space, o especialista impaciente achou que o timer não era arrastável (deveria ser PiP). O recém-chegado hesitante não sabia como adicionar a primeira matéria (a tela estava vazia). O usuário recorrente esqueceu qual edital estava estudando (não tinha reorientação). Nenhum desses bugs apareceu no happy path.

Como isso muda a orquestração

Quando eu orquestro IA, o prompt inclui os perfis. Em vez de "crie um dashboard", o prompt é: "crie um dashboard. Antes de declarar pronto, teste com: (1) alguém que já sabe usar e quer velocidade, (2) alguém que nunca viu e precisa de orientação, (3) alguém que voltou depois de 2 semanas e precisa se reorientar. Se qualquer um falhar, não tá pronto."

A IA agora testa além do que eu imaginei. Não porque ela é mais inteligente, mas porque eu dei contexto suficiente pra ela considerar cenários que eu sozinho não lembraria.

Como isso se conecta ao Taste Loop

O princípio 5 é o último filtro antes de declarar que algo tá pronto. No Taste Loop, é o equivalente a "anda o caminho do usuário": se a feature sobreviveu ao Prescription Filter, passou pelo princípio 1 (ir além), pelo princípio 2 (jornada), pelo princípio 3 (standards) e pelo princípio 4 (estados de feedback), ela ainda precisa sobreviver ao teste dos 3 perfis.

O dev757 garante que isso aconteça. É a última regra antes do "pronto". Se o agente não rodou os 3 perfis, não pode declarar que terminou.