O ciclo: intenção → gerar → revisar → refinar

Tudo neste livro volta a um único ciclo. Internalize-o.

O ciclo gira até que o resultado atinja o seu padrão — e a revisão é o portão pelo qual ele precisa passar toda vez:

   ┌──────────────────────────────────────────────┐
   │                                               │
   ▼                                               │
┌────────┐    ┌──────────┐    ┌────────┐    ┌──────────┐
│ INTENT │ ─▶ │ GENERATE │ ─▶ │ REVIEW │ ─▶ │  REFINE  │
│ (spec) │    │  (AI)    │    │ (you)  │    │  (you)   │
└────────┘    └──────────┘    └───┬────┘    └──────────┘
                                  │
                            pass? ▼
                            ┌──────────┐
                            │   SHIP   │
                            └──────────┘

Intenção. Declare o que você quer e as restrições que importam — entradas, saídas, casos de borda, a stack, o estilo. Intenção vaga gera código vago.
Gerar. Deixe o modelo escrever a implementação. Não fique guiando a sintaxe passo a passo; descreva o comportamento.
Revisar. Leia o que voltou. Ele realmente faz o que deveria? Ele trata a lista vazia, o nulo, a chamada de rede que falha? É a versão mais simples que funciona?
Refinar. Aponte o que está errado, dê uma correção concreta e gere novamente. Repita até atingir o seu padrão.

A maioria dos iniciantes pula o passo 3. Eles geram, roda, e seguem em frente. Aí quebra em produção no caso que nunca foi descrito. O passo de revisão é onde a engenharia acontece de fato.

Veja como é um bom primeiro nesse ciclo:

Write a TypeScript function `parseDuration(input: string): number`
that converts strings like "1h30m", "45s", "2d" into total seconds.

Requirements:
- Support units: d (days), h (hours), m (minutes), s (seconds).
- Multiple units can combine: "1h30m" = 5400.
- Reject invalid input (empty, unknown units, negative) by throwing
  an Error with a clear message.
- No external libraries. Include 5 unit tests covering the edge cases.

Show the function and tests only.

Repare na estrutura: uma assinatura precisa, regras explícitas, os casos de borda apontados, as restrições declaradas e um pedido de testes. Você não está torcendo para que o modelo acerte no chute — você está eliminando a ambiguidade que produz chutes ruins.

O passo de refinar é uma habilidade tão importante quanto o primeiro prompt. Feedback vago gera correções vagas. Compare estas duas correções:

Bad:  "this is wrong, fix it"

Good: "parseDuration('1h30m') returns 90 instead of 5400 — you're
       summing the numbers but ignoring the unit multipliers. Multiply
       each value by its unit's seconds (d=86400, h=3600, m=60, s=1)
       before summing. Also add a test for the combined case '2d3h'."

A boa versão nomeia o sintoma, a causa e a correção. Você está revisando como faria com o de um colega — e quanto mais preciso for o seu apontamento, menos rodadas você gasta. Cada ciclo deve convergir. Se você se pegar girando em círculos, esse é um sinal de que sua intenção estava subespecificada; pare de gerar de novo e reescreva a especificação em vez disso.

O ciclo: intenção → gerar → revisar → refinar

Quer offline?