Si llevas un tiempo trabajando con Claude Code, Cursor o cualquier herramienta de desarrollo asistido por IA y tienes un CLAUDE.md con las reglas de tu proyecto, escribes especificaciones antes de darle trabajo a un agente y usas sesiones compartidas para sincronizar el contexto entre agentes especializados — ya estás haciendo Context Engineering. Solo que probablemente no lo llamabas así.
El término lo acuñó Tobi Lütke, CEO de Shopify, en una nota interna que se filtró a principios de 2025. Andrej Karpathy — ex director de IA en OpenAI y Tesla, y uno de los investigadores que popularizó el backpropagation moderno — lo amplió técnicamente: “Context Engineering es tanto ciencia como arte. Exige una guía intuitiva alrededor de la psicología de los LLMs.” Simon Willison lo explicó de forma más directa: el problema con “prompt engineering” no era el concepto en sí, sino que la gente lo interpretó como “escribir mejores prompts en un chat” cuando el problema real es el sistema completo de información que recibe el modelo.
Yo llegué a esto por el camino inverso: primero construí el sistema en producción — CLAUDE.md de 200+ líneas, issue_specs con criterios de aceptación, sesiones compartidas entre agentes, worktrees como aislamiento de contexto — y solo después encontré el nombre. Este artículo documenta ese sistema y explica por qué Context Engineering es el concepto que da coherencia a todo lo que has leído en el Lab sobre BMAD, SDD y workflows con agentes.
Qué es Context Engineering
Context Engineering es la disciplina de diseñar y gestionar toda la información que recibe un modelo de lenguaje — instrucciones, estado del proyecto, herramientas disponibles, historial de decisiones e información recuperada de fuentes externas — para maximizar la calidad, consistencia y predecibilidad de sus outputs.
No es una técnica puntual. Es una disciplina de ingeniería aplicada al sistema completo de información que procesa un LLM antes de generar cada respuesta.
La definición técnica
Un LLM opera exclusivamente sobre lo que está presente en su ventana de contexto en el momento de la inferencia. No tiene memoria persistente entre sesiones por defecto. No tiene acceso a tu base de código a menos que se lo des explícitamente. No sabe en qué estado está tu proyecto a menos que se lo expliques. La ventana de contexto es el único entorno en el que el modelo existe — y ese entorno es finito, mutable y se degrada si no se gestiona.
Context Engineering es la práctica de diseñar ese entorno de forma sistemática: qué información entra, en qué formato, en qué orden, con qué nivel de detalle y con qué mecanismos de actualización. El contexto no es un prompt largo. Es un sistema con arquitectura.
Quién lo definió y por qué el nombre importa
Tobi Lütke fue el primero en usar el término públicamente, y su framing fue empresarial: los equipos que saben construir contexto rico para sus agentes de IA son los que obtienen resultados consistentes. Karpathy añadió la dimensión técnica y psicológica: el modelo responde a los patrones del contexto de formas que no son siempre intuitivas, y diseñar bien ese contexto requiere entender cómo “piensa” el modelo.
El cambio de nombre importa porque arrastra un cambio de solución. Si el problema es “prompt”, la solución es “escribir mejor el prompt”. Si el problema es “context”, la solución es “diseñar mejor el sistema”. Son dos disciplinas con herramientas, criterios de calidad y umbrales de complejidad completamente distintos.
Del prompt al sistema: el cambio de paradigma
El prompt engineering se centra en el string: la instrucción textual que mandas al modelo en una sola llamada. Es estático, escrito manualmente, pensado para una tarea puntual. Funciona bien para tareas simples y conversacionales. Se rompe en cuanto el proyecto escala.
El Context Engineering trata el contexto como un sistema dinámico que se ensambla antes de cada llamada al modelo, adaptado a la tarea específica, con múltiples fuentes de información. Philschmid (Hugging Face) lo resume bien: “A System, Not a String.”
El momento de quiebre es claro: cuando el proyecto tiene más historia, más dependencias y más convenciones de las que caben cómodamente en un system prompt, el prompt engineering colapsa. Cualquier desarrollador que haya visto a un agente “olvidar” las convenciones del proyecto a mitad de una sesión larga sabe exactamente de qué hablo. Una consecuencia directa de esto es el desarrollo dirigido por especificaciones: una metodología que surgió precisamente para dar estructura al contexto que un agente necesita antes de empezar a trabajar.
Para quienes toman decisiones en empresas: esto explica por qué muchos proyectos de IA “funcionan en demo y fallan en producción”. El demo tiene contexto controlado — el desarrollador lo prepara todo —, producción no. La diferencia no es el modelo, es el contexto.
| Prompt Engineering | Context Engineering | |
|---|---|---|
| Alcance | Una llamada al modelo | El sistema completo de información |
| Naturaleza | Estático, escrito manualmente | Dinámico, ensamblado en tiempo de ejecución |
| Escala | Chat, tareas simples | Agentes, flujos multi-step, proyectos largos |
| Artefactos | Prompt template | CLAUDE.md, specs, RAG, MCPs, hooks |
| Predecibilidad | Variable | Alta (con sistema bien diseñado) |
| Quién lo necesita | Cualquiera que use un LLM | Desarrolladores con proyectos en producción |
Los componentes del contexto en un sistema real
Mi sistema de Context Engineering en producción tiene cinco componentes. No son teóricos — son los archivos y mecanismos que uso en cada proyecto activo.
Instrucciones persistentes: el contrato de comportamiento
El CLAUDE.md es el artefacto más importante del sistema. Define el comportamiento base del agente, las convenciones del proyecto, el stack técnico, cómo debe comunicarse con otros agentes y qué herramientas tiene permitido usar. No es un prompt largo — es un documento vivo que crece con el proyecto y persiste entre sesiones.
El CLAUDE.md de este workspace tiene más de 200 líneas activas. No es boilerplate: documenta decisiones reales de arquitectura, convenciones de commits, rutas de directorios, reglas de comportamiento de agentes especializados y restricciones explícitas. Cuando un agente nuevo empieza a trabajar, ese archivo es su primer input.
Estado del proyecto: specs como contexto estructurado
El issue_spec es un contrato de contexto para una tarea concreta: qué debe hacer el agente, cómo debe hacerlo, cuáles son los criterios de aceptación, qué restricciones aplican. Lo que se documenta en Spec-Driven Development con Claude Code es exactamente esto: reemplazar instrucciones verbales por especificaciones explícitas.
El agente no “interpreta” — ejecuta contra una especificación. El review_spec verifica que el output se ajusta al contexto dado. Son dos artefactos distintos con funciones de Context Engineering distintas: uno define el contexto de entrada, el otro verifica la fidelidad al contexto.
Por qué esto no es burocracia: escribir specs es Context Engineering en acción. Cada spec reduce la ambigüedad del contexto que recibe el agente, lo que reduce directamente los ciclos de corrección.
Herramientas y datos externos: MCPs como contexto en tiempo real
Los MCPs (Model Context Protocol) son la capa de contexto dinámico del sistema. En lugar de que el agente asuma el estado del mundo — lo que lleva a alucinaciones sobre el estado del repositorio, las métricas actuales o la documentación de una librería —, el agente lo consulta en tiempo real.
En mi workflow con Claude Code, agentes y worktrees, el agente de SEO consulta Google Search Console via MCP para tener datos de posicionamiento reales, no estimaciones. El agente de desarrollo consulta la documentación actualizada de la librería via context7 MCP, no la versión del training data. La diferencia entre un agente con MCPs y uno sin ellos es la diferencia entre trabajar con datos y trabajar con suposiciones.
Historial y memoria entre sesiones: sincronización inter-agente
Los archivos de sesión (.claude/sessions/) son el protocolo de sincronización de contexto entre agentes especializados. Cada agente — strategist, copywriter, implementer, reviewer — trabaja en fases distintas del mismo proyecto. Sin un mecanismo de sincronización de contexto, cada agente empieza de cero y pierde el contexto que construyó el agente anterior.
El protocolo es simple: cada agente lee el documento completo antes de empezar, y completa su sección antes de pasar el trabajo al siguiente. No es una convención de organización — es Context Engineering aplicado a la coordinación multi-agente. La memory MCP añade una capa adicional: un grafo de conocimiento persistente que sobrevive entre sesiones y proyectos.
Aislamiento de contexto: worktrees como contexto por tarea
Git worktrees son mecanismos de aislamiento de contexto por feature. Cada tarea activa tiene su propio directorio de trabajo, su propia rama y su propio estado del repositorio. El agente que trabaja en la feature A no puede contaminar el contexto de la feature B con cambios no relacionados.
Los hooks son los guardrails del sistema: cuando un agente intenta editar un archivo fuera de su worktree asignado, el hook lo detiene antes de que ocurra. No es solo una regla de seguridad — es una regla de Context Engineering que garantiza que cada agente opera con el contexto que le corresponde.
Por qué el contexto corrupto es el mayor enemigo de la IA en producción
Los artículos sobre Context Engineering explican qué poner en el contexto. Casi ninguno explica qué pasa cuando el contexto se degrada.
En sesiones largas, el LLM acumula tokens. Conforme la sesión crece, el modelo da más peso a la información más reciente y menos a las instrucciones iniciales. Las convenciones del proyecto que estaban en el CLAUDE.md empiezan a perderse. Los criterios de aceptación de la spec quedan enterrados bajo 40 mensajes de ida y vuelta. El agente sigue funcionando, pero empieza a producir outputs que se desvían del estándar del proyecto.
Esto es contexto corrupto. No es un fallo del modelo — es una consecuencia inevitable de la ventana de contexto finita mal gestionada.
En mi workflow, el límite de 3 ciclos de QA por sesión no es arbitrario: es Context Engineering preventivo. Después de 3 ciclos, la calidad de las respuestas empieza a degradarse de forma predecible. La solución no es pedir al agente que “recuerde” las instrucciones — es hacer un reset limpio cargando una spec bien estructurada en lugar de un historial de 30 mensajes.
El vibe coding es el caso extremo de contexto cero: instrucciones verbales, sin specs, sin CLAUDE.md, sin historial estructurado. Funciona para tareas simples de una sola sesión. Colapsa en proyectos complejos porque el contexto se pierde en el momento en que cierras la sesión.
La implicación para empresas es directa: el coste del contexto corrupto en producción es rework, bugs y tiempo del equipo corrigiendo lo que “el agente entendió mal”. No es un problema de la IA — es un problema de gestión del contexto.
Context Engineering en la práctica: el stack completo
El ciclo completo en mi workflow es: CLAUDE.md → issue_spec → agente especializado con worktree aislado → MCPs en tiempo real → review_spec → sesión actualizada para el siguiente agente.
Cada elemento de ese ciclo corresponde a un componente de Context Engineering:
| Artefacto | Componente CE | Propósito |
|---|---|---|
| CLAUDE.md | Instrucciones persistentes | Define comportamiento base y convenciones del proyecto |
| issue_spec | Estado de tarea | Contrato explícito sobre qué debe hacer el agente |
| review_spec | Verificación | Comprueba que el output se ajusta al contexto dado |
| session file | Historial inter-agente | Sincroniza contexto entre agentes especializados |
| MCPs | Datos externos | Grounding en tiempo real — el agente consulta, no asume |
| worktree | Aislamiento | Un contexto limpio y dedicado por feature |
| hooks | Guardrails | Protección contra contaminación de contexto cruzado |
Este no es el único sistema posible. El BMAD Method vs workflow de agentes tiene su propia arquitectura de Context Engineering con roles especializados y artefactos distintos. Kiro (AWS) implementa steering files y specs con el mismo objetivo. El principio es universal. El stack varía según las herramientas y el equipo.
Para CTOs y directivos: qué significa Context Engineering para tu empresa
Si tu empresa ha probado herramientas de IA y los resultados fueron inconsistentes — a veces bien, a veces mal, sin saber exactamente por qué — lo más probable es que el problema no fuera el modelo. Era el contexto.
Los LLMs no fallan de forma aleatoria. Fallan de forma predecible cuando el contexto es insuficiente, ambiguo o corrupto. Context Engineering es la disciplina que convierte esa impredecibilidad en predecibilidad.
Tres beneficios concretos para equipos que adoptan Context Engineering:
- Reducción de rework. Un agente con contexto bien diseñado necesita menos ciclos de corrección. Cada ciclo adicional tiene coste en tiempo de desarrollo y en coste de API. Con specs explícitas y CLAUDE.md bien estructurado, el primer output se ajusta al estándar del proyecto con mucha más frecuencia.
- Auditoría de decisiones. Cuando el contexto está documentado — specs, CLAUDE.md, session files —, puedes revisar por qué el agente tomó una decisión. El proceso deja de ser una caja negra. Esto es especialmente relevante en sectores con requisitos de compliance o cuando necesitas explicar decisiones técnicas a stakeholders no técnicos.
- Escalabilidad del equipo. El contexto bien diseñado permite que cualquier desarrollador — o agente nuevo — retome el trabajo con el mismo nivel de comprensión que quien lo empezó. La documentación del contexto no es overhead: es el mecanismo que hace el conocimiento del equipo transferible.
La pregunta relevante para tu empresa no es “¿usamos IA?” sino “¿gestionamos el contexto de nuestra IA?”. La diferencia entre los dos escenarios se mide en tiempo de equipo y en calidad de output.
Si quieres explorar cómo implementar Context Engineering en tu empresa o en tu equipo de desarrollo, hablemos de tu proyecto.
