Context Engineering: La Habilidad que Reemplazó al Prompt Engineering

El contexto es el nuevo código

El prompt engineering está muerto. No en el sentido de "los periódicos lo declararon muerto," sino de la forma en que el lenguaje ensamblador está muerto. Todavía puedes escribirlo. La mayoría de los profesionales han migrado a algo de más alto nivel. Ese algo es context engineering: la disciplina de estructurar, seleccionar y secuenciar información para que los agentes de IA produzcan resultados confiables en sistemas de producción.

En product.engineer, definimos context engineering como la práctica de diseñar el entorno de información completo dentro del cual opera un modelo de IA, incluyendo instrucciones del sistema, documentos recuperados, definiciones de herramientas, historial de conversación y metadata estructurada. Determina no solo lo que el modelo sabe, sino cómo razona, qué prioriza y hacia dónde dirige su atención. Si el prompt engineering se trataba de escribir una pregunta ingeniosa, el context engineering se trata de construir toda la habitación dentro de la cual el modelo piensa.

Esta distinción importa profundamente para el product engineer. Cuando eres dueño del ciclo completo desde la definición del problema hasta el feature entregado, necesitas IA que funcione de manera confiable a escala de producción. No IA que funcione impresionantemente en un demo y luego se desmorone en casos extremos. Esa confiabilidad viene del contexto, no de los prompts.

El cambio se hizo visible en 2025. En el AI Engineer World's Fair, el equipo de ingeniería de Shopify presentó su framework interno para lo que llamaron "diseño de agentes context-first." La charla ha acumulado desde entonces más de 73,000 visualizaciones. Su argumento central: la calidad del output de un agente está determinada en un 90% por el contexto que recibe y un 10% por la capacidad bruta del modelo. Mostraron datos de producción de sus herramientas de IA para comerciantes. Cuando mejoraron los prompts sin cambiar la arquitectura de contexto, la precisión se movió del 71% al 74%. Cuando reestructuraron el contexto sin cambiar el prompt, la precisión saltó del 71% al 93%.

Esa brecha de 22 puntos es todo el caso a favor del context engineering en un solo dato.

Por qué el prompt engineering llegó a un techo

El prompt engineering funcionaba cuando el caso de uso era simple: el humano escribe una pregunta, el modelo devuelve una respuesta. Podías iterar en la redacción, agregar ejemplos few-shot, especificar el formato de salida y obtener resultados significativamente mejores. Era una disciplina válida para una era específica.

Esa era terminó cuando empezamos a construir agentes.

Un agente no es un solo par de prompt-respuesta. Es un sistema que toma acciones en el tiempo, mantiene estado entre interacciones, llama herramientas, lee documentos y toma decisiones con consecuencias. Cuando tu feature de IA reserva un restaurante, modifica una base de datos o hace commit de código, los riesgos de una respuesta incorrecta pasan de "ligeramente molesto" a "incidente de producción."

El problema del prompt engineering para agentes es estructural. Un prompt es una sola cadena de texto. El contexto de un agente es un sistema dinámico de múltiples fuentes que cambia en cada turno. Considera lo que un agente de código como Cursor o Windsurf necesita para funcionar correctamente:

• La instrucción actual del usuario
• El archivo actualmente abierto
• Archivos relacionados en el proyecto
• Las convenciones de codificación del proyecto (desde CLAUDE.md o similar)
• Historial reciente de git para contexto de cambios
• Definiciones de herramientas para operaciones de archivos, comandos de terminal, búsqueda web
• Historial de conversación (comprimido o completo)
• Mensajes de error de intentos anteriores
• Resultados de tests de la última ejecución

Esas son nueve fuentes de información diferentes, cada una con diferentes frecuencias de actualización, diferentes ventanas de relevancia y diferentes niveles de prioridad. "Escribir un mejor prompt" aborda exactamente una de esas nueve dimensiones. Context engineering aborda todas simultáneamente.

La investigación del equipo de evaluaciones de Anthropic demuestra que el contexto estructurado (prompts de sistema con secciones explícitas, descripciones de herramientas con ejemplos y documentos recuperados con puntajes de relevancia) mejora significativamente las tasas de completación de tareas comparado con contexto no estructurado con el mismo contenido de información. La misma información. Diferente estructura. Resultados significativamente mejores.

Eso no es un truco de prompting. Eso es arquitectura.

La anatomía de un sistema de contexto

Un contexto bien diseñado tiene cinco capas. Cada capa cumple una función diferente, y el product engineer que entiende las cinco entrega features de IA que realmente funcionan en producción.

Capa 1: Identidad y restricciones

Este es el prompt de sistema, pero pensar en él como "un prompt de sistema" subestima lo que hace. Establece los parámetros operativos del modelo: quién es, qué puede y no puede hacer, cómo debe manejar la ambigüedad y cómo deberían verse sus modos de fallo.

Los features de IA de Linear usan capas de identidad que especifican no solo el tono ("conciso, técnico") sino los límites de decisión ("si la solicitud del usuario afectaría más de 50 issues, confirmar antes de proceder"). El asistente de documentación de Stripe tiene capas de restricción que le impiden generar llamadas API con combinaciones de parámetros inválidas, incluso si el usuario las solicita explícitamente.

La capa de identidad responde: ¿cuáles son los límites del mundo de este agente?

Capa 2: Conocimiento (recuperado e inyectado)

Aquí es donde vive RAG (retrieval-augmented generation), pero es más amplio que RAG. El contexto de conocimiento incluye:

• Documentos recuperados por búsqueda semántica
• Datos estructurados extraídos de bases de datos
• Información en tiempo real de llamadas a APIs
• Datos específicos del usuario (preferencias, historial, permisos)

El desafío de ingeniería aquí no es la recuperación. Es la selección y compresión. Un modelo con 128K de contexto puede almacenar mucha información. Pero la investigación de Google DeepMind (publicada en su paper "Lost in the Middle", 2023) demostró que la información colocada en el medio de contextos largos se recuerda con un 20-30% menos de precisión que la información al principio o al final. La posición importa. El orden importa. Context engineering significa decidir no solo qué incluir, sino dónde colocarlo.

Capa 3: Herramientas y capacidades

Las definiciones de herramientas son contexto. Cuando describes los parámetros de una función, su comportamiento esperado, sus modos de fallo y sus efectos secundarios, estás diseñando la comprensión del modelo sobre lo que puede hacer. Descripciones pobres de herramientas producen modelos que llaman la herramienta equivocada, pasan parámetros incorrectos o fallan en usar herramientas disponibles.

El producto v0 de Vercel demuestra esto bien. Sus definiciones de herramientas incluyen no solo la firma de la función sino ejemplos explícitos de cuándo usar cada herramienta, errores comunes a evitar y el formato de salida esperado. Esto es harness engineering en la práctica: construir la infraestructura que hace predecible el comportamiento del agente.

Capa 4: Memoria y estado de conversación

¿Qué pasó antes de este turno? ¿Qué dijo el usuario hace tres mensajes? ¿Qué intentó el agente que falló? La gestión de memoria es un problema de context engineering porque los modelos tienen ventanas finitas y las conversaciones reales tienen longitud potencialmente infinita.

El enfoque ingenuo es incluir el historial completo de conversación hasta alcanzar el límite de contexto, luego truncar desde el principio. El enfoque diseñado es mantener un resumen comprimido de interacciones anteriores, preservar los puntos de decisión críticos de forma literal y descartar los turnos de baja información por completo.

Los features de IA de Notion implementan lo que llaman "resumen progresivo" para el contexto. Los mensajes recientes se incluyen de forma literal. Los mensajes de más de 10 turnos se resumen en hechos clave. Los mensajes de más de 50 turnos se reducen solo a relaciones entre entidades (el usuario prefiere X, el proyecto requiere Y). Esto mantiene la ventana de contexto eficiente mientras preserva la información que el modelo realmente necesita.

Capa 5: Estructura de salida

La capa final le dice al modelo cómo estructurar su output. Esto no es "responde en JSON." Es proporcionar la forma de la respuesta esperada, incluyendo pasos de razonamiento intermedios, validaciones requeridas antes del output final y restricciones de formato de las que dependen sistemas posteriores.

Cuando los features de IA de Figma generan sugerencias de diseño, la estructura de salida incluye metadata requerida (tipo de componente, compatibilidad de variantes, notas de accesibilidad) que el sistema de renderizado necesita. El modelo no decide qué metadata incluir. El context engineering lo define.

El framework de context engineering

Después de trabajar con sistemas de IA a escala, tanto en AWS como en mis propias empresas, he encontrado que el context engineering efectivo involucra cinco dimensiones clave: Prioridad, Relevancia, Instrucción, Estructura y Medición.

Prioridad determina qué información va dónde en la ventana de contexto. Las restricciones críticas van primero (prompt de sistema). Las definiciones de herramientas van cerca de la consulta del usuario. Los documentos recuperados van entre medio, ordenados por puntaje de relevancia.

Relevancia es el filtro que decide qué entra al contexto. No todo lo que el modelo podría saber debería estar en el contexto. Un agente de código trabajando en un componente React no necesita el esquema de base de datos del proyecto a menos que el componente obtenga datos. El filtrado de relevancia es la diferencia entre un contexto enfocado de 4K tokens y un contexto ruidoso de 90K tokens. El contexto enfocado gana casi siempre.

Instrucción es la capa de restricciones. Reglas explícitas que el modelo debe seguir, formuladas como imperativos. No "podrías considerar" sino "debes validar los inputs antes de llamar APIs externas." La investigación propia de Anthropic mostró que la formulación imperativa en prompts de sistema aumentó la adherencia a instrucciones un 18% comparado con la formulación sugestiva.

Estructura significa usar formato consistente. Encabezados, viñetas, tags XML, esquemas JSON. Los modelos procesan texto estructurado de forma más confiable que la prosa. Anthropic recomienda tags XML para la delimitación de secciones. La documentación de OpenAI recomienda encabezados de markdown. Ambos funcionan. La consistencia es lo que importa.

Medición es el ciclo de retroalimentación. Instrumentas tu contexto para entender qué usa realmente el modelo. Si incluyes 50 documentos recuperados y el modelo solo referencia 3, tu filtrado de relevancia necesita trabajo. Si el modelo viola una restricción, tu capa de instrucciones necesita fortalecimiento.

Context engineering en el flujo de trabajo del product engineer

Esto no es un ejercicio académico. Para cualquiera que construya features de IA, el context engineering es trabajo diario. Aparece en tres lugares.

Diseñando features de agentes

Cuando especificas un feature de IA (siguiendo desarrollo dirigido por specs), la arquitectura de contexto es parte de la especificación. Defines qué fuentes de información necesita el agente, cómo se recuperan y qué prioridad toman. Esto es una parte tan importante del diseño del feature como el mockup de UI.

En AWS, he visto equipos perder meses porque diseñaron el UX para un feature de IA sin diseñar el contexto. Construyeron una hermosa interfaz de chat. Las respuestas eran terribles porque nadie diseñó lo que el modelo realmente recibía. La solución siempre fue la misma: volver atrás, diseñar el sistema de contexto, entregar de nuevo.

Configurando herramientas de desarrollo

Cada ingeniero usando Cursor, Claude Code, Windsurf o GitHub Copilot está haciendo context engineering sea que lo reconozca o no. Tu archivo CLAUDE.md es context engineering. Tu archivo .cursorrules es context engineering. La forma en que estructuras tu codebase para que una IA pueda navegarlo es context engineering.

Esto conecta directamente con la ingeniería agéntica. Los ingenieros que obtienen ganancias de productividad de 10x de herramientas de IA no están escribiendo mejores prompts. Están diseñando mejor contexto: estructuras de archivos más claras, mejores convenciones de nomenclatura, documentación explícita de decisiones y restricciones.

Construyendo sistemas de IA en producción

Cuando entregas un feature de IA a los usuarios, el sistema de contexto es infraestructura de producción. Necesita monitoreo, versionado, testing A/B y respuesta a incidentes, igual que cualquier otro sistema de producción.

PostHog trata los contextos de sus features de IA como código. Los versionan en git, los revisan en PRs y miden su impacto con el mismo rigor que aplican a cualquier cambio de producto. Cuando un cambio de contexto produce una regresión en la calidad del output, lo revierten como revertirían un deploy fallido.

El toolkit de context engineering del product engineer

Así se ve el toolkit en la práctica:

Patrones del mundo real desde producción

Permítanme compartir tres patrones que he visto funcionar repetidamente entre equipos.

Patrón 1: El contrato de contexto. Antes de construir un feature de IA, escribe un documento que especifique exactamente lo que el modelo recibe en cada escenario. Trátalo como un contrato de API. Cuando el producto cambia, actualiza el contrato de contexto primero, luego actualiza la implementación. Esto previene la deriva entre lo que crees que el modelo ve y lo que realmente ve.

Patrón 2: El presupuesto de contexto. Asigna presupuestos de tokens a cada capa. Ejemplo: 2,000 tokens para el prompt de sistema, 4,000 para herramientas, 8,000 para documentos recuperados, 2,000 para historial de conversación. Cuando nueva información necesita entrar, algo más tiene que salir. Esto fuerza decisiones de priorización y previene la inflación del contexto.

Patrón 3: El test de regresión de contexto. Mantén un conjunto de escenarios de entrada con outputs esperados. Cuando cambies la arquitectura de contexto, ejecuta el conjunto. Esto no es una evaluación en el sentido de ML; es un test funcional que asegura que tus cambios de contexto no rompan el comportamiento existente. Stripe ejecuta más de 2,000 tests de regresión de contexto en sus features de IA antes de cualquier deploy.

Desde mi propia experiencia

Habiendo asesorado a más de 12,000 ingenieros y contratado a más de 600, puedo decirles el patrón que veo una y otra vez: los ingenieros que luchan con features de IA se enfocan en el modelo. Los ingenieros que entregan features de IA confiables se enfocan en el contexto. Esto es verdad ya sea que estén construyendo herramientas internas en AWS o productos de consumo en una startup.

En mi propio trabajo como Sr. Product Engineer en AWS, el cambio fue dramático. Los primeros features de IA en los que trabajé pasaban el 80% del tiempo de desarrollo en iteración de prompts. Probábamos cientos de variaciones de prompt, encontrábamos una que funcionaba bien en nuestros casos de prueba, la desplegábamos, y luego la veíamos fallar en inputs del mundo real que no habíamos anticipado. El problema nunca fue el modelo. Siempre fue el contexto: información faltante, instrucciones mal estructuradas o definiciones de herramientas que no contemplaban casos extremos.

Cuando cambiamos a desarrollo context-first, nuestros ciclos de iteración bajaron de semanas a días. Pasamos menos tiempo ajustando lenguaje y más tiempo diseñando qué información recibía el modelo, cómo estaba estructurada y cuándo se actualizaba. Las mejoras de calidad fueron consistentes y predecibles de una forma que el ajuste de prompts nunca fue.

El cambio en la contratación

Esto tiene implicaciones para cómo las empresas contratan product engineers. El prompt engineering nunca fue una disciplina de ingeniería real. Era una habilidad, como "escribir buenas búsquedas en Google." Útil, pero no suficiente para construir sistemas de producción.

Context engineering es diferente. Requiere pensamiento de sistemas, arquitectura de información, metodología de testing y habilidades de ingeniería de producción. Es por eso que empresas como Vercel, Linear y Notion buscan cada vez más ingenieros que entiendan tanto producto como sistemas de IA; que puedan diseñar una arquitectura de contexto con el mismo rigor que aplican a un esquema de base de datos o un diseño de API.

Si eres un product engineer buscando construir features de IA, invierte en context engineering. No en plantillas de prompts. No en "prompts mágicos" de hilos de Twitter. Los fundamentos: cómo los modelos procesan contexto, cómo la prioridad de información afecta la calidad del output, cómo testear y medir la efectividad del contexto.

Errores comunes

Cinco errores que veo a los equipos cometer repetidamente:

1. Meter todo. Más contexto no es mejor contexto. Un contexto de 100K tokens con 80K tokens de documentos marginalmente relevantes funciona peor que un contexto de 20K tokens con información precisamente relevante. Los modelos se confunden con el ruido.

2. Ignorar efectos de posición. Las instrucciones críticas enterradas en el medio de un contexto largo se siguen con menos frecuencia. Coloca tus restricciones más importantes al principio y al final.

3. Contexto estático para tareas dinámicas. Si tu agente maneja diferentes tipos de solicitudes, el contexto debe adaptarse. Un agente de soporte al cliente respondiendo preguntas de facturación necesita diferente contexto que el mismo agente respondiendo preguntas técnicas. Un contexto de talla única produce resultados mediocres para todos los casos.

4. Sin medición. Si no instrumentas lo que el modelo realmente atiende y usa, estás adivinando. Agrega logging que rastree qué documentos recuperados se referencian en los outputs, qué herramientas se llaman y qué instrucciones se siguen.

5. Tratar el contexto como un prompt. El contexto es infraestructura. Necesita versionado, testing, monitoreo, capacidad de rollback y un responsable. Si tu contexto vive en un string literal dentro de una función y nadie revisa los cambios, tendrás incidentes de producción.

Puntos clave

• Context engineering estructura el entorno de información completo en el que opera una IA, no solo el texto del prompt.
• Reestructurar el contexto sin cambiar los prompts elevó la precisión del 71% al 93% en las herramientas de IA en producción de Shopify.
• Un contexto bien diseñado tiene cinco capas: identidad, conocimiento, herramientas, memoria y estructura de salida.
• Trata el contexto como infraestructura de producción que necesita versionado, testing, monitoreo y capacidad de rollback.
• Los ingenieros que entregan features de IA confiables se enfocan en la arquitectura de contexto, no en la iteración de prompts.

FAQ

¿Cuál es la diferencia entre context engineering y prompt engineering?

El prompt engineering se enfoca en elaborar el texto de una sola consulta para obtener mejores respuestas de un modelo. Context engineering es más amplio: abarca el entorno de información completo dentro del cual opera el modelo, incluyendo instrucciones del sistema, definiciones de herramientas, documentos recuperados, historial de conversación y estructura de salida. El prompt engineering es un input. Context engineering es todo el sistema.

¿Necesito saber context engineering si no estoy construyendo productos de IA?

Sí, si usas herramientas de desarrollo con IA. Cada ingeniero usando Cursor, Claude Code, GitHub Copilot o herramientas similares se beneficia del context engineering. Cómo estructuras tu codebase, escribes documentación y configuras las herramientas afecta directamente la calidad de la asistencia de IA que recibes. Los ingenieros que obtienen ganancias de productividad de 10x han diseñado su contexto, no solo sus prompts.

¿Cómo mido si mi context engineering está funcionando?

Tres métricas importan: tasa de completación de tareas (¿el agente termina lo que empieza?), adherencia a instrucciones (¿sigue las restricciones que estableciste?) y utilización de relevancia (¿usa la información que proporcionas?). Rastrea estas a través de cambios de contexto para entender qué mejoras realmente mueven la aguja.

¿Qué herramientas debería usar para context engineering?

Las herramientas son menos importantes que la práctica. Dicho esto, control de versiones (git) para definiciones de contexto, frameworks de evaluación (como los de Anthropic o las herramientas de eval de OpenAI) para medir calidad, y plataformas de observabilidad (como LangSmith o Helicone) para monitoreo en producción forman una base sólida. La clave es tratar el contexto como código que se revisa, testea y monitorea.

¿El context engineering solo es relevante para sistemas basados en LLM?

Los principios aplican donde sea que un sistema de IA necesite input estructurado para producir output confiable. Pero las técnicas específicas (presupuesto de tokens, optimización de posición, resumen progresivo) son más directamente aplicables a modelos de lenguaje basados en transformers con ventanas de contexto finitas. A medida que las ventanas de contexto crezcan y las arquitecturas evolucionen, los detalles cambiarán. La disciplina de diseñar entornos de información no.

El futuro tiene forma de contexto

El prompt engineering era un juego de un solo jugador. Escribe un mejor prompt, obtén una mejor respuesta. Context engineering es un deporte de equipo. Toca diseño de producto (¿qué información necesita proporcionar el usuario?), ingeniería backend (¿cómo recuperamos y estructuramos el conocimiento?), ingeniería de datos (¿cómo mantenemos el contexto actualizado?) e ingeniería frontend (¿cómo presentamos interacciones multi-paso con agentes?).

Esta es la razón por la cual el product engineer está posicionado de forma única para ser responsable de esto. No el ingeniero de ML que optimiza modelos. No el data scientist que construye evaluaciones. La persona que entiende el sistema completo, desde la intención del usuario hasta el feature entregado, y puede tomar las decisiones arquitectónicas que determinan si un feature de IA funciona en producción o se desmorona ante el primer caso extremo.

El contexto es el nuevo código. Diséñalo en consecuencia.

Lectura relacionada

• ¿Qué Es un Product Engineer? La Guía Definitiva
• Harness Engineering: Construyendo Infraestructura para Agentes de IA
• Ingeniería Agéntica: Cómo los Product Engineers Construyen con IA
• Desarrollo Dirigido por Specs para Product Engineers
• No Construyas Agentes, Construye Skills