Alternar tema

A IA vive escrevendo código errado? Domine 5 técnicas de prompt e ganhe 50% de eficiência

Easton editorial illustration: solo-founder business system console

Sexta-feira, quatro e meia da tarde. O Cursor acabou de gerar um código e eu fiquei sem reação.

Eu só queria que ele escrevesse uma API de login de usuário. O resultado foi um monstro de 300 linhas: tipos de parâmetros todos errados, conexão com banco de dados hardcoded no código e três estilos diferentes de tratamento de erro misturados. Respirei fundo, apaguei tudo e comecei de novo. Na segunda tentativa, ele mexeu num arquivo de configuração que eu nunca tinha pedido para tocar e deixou tudo irreconhecível.

Foi aí que a ficha caiu: o problema não estava na IA. Estava no fato de eu não ter dito direito o que ela deveria fazer e, principalmente, o que ela não deveria fazer.

A ferramenta de programação com IA estava instalada, a empolgação também era alta, mas depois de usar por um tempo percebi um padrão: o código gerado ou não tinha nada a ver com a necessidade, ou parecia certo e quebrava assim que rodava. Depois de várias rodadas de correção, eu teria terminado mais rápido escrevendo à mão.

Um colega usava o mesmo Cursor, para escrever uma funcionalidade parecida, e resolvia em dez minutos o que eu levava uma hora tentando ajustar. A diferença? O prompt dele tinha estrutura clara, contexto completo e limites bem definidos.

Este artigo mostra, passo a passo, 5 técnicas de prompt para Cursor que funcionam de imediato. Não é teoria sofisticada; são fórmulas simples tiradas da prática. No fim, você vai saber como fazer a IA entender de verdade a necessidade e gerar código preciso e utilizável.

Por que seu prompt sempre “falha”

A IA não lê pensamentos; ela só “enxerga” as informações que você entrega

Muita gente acha que, por a IA ser inteligente, ela deveria adivinhar o que queremos. Errado. Por mais forte que seja, a IA ainda é um “autocompletador de texto avançado”: ela só raciocina com base nas informações que você fornece. O que você não diz, ela tenta adivinhar.

É como ligar para um amigo e pedir para ele comprar café dizendo só: “compra um café pra mim”. Quando ele chega à cafeteria, trava: americano ou latte? Grande ou médio? Com açúcar? No fim, ele compra qualquer coisa no palpite. Com IA é igual.

Em projetos grandes, o problema de “memória curta” da IA fica ainda mais evidente. A janela de contexto é limitada; ela não consegue colocar sua codebase inteira na “cabeça”. Você pede para alterar uma função, e ela talvez nem saiba que essa função é chamada por outros 20 lugares. Uma mudança pode derrubar tudo.

Três desastres comuns de prompt

Desastre 1: vago demais

❌ “Me ajude a implementar ordenação”

Esse comando é como colocar “quero ir para São Paulo” no GPS. São Paulo onde? De carro, metrô ou avião? Que horas precisa chegar? Ao receber algo assim, a IA improvisa. Ela pode escrever um bubble sort ou chamar uma biblioteca de terceiros que nem existe no seu projeto.

✅ “Adicione uma função em utils/array.ts para ordenar a lista de usuários por data de cadastro em ordem decrescente, usando o método nativo Array.sort() e sem adicionar novas dependências”

Percebe a diferença? A segunda versão deixa claro: qual arquivo, quais dados, qual método e quais limites.

Desastre 2: falta de contexto

❌ “Adicione tratamento de erro”

IA: adicionar onde? Tratar qual erro? Usar try-catch ou código de erro? Retornar em qual formato?

É como o médico perguntar “onde dói?” e você responder só “dói”. Dá para diagnosticar? Não.

✅ “Na função handleLogin de api/login.ts, adicione tratamento de erro:

  • Capture falhas de requisição de rede usando try-catch
  • Retorne o formato unificado { success: false, error: string }
  • Use como referência o tratamento de erro existente em api/register.ts”

Desastre 3: sem restrições

❌ “Otimize o desempenho deste componente”

Ao receber isso, a IA pode desmontar o seu código: adicionar biblioteca, mudar gerenciamento de estado ou até reescrever a arquitetura do componente. Você queria só adicionar React.memo; ela faz uma cirurgia completa.

✅ “Otimize o desempenho do componente UserList.tsx:

  • Use apenas React.memo ou useMemo
  • Não modifique a interface de props do componente
  • Não adicione novas bibliotecas de terceiros”

A verdade sobre as “alucinações” da IA

Você já viu a IA chamar uma função que não existe? Ou usar uma variável que não aparece no seu projeto? Isso é a tal alucinação.

Segundo estudos de boas práticas do time do Cursor, fornecer contexto claro pode reduzir 70% dos problemas de alucinação. Por quê?

Quando a informação está incompleta, a IA “preenche os buracos” sozinha. Se você não mostra como o código atual é, ela deduz a partir de padrões comuns. Por exemplo: você pede uma tela de login, e ela assume que existe um método authService.login(). Só que talvez esse método nem exista no seu projeto.

A solução é simples: mostre explicitamente para a IA o código existente relevante.

Hoje, antes de escrever qualquer prompt, eu me faço três perguntas:

  1. A IA sabe em qual arquivo deve agir?
  2. A IA conhece a estrutura do código existente?
  3. A IA sabe o que pode e o que não pode alterar?

Se não consigo responder a essas três perguntas, ainda não é hora de enviar o prompt.

A fórmula de ouro do prompt estruturado

Framework 5W1H: faça a IA entender a necessidade em segundos

Jornalistas usam uma fórmula clássica: 5W1H (Who, What, When, Where, Why, How). Dá para usar a mesma lógica em prompts.

  • What (objetivo): o que você quer que a IA faça?
  • Why (motivo): por que isso deve ser feito? (ajuda a IA a entender a intenção)
  • Where (local): em qual arquivo ou módulo agir?
  • When (momento): em que situação isso é acionado?
  • Who (objeto): qual objeto de dados será manipulado?
  • How (forma): qual stack ou biblioteca deve ser usada?

Parece complicado? Na prática, você não precisa escrever tudo sempre. O ponto central é: não faça a IA adivinhar.

Imagine que você quer que a IA adicione validação de dados:

❌ Versão vaga:

Adicionar validação de entrada do usuário

✅ Versão 5W1H:

**What**: adicionar validação de entrada no formulário de cadastro de usuário
**Where**: src/components/RegisterForm.tsx
**Who**: validar os campos usuário, e-mail e senha
**How**: usar a biblioteca Yup já existente no projeto
**When**: disparar quando o usuário clicar no botão de envio
**Why**: impedir que dados inválidos sejam enviados ao backend

Com isso, a IA dificilmente sai do trilho.

O template estruturado recomendado pelo Cursor

O time do Cursor consolidou um template ainda mais prático. Usei por meses e ele realmente ajuda:

## Goal (objetivo)
[Uma frase explicando o que deve ser implementado]

## Context (contexto)
[Arquivo atual, código relacionado, stack técnica]

## Current Behavior (comportamento atual)
[Como está hoje]

## Desired Behavior (comportamento esperado)
[Qual resultado você espera]

## Acceptance Criteria (critérios de aceite)
[Quando a tarefa pode ser considerada concluída]

## Constraints (restrições)
[O que não pode ser modificado e quais regras devem ser seguidas]

A melhor parte do template é a seção Constraints (restrições). Muita gente escreve no prompt só o que quer fazer, mas não escreve o que não quer. Aí a IA improvisa demais.

Caso prático: login em React

Vamos comparar com um cenário real. Imagine que você quer adicionar login de usuário em um projeto React.

❌ Prompt vago, comum para iniciantes:

Me ajude a implementar login de usuário

A IA pode responder com um componente de 200 linhas, adicionar bibliotecas que você não precisa ou até inventar uma API inexistente.

✅ Prompt estruturado, do jeito certo:

## Goal
Implementar login de usuário em um projeto React

## Context
- O projeto usa React 18 + TypeScript
- Gerenciamento de estado: Redux Toolkit
- Serviço de API existente: src/services/authService.ts (contém o método login)
- Biblioteca de UI: Ant Design 5.x

## Current Behavior
A página de login (src/pages/Login.tsx) tem apenas UI estática, sem lógica de interação

## Desired Behavior
1. O usuário digita usuário e senha e clica em "Login"
2. Chama authService.login() para autenticação
3. Sucesso: salva o token no Redux e redireciona para /dashboard
4. Falha: mostra mensagem de erro usando message.error do Ant Design

## Acceptance Criteria
- [ ] Validação de formulário: usuário e senha não podem ficar vazios
- [ ] O processo de login mostra estado de loading
- [ ] O campo de senha usa type="password"
- [ ] Passa nas verificações de ESLint e TypeScript

## Constraints
- **Não modifique** o arquivo authService.ts
- **Não adicione** novas bibliotecas de terceiros
- **Use obrigatoriamente** o Redux slice existente (src/store/authSlice.ts)

Compare o resultado:

Com o primeiro prompt, a IA pode gerar algo assim:

// ❌ Resultado de uma IA improvisando
import { useState } from 'react';
import axios from 'axios'; // você não pediu para adicionar uma biblioteca nova

function Login() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');

  const handleLogin = async () => {
    // Chamada direta para uma API que talvez nem exista
    const res = await axios.post('/api/auth/login', { username, password });
    localStorage.setItem('token', res.data.token); // não usou Redux
  };

  // ... mais 150 linhas que você não precisava
}

Com o segundo prompt, a IA tende a seguir exatamente suas regras:

// ✅ Resultado de um prompt estruturado
import { useState } from 'react';
import { Form, Input, Button, message } from 'antd';
import { useDispatch } from 'react-redux';
import { login } from '@/services/authService';
import { setToken } from '@/store/authSlice';
import { useNavigate } from 'react-router-dom';

export default function Login() {
  const [loading, setLoading] = useState(false);
  const dispatch = useDispatch();
  const navigate = useNavigate();

  const handleSubmit = async (values: { username: string; password: string }) => {
    setLoading(true);
    try {
      const { token } = await login(values.username, values.password);
      dispatch(setToken(token));
      navigate('/dashboard');
    } catch (error) {
      message.error('Falha no login. Verifique o usuário e a senha.');
    } finally {
      setLoading(false);
    }
  };

  return (
    <Form onFinish={handleSubmit}>
      <Form.Item name="username" rules={[{ required: true, message: 'Informe o usuário' }]}>
        <Input placeholder="Usuário" />
      </Form.Item>
      <Form.Item name="password" rules={[{ required: true, message: 'Informe a senha' }]}>
        <Input.Password placeholder="Senha" />
      </Form.Item>
      <Button type="primary" htmlType="submit" loading={loading}>
        Login
      </Button>
    </Form>
  );
}

Viu a diferença? O segundo código:

  • Usa os componentes do Ant Design que você especificou
  • Chama o authService existente
  • Usa Redux para armazenar o token
  • Tem validação de formulário e estado de loading
  • Não adiciona nenhuma dependência nova

Essa é a força de um prompt estruturado.

5 técnicas de prompt que funcionam de imediato

Técnica 1: planeje antes de codar (Plan Mode)

Esse foi o recurso que mais me surpreendeu.

Antes, eu pedia para a IA sair escrevendo código direto e o resultado muitas vezes dava ruim: ela mexia em arquivos errados, apagava código importante ou bagunçava a lógica. Depois descobri que o Cursor tem um modo Plan (alternado com Shift+Tab), e isso mudou meu fluxo de trabalho.

A lógica do Plan Mode é: a IA pensa antes de agir.

Fluxo prático:

  1. Você descreve a necessidade
  2. A IA analisa sua codebase e faz perguntas, como “você quer manter o tratamento de erro atual?”
  3. A IA monta um plano de ação, dizendo quais arquivos serão alterados e quais recursos serão adicionados
  4. Você revisa e ajusta o plano
  5. Só depois da confirmação a IA começa a escrever código

Por que isso é útil? Porque dá a você uma chance de se arrepender.

Exemplo: na semana passada, pedi para a IA adicionar internacionalização a um projeto. No Plan Mode, ela primeiro listou:

Plano:
1. Instalar i18next e react-i18next
2. Criar o diretório src/i18n/locales/
3. Modificar App.tsx para adicionar I18nProvider
4. Atualizar todos os textos hardcoded dos componentes (cerca de 30 arquivos)

Quando vi o passo 4, parei na hora: “Espera, não mexa nesses 30 arquivos; primeiro vamos testar em 3 páginas.” Ajustei o plano, e só então a IA executou.

Sem Plan Mode, a IA provavelmente já teria alterado 30 arquivos. Depois, reverter seria bem mais chato.

Valor prático: evita que a IA mexa direto e bagunce o código, especialmente em refatorações grandes e funcionalidades novas.

Técnica 2: forneça exemplos concretos de código

A IA tem uma característica: ela é muito boa em “seguir o modelo”. Se você mostra alguns exemplos, ela imita seu estilo. Em termos técnicos, isso é Few-shot Prompting.

Cenário: você quer que a IA escreva uma API, mas seu projeto tem um estilo próprio de código e tratamento de erro.

❌ Prompt sem exemplo:

Me ajude a escrever uma API para listar usuários

A IA pode gerar algo assim:

app.get('/users', (req, res) => {
  // estilo totalmente diferente do seu
  const users = db.getUsers();
  res.json(users);
});

✅ Prompt com exemplo:

Me ajude a escrever uma API para listar usuários, seguindo o estilo do endpoint existente abaixo:

**Exemplo 1**:
\`\`\`typescript
export const getProductById = async (req: Request, res: Response) => {
  try {
    const { id } = req.params;
    const product = await productService.findById(id);

    if (!product) {
      return res.status(404).json({
        success: false,
        error: 'Product not found'
      });
    }

    res.json({ success: true, data: product });
  } catch (error) {
    logger.error('Error fetching product:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};
\`\`\`

Implemente getUserList seguindo esse estilo:
- Use async/await
- Use tratamento de erro unificado
- Retorne no formato: { success, data/error }
- Use logger para registrar erros

A IA tende a gerar:

export const getUserList = async (req: Request, res: Response) => {
  try {
    const users = await userService.findAll();
    res.json({ success: true, data: users });
  } catch (error) {
    logger.error('Error fetching users:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};

Combina muito melhor com seu estilo de código.

Dica pequena: crie um arquivo prompts/templates.md na raiz do projeto e guarde ali os exemplos de código mais usados. Quando precisar, copie direto para o prompt.

Técnica 3: deixe claro o que não fazer

Essa técnica já me salvou muitas vezes.

Por padrão, a IA tenta “ajudar” ao máximo, mas às vezes essa ajuda não é o que você precisa. Se você pede para corrigir um bug, ela pode aproveitar e “otimizar” o código ao redor, criando um problema novo.

Segundo o time do Cursor, restrições explícitas podem reduzir 60% das mudanças inesperadas.

Caso prático:

❌ Prompt sem restrição:

Corrija o bug de paginação do componente UserList

A IA pode:

  • Modificar a interface de props do componente, quebrando o componente pai
  • Reescrever toda a lógica de paginação e introduzir outro bug
  • Adicionar uma biblioteca de terceiros desnecessária

✅ Prompt com restrições:

Corrija o bug de paginação do componente UserList

**Restrições**:
- **Não modifique** a interface de props do componente (tipos TypeScript)
- **Não adicione** novas bibliotecas de terceiros
- **Modifique apenas** a lógica interna da função handlePageChange
- **Não altere** estilos nem estrutura de UI

A IA tende a respeitar essas regras e mexer só no necessário.

Há ainda uma técnica avançada: peça para a IA listar suas hipóteses antes de começar.

Corrija o bug de paginação. Antes de começar, liste suas hipóteses:
1. Qual você acha que é a causa do bug?
2. Quais trechos de código pretende modificar?
3. Você pretende adicionar dependências ou mudar alguma interface?

A IA responde primeiro. Você confere se ela entendeu certo e só então deixa agir. Isso funciona muito bem em correções de bug mais complexas.

Técnica 4: use critérios de aceite como âncora

Essa técnica vem emprestada do desenvolvimento ágil.

Defina os critérios de aceite no começo do prompt, não no fim. A IA passa a raciocinar em torno deles, como se você tivesse definido “as metas obrigatórias”.

Compare:

❌ Sem critérios de aceite:

Refatore o desempenho do componente DataTable

IA: refatorar para quê? Com qual método? Como medir? Ela só consegue chutar.

✅ Com critérios de aceite:

Refatore o desempenho do componente DataTable

**Critérios de aceite** (todos obrigatórios):
- [ ] Ao renderizar 1000 linhas, o FPS não pode ficar abaixo de 55
- [ ] Use React.memo e useMemo
- [ ] Não modifique a API do componente (props e callbacks)
- [ ] Todos os testes unitários existentes devem passar
- [ ] O código deve passar no ESLint

**Problema atual**:
Ao renderizar 500 linhas, o FPS cai para 20 e a rolagem trava

A IA passa a usar esses critérios como “estrela-guia” e orienta cada mudança nessa direção. Se uma otimização quebrar testes ou alterar a API, ela tende a evitar.

Benefício: impede que a IA faça mudanças que parecem úteis, mas não resolvem o problema real.

Técnica 5: diferencie Inline Edit e Agent Mode

Muita gente não sabe que o Cursor tem dois modos de trabalho. Escolher o certo pode dobrar a eficiência.

Inline Edit (Cmd+K):

  • Indicado para: mudanças pequenas em um único arquivo, refatoração e correção de bug
  • Características: rápido, preciso e sem alterações soltas em outros arquivos
  • Exemplos: renomear uma função, adicionar um parâmetro, corrigir um bug

Agent Mode (Cmd+I ou Chat):

  • Indicado para: raciocínio entre vários arquivos, funcionalidades novas e mudanças de arquitetura
  • Características: consegue analisar a codebase inteira, operar entre arquivos e montar planos
  • Exemplos: adicionar nova funcionalidade, refatoração grande, migração de stack

Antes eu usava Agent Mode para tudo, e isso deixava o fluxo lento. Depois percebi: tarefas simples vão para Inline Edit; tarefas complexas vão para Agent Mode.

Árvore de decisão:

Precisa modificar vários arquivos?
├─ Sim → Agent Mode
└─ Não → precisa entender contexto complexo?
    ├─ Sim → Agent Mode
    └─ Não → Inline Edit

Exemplos:

Cenário 1: renomear a função getUserData para fetchUserData
→ Use Inline Edit: selecione o nome da função, pressione Cmd+K e digite “renomear para fetchUserData”. Pronto.

Cenário 2: adicionar controle de permissões de usuário, envolvendo Model, Controller, View e Config
→ Use Agent Mode: ele analisa a estrutura do projeto, faz perguntas, monta um plano e implementa entre arquivos.

Consequências de escolher errado:

  • Usar Inline Edit em tarefa complexa → ele não enxerga o todo e pode perder mudanças relacionadas
  • Usar Agent Mode em tarefa simples → demora mais e ainda pode improvisar demais

Dica pequena: se não tiver certeza, use primeiro o recurso Plan do Agent Mode e veja quantos arquivos ele pretende alterar. Se forem apenas 1 ou 2, volte para Inline Edit.

Técnica avançada: monte sua caixa de ferramentas de prompts

Crie templates de prompt reutilizáveis

Depois de escrever prompts por um tempo, você percebe que muitas tarefas se repetem: criar endpoint de API, adicionar componente, escrever teste unitário, migrar banco de dados.

Em vez de começar do zero toda vez, transforme seus prompts frequentes em templates.

Hoje, meus projetos costumam ter uma pasta prompts/ na raiz, organizada por tipo de tarefa:

prompts/
├── api-endpoint.md       # Template para novo endpoint de API
├── react-component.md    # Template para componente React
├── unit-test.md          # Template para teste unitário
├── migration.md          # Template para migração de banco de dados
└── refactor.md           # Template para refatoração

Exemplo: template de endpoint de API (prompts/api-endpoint.md)

# Template de novo endpoint de API

## Goal
Adicionar um endpoint de API para [descrição da funcionalidade] em [nome do módulo]

## Context
- Arquivo de rotas: src/routes/[módulo].routes.ts
- Controller: src/controllers/[módulo].controller.ts
- Camada de serviço: src/services/[módulo].service.ts
- Modelo de dados: src/models/[módulo].model.ts

## Desired Behavior
**Requisição**:
- Method: [GET/POST/PUT/DELETE]
- Path: /api/[caminho]
- Body/Query: [descrição dos parâmetros]

**Resposta**:
- Sucesso: { success: true, data: [...] }
- Falha: { success: false, error: "..." }

## Acceptance Criteria
- [ ] Seguir o padrão atual de tratamento de erro (referência em outros endpoints)
- [ ] Usar async/await
- [ ] Adicionar validação de entrada (usando Joi ou Zod)
- [ ] Registrar logs de erro (usando logger)
- [ ] Passar na checagem de tipos do TypeScript

## Constraints
- **Não modifique** a estrutura atual de configuração de rotas
- **Não adicione** novas bibliotecas de terceiros, a menos que seja necessário e justificado
- **Use obrigatoriamente** a conexão de banco de dados existente; não crie uma nova conexão

Quando precisar, copie o template e preencha as lacunas.

Benefício para times: quando a equipe compartilha esses templates, o código sai com estilo mais consistente e pessoas novas pegam o ritmo mais rápido.

Use Agent Skills, recurso novo de 2026

Essa é uma grande tendência das ferramentas de programação com IA em 2026.

Em termos simples, Agent Skills são “aplicações de IA” reutilizáveis. Você pode empacotar uma prática boa em uma Skill e chamá-la quando precisar, como se chamasse uma função.

Exemplo:

Quando eu escrevia artigos para o blog, precisava escolher imagens manualmente toda vez. Depois criei uma Agent Skill que faz isso por mim:

  1. Analisa o conteúdo do artigo
  2. Identifica seções que precisam de imagem
  3. Gera prompts de imagem
  4. Marca os pontos de inserção

Agora eu só executo essa Skill, e ela cuida do fluxo inteiro.

Como criar Agent Skills?

No Cursor, você pode criar Skills personalizadas dentro da pasta .cursor/:

.cursor/
└── skills/
    ├── code-review.md      # Skill de revisão de código
    ├── test-generator.md   # Skill de geração de testes
    └── api-doc.md          # Skill de geração de documentação de API

Atualização recente: em dezembro de 2025, Agent Skills se tornou uma especificação aberta, com suporte em ferramentas como Claude Code, Cursor, VS Code e GitHub Copilot. Isso significa que uma Skill que você escreve pode ser usada entre ferramentas.

Para ser sincero, no começo eu achava Skills um pouco “engenharia demais”. Até usar Skills compartilhadas por um time num projeto colaborativo: a qualidade do código e a eficiência subiram imediatamente.

Otimize a estrutura do projeto para ajudar a IA a entender

A IA não é uma pessoa; ela entende uma codebase de um jeito diferente do nosso. Um projeto com estrutura clara melhora muito o desempenho dela.

Sugestões práticas:

  1. Crie uma pasta /prompts
    Guarde templates de prompt e exemplos de código para copiar e colar com facilidade.

  2. Use a pasta .cursor/ para armazenar contexto do projeto
    Crie um arquivo .cursor/context.md explicando:

    • Stack do projeto
    • Regras de estilo de código
    • Bibliotecas de terceiros usadas com frequência
    • Convenções especiais, como “usamos _ no começo de métodos privados”

    A IA lê esse arquivo automaticamente e entende melhor as características do projeto.

  3. Use estrutura de diretórios e nomes claros
    A IA deduz o uso do código a partir dos nomes de arquivos e pastas. Se seus arquivos se chamam utils.ts, helpers.ts e common.ts, ela fica perdida: o que exatamente existe ali?

    Melhor algo assim:

    utils/
    ├── date-formatter.ts
    ├── string-validator.ts
    └── array-helpers.ts

Tenho uma regra de bolso: quanto mais confusa a estrutura do projeto, mais a IA alucina. Organizar diretórios ajuda humanos e também ajuda a IA a entender você.

Guia antiarmadilhas: erros comuns e soluções

Erro 1: sobrecarga de informação, tudo de uma vez

Quando comecei a usar IA para programar, cometi esse erro: colava o documento inteiro de requisitos, três arquivos relacionados e cinco artigos de referência para a IA, pensando “quanto mais informação, melhor”.

Resultado? A IA se afogava.

Ela ou não pegava o ponto principal, ou entendia errado, ou simplesmente estourava tempo. É como explicar dez assuntos ao mesmo tempo para uma pessoa; no fim, ela lembra menos.

O jeito certo: divulgação progressiva

Não despeje tudo na IA logo no começo. Faça assim:

  1. Explique primeiro a necessidade central
  2. Se a IA tiver dúvidas, forneça detalhes
  3. Entregue o contexto em etapas

Exemplo:

❌ Versão com informação demais:

Me ajude a refatorar o módulo de autenticação de usuários.
[cola 500 linhas de código]
[cola documento de requisitos]
[cola três artigos técnicos]
Requisitos: melhorar desempenho, reforçar segurança, deixar o código elegante...

✅ Versão progressiva:

Primeira rodada:
Quero refatorar o módulo de autenticação de usuários, com o objetivo de melhorar a segurança.
Hoje usamos JWT, e o problema é que o token não tem mecanismo de refresh.
Que informação você precisa?

[A IA pergunta: qual é o tempo de expiração do token hoje? Onde ele é armazenado?]

Segunda rodada:
O token expira em 1 hora e fica armazenado em localStorage.
Aqui está a lógica atual de autenticação (código principal):
[cola apenas as 50 linhas essenciais]

Como você pretende melhorar isso?

[A IA propõe uma solução, você confirma e só depois deixa ela agir]

Assim, a IA foca no problema central e você consegue corrigir a compreensão dela a qualquer momento.

Erro 2: depender demais da IA e não revisar código

Esse foi o erro que mais me custou.

Uma vez, a IA escreveu uma função de processamento de dados. Rodava sem erro, os testes unitários passavam, e o código parecia limpo. Eu olhei, achei bom e fiz merge. Depois do deploy, descobrimos que a função retornava resultado errado em casos de borda e bagunçava dados de usuários.

Código gerado por IA, especialmente o que “parece completamente correto”, é o mais perigoso.

Aviso: quanto mais rápido a IA gera, mais atenção você precisa ter na revisão.

Hoje eu criei o hábito de fazer três perguntas depois que a IA escreve código:

  1. Casos de borda: array vazio, null, undefined, valores muito altos e muito baixos foram tratados?
  2. Efeitos colaterais: este trecho pode afetar outros módulos?
  3. Desempenho: há loop infinito, vazamento de memória ou cálculo repetido desnecessário?

Técnica prática: peça para a IA revisar o próprio código.

Revise o código que você acabou de gerar e responda:
1. O que acontece se a entrada for um array vazio?
2. Este trecho tem problema de desempenho?
3. Quais hipóteses você usou? Elas valem em todos os casos?

A IA reexamina o código e muitas vezes encontra os próprios problemas.

Erro 3: esperar uma resposta perfeita de primeira

Muita gente trata a IA como um “botão mágico”: escreve a necessidade e espera receber código perfeito na hora. Isso não é realista.

A IA funciona melhor como colaboradora, não como “gerador de código totalmente automático”. O fluxo mais eficiente é uma conversa iterativa:

  1. Você descreve a necessidade
  2. A IA oferece uma proposta inicial ou faz perguntas
  3. Você confirma, corrige e complementa
  4. A IA melhora com base no feedback
  5. Repita 3-4 vezes, até ficar satisfeito

Exemplo correto:

Você: me ajude a implementar busca na lista de usuários

IA: claro. Pretendo adicionar um campo de busca e filtrar a lista de usuários em tempo real.
    Quais campos você quer pesquisar: nome de usuário, e-mail ou outros?

Você: pesquisar nome de usuário e e-mail, mas não precisa filtrar em tempo real.
    A busca deve disparar só depois de clicar no botão "Pesquisar".

IA: entendido. A filtragem será no frontend ou por requisição ao backend?

Você: no frontend, porque o volume de dados não é grande.

IA: certo. Vou usar Array.filter().
    Primeiro mostro o plano de implementação...

Percebe? Isso é conversa, não comando seco.

Dica: use o modo “Show Work” do Cursor, ativado nas configurações. A IA mostra seus passos de raciocínio, e você consegue ver como ela está pensando, o que torna mais fácil encontrar problemas.

Extra: não desperdice tempo “lapidando” prompts

Para fechar, uma recomendação contraintuitiva: não busque o prompt perfeito a qualquer custo.

Já vi gente passar 30 minutos desenhando um prompt, e o código gerado ainda era pior do que escrever à mão. A prioridade ficou invertida.

O objetivo da engenharia de prompts é aumentar eficiência, não exibir um prompt bonito. Se você consegue terminar uma tarefa sozinho em 10 minutos, não gaste 20 minutos escrevendo prompt.

Quando vale usar IA?

  • ✅ Tarefas repetitivas, como alterações em lote e geração de templates
  • ✅ Áreas pouco familiares, como nova stack ou nova biblioteca
  • ✅ Tarefas complexas, mas com padrão claro, como endpoints de API e operações CRUD

Quando não vale?

  • ❌ Código tão simples que você escreveria de olhos fechados
  • ❌ Design de algoritmo que exige raciocínio profundo
  • ❌ Código altamente personalizado e sem padrão de referência

Lembre: IA é ferramenta, não objetivo. O que importa é resolver o problema rápido.

Conclusão

Escrever um bom prompt não é uma técnica misteriosa. O núcleo é simples: explicar bem o objetivo, fornecer contexto suficiente e definir limites claros.

Relembrando as 5 técnicas principais deste artigo:

  1. Use Plan Mode para planejar primeiro: dê a si mesmo uma chance de se arrepender antes da execução
  2. Forneça exemplos de código: faça a IA seguir seu estilo
  3. Defina restrições explícitas: diga o que a IA não pode mexer
  4. Estabeleça critérios de aceite: dê à IA um objetivo claro
  5. Escolha o modo certo: tarefa simples no Inline Edit, tarefa complexa no Agent Mode

Depois de dominar isso, a IA deixa de parecer uma assistente desajeitada e passa a ser uma parceira real de programação. No meu caso, a precisão do código gerado por IA melhorou pelo menos 50%, e muitas tarefas repetitivas agora ficam prontas em 10 minutos.

Abra o Cursor e teste um template estruturado na próxima funcionalidade. Comece no formato “Goal - Context - Desired Behavior - Constraints”. A diferença aparece rápido.

O futuro da programação com IA não é “IA substituindo programadores”; é “programadores que sabem usar IA substituindo os que não sabem”. Essa diferença começa no seu primeiro prompt de alta qualidade.

Como usar prompts estruturados para melhorar a qualidade do código gerado por IA

Domine o fluxo prático de engenharia de prompts no Cursor, saindo de instruções vagas para resultados precisos.

⏱️ Estimated time: 30 min

  1. 1

    Step 1: Entenda como a IA trabalha: evite os desastres comuns de prompt

    A IA só consegue raciocinar com base nas informações que você fornece; ela não lê pensamentos. Há três desastres comuns:

    **Vago demais**:
    ❌ "Me ajude a implementar ordenação"
    ✅ "Adicione uma função no arquivo utils/array.ts para ordenar a lista de usuários por data de cadastro em ordem decrescente, usando Array.sort() nativo e sem adicionar novas dependências"

    **Falta de contexto**:
    ❌ "Adicione tratamento de erro"
    ✅ "Adicione tratamento de erro na função handleLogin de api/login.ts: capture falhas de requisição de rede com try-catch, retorne o formato unificado &#123; success: false, error: string &#125; e use como referência o tratamento de api/register.ts"

    **Sem restrições**:
    ❌ "Otimize o desempenho deste componente"
    ✅ "Otimize o desempenho do componente UserList.tsx: use apenas React.memo ou useMemo, não altere a interface de props e não adicione novas bibliotecas de terceiros"

    Ponto principal: contexto claro pode reduzir 70% das alucinações da IA, e restrições explícitas podem reduzir 60% das mudanças inesperadas.
  2. 2

    Step 2: Use a fórmula de ouro do prompt estruturado

    Use o template de 6 partes recomendado pelo Cursor:

    ## Goal (objetivo)
    Uma frase explicando o que deve ser implementado

    ## Context (contexto)
    • Stack do projeto (React 18 + TypeScript)
    • Caminhos de arquivos relevantes (src/pages/Login.tsx)
    • Serviço existente (src/services/authService.ts)
    • Biblioteca usada (Ant Design 5.x)

    ## Current Behavior (comportamento atual)
    A tela de login tem apenas UI estática, sem lógica de interação

    ## Desired Behavior (comportamento esperado)
    1. O usuário digita usuário e senha e clica em login
    2. Chama authService.login() para validar
    3. Sucesso: salva o token no Redux e redireciona para /dashboard
    4. Falha: mostra mensagem de erro (Ant Design message.error)

    ## Acceptance Criteria (critérios de aceite)
    • Validação de formulário: usuário e senha não podem ficar vazios
    • O processo de login mostra estado de loading
    • O campo de senha usa type=&quot;password&quot;
    • Passa nas verificações de ESLint e TypeScript

    ## Constraints (restrições)
    • Não modificar o arquivo authService.ts
    • Não adicionar novas bibliotecas de terceiros
    • Usar obrigatoriamente o Redux slice existente (src/store/authSlice.ts)

    Esse template impede que a IA precise adivinhar e faz o código gerado seguir as regras do seu projeto.
  3. 3

    Step 3: Domine 5 técnicas práticas que funcionam de imediato

    **Técnica 1: planeje antes de codar (Plan Mode)**
    • Pressione Shift+Tab para alternar para o modo Plan
    • A IA analisa a codebase e faz perguntas primeiro
    • Ela monta um plano de ação, incluindo quais arquivos serão alterados
    • Você revisa e ajusta o plano antes da execução
    • Isso evita que a IA mexa direto e bagunce o código

    **Técnica 2: forneça exemplos concretos de código (Few-shot Prompting)**
    • Cole exemplos existentes de código no prompt
    • A IA imita seu estilo de código e seus hábitos de tratamento de erro
    • Vale criar prompts/templates.md para guardar exemplos frequentes

    **Técnica 3: deixe claro o que não fazer**
    • Liste proibições na seção Constraints
    • Reduza 60% das mudanças inesperadas
    • Técnica avançada: peça para a IA listar hipóteses antes de agir (causa do bug, escopo da mudança, alterações de dependência)

    **Técnica 4: use critérios de aceite como âncora**
    • Defina os critérios de aceite no começo do prompt
    • A IA usa isso como uma "estrela-guia" para raciocinar
    • Evita mudanças que parecem úteis, mas não resolvem o problema

    **Técnica 5: diferencie Inline Edit de Agent Mode**
    • Inline Edit (Cmd+K): mudança pequena em um único arquivo, rápida e precisa
    • Agent Mode (Cmd+I): raciocínio entre vários arquivos, desenvolvimento de funcionalidade nova e mudanças de arquitetura
    • Árvore de decisão: precisa modificar vários arquivos? Se sim, use Agent; se não, use Inline
  4. 4

    Step 4: Monte uma caixa de ferramentas reutilizável de prompts

    **Crie uma biblioteca de templates de prompt**:
    Na raiz do projeto, crie uma pasta prompts/ e organize por categoria:
    • api-endpoint.md (template de endpoint de API)
    • react-component.md (template de componente React)
    • unit-test.md (template de teste unitário)
    • migration.md (template de migração de banco de dados)
    • refactor.md (template de refatoração)

    Cada template deve conter Goal, Context, Desired Behavior, Acceptance Criteria e Constraints. Na hora de usar, basta copiar e preencher.

    **Use Agent Skills (recurso novo de 2026)**:
    Na pasta .cursor/skills/, crie aplicações de IA reutilizáveis:
    • code-review.md (Skill de revisão de código)
    • test-generator.md (Skill de geração de testes)
    • api-doc.md (Skill de geração de documentação de API)

    Em dezembro de 2025, Agent Skills virou uma especificação aberta e pode ser usado entre Cursor, VS Code, GitHub Copilot e outras ferramentas.

    **Otimize a estrutura do projeto para ajudar a IA a entender**:
    • Crie um arquivo .cursor/context.md com stack, estilo de código e convenções especiais do projeto
    • Use uma estrutura de pastas e nomes claros, como date-formatter.ts em vez de utils.ts
    • Quanto mais confusa a estrutura do projeto, mais alucinações a IA tende a produzir
  5. 5

    Step 5: Evite os três erros mais comuns

    **Erro 1: sobrecarga de informação**
    ❌ Colar 500 linhas de código + documento de requisitos + artigos técnicos de uma vez
    ✅ Divulgação progressiva: explique a necessidade central → deixe a IA perguntar → forneça detalhes → entregue contexto em etapas

    **Erro 2: depender demais da IA sem revisar o código**
    Depois que a IA escrever o código, faça três perguntas:
    • Casos de borda (array vazio, null, undefined, valores extremos) foram tratados?
    • Este trecho afeta outros módulos?
    • Há loop infinito, vazamento de memória ou cálculo repetido desnecessário?

    Técnica prática: peça para a própria IA revisar o código e responder "o que acontece se a entrada for um array vazio", "há problema de desempenho?" e "quais hipóteses foram usadas".

    **Erro 3: esperar uma resposta perfeita de primeira**
    A IA é uma colaboradora, não um botão mágico. O jeito certo é iterar a conversa:
    1. Você descreve a necessidade
    2. A IA dá uma proposta inicial ou faz perguntas
    3. Você confirma, corrige e complementa
    4. A IA melhora com base no feedback
    5. Repita 3-4 vezes até ficar bom

    Ative o modo "Show Work" do Cursor para ver os passos de raciocínio da IA e detectar problemas com mais facilidade.

FAQ

Por que meu prompt é detalhado, mas a IA ainda gera código errado?
Verifique se não faltou contexto essencial:

• Você deixou claro o caminho do arquivo que será alterado? (A IA não sabe onde agir.)
• Você forneceu exemplos do código existente? (A IA não conhece seu estilo.)
• Você explicou as restrições? (A IA pode improvisar demais.)

Um jeito prático: responda três perguntas dentro do prompt. A IA sabe em qual arquivo deve operar? A IA conhece a estrutura do código existente? A IA sabe o que pode e o que não pode alterar? Se a resposta for não, complemente as informações antes de enviar o prompt.

Além disso, use Plan Mode para a IA montar um plano primeiro; você revisa e só então deixa executar. Isso evita muitos problemas.
Quando usar Inline Edit e quando usar Agent Mode?
Árvore de decisão:

**Precisa modificar vários arquivos?**
• Sim → use Agent Mode (Cmd+I ou Chat)
• Não → precisa entender um contexto complexo?
- Sim → Agent Mode
- Não → Inline Edit (Cmd+K)

Cenários concretos:
• Inline Edit: renomear função, adicionar parâmetro, corrigir um bug isolado, refatorar uma função única
• Agent Mode: adicionar nova funcionalidade envolvendo Model/Controller/View, refatoração grande, migração de stack ou tarefa que exige analisar a codebase inteira

Dica: se estiver em dúvida, comece pelo recurso de Plan do Agent Mode para ver quantos arquivos ele pretende alterar. Se forem só 1 ou 2, voltar para Inline Edit costuma ser mais rápido.
Como fazer o código gerado pela IA seguir o estilo do meu projeto?
Há três métodos:

**Método 1: forneça exemplos concretos de código (o mais eficaz)**
Cole no prompt exemplos existentes do seu projeto. A IA tende a imitar estilo, tratamento de erro e convenções de nomenclatura. Isso se chama Few-shot Prompting.

**Método 2: crie um arquivo de contexto do projeto**
Em .cursor/context.md, registre:
• Stack do projeto
• Regras de estilo de código, como "usamos _ no começo de métodos privados"
• Bibliotecas de terceiros frequentes
• Convenções especiais

A IA lê esse arquivo automaticamente.

**Método 3: crie templates reutilizáveis de prompt**
Na raiz do projeto, crie uma pasta prompts/ com templates comuns para endpoints de API, componentes React, testes unitários e outras tarefas. Quando o time compartilha esses templates, o estilo do código fica naturalmente mais consistente.
O código gerado pela IA parece certo, mas dá bug em runtime. O que fazer?
Esse é o caso mais perigoso: código que parece completamente correto. A saída é:

**Sempre revise o código gerado pela IA** e faça três perguntas:
1. Casos de borda foram tratados? (array vazio, null, undefined, valores muito altos ou muito baixos)
2. Este trecho afeta outros módulos? (checagem de efeitos colaterais)
3. Há problema de desempenho? (loop infinito, vazamento de memória, cálculo repetido desnecessário)

**Técnica prática**: peça para a IA revisar o próprio código:
"Revise o código que você acabou de gerar e responda: 1) o que acontece se a entrada for um array vazio? 2) este trecho tem problema de desempenho? 3) quais hipóteses você usou? Elas valem em todos os casos?"

A IA reexamina a solução e muitas vezes encontra os próprios problemas. Também vale ativar o modo "Show Work" do Cursor para enxergar o raciocínio e descobrir riscos escondidos.
Quando vale a pena usar IA para escrever código e quando não vale?
Vale usar IA em:
• Tarefas repetitivas, como alterações em lote, geração de código boilerplate e refatoração de lógica repetida
• Áreas pouco familiares, como uma stack nova, uma biblioteca nova ou APIs menos comuns
• Tarefas complexas, mas com padrão claro, como endpoints de API, operações CRUD, validação de formulário e transformação de dados

Não vale usar IA em:
• Código tão simples que você escreveria de olhos fechados, como renomear uma variável ou adicionar um comentário
• Design de algoritmo que exige raciocínio profundo, como lógica central de negócio ou otimização complexa
• Código altamente personalizado e sem padrão de referência, como uma funcionalidade muito específica ou inovadora

Critério prático: se você consegue escrever sozinho em 10 minutos, não gaste 20 minutos montando prompt. O objetivo da engenharia de prompts é ganhar eficiência, não provar que seu prompt é bonito. IA é ferramenta, não objetivo; resolver rápido é o que importa.
Como usar o Plan Mode na prática? Em quais cenários ele funciona melhor?
**Como usar o Plan Mode**:
1. Pressione Shift+Tab para alternar para o modo Plan
2. Descreva sua necessidade
3. A IA analisa a codebase e faz perguntas, como "você quer manter o tratamento de erro atual?"
4. A IA monta um plano de ação, listando quais arquivos serão modificados e quais recursos serão adicionados
5. Você revisa e ajusta o plano
6. Só depois da confirmação a IA começa a escrever código

**Cenários em que funciona melhor**:
• Refatorações grandes, para evitar que a IA mexa no arquivo errado ou apague código importante
• Desenvolvimento de funcionalidades novas, especialmente quando envolve vários arquivos
• Quando você não tem certeza de que a IA entendeu a tarefa, usando o plano para validar a compreensão
• Tarefas complexas, como adicionar internacionalização ou migrar banco de dados

O valor central do Plan Mode é dar a você uma chance de se arrepender antes da execução. Ele evita que a IA saia mexendo direto e bagunce o código, especialmente em mudanças grandes e difíceis de reverter.
Como evitar que a IA adicione bibliotecas de terceiros desnecessárias?
Deixe a restrição explícita na seção Constraints do prompt:

**Proíba novas bibliotecas de forma clara**:
"**Não adicione** novas bibliotecas de terceiros"
"**Não instale** nenhum pacote npm"
"**Use apenas** as dependências que já existem no projeto, listadas em package.json"

**Especifique as bibliotecas obrigatórias**:
"**Use obrigatoriamente** os componentes atuais do Ant Design, já instalado na versão 5.x"
"**Use obrigatoriamente** o authService do projeto (src/services/authService.ts)"

**Forneça exemplos das bibliotecas existentes**:
Na seção Context, liste as dependências já usadas pelo projeto e como elas são aplicadas. A IA tende a priorizar isso em vez de inventar uma alternativa.

**Use Plan Mode**:
Quando a IA monta o plano antes de executar, você consegue ver se ela pretende adicionar alguma biblioteca e bloquear a dependência a tempo.

Lembre: quanto mais explícitas forem as restrições, menos a IA improvisa.

23 min de leitura · Publicado em: 29 jan 2026 · Atualizado em: 14 jul 2026

Comentários

Entre com GitHub para comentar

Easton BlogEaston Blog