Seu primeiro bom prompt

Um prompt não substitui uma decisão de produto: ele a torna visível para que outra pessoa ou uma inteligência artificial (IA) possa agir sobre ela. A prática recomendada por OpenAI e Google parte de instruções claras, contexto relevante, exemplos quando trazem um padrão, e ciclos de revisão. Aqui você vai aplicar essa pauta a um formulário para criar tarefas.

O caso é pequeno de propósito. O formulário precisa de título, responsável, prazo e prioridade; deve recusar dados incompletos e confirmar que salvou. Esse escopo permite observar se cada instrução muda um comportamento concreto.

Transforme a ideia numa tarefa verificável

«Faça um gerenciador de tarefas» descreve um produto, mas não define a próxima mudança. Uma tarefa verificável indica o que deve aparecer, o que uma pessoa consegue fazer e como você saberá que funciona. No nosso caso, o primeiro objetivo é preencher um formulário e salvar uma tarefa válida.

Formule o pedido com um verbo e um resultado observável. Por exemplo: «Crie o formulário para registrar uma tarefa com título, responsável, prazo e prioridade; ao enviar, acrescente a tarefa à lista». Essa frase ainda precisa de contexto e validação, mas já impede que a IA invente um painel, um calendário ou um sistema de permissões.

Se quiser aprender o ciclo completo em volta desse pedido, veja o que é vibe coding. O prompt inicia uma iteração; a revisão, os testes e a decisão de aceitar a mudança continuam sendo seus.

Traga só o contexto que muda a solução

O contexto útil reduz decisões ocultas. Nomeie o framework, se já existir, os componentes que devem ser reaproveitados, o idioma da interface e onde o estado é guardado. Indique também quais arquivos ou áreas não devem mudar.

Para o formulário de tarefas, o contexto poderia dizer que o aplicativo já tem uma lista e um componente de botão, que os textos ficam em português e que o estado permanece em memória. Não é preciso explicar a história inteira do projeto. Inclua a informação que mudaria a implementação ou a forma de conferi-la.

Quando você não conhece a stack, diga isso de forma direta. Peça primeiro uma proposta curta com suas consequências e aprove antes de autorizar mudanças. Essa pausa evita que uma escolha técnica acidental vire uma dependência difícil de remover.

Descreva o resultado antes de pedir código

A saída esperada inclui estrutura e comportamento. No exemplo, você precisa de quatro campos rotulados, um botão de envio, erros junto ao campo afetado e uma confirmação depois de salvar. Também dá para pedir a lista de arquivos alterados e os testes executados.

Um exemplo concreto ajuda quando a forma do resultado importa. Escreva uma tarefa válida, como «Preparar a demo, responsável Ana, prazo 20 de julho, prioridade alta», e uma entrada inválida com o título vazio. Assim o modelo tem um padrão para o estado correto e outro para o erro.

Não use o exemplo como substituto da regra. Se você mostrar apenas uma data válida, a IA pode aceitar qualquer texto parecido. Explique também que a data precisa ser real e não anterior ao dia atual.

Fixe critérios de aceitação observáveis

Critérios de aceitação transformam «parece pronto» numa revisão repetível. Para este formulário, cada critério precisa ser verificável na interface ou por um teste. Evite frases como «que seja intuitivo», porque não dizem qual comportamento deve mudar.

Você pode definir os resultados a seguir. Cada um corresponde a um teste visível:

1. Título, responsável e data são obrigatórios.
2. Uma data passada mostra uma mensagem ao lado do campo e não salva a tarefa.
3. Um envio válido acrescenta uma única tarefa com todos os seus valores.
4. O formulário só é limpo depois de salvar com sucesso.
5. A navegação por teclado alcança campos, opções e botão numa ordem lógica.

Esses critérios também limitam o escopo. Se a IA acrescentar filtros, autenticação ou sincronização remota, ela trabalhou fora da tarefa, ainda que o resultado pareça bonito.

Melhore o resultado com feedback específico

A primeira versão pode falhar mesmo com um prompt claro. Reproduza o problema e responda com três dados: o que você fez, o que aconteceu e o que esperava. Para o formulário: «Escolhi ontem como data, o envio foi aceito e eu esperava um erro ao lado do campo».

Acrescente um teste que impeça a regressão. Peça para cobrir uma data passada e outra futura, rodar a suíte existente e mostrar o resultado. Essa prática transforma feedback em evidência e evita uma correção visual que deixe a lógica intacta.

Não misture várias correções sem relação. Se você também quer mudar cores e acrescentar rótulos, deixe essas tarefas para iterações separadas. Assim dá para atribuir cada resultado a uma instrução e reverter só o necessário.

Reconheça os limites e as falhas do prompt

Um prompt detalhado não garante uma solução correta. O modelo pode assumir um fuso horário, ignorar uma convenção do repositório, inventar uma API ou escrever um teste que só confirma a própria implementação. Leia o código e execute o fluxo real.

Dados sensíveis exigem outra camada de cuidado. Não cole credenciais, dados pessoais nem conteúdo privado para «dar contexto». Se o trabalho precisar de acesso externo ou ações irreversíveis, defina permissões mínimas e aprovação humana; o guia de agentes de IA explica esse contrato.

A recomendação de dividir tarefas e dar feedback concreto é uma heurística prática, não uma lei universal. Uma migração coordenada pode exigir um plano amplo, enquanto uma correção local cabe num pedido curto. Ajuste a profundidade ao risco e mantenha sempre uma forma independente de conferir o resultado.

Revise o prompt antes de enviar

Use esta lista como porta de entrada da tarefa. Cada caixa deve corresponder a uma frase ou critério visível no seu pedido.

• O objetivo nomeia uma única mudança concluída.
• O contexto inclui só dados, arquivos e decisões relevantes.
• O resultado esperado descreve estados válidos e estados de erro.
• Os critérios de aceitação podem ser conferidos sem interpretar intenções.
• O escopo exclui mudanças e ações que você não autorizou.
• A tarefa contém um teste ou percurso para validar o resultado.

Se não conseguir marcar uma caixa, corrija o prompt antes de ampliá-lo. No formulário de tarefas, o objetivo final não é receber muito código: é conseguir criar uma tarefa válida, recusar uma inválida e demonstrar os dois comportamentos.