Context Engineering: La Habilidad que Reemplazó al Prompt Engineering en 2026

Andrej Karpathy lo dijo claramente: «Prompt engineering» es un término engañoso. Implica que el arte de trabajar con modelos de lenguaje consiste en redactar instrucciones cuidadosamente — escribir la frase mágica que desbloquea el resultado correcto. Ese marco siempre subestimó el trabajo real, y en 2026 ya no describe lo que los equipos de IA serios están haciendo realmente.

Lo que están haciendo es context engineering: la práctica deliberada y sistemática de construir la información correcta en el momento correcto en el formato correcto para ocupar la ventana de contexto de un LLM durante la inferencia. Es parte recuperación, parte gestión de memoria, parte diseño de sistemas y parte UX. No es un prompt. Y los equipos que lo tratan como tal están dejando la mayor parte de la capacidad de su modelo sin aprovechar.

Por qué «Prompt Engineering» Siempre Fue el Marco Equivocado

La frase «prompt engineering» vino de las intuiciones de la era GPT-3: los modelos eran opacos, la formulación correcta desbloqueaba capacidades ocultas, y la habilidad era esencialmente incantantoria. El modelo funcionaba si escribías el encantamiento correctamente.

Ese modelo mental se rompió por tres razones:

1. Las ventanas de contexto se expandieron. Cuando los modelos tenían 4K tokens, los prompts eran cortos. Con 128K, 200K y 1M+ tokens, lo que pones en la ventana es un problema de diseño de sistemas, no de redacción.
2. Los sistemas se volvieron dinámicos. Las aplicaciones de IA modernas no usan un prompt estático. Recuperan documentos, llaman herramientas, mantienen memoria entre sesiones y procesan resultados intermedios. El «prompt» se ensambla en tiempo de ejecución desde muchas fuentes.
3. La señal se movió. Empíricamente, las mayores brechas de rendimiento entre equipos provienen de la calidad del contexto, no de la redacción del prompt. El mismo modelo con mejor contexto supera consistentemente a un modelo más grande con contexto deficiente.

Las Seis Capas del Contexto

El context engineering significa pensar deliberadamente sobre seis componentes distintos que pueden ocupar la ventana de contexto de un modelo durante la inferencia:

• Capa 1 — Prompt del sistema e instrucciones. Definición de rol, restricciones de tareas, especificación de formato de salida, esquemas de herramientas. Esto es fijo y relativamente pequeño — típicamente 5–10% del presupuesto.
• Capa 2 — Ejemplos few-shot. Demostraciones de entrada/salida que anclan el formato, el tono y el manejo de casos extremos. Los buenos few-shots hacen trabajo más confiable que los párrafos de instrucciones elaboradas.
• Capa 3 — Memoria de trabajo / Estado. El borrador del agente: razonamiento intermedio, progreso de la tarea, esquema de salida estructurada. Esta capa crece durante una tarea y necesita gestión activa.
• Capa 4 — Documentos recuperados (RAG). Conocimiento externo obtenido en tiempo de inferencia: resultados de búsqueda vectorial, consultas de bases de datos, fragmentos de código base, datos en tiempo real.
• Capa 5 — Resultados de herramientas y acciones. La salida de llamadas a API, ejecución de código, búsqueda y otras invocaciones de herramientas. Estos suelen ser verbosos y necesitan truncamiento o resumen.
• Capa 6 — Historial de conversación. Turnos anteriores, memoria resumida y preferencias de usuario persistidas. Las conversaciones largas requieren estrategias de compresión.

La idea clave: un «prompt» es la capa 1 en el mejor de los casos. El context engineering es la práctica de gestionar las seis capas simultáneamente dentro de un presupuesto de tokens finito.

La Calidad del Contexto Supera el Tamaño del Modelo

El hallazgo más práctico en la literatura de context engineering es también el más contraintuitivo: un modelo más pequeño con contexto bien diseñado supera rutinariamente a un modelo más grande con contexto deficiente.

Esto se ha demostrado en múltiples benchmarks. En tareas de generación de código, GPT-4o con few-shots cuidadosamente curados y contexto relevante del código base supera a o3 dado un prompt de sistema genérico. En implementaciones RAG empresariales, cambiar del retrieval naivo de documentos completos al chunking semántico con re-ranking produce mayores ganancias de precisión que actualizar el modelo.

«Pasamos tres meses probando diferentes modelos. Un sprint en calidad del contexto nos dio las mismas ganancias que habíamos estado persiguiendo durante un trimestre.» — Desarrollador en Hacker News

El Presupuesto de Contexto: Tratar los Tokens como un Recurso Finito

El cambio de modelo mental más útil en el context engineering es tratar los tokens como un presupuesto. La ventana de contexto es un recurso escaso. Todo lo que entra desplaza a algo más.

Técnicas de gestión del presupuesto que aparecen repetidamente en sistemas de producción:

Recuperación por niveles

No recuperar documentos completos. Usar una pipeline de dos etapas: un modelo de recuperación rápido y barato selecciona candidatos; un re-ranker de codificación cruzada selecciona los pasajes de mayor relevancia. Un resultado top-5 re-rankeado típicamente contiene más señal que un retrieval naivo top-20, con una fracción del costo de tokens.

Resumen progresivo

El historial de conversación y el estado intermedio crecen sin límite si no se gestionan. El patrón de producción es resumir después de un umbral — típicamente después de cada N turnos o cuando el historial supera X tokens.

Few-shots dinámicos

Si tiene una biblioteca de 200 ejemplos, recupere los 3–5 más semánticamente similares al input actual. Esta técnica — selección de few-shots aumentada por recuperación — es una de las optimizaciones de contexto de mayor impacto.

El Problema de la Calidad del Retrieval

RAG es donde falla la mayor parte del context engineering en producción. Modos de fallo comunes:

Errores en los límites de los chunks

El chunking de tamaño fijo a menudo divide pasajes semánticamente coherentes entre chunks, devolviendo respuestas a medias. El chunking consciente del documento supera consistentemente al chunking de tamaño fijo.

Contexto faltante para chunks recuperados

La técnica «Contextual Retrieval» de Anthropic antepone un resumen de contexto específico del chunk a cada chunk en el momento de la indexación. En sus benchmarks, esto redujo los fallos de retrieval en un 49% combinado con re-ranking.

Desajuste consulta-documento

HyDE (Hypothetical Document Embeddings) aborda esto generando una respuesta hipotética a la consulta y embebiendo eso, en lugar de embeber la consulta en bruto.

Qué Construir Primero

1. Auditar la pipeline de retrieval. Cambiar de chunks de tamaño fijo a chunks semánticos o conscientes del documento. Agregar un paso de re-ranking.
2. Implementar el resumen de conversación. Limitar el historial de conversación a un límite de tokens y resumir cuando se supere.
3. Agregar recuperación de few-shots dinámica. Construir una pequeña biblioteca de ejemplos de alta calidad. En el momento de la inferencia, recuperar los top-3 más similares al input actual.
4. Externalizar el estado del agente. Si está construyendo sistemas multi-agente, mover el estado intermedio a stores externos estructurados desde el principio.
5. Instrumentar la calidad del contexto. Agregar registro para ventanas de contexto y resultados.

El Punto Más Profundo

El context engineering no es una técnica. Es un cambio de perspectiva: de tratar los modelos de lenguaje como generadores de texto que responden a instrucciones, a tratarlos como motores de inferencia cuyo rendimiento está limitado por la calidad de la información que les proporciona en tiempo de ejecución.

La brecha entre lo que los equipos están logrando y lo que es posible es casi siempre una brecha de contexto. Esa brecha es un problema de ingeniería. Y como todos los problemas de ingeniería, responde a la inversión sistemática.

El hechizo nunca fueron las palabras. Siempre fue la información detrás de ellas.