Relatório: Spend, a v0.09 do Hunch contra a versão em produção, um prompt simples e o grill-me

Data: 2026-10-10. O pacote da v0.09 saiu do commit 25694ab e o da versão em produção, do commit 3ca8931 (a main, gerado com o código dela, numa cópia separada do repositório).

O teste

O app: Spend, reembolso de despesas numa empresa pequena.

• O ciclo: a pessoa cria a despesa como rascunho e a envia; o gestor da equipe aprova ou recusa (com motivo) até 500,00; acima disso, só o financeiro; o financeiro paga.
• Os limites: uma despesa vale de 0,01 a 10.000,00 e não pode ser do futuro; o teto mensal é de 2.000,00 por pessoa, sem contar rascunhos e recusadas.
• A forma: é um monolito Node.js com API JSON e SQLite, só com os módulos do Node 24. Dentro da caixa do app, o board desenha a arquitetura onion.

O mesmo board (design/) gerou os dois pacotes e deixava zero perguntas na v0.09. Os agentes eram do mesmo modelo, rodaram em paralelo e recebiam as mesmas instruções (../tools/agent-prompt.md).

Resultado

A v0.09 é melhor que a versão em produção?

O critério foi escrito no roadmap antes de rodar: não perder em comportamento nem em contrato, e gastar menos tokens ou registrar menos decisões, sem piorar a cobertura nem a forma.

• Comportamento e contrato: empate, 34 de 34 e 12 de 12 nas duas.
• Custo: 15% menos tokens, 36% menos tempo e 13 chamadas de ferramenta em vez de 20.
• Decisões: 7 em vez de 24. As 24 da versão em produção incluem:
• as duas perguntas em aberto que o pacote dela deixava, por defeitos já corrigidos;
• a lista inteira de códigos de erro;
• as mensagens de 405 e 500;
• a ordem das checagens de cada endpoint.

A v0.09 já fixa tudo isso.

• Forma: nenhuma quebra nas duas.
• Cobertura: linhas (+2 pontos) e funções (+4,2) melhoraram, mas ramos caiu 1,6 ponto (95,9% para 94,3%). Pela letra do critério, isso é uma piora, e fica registrado assim.

Veredito: melhor, com essa ressalva. A versão em produção escreveu 106 testes à mão, quase o dobro, e isso pesa nos ramos cobertos. A v0.09 recebeu 28 testes prontos e escreveu 26. Gastou menos e chegou ao mesmo comportamento.

E contra o prompt simples?

• O Hunch ganha no que foi combinado. O simples errou 5 dos 12 códigos (400 em vez de 422, 404 em vez de 403). Também deixou um gestor criar despesa e deixou a pessoa ver a fila de aprovação, coisas que o board proíbe.
• E na forma do código. O simples tem uma função de 146 linhas com complexidade 35, um arquivo que mistura HTTP e SQL, e 3 arquivos no total.
• O simples continua mais barato: cerca de metade dos tokens. A proporção (1,9x) é a mesma do Shelf e do Clinic. A v0.09 ficou mais barata que a versão anterior do Hunch, não que um parágrafo. O custo restante acompanha o código e os testes que a arquitetura pede: 558 linhas de código e 671 de teste, contra 372 e 250.

E contra o grill-me?

O Hunch ganha. Os dois chegam a 34 de 34 regras e 12 de 12 códigos, mas:

• Custo: o Hunch gasta 2,7 vezes menos tokens do agente (82 mil contra 224 mil), sem contar os 117 mil da pessoa simulada no grill-me.
• A pessoa: com o Hunch, ela não responde nada; com o grill-me, foram 36 perguntas em 3 rodadas.
• Código: é mais simples no Hunch: maior função de 34 linhas contra 84, complexidade máxima de 8 contra 17, nenhuma função acima de 40 linhas (o grill-me tem 2) e menos duplicação.
• Cobertura: maior no Hunch nas três medidas.
• Decisões: 7 contra 24. A entrevista fixou o produto, mas deixou para o agente os códigos de erro, as mensagens de 401 e 405 e a ordem das checagens, que o pacote do Hunch já traz.

Desta vez, o grill-me não construiu nada além do pedido. A pessoa recusou as sugestões que iam além do board: edição de rascunho, a lista de pagamentos e /me. No Clinic, ela tinha aceitado 4. Isso depende de quem responde, e numa pessoa real é difícil de prever.

O grill-me continua bom para descobrir o que a pessoa quer quando ainda não há um board. Quando o board existe, a entrevista refaz em 36 perguntas o que o pacote entrega pronto.

Defeitos do Hunch encontrados e corrigidos

Ao desenhar o board (commit 25694ab):

• Uma história não achava a entidade quando só o caminho a nomeava (/expenses/{id}/submit). Agora o caminho conta.
• Um campo `category` com enum recebia a pergunta "quais transições são permitidas?" Agora só um campo de status (status, state, stage) é perguntado.
• A mesma lacuna aparecia duas vezes no Build with AI.

Pelo agente da v0.09 (commit b6d43c0):

• O teste de contrato do 404 por id mandava `reject` sem corpo, o que contradiz a ordem das checagens: o 400 viria antes. O agente mudou a ordem do app para passar no teste. Agora o teste manda um corpo válido.
• O app que o harness sobe não tinha como ter o relógio ajustado, e os testes de regras de data usaram a data real. Agora startApp({ now }) passa NOW ao app, e o padrão do AGENTS.md manda o relógio começar dele.

Pela medição (commit 79d650b):

• O harness falhava de vez em quando. Na primeira medição, 4 dos 54 testes da v0.09 falharam, e numa repetição falharam de novo uma vez em três execuções. Os arquivos de teste rodam em paralelo; o harness reservava uma porta, soltava e só depois subia o app, então dois arquivos podiam pegar a mesma porta, e ele esperava só 10 segundos sem perceber que o app tinha morrido. Agora ele tenta outra porta quando o app morre, confere que respondeu o próprio app e, se não subir, falha com uma mensagem clara. Com o harness novo, o mesmo app passou em 6 de 6 execuções. O metrics.json guarda a medição como saiu (50 de 54).

Limites deste teste

• Uma rodada de cada lado, com um modelo. O ganho sobre a versão em produção (15% de tokens) está dentro do que uma segunda rodada poderia mudar. A diferença em decisões (7 contra 24) é grande demais para ser só variação.
• Quem desenhou o board, escreveu a sonda e avaliou também construiu o Hunch. A sonda separa comportamento de contrato, e a robustez não vem do board.
• Os três defeitos achados pelo agente da v0.09 e pela medição foram corrigidos depois da rodada, e não rodei os agentes de novo.
• O grill-me rodou depois dos outros três e foi interrompido duas vezes (pelo limite de uso e por o computador dormir). O trecho em que ele escreveu a rodada 3 não informou tokens, então o total dele está um pouco abaixo do real. O tempo do fim da entrevista ficou de fora pelo mesmo motivo.

Arquivos

• design/: o board (board.hunch e boards/app.hunch)
• with-hunch/: o pacote da v0.09 e o app
• hunch-prod/: o pacote da versão em produção e o app
• simple/: o prompt e o app
• grill-me/: o prompt, a skill, a entrevista (GRILL.md), o plano (PLAN.md) e o app
• eval/probe.mjs e eval/result-*.json: a sonda e os resultados
• runs.json e metrics.json: os números