PRECISE

O PRECISE é a heurística proposta no Capítulo 4 de Agentic SDLC como a sucessora do INVEST — a lista de verificação de 2003 de Bill Wake para histórias de usuário. Uma boa história, argumentou Wake, deveria ser Independent (Independente), Negotiable (Negociável), Valuable (Valiosa), Estimable (Estimável), Small (Pequena) e Testable (Testável). O INVEST se tornou uma das heurísticas mais amplamente adotadas no desenvolvimento ágil. Ele é ensinado em certificações Scrum, impresso em pôsteres nas salas das equipes e embutido no modelo mental de product owners e desenvolvedores no mundo inteiro.

Para equipes humanas escrevendo itens de trabalho de tamanho humano, ele funciona. Mas o INVEST foi projetado para um modelo de execução em que um desenvolvedor humano lê uma história, discute com um product owner, usa julgamento profissional para preencher as lacunas e a implementa. Quando o executor é um agente de IA, várias propriedades do INVEST exigem reconsideração — e uma delas, a Negociável, pode ser ativamente prejudicial.

Negociável: a propriedade mais perigosa

Negociável significa que uma história de usuário não é uma especificação detalhada. É um convite a uma conversa. A história captura a intenção em um nível alto, e os detalhes são resolvidos entre o product owner e a equipe de desenvolvimento durante a implementação. Isso fazia sentido quando a comunicação humana era o gargalo e escrever especificações detalhadas era caro: uma conversa de cinco minutos era mais barata que uma especificação de cinco páginas.

Agora considere um agente pegando uma história que diz: "Como usuário, eu quero redefinir minha senha para poder recuperar o acesso à minha conta." O link de redefinição deve expirar? Depois de quanto tempo? A nova senha deve atender a requisitos de complexidade? O sistema deve registrar as tentativas de redefinição? Deve haver um limite de taxa?

Um desenvolvedor humano faria essas perguntas durante a conversa de negociação. Um agente, sem essa conversa, vai adivinhar. Algumas de suas suposições serão razoáveis; algumas serão erradas. E, como o agente não sabe quais suposições estão erradas, ele produzirá com confiança uma implementação que pode não corresponder ao que o product owner pretendia. Isso não é uma falha do agente. É uma falha da especificação. O problema é que inferência não é negociação.

Flexibilidade não exige ambiguidade.

Uma especificação pode ser adaptável — capaz de evoluir conforme os requisitos mudam — sem ser ambígua. O problema com o Negociável não é que ele valoriza a flexibilidade. O problema é que ele iguala flexibilidade a deixar coisas por dizer. Em um modelo de execução humana, deixar coisas por dizer era eficiente; a conversa as preencheria. Em um modelo agêntico, deixar coisas por dizer significa deixá-las para a inferência do agente. E inferência não é o mesmo que entendimento.

O princípio mais profundo

Humanos negociam porque a comunicação é cara. Máquinas precisam de especificações porque a execução é barata.

Quando a comunicação é o gargalo — quando o tempo do product owner é escasso, quando as reuniões são caras, quando escrever documentação parece custo indireto — a estratégia racional é minimizar a comunicação. Escreva menos. Converse mais. Preencha as lacunas pela conversa.

Quando o custo de execução colapsa — quando agentes conseguem produzir código em segundos — a estratégia racional se desloca. O gargalo não é mais a comunicação entre humanos. É a fidelidade da especificação contra a qual o agente executa. Uma especificação precisa produz uma implementação correta. Uma especificação ambígua produz uma implementação rápida, mas incorreta. Nesse mundo, investir na qualidade da especificação não é custo indireto. É alavancagem.

O resto do INVEST, reconsiderado

• Independente — ainda valioso, mas a ênfase se desloca. Importava para permitir trabalho humano paralelo. Para agentes, importa para a verificação: um entregável independente pode ser verificado independentemente, e sua implantação não arrisca quebrar outra coisa que está pela metade.
• Valioso — inalterado. Se algo, mais importante: quando a execução é barata, a tentação é implementar tudo. Mas código é um passivo, não um ativo. Cada linha que não entrega valor ainda precisa ser mantida, testada e entendida.
• Estimável — relevância em declínio. A execução é elástica; você pode rodar mais agentes em paralelo. O fator limitante não são as horas humanas, mas a qualidade da especificação. A pergunta se desloca de "quanto tempo um humano levará?" para "essa especificação está clara o bastante para um agente executar de forma confiável?"
• Pequeno — precisa de redefinição. A medida relevante não é se o trabalho cabe em uma janela de duas semanas. É se o trabalho pode ser especificado com precisão e verificado completamente dentro de uma única unidade de execução.
• Testável — importância crescente. Torna-se a propriedade mais importante de todas: a propriedade que restringe a execução autônoma. Especificações testáveis são a interface entre a intenção humana e a verificação por máquina.

De INVEST para PRECISE

A diferença entre as duas heurísticas é a diferença entre otimizar para a coordenação da execução humana e otimizar para a governança da execução agêntica. O INVEST ajuda uma equipe a responder: "Esta história está pronta para um humano trabalhar nela?" O PRECISE ajuda uma equipe a responder: "Esta especificação está pronta para um agente executar de forma confiável — e para um humano revisar de forma significativa?" São perguntas diferentes, e merecem heurísticas diferentes.

O resultado final

O INVEST não é inútil. É uma heurística criada para um modelo de execução específico, e funciona bem dentro desse modelo. Ele não deveria ser tratado como uma lei universal do desenvolvimento de software — e certamente não deveria ser aplicado sem modificação à execução agêntica.

Toda prática tem suposições. Toda heurística foi criada em um contexto. A questão é se o contexto ainda se aplica.