El ciclo OODA para la ingeniería de prompts: lo que cinco fracasos me enseñaron

El ciclo OODA del coronel John Boyd fue desarrollado para la toma de decisiones de pilotos de combate en la década de 1960, donde el piloto que completaba el ciclo observar-orientar-decidir-actuar más rápido obtenía una ventaja decisiva, independientemente de las capacidades de la aeronave. Descubrí que el mismo principio se aplica a la ingeniería de prompts, después de que cinco fracasos costosos me enseñaran que escribir el prompt es el paso menos importante.¹

TL;DR

El ciclo OODA (Observar, Orientar, Decidir, Actuar) proporciona un marco sistemático para la ingeniería de prompts que previene el modo de fallo más común: actuar (escribir un prompt) antes de observar (comprender el contexto completo). Después de construir 44 skills —cada uno un prompt estructurado con lógica de activación automática— he aprendido que el prompt en sí representa aproximadamente el 20% del resultado. El otro 80% es observación (¿qué contexto necesita el modelo?), orientación (¿qué tipo de tarea es la tarea?) y decisión (¿qué patrón de prompt se ajusta al tipo de tarea?). El constructor interactivo a continuación recorre el ciclo OODA completo. El resultado: prompts que funcionan en el primer intento en lugar de requerir refinamiento iterativo.

El prompt que falló cinco veces

Antes de aprender a observar antes de actuar, escribía prompts como un desarrollador escribe código: saltar directamente a la solución.

Fracaso 1: El evaluador de blog. Mi primer intento con un prompt de evaluación de calidad para blog: “Evalúa esta publicación de blog y dale una puntuación del 1 al 10.” El modelo devolvió un párrafo vago con “7/10” y sin retroalimentación accionable. Iteré cuatro veces antes de darme cuenta de que el problema no era la redacción del prompt — el problema era que no había definido qué significaba “calidad”.

La corrección OODA: Dediqué 30 minutos a observar mi propio proceso de evaluación. Identifiqué seis dimensiones específicas que me importaban: valor para el lector (25%), precisión técnica (20%), calidad educativa (20%), calidad de escritura (15%), integridad factual (15%) y efectividad SEO (5%). La rúbrica ponderada se convirtió en el skill blog-evaluator, y cada evaluación desde entonces ha producido puntuaciones consistentes y accionables.²

Fracaso 2: El revisor de código. Mi primer prompt de revisión: “Revisa este código en busca de errores y problemas de seguridad.” El modelo devolvió 15 hallazgos, 12 de los cuales eran observaciones estilísticas menores. La relación señal-ruido hizo que la revisión fuera inútil.

La corrección OODA: Orienté la tarea como tres subtareas separadas (corrección, seguridad, convenciones) y construí tres subagentes revisores dedicados, cada uno con acceso restringido a herramientas y criterios de evaluación específicos. El revisor de corrección solo señala errores lógicos. El revisor de seguridad solo señala vulnerabilidades OWASP. El revisor de convenciones solo señala desviaciones de patrones. El ruido se redujo a casi cero porque cada prompt tiene un alcance estrecho en una sola dimensión.³

Fracaso 3: El prompt de traducción. “Traduce esta publicación de blog al coreano.” El modelo tradujo pero perdió todo el formato markdown, eliminó las referencias de notas al pie y reescribió términos técnicos que deberían haber permanecido en inglés.

La corrección OODA: Observé lo que “traducir” realmente significaba para mi caso de uso: preservar la estructura markdown, preservar la numeración de notas al pie, mantener los bloques de código sin traducir, mantener los nombres propios en inglés, adaptar modismos en lugar de transliterarlos. La lista de restricciones se volvió más larga que la instrucción de traducción. Cada restricción eliminó un modo de fallo que “traduce esto” habría producido.⁴

El ciclo OODA aplicado a la creación de prompts

Fase 1: Observar

Antes de escribir una sola palabra del prompt, observe el espacio del problema:

¿Cuál es la tarea real? No la solicitud superficial, sino la necesidad subyacente. “Resume este documento” podría significar en realidad “extrae las tres decisiones tomadas en esta reunión para que pueda dar seguimiento a los puntos de acción.”

¿Qué necesita saber el modelo? Enumere el contexto requerido para una respuesta correcta. El contexto faltante produce alucinaciones. El contexto excesivo desperdicia tokens y puede distraer al modelo.

¿Cómo luce la salida? Defina el formato, longitud, tono y estructura de la salida deseada antes de escribir el prompt. Expectativas vagas de salida producen salidas vagas.⁵

Lista de verificación de observación: - [ ] Tarea real (no la solicitud superficial) identificada - [ ] Contexto requerido enumerado - [ ] Formato de salida definido - [ ] Criterios de éxito especificados - [ ] Modos de fallo anticipados

Fase 2: Orientar

Oriente la tarea dentro del espacio de capacidades del modelo:

Clasificación del tipo de tarea. ¿Es la tarea extracción (obtener información del texto proporcionado), generación (crear contenido nuevo), transformación (convertir entre formatos), análisis (evaluar y razonar sobre contenido) o clasificación (categorizar la entrada)?⁶

Cada tipo de tarea tiene patrones de prompt establecidos. Mis 44 skills reflejan el patrón: el skill blog-evaluator usa patrones de análisis (rúbrica ponderada, puntuación estructurada). El skill blog-writer-core usa patrones de generación (reglas de estilo, listas de restricciones, estructuras de ejemplo). El skill citation-verifier usa patrones de extracción (extraer afirmaciones, contrastar con fuentes).

Evaluación de complejidad. ¿Se puede completar la tarea en un solo prompt, o requiere descomposición? Una regla general: si la tarea requiere más de tres operaciones cognitivas distintas, descomponga.

Mi sistema de deliberación lleva la descomposición más lejos: cuando la confianza es baja (puntuación inferior a 0,70), el sistema genera múltiples agentes para explorar el problema de forma independiente, luego clasifica sus respuestas por calidad. Los umbrales de complejidad para un solo prompt varían, pero descompongo cualquier tarea que mezcle investigación, análisis y generación.

Mapeo de restricciones. ¿Qué restricciones aplican? Límites de tokens, requisitos de formato de salida, necesidades de precisión factual, requisitos de tono, consideraciones de audiencia. Cada restricción se convierte en una instrucción explícita en el prompt.

Fase 3: Decidir

Basándose en la observación y orientación, decida la arquitectura del prompt:

Selección del patrón de prompt:

Asignación de rol. Los roles funcionan cuando la tarea se beneficia de una perspectiva particular. Mi subagente security-reviewer recibe el rol “ingeniero de seguridad senior revisando código en busca de vulnerabilidades OWASP Top 10” — el rol enfoca la salida en preocupaciones de seguridad. Los roles fallan cuando el rol contradice la tarea (“Usted es un escritor creativo” para una tarea de análisis factual).⁷

Fase 4: Actuar

Escriba el prompt usando las decisiones de la Fase 3. El prompt sigue una estructura 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)

La estructura no es una plantilla para completar mecánicamente. La estructura es una lista de verificación: ¿las fases de observación, orientación y decisión han producido suficiente claridad para escribir cada sección? Si alguna sección no es clara, regrese a la fase anterior apropiada.⁸

Mi biblioteca de prompts: 44 skills como prompts estructurados

Mi sistema de skills de Claude Code es esencialmente una biblioteca de prompts organizada por tipo de tarea. Cada skill sigue la estructura 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]

La descripción del skill maneja la observación (¿cuándo debería activarse el skill?). El campo allowed-tools maneja la orientación (¿qué capacidades necesita la tarea?). El cuerpo maneja la decisión y la acción (¿qué patrones debe seguir el modelo?).⁹

El skill blog-writer-core codifica 14 reglas de estilo obligatorias — restricciones que descubrí a través de fracasos:

1. Solo voz activa (“Los ingenieros instalaron” no “fue instalado por”)
2. No usar “esto” como sujeto (siempre especificar el referente)
3. Cada afirmación citada con una nota al pie
4. Bloques de código etiquetados con identificadores de lenguaje
5. Sin rayas em (usar comas o punto y coma)

Cada regla existe porque publiqué un artículo que la violó. La regla #1 surgió cuando el hook blog-quality-gate detectó 7 oraciones en voz pasiva. La regla #3 surgió al publicar una afirmación sin citar sobre una estadística de McKinsey. La fase de observación OODA identificó el fallo; la restricción en el prompt previene la recurrencia.¹⁰

El ciclo de iteración

El ciclo OODA es inherentemente iterativo. Después de actuar (enviar el prompt) y observar el resultado:

1. Observe la salida: ¿Qué es correcto? ¿Qué es incorrecto? ¿Qué falta?
2. Oriente la brecha: ¿El problema es de contexto (información faltante), formato (estructura incorrecta) o capacidad (tarea demasiado compleja para un solo prompt)?
3. Decida la corrección: Agregar contexto, ajustar instrucciones de formato o descomponer la tarea.
4. Actúe con el prompt revisado.

Cada ciclo de iteración debe cambiar exactamente una variable. Cambiar múltiples elementos del prompt simultáneamente hace imposible identificar qué cambio produjo qué efecto.¹¹

Mi flujo de trabajo de evaluación de blog sigue el ciclo de iteración 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 paso usa un prompt diferente optimizado para su tipo de tarea. El paso de lint usa extracción (encontrar violaciones). El paso de evaluación usa análisis (puntuar contra la rúbrica). El paso de crítica usa generación (producir sugerencias de mejora). El paso de corrección usa transformación (aplicar cambios preservando la estructura). La cadena produce mejores resultados que un solo prompt monolítico de “mejora esta publicación”.¹²

Conclusiones clave

Para ingenieros construyendo funciones de IA: - Aplique el ciclo OODA completo antes de escribir prompts; 5 minutos de observación y orientación ahorran 30 minutos de refinamiento iterativo de prompts - Clasifique el tipo de tarea (extracción, generación, transformación, análisis, clasificación) antes de seleccionar un patrón de prompt; cada tipo tiene patrones establecidos que superan al prompting genérico - Construya una biblioteca de prompts organizada por tipo de tarea; mis 44 skills representan patrones de prompt validados que reutilizo en todos los proyectos

Para equipos de producto que usan IA a diario: - Cuando una salida de IA decepciona, diagnostique si el fallo está en la observación (tarea incorrecta identificada), orientación (enfoque incorrecto), decisión (patrón de prompt incorrecto) o acción (redacción incorrecta del prompt); la corrección difiere para cada fase - Las restricciones previenen más fallos que la redacción ingeniosa del prompt; las 14 reglas obligatorias de mi escritor de blog producen una calidad más consistente que cualquier cantidad de “por favor escriba bien”

Referencias