Context Engineering: el término que realmente describe lo que estás haciendo

Si llevas un tiempo trabajando con IA, seguramente habrás visto en algún README, en algún hilo de Twitter o en alguna charla de meetup el consejo universal: “dale más contexto a la IA”. Lo dice todo el mundo con esa convicción de quien ha descubierto el agua caliente.

Y sí, dar contexto ayuda. El problema es que “dar contexto” como gesto vago no es lo mismo que hacerlo bien. Y hacerlo bien tiene nombre, tiene disciplina, y ese nombre no es el que circula por ahí.

Por qué no se llama Context Driven Development #

Hay una confusión que vale la pena aclarar antes de seguir, porque si buscas bibliografía seria sobre este tema no vas a encontrar el término Context Driven Development como práctica establecida. No lo usa GitHub en sus artículos sobre flujos agénticos. No lo usa Anthropic en su guía sobre construcción de agentes. No lo usan ni Andrej Karpathy ni Simon Willison, que son probablemente las dos personas que más han articulado públicamente esta idea.

Lo que sí aparece de forma consistente es Context Engineering.

La diferencia no es solo semántica. Llamarlo development insinúa una metodología de ciclo de vida: fases, entregables, algo parecido a TDD o BDD. Pero lo que documentan estas fuentes no es eso: es una disciplina de diseño operativo sobre cómo alimentar a un modelo o a un agente. No una metodología de desarrollo. Mezclar los dos términos da lugar a comparaciones que no tienen mucho sentido, y a artículos con tablas comparativas que comparan cosas que no están al mismo nivel. Así que usemos el término correcto.

De dónde viene el término #

Simon Willison documentó en junio de 2025 cómo Tobi Lütke, CEO de Shopify, había empezado a usar el término argumentando que describe mejor la habilidad central que hace falta al trabajar con LLMs. Su definición: “the art of providing all the context for the task to be plausibly solvable by the LLM”.

Andrej Karpathy lo recogió y lo precisó con una variante que me parece más útil todavía: “the delicate art and science of filling the context window with just the right information for the next step”.

La clave está en just the right information. No toda la información disponible. La correcta, en el orden correcto, con el peso adecuado.

Eso parece obvio hasta que te pones a hacerlo. Meter mucho contexto mal priorizado no ayuda al modelo: le añade ruido. Y cuando hay demasiado ruido, las señales importantes se pierden entre el fondo. He visto este error muchas veces, y también lo he cometido: pegar cinco archivos en el chat, esperar magia, y recibir algo que mezcla patrones de tres versiones distintas del proyecto.

Qué es Context Engineering #

Sintetizando las fuentes anteriores, yo lo definiría así:

Context Engineering es decidir, antes de que el agente empiece a trabajar, qué información necesita ver, en qué forma y con qué prioridad para que pueda resolver la tarea sin tener que adivinar nada.

Esa información puede ser muchas cosas:

• el estado actual del repositorio
• documentación normativa del proyecto
• decisiones de arquitectura previas (ADRs)
• ejemplos de código que representan el patrón correcto ahora, no el de hace dos años
• convenciones y reglas del equipo
• issues o tickets con el comportamiento esperado
• restricciones técnicas y de negocio documentadas
• resultados de tests o logs de errores recientes
• herramientas disponibles para el agente
• memoria de interacciones anteriores relevantes
• reglas explícitas de validación o compliance

Anthropic, en Building effective agents, describe los sistemas agénticos modernos exactamente así: LLMs aumentados con recuperación, herramientas y memoria. No son modelos en el vacío que reciben un prompt; son sistemas donde la calidad de lo que entra en la ventana de contexto determina directamente la calidad de lo que sale.

O dicho de otra forma: el contexto no es “información adicional”. Es una parte estructural del sistema, igual que lo es el esquema de tu base de datos o la arquitectura de tu API.

Qué no es Context Engineering #

Como todo término que empieza a sonar bien en las charlas y en los READMEs, Context Engineering corre el riesgo de convertirse en un cajón de sastre donde cabe todo. Y cuando todo cabe, el término deja de significar algo útil. Así que merece la pena ser concreto sobre lo que no es.

No es escribir prompts más largos. Un prompt de 2.000 palabras con información dispersa es ruido con buenas intenciones. La longitud no es la métrica. La relevancia y la estructura sí.

No es copiar medio repositorio en una conversación. Meter cinco archivos sin criterio de selección no mejora el resultado; muchas veces lo empeora, porque el modelo tiene que inferir cuál es relevante y cuál es fondo. Y cuando falla esa inferencia, el resultado es inconsistente de una respuesta a otra.

No es dejar que el modelo improvise con señales contradictorias. Si el contexto incluye ejemplos que contradicen las convenciones actuales del proyecto, el agente va a tomar una decisión. Probablemente la equivocada, o peor: diferente según el archivo que le tocó leer primero.

Y no es lo mismo que vibe coding. Karpathy describió el vibe coding como una práctica válida para proyectos desechables o de fin de semana: fluir con la IA sin demasiado rigor, moverse rápido, aceptar resultados aproximados. Tiene su sitio. Nadie hace Context Engineering para un script de automatización personal del sábado por la tarde. Pero en aplicaciones serias, con equipos reales, con código que alguien va a mantener, el diseño deliberado del contexto sí importa.

La diferencia entre hacerlo intuitivo y hacerlo bien #

Hay una diferencia práctica clara entre un developer que “da contexto” cuando nota que el agente se ha perdido, y uno que diseña el paquete de contexto antes de pedir nada.

El primero es reactivo. Añade información cuando ya hay un problema. Lo hace por ensayo y error. Es caro en tiempo y en frustración.

El segundo decide antes de empezar: qué archivos debe leer el agente, qué documentación es normativa y cuál es solo de apoyo, qué ejemplos representan el patrón correcto, qué señales del entorno sirven de ground truth si aparece alguna contradicción.

Algunas decisiones concretas de ese diseño:

• Cuándo usar recuperación (RAG) y cuándo pasar el documento directamente.
• Qué partes del historial resumir en vez de reenviar completas.
• Qué ejemplos representan el patrón actual del equipo, no el de la versión anterior.
• Qué herramientas tiene disponibles el agente y en qué orden debería consultarlas.
• Cuándo una spec formal es la señal más útil y cuándo basta con un ADR bien escrito.

No es magia, ni es especialmente complicado. Es diseño de sistemas aplicado a la capa que alimenta al modelo. Igual que diseñas el esquema de tu base de datos antes de escribir queries, diseñas el paquete de contexto antes de pedir ejecución.

Por qué estas prácticas no son nuevas #

Context Engineering no aparece de la nada. Recoge prácticas que ya existían antes de que los LLMs se pusieran de moda:

Few-shot examples: dar al modelo ejemplos representativos del comportamiento esperado, no solo describirlo. El modelo aprende del patrón que muestras, no solo de la instrucción que escribes.

RAG (Retrieval Augmented Generation): recuperar documentación o código relevante en el momento de la inferencia, en vez de meterlo todo en el contexto de forma estática. Útil cuando la base de conocimiento es grande o cambia con frecuencia.

Compactación de historial: resumir conversaciones largas para mantener el contexto manejable sin perder información crítica. Especialmente importante en flujos multi-paso donde el agente necesita recordar decisiones anteriores.

Tool use: dar al agente acceso a herramientas concretas en vez de pedirle que infiera cómo funciona algo o que opere de memoria.

Lo que ha cambiado es que todas estas técnicas, que antes se aplicaban de forma aislada, ahora se combinan en sistemas donde el diseño del contexto es la decisión de arquitectura más importante. Un agente que trabaja sobre un repositorio grande, con convenciones implícitas y un historial de decisiones que nadie documentó bien, no va a rendir bien por mucho que el modelo base sea capaz. El cuello de botella no es el modelo. Es el contexto.

Para terminar #

Si hasta ahora le dabas “más contexto” a la IA porque notabas que los resultados mejoraban, ya hacías Context Engineering de forma intuitiva. El término solo le pone nombre a algo que estabas haciendo sin llamarlo así.

La diferencia está en pasarlo de intuitivo a deliberado: diseñar el paquete de contexto antes de que el agente empiece a trabajar, no después de que ya se haya perdido. Eso, en proyectos con algo de complejidad, se nota en los resultados.

¿Y cómo encaja esto con Spec Driven Development? ¿Son enfoques alternativos o se complementan? Eso lo vemos en el siguiente artículo: SDD vs Context Engineering: cuándo usar cada uno (y cuándo usarlos juntos).

Fuentes: Simon Willison — Context engineering, Simon Willison — Andrej Karpathy on vibe coding, Anthropic Engineering — Building effective agents