Como escrever uma tarefa para um assistente de IA com um resultado que você consiga revisar?

Peça uma só mudança, diga onde ela fica e o que não pode mudar, dê uma verificação que passa ou falha e peça um relatório do que foi feito.

Peça uma só mudança, pequena o bastante para testar em poucos minutos. Diga onde ela fica, o que deve continuar como está, como verificar que funciona e o que você quer ouvir de volta. Uma tarefa escrita assim volta como algo que você consegue julgar: uma lista curta de arquivos alterados, uma verificação que passou ou falhou e um jogo que você pode jogar para confirmar. Uma tarefa vaga volta como uma mudança grande que "parece pronta", e aí toda a conferência fica com você.

O que torna uma tarefa revisável?

Cinco partes. A maioria das tarefas precisa das cinco, e cada uma cabe em uma ou duas frases.

Nada disso é novo. O guia do GitHub para escrever prompts para o Copilot pede um pedido simples e específico, dividido em passos, com um ou dois exemplos do que você espera. As boas práticas do Claude Code colocam em primeiro lugar uma verificação que o assistente possa rodar, porque sem ela "parece pronto" é o único sinal que ele tem. As duas páginas diziam isso em 25 de outubro de 2026. O que segue aplica esses conselhos a um jogo pequeno.

Qual deve ser o tamanho de uma tarefa?

Pequena o bastante para descrever a mudança em uma frase e testá-la em poucos minutos. "Adicione uma tela de pausa" é uma tarefa. "Adicione uma tela de pausa, um menu de configurações e som" são três, e quando algo quebrar você não vai saber qual delas foi.

Se uma tarefa precisa de uma descrição mais longa, peça primeiro um plano e deixe o código para depois. A página do Claude Code sugere exatamente isso: deixe o assistente ler o código e propor quais arquivos mudariam, leia o plano você mesmo e só então deixe ele escrever. Um plano que mexe em metade do projeto é sinal de que a tarefa deve ser dividida.

É a mesma regra de manter seu primeiro jogo pequeno: cada recurso tem que funcionar com todos os outros, então uma tarefa que adiciona três multiplica a conferência.

Como fica uma tarefa vaga ao lado de uma revisável?

Aqui está um mesmo pedido para um pequeno jogo de tiro, escrito duas vezes.

A coluna da direita é mais longa, mas cada linha dela pode ser verificada. A terceira é parecida com o que fizemos ao adicionar controles por toque ao KittenGalaxy: os botões enviam os eventos de tecla que o teclado enviaria, então o jogo em si não precisou mudar.

Como dizer ao assistente como verificar o próprio trabalho?

Dê a ele algo que responda sim ou não.

• Um teste que o assistente possa rodar, com os casos escritos: "um reinício deixa a pontuação em 0".
• Um comando cujo resultado dá para ler: a compilação termina, a página carrega sem erros no console.
• Passos que você mesmo vai jogar, escritos antes da mudança: "começar, perder todas as vidas, apertar reiniciar, a pontuação mostra 0".

Peça ao assistente para rodar a verificação e mostrar a saída, não para dizer que passou. Um resultado de teste colado ou um log do console sem erros se lê em segundos; uma frase dizendo "tudo funciona" não prova nada.

Algumas coisas só uma pessoa pode julgar: se um pulo parece certo, ou se uma fase é justa. Para essas, escreva o que você vai observar e jogue você mesmo. Não deixe o relatório do assistente tomar esse lugar.

O que o assistente deve dizer quando terminar?

Peça, na mesma tarefa, um relatório curto nesta ordem:

1. quais arquivos mudaram e, em uma linha para cada, por quê;
2. quais verificações ele rodou e o que elas retornaram;
3. o que ele não testou, e por quê;
4. qualquer coisa que ele mudou sem você pedir.

O último item é o mais importante. Uma mudança além do pedido nem sempre está errada, mas é sempre algo que você não planejava revisar. Compare a lista de arquivos com a parte 3 da sua tarefa: um arquivo que não deveria ter mudado é o primeiro lugar para olhar.

O que vai em um arquivo do projeto em vez de em cada tarefa?

Tudo o que você teria de repetir: como rodar o jogo e os testes, quais pastas não podem ser tocadas, as regras do código. A maioria dos assistentes lê um arquivo assim no começo de uma sessão (o Claude Code o chama de CLAUDE.md). Mantenha-o curto; a página do Claude Code avisa que, em um arquivo longo, as regras importantes se perdem.

Uma regra merece lugar ali quando esquecê-la quebra o jogo. As anotações que mantemos para o KittenGalaxy dizem que, sempre que uma tecla, uma tela ou um estado do jogo é adicionado, o controle por toque correspondente entra na mesma mudança, senão quem joga no celular não consegue chegar até ele. Assim a tarefa só precisa dizer o que é novo.

O que fazer quando o resultado está errado?

Volte atrás e peça de novo com uma tarefa melhor.

Salve uma versão que funciona antes de cada tarefa, como um commit no controle de versão, para que uma mudança ruim possa ser desfeita em um passo. Quando uma verificação falha, você pode pedir uma correção uma ou duas vezes. Se duas correções falharem, a página do Claude Code sugere começar uma sessão nova com um primeiro pedido melhor em vez de corrigir de novo e de novo, porque as tentativas que falharam ficam na conversa. Desfaça a mudança, acrescente à tarefa o que você aprendeu e envie de novo.

Perguntas frequentes

Preciso ser programador para escrever tarefas assim? Não. As partes 1, 3 e 5 falam do que o jogo faz, em palavras simples. Para a parte 2, pergunte ao assistente onde a mudança deve ficar antes de pedir que ele a faça.

Uma tarefa longa é melhor que uma curta? Não por si só. Uma tarefa longa que pede muitas mudanças é mais difícil de revisar que uma curta que pede uma. O tamanho ajuda quando acrescenta uma verificação ou um limite.

Devo pedir testes em um jogo pequeno? Para regras que dá para dizer com exatidão (a pontuação, as vidas, um cronômetro, os jogos salvos), sim. Eles custam pouco para rodar depois de cada mudança seguinte. Sensação e diversão continuam precisando ser jogadas.

E se o assistente me fizer perguntas? Responda na tarefa antes de ele começar a escrever. Uma pergunta feita cedo custa menos que uma mudança errada.

Quando o jogo está pronto para mostrar às pessoas? Quando um desconhecido consegue abri-lo por um link e terminá-lo sem a sua ajuda. Aí você pode enviá-lo ao HeapPlay, e desenvolvedores verificados podem registrar cada nova versão e o que mudou.