Context Engineering: proyectos con IA sin perder el hilo
DominicodeLa primera vez que me pasó, pensé que era un fallo del modelo.
Llevaba tres días construyendo una API con Claude Code. Arquitectura decidida, endpoints definidos, estructura de carpetas lista. Todo tenía sentido. Abrí una sesión nueva al cuarto día y le pedí que añadiera autenticación al módulo de usuarios.
Me devolvió código que contradecía las decisiones que habíamos tomado el día anterior. Naming diferente. Patrón de errores distinto. Como si hubiera arrancado desde cero.
No era un fallo del modelo. Era un fallo mío. No le había dado context engineering. Le había dado prompts.
Lo que me faltaba tiene nombre. Y no es lo mismo que prompt engineering.
El problema real: el modelo no sabe qué decidiste ayer
Los LLMs no tienen memoria entre sesiones. Cada conversación nueva es, literalmente, una pizarra en blanco.
Dentro de una misma sesión tienen una ventana de contexto — los modelos actuales manejan ventanas de entre 128k tokens (GPT-4o) y 200k tokens (Claude 3.5/3.7), cifras de junio 2026 que seguirán creciendo — pero esa ventana se llena. Y cuando se llena, el modelo empieza a “olvidar” las partes más antiguas de la conversación. Las decisiones de arquitectura que tomaste al principio. Las convenciones de naming que acordaste. El motivo por el que descartaste la opción B.
El resultado es predecible: inconsistencia. Código que contradice decisiones previas. Respuestas que suenan razonables pero no encajan con el proyecto real. Y tú volviendo a explicar, sesión tras sesión, qué estás construyendo y cómo.
Cualquier developer que haya usado IA durante más de dos semanas en un proyecto real lo ha vivido. La inconsistencia entre sesiones es la fricción número uno.
Context engineering no es prompt engineering
Mucha gente confunde los dos. No son lo mismo.
Prompt engineering trata una sola interacción. Cómo formular la pregunta. Qué ejemplos incluir. Qué rol asignarle al modelo. Es útil, pero es táctica de un solo turno.
Context engineering es la disciplina de estructurar y gestionar toda la información que recibe el modelo para que produzca resultados consistentes a lo largo de un proyecto completo. No en un prompt. En semanas de trabajo.
La diferencia es la misma que hay entre saber hacer una buena pregunta en una entrevista y saber gestionar a un equipo durante un sprint.
| Prompt Engineering | Context Engineering | |
|---|---|---|
| Alcance | Un turno de conversación | Un proyecto completo |
| Problema que resuelve | Calidad de una respuesta | Consistencia entre sesiones |
| Habilidad principal | Redactar instrucciones claras | Diseñar sistemas de información |
| Cuándo falla | Respuesta ambigua o incorrecta | Proyecto incoherente en semana 3 |
| Herramienta clave | El prompt en sí | CLAUDE.md, specs, logs de decisiones |
Puedes ser un maestro del prompt engineering y aun así tener un proyecto que se rompe cada semana. El context engineering es lo que lo sostiene.
Las 4 técnicas que uso en producción
1. CLAUDE.md / AGENTS.md — la memoria persistente del proyecto
Este es el punto de partida. Un archivo en la raíz del proyecto que le dice al modelo, al inicio de cada sesión, quién eres, qué estás construyendo y cómo trabajas.
No es un README. Es un system prompt que el modelo lee antes de hacer nada.
Lo mínimo que debe tener:
- Descripción del proyecto en 2-3 líneas (qué es, para quién)
- Stack técnico con versiones concretas
- Convenciones de código que no se negocian
- Lo que NO debe hacer el modelo (igual de importante)
- Estado actual del proyecto — en qué fase estás
Un ejemplo mínimo que uso en proyectos reales:
# CLAUDE.md — API de Usuarios
## Proyecto
API REST de gestión de usuarios para SaaS B2B.
Stack: NestJS 10 + PostgreSQL + Prisma 5.
## Convenciones
- Naming: camelCase para variables, PascalCase para clases, kebab-case para archivos
- Errores: siempre usar HttpException con código y mensaje estructurado
- No usar `any` en TypeScript — tipos explícitos o `unknown`
## NO hacer
- No generar migraciones de Prisma automáticamente — las revisamos manualmente
- No cambiar el schema sin actualizar architecture.md
## Estado actual
Fase 2 — módulo de autenticación JWT. Ver tasks.md para detalle.
Si usas Claude Code, este archivo es CLAUDE.md. Si usas Cursor o Windsurf, es __INLINE_PLACEHOLDER_0__ o __INLINE_PLACEHOLDER_1__ (__INLINE_PLACEHOLDER_2__ sigue siendo compatible pero es el formato legacy de Cursor). El nombre cambia. El concepto es el mismo.
Ya escribí un post completo sobre cómo estructurar este archivo: CLAUDE.md: el system prompt de tu proyecto con Claude Code. Si no lo has leído, empieza por ahí.
2. Archivos de estado — lo que el modelo no puede inferir
El CLAUDE.md da el contexto estático: qué es el proyecto y cómo funciona. Pero los proyectos evolucionan. Necesitas capturar el estado dinámico.
Yo mantengo tres archivos en cada proyecto:
__INLINE_PLACEHOLDER_3__ — lista de tareas con estado (pendiente / en progreso / hecho). Una línea por tarea, fecha de última actualización. El modelo la lee y sabe exactamente dónde estás.
__INLINE_PLACEHOLDER_4__ — log de decisiones arquitectónicas. Cada decisión con su fecha, la opción elegida y el motivo por el que se descartó la alternativa. Este archivo vale oro cuando vuelves a un proyecto tres semanas después.
__INLINE_PLACEHOLDER_5__ — snapshot de la arquitectura actual. No el diagrama ideal. El diagrama real, con los módulos que existen ahora mismo. El modelo lo usa para no proponer soluciones que contradigan lo ya construido.
Tres archivos. Ninguno supera las dos páginas. Pero juntos eliminan el 80% de la inconsistencia.
3. Chunking de tareas — no pidas todo en un prompt
Este error lo cometo yo también cuando tengo prisa.
“Implementa el sistema de autenticación completo con JWT, refresh tokens, roles y middleware de autorización.”
El modelo lo intenta. Genera código. Pero es código que asume cosas sobre tu proyecto que no conoce, o que contradice la arquitectura que ya tienes. Y cuando algo falla, el problema está distribuido en 400 líneas de código que no entiendes del todo.
La regla que aplico: una tarea por sesión, una función por tarea.
En lugar de pedir la autenticación completa, pido:
- Primero: el módulo de usuarios con su schema y validaciones
- Luego: la generación de JWT con los claims que necesito
- Luego: el endpoint de login que conecta ambos
- Luego: el middleware que verifica el token
Cuatro sesiones. Cuatro archivos de contexto actualizados al final de cada una. Un sistema que entiendo porque lo construí pieza a pieza.
El modelo produce mejor código cuando el scope es pequeño y el contexto es preciso. En la práctica, siempre.
4. Resúmenes de sesión — el handoff entre el tú de hoy y el tú de mañana
Al final de cada sesión de trabajo, antes de cerrar, escribo este prompt:
“Resume lo que hemos hecho en esta sesión en 5-7 puntos: qué se implementó, qué decisiones se tomaron, qué problemas encontramos y qué queda pendiente para la siguiente.”
Copio esa respuesta en un archivo __INLINE_PLACEHOLDER_6__ con la fecha.
Cuando vuelvo al proyecto al día siguiente, la primera cosa que hago es darle ese log al modelo junto con el CLAUDE.md. El modelo arranca con el contexto exacto de donde lo dejé. Sin tener que re-explicar. Sin inconsistencias.
Diez minutos al final de cada sesión que ahorran una hora al principio de la siguiente.
Ejemplo práctico: un proyecto de tres semanas sin perder el hilo
Semana 1 — Cimentar el contexto
Antes de escribir una línea de código, genero la spec del proyecto con Spec-Driven Development: visión, usuarios, funcionalidades, arquitectura. Ese documento se convierte en la base del CLAUDE.md.
Creo los tres archivos de estado vacíos: __INLINE_PLACEHOLDER_7__, __INLINE_PLACEHOLDER_8__, __INLINE_PLACEHOLDER_9__. El modelo los actualiza conforme avanzamos.
Semana 2 — Construcción en chunks
Cada sesión tiene una tarea concreta de __INLINE_PLACEHOLDER_10__. Arranca con el CLAUDE.md, el archivo de arquitectura y el log de la sesión anterior. Termina con el modelo actualizando el estado de la tarea y generando el resumen de sesión.
Semana 3 — Cuando todo se complica
En la semana 3 es cuando los proyectos sin sistema se rompen. El código empieza a contradecirse. Las decisiones del día 1 ya nadie las recuerda. Las nuevas funcionalidades no encajan con lo que ya existe.
Con context engineering, la semana 3 es igual de fluida que la semana 1. Porque el modelo tiene, en cada sesión, el mismo nivel de contexto que tenías tú el primer día. El __INLINE_PLACEHOLDER_11__ le dice por qué tomaste las decisiones que tomaste. El __INLINE_PLACEHOLDER_12__ le muestra la estructura real. El log de sesión le dice dónde lo dejaste.
No es magia. Es sistema.
Lo que cambia cuando aplicas esto
La diferencia no es velocidad. Es consistencia.
Un developer sin context engineering puede ir rápido la primera semana. Pero en la semana 3, la deuda de contexto empieza a pasarle factura. Cada sesión nueva cuesta más porque hay que re-explicar más. Cada funcionalidad nueva tiene más probabilidad de romperse con algo anterior.
Un developer con context engineering mantiene el mismo ritmo en la semana 8 que en la semana 1. Porque el contexto no es algo que se pierde — es algo que se gestiona.
Esta es exactamente la mentalidad que enseño en el curso Construye con IA: de la idea al producto con Claude Code. No “cómo usar Claude”. Cómo construir con sistema.
FAQ
¿El context engineering solo funciona con Claude Code?
No. Los principios aplican a cualquier LLM y cualquier herramienta — Cursor, Windsurf, ChatGPT, Gemini. El CLAUDE.md tiene su equivalente en cada entorno: __INLINE_PLACEHOLDER_13__, __INLINE_PLACEHOLDER_14__, un system prompt inicial. La técnica de chunking y los resúmenes de sesión son agnósticos al modelo.
¿Cuánto tiempo añade a mi flujo de trabajo?
En la práctica, entre 10 y 20 minutos al día. Cinco minutos actualizando el __INLINE_PLACEHOLDER_15__, diez minutos pidiendo y guardando el resumen de sesión. El retorno es que ahorras una o dos horas semanales de re-explicar contexto y corregir inconsistencias. La matemática es clara.
¿Necesito crear estos archivos manualmente desde cero?
Puedes empezar con plantillas. En el curso Construye con IA incluyo las plantillas exactas de CLAUDE.md, __INLINE_PLACEHOLDER_16__ y __INLINE_PLACEHOLDER_17__ que uso en mis proyectos reales. Y si quieres la metodología de especificación completa, el libro SDD cubre el proceso de principio a fin.
¿Context engineering resuelve el problema de la ventana de contexto?
Parcialmente. No puedes ampliar la ventana de contexto del modelo — eso lo determina el proveedor. Lo que puedes hacer es gestionar qué información entra en esa ventana en cada sesión. Context engineering te da control sobre eso: qué es esencial que el modelo sepa, qué puede inferir y qué no necesita en ese momento concreto. No elimina la limitación. La hace manejable.
¿Cuál es la diferencia entre context engineering y RAG?
RAG (Retrieval-Augmented Generation) es una arquitectura técnica para recuperar información de fuentes externas y añadirla al contexto del modelo en tiempo de ejecución. Context engineering es una disciplina de trabajo que aplicas como developer para gestionar el contexto a lo largo de un proyecto. Son complementarios, no equivalentes. RAG es una herramienta. Context engineering es el sistema que decide qué información recuperar, cuándo y por qué.
Si quieres profundizar en cómo aplicar estas técnicas con proyectos reales y ver el flujo en acción, en Dominicode Labs tenemos sesiones prácticas donde trabajamos esto con proyectos concretos de la comunidad.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.