Construir & corrigir

O ciclo construir-testar-corrigir

Enviaste o teu mini-PRD, a IA gerou a base da tua app. Começa agora a fase mais longa — e a mais formadora — do projeto: a construção iterativa. O ritmo é sempre o mesmo: pedes uma coisa, a IA fá-la, testas imediatamente, e consoante o resultado validas ou corriges. Depois recomeças com a coisa seguinte.

Este ritmo pode parecer lento comparado com a tentação de pedir tudo de uma vez. Na realidade, é muito mais rápido ao longo do tempo, por uma razão simples: quando aparece um bug, sabes exatamente que pedido o introduziu — o último. Sem esta disciplina, um bug pode vir de qualquer um dos teus cinco últimos pedidos, e vais passar mais tempo à procura do culpado do que a corrigi-lo.

flowchart LR
  D["Pede UMA coisa"] --> G["A IA gera"]
  G --> T["Testa imediatamente"]
  T -->|"Funciona"| V["Valida e passa ao seguinte"]
  T -->|"Parte-se"| E["Copia o erro exato"]
  E --> C["Pede a correção"]
  C --> T
  V --> D

Testar cada etapa: a tua checklist

Após cada geração, abre a app e experimenta realmente a funcionalidade. Não te contentes em olhar para o ecrã: usa a app como o faria um utilizador. Para a função «adicionar um hábito» do Tom, isso significa: escrever um nome, clicar no botão, verificar que o hábito aparece, adicionar um segundo, e depois recarregar a página para verificar que tudo continua lá.

Habitua-te também a testar os casos limites — é lá que se escondem os bugs: o que acontece se adicionares um hábito com nome vazio? Se adicionares vinte? Se clicares duas vezes muito depressa? Não precisas de ser exaustivo, mas dois ou três ensaios «fora das linhas» por funcionalidade revelam as fragilidades antes dos teus utilizadores.

• Testar o caso normal: a ação principal funciona?
• Recarregar a página: os dados continuam lá?
• Testar um caso limite: campo vazio, valor estranho, duplo clique.
• Verificar no telemóvel (ou encolhendo a janela) se a tua app é mobile-first.

A consola do navegador: o teu melhor aliado

Quando algo parte sem explicação visível, a resposta está quase sempre na consola do navegador. Carrega em F12 (ou clique direito → «Inspecionar»), depois abre o separador «Console». É lá que o navegador escreve os erros: linhas vermelhas, muitas vezes em inglês, que indicam o que falhou e onde.

Não precisas de compreender estas mensagens — só precisas de as copiar. Eis o aspeto de um erro típico:

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
    at app.js:24:18

Tradução livre: «na linha 24 do ficheiro app.js, o código tenta usar algo que não existe». É exatamente o tipo de pista de que a IA precisa para corrigir numa mensagem em vez de cinco. Erros frequentes que vais encontrar: TypeError (o código manipula um valor do tipo errado), ReferenceError (usa um nome que não existe), SyntaxError (o próprio código está mal formado), e 404 Not Found (um ficheiro não foi encontrado).

O prompt de depuração perfeito

Quando parte, não digas «não funciona». A IA não tem maneira nenhuma de adivinhar o que vês no ecrã. Um bom relatório de bug contém quatro elementos: o que estavas a fazer, o que esperavas, o que aconteceu em vez disso, e a mensagem de erro exata da consola. Com estas quatro informações, o diagnóstico é quase sempre imediato.

Bug a corrigir.
O que estava a fazer: clico em «adicionar um hábito» depois de escrever «Leitura» no campo.
O que esperava: o hábito aparece na lista.
O que acontece: nada aparece, o campo esvazia-se.
Erro na consola: Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at app.js:24:18
Diagnostica a causa e corrige, explicando-me de forma simples o que estava mal.

Repara na última frase: «explicando-me de forma simples o que estava mal». É ela que transforma cada bug numa lição. Ao fim de dez correções, vais reconhecer tu mesmo os erros comuns — e escreverás pedidos que os evitam à partida.

Quando a IA anda em círculos

Acontece: assinalas um bug, a IA «corrige», o bug continua lá, ela «corrige» de novo, e nada muda — ou pior, outra coisa parte. Ao fim de duas ou três tentativas infrutíferas, para de insistir no mesmo caminho. Três estratégias eficazes: pede à IA que recomece do zero nessa funcionalidade («apaga todo o código do calendário e refá-lo de forma mais simples»), pede-lhe que adicione mensagens de diagnóstico («adiciona console.log para vermos onde bloqueia»), ou reformula completamente o teu pedido inicial, que talvez fosse ambíguo.

Tem também em mente a opção nuclear: voltar à última versão que funcionava e retomar a partir daí. É exatamente para isso que serve o Git, de que falamos já a seguir — uma rede de segurança que torna as experiências sem risco.

Guardar com o Git: a tua rede de segurança

O Git é a ferramenta que todos os programadores usam para guardar o histórico de um projeto. A ideia cabe numa imagem: a cada etapa que funciona, tiras uma «fotografia» (um commit) do teu projeto. Se uma experiência correr mal, voltas à última fotografia num instante. Já não precisas de ter medo de partir: tudo é reversível.

Se estás numa ferramenta de navegador (Lovable, v0, Bolt), boa notícia: a maioria gere o histórico de versões por ti — procura um menu «History» ou «Versions» e descobre como restaurar um estado anterior. Se estás no Cursor ou no Claude Code, pede simplesmente à IA que faça os commits por ti, ou aprende os três comandos essenciais:

# A cada etapa que funciona, tira uma fotografia do projeto:
git add .
git commit -m "Adicionar hábito funciona"

# Para ver o histórico das tuas fotografias:
git log --oneline

O ritmo certo: um commit após cada funcionalidade testada e validada. A mensagem do commit descreve o que funciona («marcação diária OK», «calendário visível»). O Tom adquire este hábito logo na primeira noite — e no dia em que uma experiência de design parte toda a sua disposição, volta atrás em trinta segundos em vez de reconstruir tudo.

Avançar por pequenos passos seguros

Uma funcionalidade testada e que funciona = um ponto de apoio sólido. Constróis sobre o estável, não sobre areia. É o que evita o efeito «está tudo partido e não sei porquê» que desencoraja tantos iniciantes. A sequência completa do Tom para cada funcionalidade: pedir → testar → corrigir se necessário → fazer commit → passar à seguinte.

Este método tem um efeito secundário precioso: a confiança. Cada pequeno passo validado é uma vitória concreta, e a motivação alimenta-se de vitórias. No fim do capítulo, a app do Tom faz tudo o que a v1 previa — adição, eliminação, marcação diária, streak — e cada tijolo foi verificado. Está pronto para a publicação online.