Context Engineering: qué es y cómo aplicarlo en código con IA
Tabla de contenidos
Cuanto mejor se vuelve el modelo, menos importa el modelo.
Lo que cambia tus resultados hoy entre un agente que improvisa y uno que ejecuta con criterio no es GPT-4o vs Claude Fable 5. Es lo que tienen delante antes de empezar: las convenciones del proyecto, el flujo de trabajo del equipo, las restricciones que no se pueden saltar.
Eso tiene nombre: Context Engineering. Y en 2026 sigue siendo la skill más ignorada entre los developers que ya usan IA a diario, no porque sea difícil, sino porque casi todo el contenido que existe la explica desde el mundo enterprise. Este artículo va al único sitio donde importa: tu flujo de trabajo.
¿Qué es Context Engineering?
Context Engineering es la disciplina de diseñar y gestionar toda la información que un sistema de IA recibe antes de generar una respuesta. No es solo el prompt. Es todo lo que rodea al prompt: las instrucciones del sistema, la memoria del proyecto, los documentos relevantes, las herramientas disponibles y el estado de la sesión.
Andrej Karpathy y Tobi Lütke (CEO de Shopify) lo hicieron viral en X/Twitter:
Está claro que los modelos de IA no leen mentes (o por lo menos, no de momento); predicen el siguiente token basándose exclusivamente en lo que tienen disponible en su ventana de contexto. Si lo que tienen es un prompt suelto, improvisarán. Si lo que tienen es el contexto completo — especificaciones del sistema, flujo de trabajo, historial relevante — ejecutarán.
Context Engineering vs Prompt Engineering: no son lo mismo
La mayoría de developers que llevan tiempo usando IA han hecho Prompt Engineering sin saberlo. Es decir, ajustar la instrucción hasta que el modelo da el output correcto. Es útil, pero tiene un techo.
| Dimensión | Prompt Engineering | Context Engineering |
|---|---|---|
| Alcance | Una instrucción específica | Todo el ecosistema de información del agente |
| Naturaleza | Estático (se escribe antes) | Dinámico (se gestiona durante la sesión) |
| Escalabilidad | Funciona bien para tareas simples | Necesario para tareas complejas y sistemas reales |
| Dónde vive | En el chat o en el código | En archivos de configuración, repos, herramientas conectadas |
| Quién lo mantiene | Cualquiera | El developer responsable del contexto del proyecto |
El diagnóstico más habitual cuando la IA «falla» en algo complejo: no es el prompt, es el contexto. Si tu agente genera código que no encaja con las convenciones del equipo, toma decisiones de arquitectura que ya descartaste o ignora el stack que estás usando, el problema de base es que al agente le falta información.
Grábatelo a fuego: un copiloto sin contexto configurado es como un junior que llega su primer día sin haber pasado onboarding. Sabe programar, pero no sabe cómo trabaja tu equipo. Un copiloto bien configurado es como un senior que ya ha pasado ese onboarding antes de escribir la primera línea.
Las 3 capas del Context Engineering
Son tres capas que el developer puede definir, curar y versionar de forma independiente.
1. Especificaciones técnicas — lo que el agente necesita saber sobre cómo está construido el sistema:
- Stack tecnológico y setup del entorno de desarrollo.
- Arquitectura y estructura de ficheros del proyecto.
- Entidades del modelo de datos.
- Patrones de diseño y convenciones: naming, git workflow, estructura de tests, gestión de errores, logging, documentación.
Esta es la capa más estable que define las reglas del proyecto y rara vez cambia. En la práctica vive en ficheros como testing-standards.mdc, frontend-standards.mdc o data-model.mdc, todos referenciados desde un archivo base.
2. Flujo de trabajo — cómo trabaja el equipo desde que llega una petición hasta que el código está en producción:
- Qué proceso sucede de manera sistemática.
- Quién interviene y cuál es su entregable.
- Qué define a cada entregable para ser considerado excelente: una PRD, historia de usuario, ticket técnico, código, tests, documentación.
Si el agente no entiende el proceso del equipo, genera código técnicamente correcto, pero que no encaja en el flujo del proyecto. Un agente que no sabe que antes del código va una spec no va a pedirla.
3. Contexto compartido y actualizado — el salto de productividad individual a estándar de equipo:
- Consistencia: todos trabajan con las mismas reglas, no cada uno con su propio setup.
- Coherencia: el contexto refleja cómo trabaja el equipo realmente, no como se supone que trabaja.
- Independencia del prompt: el resultado no depende de que alguien escriba el prompt perfecto.
- Independencia del seniority: un junior con el contexto correcto produce outputs más predecibles que un senior sin él.
La diferencia entre tener contexto y tener un buen sistema de contexto está en esta tercera capa. No basta con que exista, tiene que estar compartido, versionado y actualizado.
Context Engineering aplicado al código
Las 3 capas son archivos en tu repositorio.
El CLAUDE.md es donde defines las especificaciones técnicas y el flujo de trabajo para Claude Code. Un ejemplo mínimo:
# Especificaciones técnicas
Stack: TypeScript + Node.js + PostgreSQL
Framework: NestJS (módulos domain-driven)
Tests: Jest, cobertura mínima 80%
# Convenciones
- PascalCase para clases, camelCase para variables
- Commits en inglés, formato conventional commits
- Sin comentarios inline salvo lógica no obvia
# Restricciones
- No modificar el esquema de base de datos sin migración
- No instalar dependencias sin aprobación en PR
El .cursorrules es el equivalente en Cursor. El AGENTS.md cubre el flujo de trabajo para sistemas multiagente. Y los MCPs conectados añaden la capa del flujo de trabajo en tiempo real: un equipo con Claude Code + MCP de GitHub + MCP de Jira tiene un agente que conoce las issues abiertas, el historial de PRs y las convenciones del repo (todo ello antes de escribir la primera línea de código).
Si quieres una base de referencia ya estructurada con las tres capas, el equipo de LIDR mantiene lidr-specboot en GitHub (https://github.com/LIDR-academy/lidr-specboot): ficheros de configuración, reglas de desarrollo y estándares listos para importar en cualquier proyecto.
Desarrollo de software en equipo: del caos individual al estándar compartido con IA
El problema más costoso del context engineering es organizativo.
En la mayoría de equipos que llevan meses con Claude Code, Cursor o Copilot, cada developer ha construido su propio contexto de forma independiente. Uno tiene un CLAUDE.md detallado. Otro tiene uno genérico. El tercero no tiene ninguno. El resultado: el mismo agente, el mismo modelo, outputs completamente distintos según quién lo use.
El informe DORA 2025 de Google (casi 5.000 profesionales, septiembre 2025) lo resume en una frase: «la IA amplifica lo que ya hay».
Los equipos fuertes mejoran con IA; los equipos con problemas los ven amplificados. El factor que separa a unos de otros es la claridad en los flujos de trabajo y la alineación del equipo. Un developer individual quizás se siente más productivo mientras el equipo en conjunto rinde peor.
Así pues las especificaciones técnicas y el flujo de trabajo deben vivir en el repositorio compartido, no en el entorno local de cada developer. Cuando las tres capas están versionadas en git, todos trabajan con la misma base. El resultado deja de depender de quién configuró el agente.
Errores comunes al aplicar Context Engineering
- Confundir la primera con la tercera capa. Muchos developers crean especificaciones técnicas (capa 1) pero nunca llegan a compartirlas ni versionarlas (capa 3). Un buen CLAUDE.md en local que no está en el repo no es un estándar de equipo.
- Olvidar el flujo de trabajo (capa 2). La mayoría de los ficheros de contexto describen cómo está construido el sistema, pero no cómo trabaja el equipo. Un agente que no sabe que existe un proceso de revisión humana tomará atajos que nadie le autorizó.
- Context overload. Llenar el contexto con todo lo que existe en el proyecto. El fenómeno lost in the middle (Liu et al., 2024 — Stanford/UC Berkeley) describe cómo los modelos pierden precisión cuando la información crítica está enterrada entre ruido: la precisión cae más del 30% cuando la información relevante aparece en el centro del contexto en lugar de al inicio o al final.
- Context staleness. Contexto desactualizado. Si el CLAUDE.md describe una arquitectura que ya no existe, el agente trabaja contra decisiones que ya se descartaron. El contexto envejece como el código y no mejora como el vino 😉 . Hay que mantenerlo.
- No versionar el contexto. Si los ficheros de contexto no están en git, no son un estándar de equipo. Y no puedes hacer debugging de comportamientos inesperados del agente si no sabes qué contexto tenía cuando lo generó.
En definitiva, Context Engineering es el nombre de algo que la mayoría hace mal sin saberlo. Cada vez que la IA ha fallado en algo complejo — generando código que no encaja, tomando decisiones que ya descartaste, ignorando las convenciones del equipo — ahora ya lo sabes, el problema era el contexto.
¿Quieres aprender cómo aplicar context engineering en tus propios proyectos? Apúntate al Máster AI4Devs, las inscripciones para la próxima edición ya están abiertas.