DEV Community: MeloLabs.net

How to use Haiku in everyday SDD without overspending

MeloLabs.net — Sun, 08 Nov 2026 04:04:56 +0000

The plain version of the study "SDD with Haiku only". If you want the scientific rigor, read the technical article. This is what it means for someone who wants to use Haiku tomorrow.

In one sentence

Haiku does the job of writing documents (PRD, technical spec, tasks) almost as well as Sonnet for about 1/5 of the price. On code, it works well when you put it in a process with tests and correction; alone, it fails more. The study does not prove it is worse or equal on code. And in a real project it is almost never only the AI: with an engineer reviewing, this is a good path to start with.

What we tested

We ran the full cycle (PRD, technical spec, tasks and code) 198 times on a real open-source project, h3, with Haiku 5.5 and Sonnet 5.5, and checked the code with hidden tests the model never saw. Three AI judges, without knowing which model wrote each document, scored the documents.

What we found

1. Cost. Haiku with the process below cost US$ 0.22 per run, against US$ 1.23 for Sonnet. Counting only the runs where the code passed the tests, it is US$ 0.31 against US$ 1.36.

2. Documents. On TechSpec and Tasks scores, Haiku was practically tied with Sonnet: less than 1 point apart, out of 35 and 25. Note: the judges did not see the original request, so this measures text quality and structure, not "faithful to the request".

3. Code. Here is the map by task (green always passed, red almost never):

Plain Haiku (no process) did badly on three tasks.
Haiku with tests first and a correction loop improved a lot, but still failed on #1384-a, #1384-c and #1267.
Almost all of Haiku's failures on the #1384 tasks came from one edge case (asking for a route that does not exist and getting the error in the right format). Without that case, Haiku passes as much as Sonnet.

The recipe that worked best

A clear, short request. Say what the feature does, with the exact names (functions, options, response formats) and expected behaviors. The vaguer the request, the more the model invents.
Haiku writes the documents. PRD, technical spec and tasks. This is where it pays off most for the price.
Automatic document checks. A simple script checks what a human does not need to: whether headings follow the agreed format, whether the files and lines cited exist, whether every PRD requirement is covered by a task. If it fails, give Haiku the real errors, at most twice. In practice the gate rarely failed (3 of 234 documents), so it is a cheap safety net.
Tests first. Ask Haiku to write tests from the spec, run them and watch them fail, and only then implement.
Correction loop with real output. Run tests, typecheck and lint, and give the model what the command actually printed, for up to 3 rounds.
A person reviews. And if the code still does not pass the tests, hand the task to a larger model (Sonnet). Note: this last step is a suggestion. The study did not test real escalation (the study's cascade never escalated).

Steps 1 to 5 are what was measured. Step 6 is the natural conclusion, but it is still a hypothesis.

And the engineer in all this?

In a real project, the AI does not run alone. There is a person behind it: who writes the request, reads the documents, looks at the test results and decides what to do. In the study, nobody intervened, on purpose, to measure the raw model. It is a hard test: no error was caught by a person.

That changes the reading. Haiku's main error was a forgotten edge case (asking for a route that does not exist and getting the error in the right format). That is the kind of thing a code review, or one more line in the request, usually catches before production. With an engineer in the process:

Moment	What the person does
Request	Writes it with exact names and remembers the edge cases
Documents	Reads the spec and the tasks and fixes what looks off
Tests	Checks that the tests Haiku wrote cover what matters and adds what is missing
When something fails	Decides whether to fix the request, adjust the code or hand the task to a larger model
Delivery	Reviews the result, as with any colleague

Our reading, optimistic: Haiku does the heavy lifting, fast and cheap, and the person guarantees final quality. Mind the difference: this is reasoning from the data, not something the study measured. Measuring "Haiku plus engineer" is the next step.

What is not worth it

Asking Haiku to "improve" its own text with no check. It was a control in the study; there is no evidence it helps.
Putting Sonnet only on the technical spec (hybrid): it cost more than 3 times the cascade without improving scores.
Counting on persona and extra context in the prompt as a magic fix: the gain, if any, is about 1 point and is still a weak signal.

To start tomorrow

[ ] Pick a small feature that already has automated tests.
[ ] Write the request with exact names and expected behaviors.
[ ] Ask Haiku for the three documents and run a simple check on them.
[ ] Ask for tests first, then the code, and feed back the real command output.
[ ] Decide who reviews and what that person checks (request, documents, tests).
[ ] If it fails more than 3 rounds, hand it to a larger model.
[ ] Record cost and result. Your project may give different numbers than ours.

What we do not know yet

We tested one project (TypeScript, three features). The conclusion on code is still open, and the document rubric has limitations. But the path (Haiku on documents, tests first and correction on code, and a person reviewing) is cheap, showed results in several cases and fits how real teams work. The technical article has the numbers, the intervals and everything that may be wrong.

The experiments, data and conclusions are mine. The writing was AI-assisted and reviewed by me.

Como usar o Haiku no dia a dia do SDD, sem gastar à toa

MeloLabs.net — Sun, 08 Nov 2026 04:02:16 +0000

Versão simples do estudo "SDD só com Haiku". Se você quer o rigor científico, leia o artigo técnico. Aqui está o que ele significa para quem quer usar o Haiku amanhã.

Em uma frase

O Haiku faz o trabalho de escrever documentos (PRD, especificação técnica, tarefas) quase tão bem quanto o Sonnet por cerca de 1/5 do preço. No código, ele funciona bem quando você o coloca num processo com testes e correção; sozinho, erra mais. O estudo não prova que ele é pior ou igual em código. E num projeto real quase nunca é só a IA: com um engenheiro revisando, esse é um caminho bom para começar.

O que a gente testou

Rodamos 198 vezes o ciclo completo (PRD, especificação técnica, tarefas e código) num projeto aberto de verdade, o h3, com o Haiku 5.5 e o Sonnet 5.5, e conferimos o código com testes escondidos que o modelo nunca viu. Três juízes de IA, sem saber qual modelo escreveu cada documento, deram notas aos documentos.

O que a gente descobriu

1. Custo. O Haiku com o processo abaixo custou US$ 0,22 por execução, contra US$ 1,23 do Sonnet. Se contarmos só as execuções em que o código passou nos testes, são US$ 0,31 contra US$ 1,36.

2. Documentos. Nas notas de TechSpec e Tasks, o Haiku ficou praticamente empatado com o Sonnet: diferença de menos de 1 ponto, de 35 e de 25 possíveis. Atenção: os juízes não viam o pedido original, então isso mede qualidade do texto e da estrutura, não "ficou fiel ao pedido".

3. Código. Veja o mapa por tarefa (verde passou sempre, vermelho quase nunca):

O Haiku simples (sem processo) foi mal em três tarefas.
O Haiku com testes primeiro e loop de correção melhorou bastante, mas ainda falhou em #1384-a, #1384-c e #1267.
Quase toda a falha do Haiku nas tarefas #1384 foi um único caso de borda (pedir uma rota que não existe e receber o erro no formato certo). Sem esse caso, o Haiku passa tanto quanto o Sonnet.

A receita que funcionou melhor

Pedido claro e curto. Diga o que a feature faz, com os nomes exatos (funções, opções, formatos de resposta) e os comportamentos esperados. Quanto mais vago o pedido, mais o modelo inventa.
O Haiku escreve os documentos. PRD, especificação técnica e tarefas. É aqui que ele rende mais pelo preço.
Checagem automática dos documentos. Um script simples confere o que dá para conferir sem ser humano: se os cabeçalhos estão no formato combinado, se os arquivos e linhas citados existem, se toda exigência do PRD foi coberta por uma tarefa. Se reprovar, devolva ao Haiku os erros reais, no máximo duas vezes. Na prática o gate raramente reprovou (3 em 234 documentos), então ele é um seguro barato.
Testes primeiro. Peça ao Haiku que escreva testes a partir da especificação, rode e veja falhar, e só então implemente.
Loop de correção com a saída real. Rodar testes, typecheck e lint, e devolver ao modelo o que o comando realmente imprimiu, em até 3 rodadas.
Uma pessoa revisa. E se o código ainda não passar nos testes, passe a tarefa para um modelo maior (Sonnet). Atenção: esse último passo é uma sugestão. O estudo não testou escalar de verdade (a cascata do estudo nunca escalou).

Os passos 1 a 5 são o que foi medido. O passo 6 é a conclusão natural, mas ainda é hipótese.

E o engenheiro nessa história?

Num projeto real, a IA não roda sozinha. Tem uma pessoa por trás: quem escreve o pedido, lê os documentos, olha o resultado dos testes e decide o que fazer. No estudo, ninguém interveio, de propósito, para medir o modelo puro. É um teste duro: nenhum erro foi pego por uma pessoa.

Isso muda a leitura. O principal erro do Haiku foi um caso de borda esquecido (pedir uma rota que não existe e receber o erro no formato certo). É o tipo de coisa que uma revisão de código, ou uma linha a mais no pedido, costuma pegar antes de ir para produção. Com um engenheiro no processo:

Momento	O que a pessoa faz
Pedido	Escreve com nomes exatos e lembra dos casos de borda
Documentos	Lê a especificação e as tarefas e corrige o que estiver estranho
Testes	Confere se os testes escritos pelo Haiku cobrem o que importa e acrescenta o que faltou
Quando algo falha	Decide se corrige o pedido, ajusta o código ou passa a tarefa para um modelo maior
Entrega	Revisa o resultado, como faria com qualquer colega

A nossa leitura, otimista: o Haiku faz o trabalho pesado, rápido e barato, e a pessoa garante a qualidade final. Fique atento à diferença: isso é um raciocínio a partir dos dados, não algo que o estudo mediu. Medir "Haiku mais engenheiro" é o próximo passo.

O que não vale a pena

Pedir ao Haiku para "melhorar" o próprio texto sem nenhuma checagem. Foi um controle do estudo; não há evidência de que ajude.
Pôr o Sonnet só na especificação técnica (modelo híbrido): custou mais de 3 vezes o da cascata sem melhorar as notas.
Contar com persona e contexto extra no prompt como solução mágica: o ganho, se existe, é de cerca de 1 ponto e ainda é um sinal fraco.

Para começar amanhã

[ ] Escolha uma feature pequena e com testes automáticos já existentes.
[ ] Escreva o pedido com nomes exatos e comportamentos esperados.
[ ] Peça ao Haiku os três documentos e rode uma checagem simples neles.
[ ] Peça os testes primeiro, depois o código, e devolva a saída real dos comandos.
[ ] Defina quem revisa e o que essa pessoa confere (pedido, documentos, testes).
[ ] Se falhar mais de 3 rodadas, passe para um modelo maior.
[ ] Anote o custo e o resultado. Seu projeto pode dar números diferentes dos nossos.

O que ainda não sabemos

Testamos um projeto (TypeScript, três funcionalidades). A conclusão sobre o código ainda é aberta, e a rubrica dos documentos tem limitações. Mas o caminho (Haiku nos documentos, testes primeiro e correção no código, e uma pessoa revisando) é barato, mostrou resultado em vários casos e combina com como equipes reais trabalham. O artigo técnico traz os números, os intervalos e tudo que pode estar errado.

Os experimentos, os dados e as conclusões são meus. A redação foi assistida por IA e revisada por mim.