O Loop OODA para Engenharia de Prompts: O Que Cinco Falhas Me Ensinaram

O loop OODA do Coronel John Boyd foi desenvolvido para a tomada de decisão de pilotos de caça nos anos 1960, onde o piloto que completasse o ciclo observar-orientar-decidir-agir mais rápido ganhava uma vantagem decisiva, independentemente das capacidades da aeronave. Descobri que o mesmo princípio se aplica à engenharia de prompts — depois que cinco falhas custosas me ensinaram que escrever o prompt é a etapa menos importante.¹

TL;DR

O loop OODA (Observar, Orientar, Decidir, Agir) oferece um framework sistemático para engenharia de prompts que previne o modo de falha mais comum: agir (escrever um prompt) antes de observar (entender o contexto completo). Depois de construir 44 skills — cada uma sendo um prompt estruturado com lógica de ativação automática — aprendi que o prompt em si responde por aproximadamente 20% do resultado. Os outros 80% são observação (que contexto o modelo precisa?), orientação (que tipo de tarefa é essa?) e decisão (qual padrão de prompt se encaixa no tipo de tarefa?). O construtor interativo abaixo percorre o ciclo OODA completo. O resultado: prompts que funcionam na primeira tentativa em vez de exigir refinamento iterativo.

O Prompt Que Falhou Cinco Vezes

Antes de aprender a observar antes de agir, eu escrevia prompts como um desenvolvedor escreve código: indo direto para a solução.

Falha 1: O avaliador de blog. Minha primeira tentativa de um prompt para avaliação de qualidade de blog: “Avalie este post e dê uma nota de 1 a 10.” O modelo retornou um parágrafo vago com “7/10” e nenhum feedback acionável. Iteramos quatro vezes antes de perceber que o problema não era a redação do prompt — o problema era que eu não tinha definido o que “qualidade” significava.

A correção OODA: Passei 30 minutos observando meu próprio processo de avaliação. Identifiquei seis dimensões específicas que me importavam: valor para o leitor (25%), precisão técnica (20%), qualidade educacional (20%), qualidade da escrita (15%), integridade factual (15%) e eficácia de SEO (5%). A rubrica ponderada se tornou a skill blog-evaluator, e toda avaliação desde então produziu pontuações consistentes e acionáveis.²

Falha 2: O revisor de código. Meu primeiro prompt de revisão: “Revise este código em busca de bugs e problemas de segurança.” O modelo retornou 15 achados, dos quais 12 eram detalhes estilísticos irrelevantes. A relação sinal-ruído tornou a revisão inútil.

A correção OODA: Orientei a tarefa como três subtarefas separadas (corretude, segurança, convenções) e construí três subagentes revisores dedicados, cada um com acesso restrito a ferramentas e critérios de avaliação específicos. O revisor de corretude só sinaliza erros de lógica. O revisor de segurança só sinaliza vulnerabilidades OWASP. O revisor de convenções só sinaliza desvios de padrão. O ruído caiu para quase zero porque cada prompt tem escopo restrito a uma única dimensão.³

Falha 3: O prompt de tradução. “Traduza este post para coreano.” O modelo traduziu, mas perdeu toda a formatação markdown, removeu referências de notas de rodapé e reescreveu termos técnicos que deveriam ter permanecido em inglês.

A correção OODA: Observei o que “traduzir” realmente significava para o meu caso de uso: preservar a estrutura markdown, preservar a numeração das notas de rodapé, manter blocos de código sem tradução, manter nomes próprios em inglês, adaptar expressões idiomáticas em vez de transliterar. A lista de restrições ficou mais longa que a instrução de tradução. Cada restrição eliminou um modo de falha que “traduza isso” teria produzido.⁴

O Loop OODA Aplicado a Prompts

Fase 1: Observar

Antes de escrever uma única palavra do prompt, observe o espaço do problema:

Qual é a tarefa real? Não o pedido superficial, mas a necessidade subjacente. “Resuma este documento” pode na verdade significar “extraia as três decisões tomadas nesta reunião para que eu possa acompanhar os itens de ação.”

O que o modelo precisa saber? Enumere o contexto necessário para uma resposta correta. Contexto faltante produz alucinação. Contexto excessivo desperdiça tokens e pode distrair o modelo.

Como é o resultado esperado? Defina o formato, comprimento, tom e estrutura do resultado desejado antes de escrever o prompt. Expectativas vagas de resultado produzem resultados vagos.⁵

Checklist de observação: - [ ] Tarefa real (não o pedido superficial) identificada - [ ] Contexto necessário enumerado - [ ] Formato de saída definido - [ ] Critérios de sucesso especificados - [ ] Modos de falha antecipados

Fase 2: Orientar

Oriente a tarefa dentro do espaço de capacidades do modelo:

Classificação do tipo de tarefa. A tarefa é de extração (extrair informação do texto fornecido), geração (criar novo conteúdo), transformação (converter entre formatos), análise (avaliar e raciocinar sobre conteúdo) ou classificação (categorizar a entrada)?⁶

Cada tipo de tarefa tem padrões de prompt estabelecidos. Minhas 44 skills refletem esse padrão: a skill blog-evaluator usa padrões de análise (rubrica ponderada, pontuação estruturada). A skill blog-writer-core usa padrões de geração (regras de estilo, listas de restrições, estruturas de exemplo). A skill citation-verifier usa padrões de extração (extrair afirmações, comparar com fontes).

Avaliação de complexidade. A tarefa pode ser completada em um único prompt, ou requer decomposição? Uma regra prática: se a tarefa exige mais de três operações cognitivas distintas, decomponha.

Meu sistema de deliberação leva a decomposição adiante: quando a confiança é baixa (pontuação abaixo de 0,70), o sistema cria múltiplos agentes para explorar o problema independentemente e então classifica suas respostas por qualidade. Os limites de complexidade para prompt único variam, mas eu decomponho qualquer tarefa que misture pesquisa, análise e geração.

Mapeamento de restrições. Quais restrições se aplicam? Limites de tokens, requisitos de formato de saída, necessidades de precisão factual, requisitos de tom, considerações sobre o público. Cada restrição se torna uma instrução explícita no prompt.

Fase 3: Decidir

Com base na observação e orientação, decida sobre a arquitetura do prompt:

Seleção do padrão de prompt:

Atribuição de papel. Papéis funcionam quando a tarefa se beneficia de uma perspectiva particular. Meu subagente security-reviewer recebe o papel “engenheiro de segurança sênior revisando código para vulnerabilidades OWASP Top 10” — o papel foca a saída em questões de segurança. Papéis falham quando o papel contradiz a tarefa (“Você é um escritor criativo” para uma tarefa de análise factual).⁷

Fase 4: Agir

Escreva o prompt usando as decisões da Fase 3. O prompt segue uma estrutura consistente:

[ROLE] (if applicable)
[CONTEXT] (the information the model needs)
[TASK] (the specific instruction)
[FORMAT] (the expected output structure)
[CONSTRAINTS] (restrictions and requirements)
[EXAMPLES] (if using few-shot)

A estrutura não é um template para preencher mecanicamente. A estrutura é um checklist: as fases de observação, orientação e decisão produziram clareza suficiente para escrever cada seção? Se alguma seção estiver pouco clara, retorne à fase anterior apropriada.⁸

Minha Biblioteca de Prompts: 44 Skills como Prompts Estruturados

Meu sistema de skills do Claude Code é essencialmente uma biblioteca de prompts organizada por tipo de tarefa. Cada skill segue a estrutura OODA:

---
description: FastAPI backend development patterns and conventions
allowed-tools: [Read, Grep, Glob, Edit, Write, Bash]
---
# FastAPI Development Expertise

## Project Structure
[CONTEXT: expected file layout, naming conventions]

## Route Patterns
[CONSTRAINTS: response format, error handling, dependency injection]

## Database Patterns
[CONSTRAINTS: SQLAlchemy 2.0+ async, Pydantic v2 models]

A descrição da skill cuida da observação (quando a skill deve ser ativada?). O campo allowed-tools cuida da orientação (quais capacidades a tarefa precisa?). O corpo cuida da decisão e ação (quais padrões o modelo deve seguir?).⁹

A skill blog-writer-core codifica 14 regras de estilo obrigatórias — restrições que descobri por meio de falhas:

1. Apenas voz ativa (“Engenheiros instalaram” e não “foi instalado por”)
2. Nunca usar “isso” como sujeito (sempre especificar o referente)
3. Toda afirmação citada com nota de rodapé
4. Blocos de código identificados com a linguagem
5. Sem travessões longos (usar vírgulas ou ponto e vírgula)

Cada regra existe porque publiquei um post que a violou. A regra #1 surgiu quando o hook blog-quality-gate detectou 7 frases em voz passiva. A regra #3 surgiu após publicar uma afirmação sem citação sobre uma estatística da McKinsey. A fase de observação do OODA identificou a falha; a restrição no prompt previne a recorrência.¹⁰

O Loop de Iteração

O loop OODA é inerentemente iterativo. Após agir (enviar o prompt) e observar o resultado:

1. Observe a saída: O que está correto? O que está errado? O que está faltando?
2. Oriente a lacuna: O problema é de contexto (informação faltante), formato (estrutura errada) ou capacidade (tarefa complexa demais para um único prompt)?
3. Decida a correção: Adicionar contexto, ajustar instruções de formato ou decompor a tarefa.
4. Aja com o prompt revisado.

Cada ciclo de iteração deve alterar exatamente uma variável. Mudar múltiplos elementos do prompt simultaneamente torna impossível identificar qual mudança produziu qual efeito.¹¹

Meu fluxo de avaliação de blog segue o loop de iteração completo:

1. Lint (deterministic) → fix structural issues
2. Evaluate (LLM) → score on 6 dimensions
3. Critique (LLM) → identify specific improvements
4. Fix (LLM) → apply surgical improvements
5. Re-evaluate → verify score improved

Cada etapa usa um prompt diferente, otimizado para seu tipo de tarefa. A etapa de lint usa extração (encontrar violações). A etapa de avaliação usa análise (pontuar conforme a rubrica). A etapa de crítica usa geração (produzir sugestões de melhoria). A etapa de correção usa transformação (aplicar mudanças preservando a estrutura). A cadeia produz resultados melhores do que um único prompt monolítico “melhore este post”.¹²

Principais Conclusões

Para engenheiros construindo funcionalidades com IA: - Aplique o ciclo OODA completo antes de escrever prompts; 5 minutos de observação e orientação economizam 30 minutos de refinamento iterativo - Classifique o tipo de tarefa (extração, geração, transformação, análise, classificação) antes de selecionar um padrão de prompt; cada tipo tem padrões estabelecidos que superam prompts genéricos - Construa uma biblioteca de prompts organizada por tipo de tarefa; minhas 44 skills representam padrões de prompt validados que reutilizo entre projetos

Para equipes de produto que usam IA diariamente: - Quando um resultado de IA decepcionar, diagnostique se a falha está na observação (tarefa errada identificada), orientação (abordagem errada), decisão (padrão de prompt errado) ou ação (redação do prompt errada); a correção é diferente para cada fase - Restrições previnem mais falhas do que redação rebuscada de prompts; as 14 regras obrigatórias do meu escritor de blog produzem qualidade mais consistente do que qualquer quantidade de “por favor, escreva bem”

Referências