Prompt, Contexto, Harness: las 3 etapas de evolución que casi nadie termina

Hay tres etapas en la manera en que los desarrolladores le hablan a un modelo de IA. Prompt, Contexto, Harness. La mayoría se queda en la primera, algunos llegan a la segunda, y muy pocos terminan la tercera. Este artículo explica por qué esa progresión existe y qué gana cada etapa.

Uso los tres términos todos los días en mi trabajo con agentes de IA. Aunque parezcan sinónimos, resuelven problemas distintos. Y la confusión entre ellos es la razón por la que, según una investigación de Company of Agents de 2026, el 40% de los proyectos de agentes fallan en producción.

Etapa 1 — Ingeniería de Prompt

Sujeto: un único mensaje de entrada al modelo.

Cuando ChatGPT llegó al público en 2022, todos aprendimos a escribir prompts. Few-shot, Chain-of-Thought, ReAct. El objetivo era maximizar la precisión en una sola conversación.

Ejemplo concreto en español, del tipo que la mayoría de nosotros escribe:

“Actúa como un desarrollador senior. Revisa este código Python y encuentra bugs. Devuelve una lista con línea y descripción.”

Esto funciona para tareas cortas. Un análisis, un resumen, una traducción. Y sigue funcionando hoy. El error es creer que basta con esto para construir un agente que ejecute por horas sin supervisión.

Métrica típica de esta etapa: precisión en una sola pasada. Es lo que se mide en benchmarks como MMLU o HumanEval.

Cuándo se rompe: cuando el modelo necesita saber algo que el prompt no incluye. Un nombre de tabla, una convención interna, el contenido de un archivo. Ahí toca pegar más y más texto en el prompt, y en algún momento se vuelve inmanejable.

Etapa 2 — Ingeniería de Contexto

Sujeto: todo lo que llega al modelo (system prompt + RAG + definiciones de herramientas + memoria).

Aquí es donde empieza la ingeniería seria. En palabras de Andrej Karpathy, “es mucho más que solo el prompt en sí”. La ventana de contexto se arma dinámicamente para cada llamada, incluyendo solo lo que el modelo necesita en ese momento.

El cambio mental es grande. En vez de “cómo escribo mejor el mensaje”, la pregunta pasa a ser “cómo curo la información que llega al modelo”. Anthropic lo definió en septiembre de 2025 así:

“Ingeniería de contexto es el conjunto de estrategias para curar y mantener el conjunto óptimo de tokens durante la inferencia del LLM.”

Métrica típica: precisión a lo largo de una tarea multi-paso. Y algo muy poco discutido: costo por token. Cuando el contexto crece, la factura de la API también.

Un dato de 2026: Anthropic reportó en julio de este año que eliminaron más del 80% del system prompt de Claude Code sin pérdida medible en evaluaciones de programación. Modelos más nuevos infieren de lo que rodea el prompt lo que los modelos anteriores necesitaban que se les dijera explícitamente. Eso es ingeniería de contexto llevada al límite: menos tokens, misma calidad.

Cuándo se rompe: cuando el agente ejecuta durante horas y toma decisiones autónomas. El contexto por sí solo no puede controlar qué herramientas se invocan, qué archivos se pueden modificar, qué pasa cuando algo falla. Ahí aparece la tercera etapa.

Etapa 3 — Harness Engineering

Sujeto: todo el entorno operativo del modelo (contexto + restricciones + herramientas + ciclo de vida + retroalimentación + monitoreo).

La definición más simple es la de Louis Bouchard:

“Ingeniería de Contexto es lo que le envías al modelo. Harness Engineering es cómo funciona el todo.”

El ambiente alrededor del modelo, más allá del prompt y del contexto. Si la analogía es una cocina, el prompt es la receta, el contexto son los ingredientes, y el harness es la cocina entera.

Ejemplo concreto: un agente autónomo que revisa código durante 8 horas por la noche. Necesita:

• Un prompt que le diga qué hacer.
• Un contexto que le dé acceso al repositorio actual.
• Un harness que decida qué comandos puede correr, dónde escribe logs, qué pasa si el proceso muere a las 3 AM, cómo se reintenta, quién recibe la alerta.

Las tres capas están anidadas: Harness ⊇ Contexto ⊇ Prompt. No compiten entre sí. Se apilan.

Métrica típica: tasa de éxito de la tarea completa (medir respuestas individuales aquí engaña). Y algo que casi nadie mide: cuánto tiempo el agente pasó bloqueado esperando algo que el harness no le dio.

Un número que me sorprendió: los equipos que dominan ingeniería de contexto para agentes de IA completan tareas 55% más rápido y producen 40% menos errores, según los reportes de Anthropic de 2026. La brecha entre etapa 2 y etapa 3 es aún más grande en tareas de largo aliento.

Por qué la mayoría se queda en la etapa 1

Tres razones que veo constantemente:

Primero, la etapa 1 se siente productiva. Escribes un prompt más largo, obtienes un resultado un poco mejor, y crees que estás mejorando. Pero el retorno decae rápido. Después de cierto punto, agregar más texto al prompt no mejora nada — y a veces empeora las cosas por el problema de “context rot” que Anthropic documentó bien.

Segundo, saltar a la etapa 2 requiere infraestructura. RAG, embeddings, alguna forma de memoria persistente. No es un cambio de vocabulario, es un cambio de arquitectura. Los equipos que no tienen a alguien que sepa montar esto se quedan estancados.

Tercero, y este es el más sutil: la etapa 3 requiere decisiones de producto, no solo técnicas. ¿Qué puede hacer el agente sin permiso? ¿Cuánto puede gastar en tokens antes de pedir autorización? ¿Qué es un “fallo silencioso” vs un “fallo ruidoso”? Estas preguntas incomodan porque no tienen respuesta técnica pura.

Un artículo académico interesante sobre este tema es el paper de arXiv “Natural-Language Agent Harnesses” que discutí en otro post, donde se formaliza el concepto de harness como especificación en lenguaje natural.

Un ejemplo de las tres capas juntas

Para aterrizarlo, tomemos una tarea real: “revisar un pull request y dejar comentarios de código”.

Prompt solamente: le pegas el diff al modelo y le pides que comente. Funciona para PRs de 50 líneas.

Prompt + Contexto: agregas el archivo original, los archivos relacionados, la convención de código del equipo, ejemplos previos. Funciona para PRs de hasta ~500 líneas.

Prompt + Contexto + Harness: además tienes reglas de cuándo el agente puede aprobar sin humano (nunca), cuándo debe rechazar automáticamente (fallo de linter), cuánto tiempo puede pasar antes de escalar a un humano, qué formato tienen sus comentarios, qué pasa si el agente se cae a mitad de revisión. Funciona para PRs de cualquier tamaño y para cualquier volumen de PRs por día.

La primera versión es un prompt. La segunda es una integración. La tercera es un producto.

Qué hacer esta semana

Si estás en la etapa 1 y quieres avanzar:

• Identifica una tarea que hoy resuelves pegando texto al prompt. Reemplaza esa pegada con una función que traiga el texto dinámicamente (embedding search, o simplemente una consulta a tu base de datos).
• Mide cuántos tokens estabas gastando antes y cuántos gastas después.

Si estás en la etapa 2 y quieres avanzar:

• Elige una tarea que hoy ejecutas manualmente y que dura más de una hora. Diseña el harness antes de escribir el prompt: qué herramientas necesita, qué límites, qué pasa cuando falla.
• El harness no es código complejo. La mayoría cabe en un archivo YAML de 100 líneas.

Si ya estás en la etapa 3: recuerda que no hay etapa 4. Harness engineering no se “supera”. Se refina.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev