Pular para o conteúdo
~/.primo-academy.sh
☰ Aulas · Engenharia assistida por IA: Claude Code, Cursor, Copilot, audit, testes e refactor · 0/8
Recomendado: essencial

Dividir tarefas pra IA: quando cabe num prompt, quando precisa de plano

6 min de leitura

fonte

Você pede "faz um app de e-commerce completinho" pra IA. Ela entrega código genérico que parece funcionar mas não é o que você queria. Esse nó cobre como dividir tarefas pra IA: quando um prompt direto resolve, quando precisa de plano multi-step, e como decompor problemas complexos em sub-tarefas que IA resolve melhor.

O segredo de usar IA em código: tarefa bem definida = resultado bom. Tarefa vaga = alucinação. Decomposição é a skill #1. Não é sobre o modelo ser "bom o suficiente" - é sobre você quebrar o problema em pedaços que a IA consegue resolver.

Você sai de "IA entrega código errado" pra "IA entrega código certo porque eu decomposei o problema direito".

O essencial 🟢

A máquina de decisão: prompt direto vs plano multi-step.

Decision tree: prompt direto vs plano multi-step. Regra prática: (1) tarefa pequena + bem definida = prompt direto, (2) tarefa exploratória = chat primeiro, depois código, (3) multi-arquivo = decompor em sub-tarefas. Decomp 5+ arquivos = plano explícito com etapas, testes por etapa, e review no fim.

Os 3 níveis de tarefa pra IA.

  1. Nível 1 - Boilerplate/canned. "Escreve uma função que valida email", "Cria um componente Button com 3 variants". IA resolve em 1 prompt. Resultado bom, 80% do tempo.

  2. Nível 2 - Refactor/contexto local. "Refatora essa função pra usar async/await", "Extrai essa lógica pra um custom hook". IA resolve com contexto (1-3 arquivos). Resultado bom se contexto for claro.

  3. Nível 3 - Feature nova/arquitetura. "Adiciona autenticação OAuth", "Migra de Redux pra Zustand". IA precisa de plano - divide em sub-tarefas, cada uma com contexto próprio. Resultado bom se decomposto; ruim se pedir tudo de uma vez.

Como decompor Nível 3. Exemplo: migrar de Redux pra Zustand.

Nível 3: "Migra app de Redux pra Zustand"
  ↓
Sub-tarefa 1: "Lista todos os slices Redux
  e mapeia quais vão virar stores Zustand"
  ↓
Sub-tarefa 2: "Cria store Zustand pra
  userSlice (com testes)"
  ↓
Sub-tarefa 3: "Migra componente A (1 por
  vez, testa cada)"
  ↓
Sub-tarefa 4: "Migra componente B"
  ↓
... 30+ componentes, 1 por vez
  ↓
Sub-tarefa N: "Remove Redux, valida build"

Cada sub-tarefa = 1 prompt com contexto claro + teste verificando. Não pedir tudo numa vez.

O framework de prompt: 4 elementos.

  1. Tarefa: o que fazer.
  2. Contexto: arquivos relacionados, padrões do projeto.
  3. Constraints: limitações (performance, estilo, libs permitidas).
  4. Verificação: como saber se deu certo (teste, type check, visual).

Exemplo - Nível 1 bem feito.

Tarefa: "Cria função que valida CPF brasileiro"
Contexto: "TypeScript, ESM, sem dependências"
Constraints: "Pure function, não usar regex
  exótica, suportar CPF com/sem pontuação"
Verificação: "Deve aceitar 123.456.789-09 e
  12345678909, rejeitar 111.111.111-11"

Exemplo - Nível 2 bem feito.

Tarefa: "Refatora UserProfile pra custom hook
  useUserProfile"
Contexto:
  - src/components/UserProfile.tsx
  - src/api/user.ts (fetch já existe)
Constraints:
  - Manter compat com testes existentes
  - Não mudar a API pública do componente
Verificação: "yarn test UserProfile passa,
  yarn typecheck passa"

Exemplo - Nível 3 decomposto.

Tarefa pai: "Adiciona autenticação OAuth com
  Google"

Etapa 1: "Pesquisa e documenta o flow OAuth
  Google num arquivo docs/oauth-flow.md"
  ↓ (revisa: o flow tá certo?)
Etapa 2: "Cria estrutura /auth/google/ com
  tipos e interfaces (sem implementação)"
  ↓ (revisa: tipos cobrem o flow?)
Etapa 3: "Implementa /auth/google/callback
  route handler"
  ↓ (revisa: callback funciona local?)
Etapa 4: "Implementa /auth/google/login
  redirect"
  ↓ (revisa: redirect gera URL correta?)
Etapa 5: "Adiciona testes E2E com Playwright"
  ↓ (revisa: E2E passa?)
Etapa 6: "Adiciona ao UI (botão 'Login com
  Google')"
  ↓ (revisa: UX tá boa?)

Cada etapa = 1 prompt + review + commit. Etapa separa evita "IA fez tudo mas tem bug em algum lugar".

Os 4 erros que geram alucinação.

  1. Tarefa vaga: "faz um app bom"
    • IA inventa requisitos.
  2. Contexto faltando: "adiciona X" sem dizer onde/como - IA escolhe pattern errado.
  3. Sem verificação: "implementa Y" sem teste - IA entrega "compila" mas não "funciona".
  4. Múltiplas tarefas: "faz A, B, C, D" - IA mistura, faz A direito e B errado.

Solução: 1 tarefa por prompt, com verificação.

A regra 1-3-5. 1 objetivo por prompt. 3 arquivos máximo de contexto. 5 etapas máximo por "feature" (decomponha se for mais).

Aprofundamento 🟡

Contexto de arquivos: 1, 3, ou 10? 1 arquivo = simples, IA lê e entende. 3 arquivos = IA correlaciona, melhor resultado. 10+ arquivos = IA se perde, tenta adivinhar, gera errado. Solução: resuma 10 arquivos em 1 doc de contexto, mande esse doc como input.

Exemplo de resumo de contexto.

# Codebase context: auth module

## Estrutura
- /auth/login: recebe email/password, chama API
- /auth/callback: recebe OAuth code, troca por token
- /auth/session: armazena JWT em cookie httpOnly

## Padrões usados
- Todas as rotas async com try/catch
- Errors: throw AppError(code, message)
- Logger: log.info(message, context)
- Testes: Jest, mocks em __mocks__/

## O que adicionar
- /auth/google: OAuth com Google (novo)
- Middleware: verificar token em rotas privadas

Esse doc de contexto substitui 10 arquivos de código, IA entende rápido.

Quando usar agent mode vs prompt direto. Agent mode (Cursor Composer, Claude Code agent) é poderoso mas arriscado: IA planeja, edita, roda testes, até dar certo. Use para:

  • Refactor grande e bem definido ("renomeia X em todo código").
  • Boilerplate multi-file ("cria componente + tests + story").
  • Bug claro com teste que falha.

Não use para:

  • Decisão de arquitetura (IA escolhe errado sem review).
  • Lógica de negócio específica.
  • Código de segurança.

"Plan mode" do Cursor / Claude Code. Em vez de agente agir diretamente, planeja primeiro, mostra plano, você aprova, depois agente age. Recomendado pra Nível 3.

Exemplo de fluxo agent com plan mode.

Você: "Adiciona paginação a tabela de users"
IA: "Plano: 1) criar useUsersPaginated hook,
    2) modificar UserTable pra aceitar paginação,
    3) adicionar botões next/prev, 4) atualizar
    testes. Posso prosseguir?"
Você: "Sim, prossiga"
IA: [executa 4 etapas, mostra diffs]
Você: revisa cada diff

1 task → plano visível → review por etapa = resultado confiável.

Iteração vs geração. Em 2026, o pattern mais produtivo é iterar:

Prompt 1: "Cria função que valida CPF"
IA: [código inicial]
Você: "Botão, agora aceita CPF com pontuação
  E sem pontuação, e remove caracteres não
  numéricos antes de validar"
IA: [código melhorado]
Você: "Adiciona teste pra CPF com letras
  no meio (deve rejeitar)"
IA: [código com teste]

3-5 iterações por tarefa = 90% do valor. 1 prompt "perfeito" é raro.

Context window: o limite real. Modelos têm limite de contexto: Claude Sonnet = 200K tokens (~150K palavras), GPT-4 = 128K. Mande contexto relevante, não tudo. Não cole 50 arquivos - IA se perde, gera pior.

Resumo de contexto longo. Se o projeto é grande, resuma em 1-2K tokens e mande isso. Menos contexto + mais preciso > mais contexto + mais ruído.

Pra quem quer ir mais além 🔴

Specification-driven development (SDD). Pattern: antes de pedir código, escreve spec (1-2 páginas): objetivo, casos de uso, constraints, edge cases. Depois pede código com a spec como input. IA gera 3-5x melhor com spec clara.

Tools: TaskMaster, claude-task- master, BMAD. Frameworks que decompem feature em tasks, cada task com acceptance criteria. IA executa task por task, você revisa entre tasks. Tooling state of the art em 2026.

AI pair programming com 2 LLMs. Pair programming clássico: 1 dev dirige, outro revisa. Versão AI: 1 LLM gera código, outro LLM revisa (Claude gera, GPT revisa, ou vice-versa). 2 perspectives pegam mais bugs.

AI em TDD. Excelente. TDD define comportamento esperado (teste vermelho), IA gera código que passa o teste (verde). Fluxo:

  1. Escreve teste (você).
  2. IA gera implementação.
  3. Teste passa (verde).
  4. Refactor (IA ajuda).
  5. Repete.

Menos alucinação porque teste define comportamento. Mais rápido porque IA sabe exatamente o que precisa.

Leitura recomendada:

Dica: o erro mais comum em IA coding é pedir tarefa grande demais. "Faz um app de e-commerce" ou "migra de Redux pra Zustand" = IA alucina, gera genérico, você refaz. Decomposição em 1-3 etapas por vez = resultado confiável. Gaste 5 min decompondo = economiza 2h de código errado.

No próximo nó, vamos ler código gerado: como auditar um diff grande (200+ linhas) que IA produziu, red flags de segurança/performance, e checklist antes de aceitar.

// Quiz

Quando você deve decompor uma tarefa em sub-tarefas antes de pedir pra IA gerar código?

Escolha uma alternativa

// recursos

// avaliação da trilha

—
ainda sem avaliações