Context engineering es la disciplina de armar el contexto correcto, no el prompt correcto. El prompt es la pregunta que se le hace al modelo. El contexto es todo lo que el modelo necesita saber para responderla bien: quién es, qué información tiene a mano, qué recuerda, qué puede ejecutar.
La diferencia parece sutil. En la práctica, define si un sistema con IA funciona en producción o se rompe a las dos semanas.
Qué es context engineering
El término se popularizó en 2025, impulsado por una combinación de tres voces: Anthropic en su documentación técnica sobre construcción de agentes, Tobi Lütke (CEO de Shopify) en sus posts públicos sobre cómo se trabaja con modelos en sistemas reales, y Andrej Karpathy en sus charlas sobre la evolución del rol del ingeniero. Los tres convergieron en la misma idea: prompt engineering, como categoría, dejó de alcanzar.
Pulir la pregunta importa en un experimento aislado. En un sistema que opera todas las semanas, lo que define la calidad del output no es la formulación de la instrucción sino la calidad del escenario que rodea al modelo. Context engineering nombra esa disciplina: el diseño deliberado del contexto.
La traducción al español aún no está consolidada. La forma más usada es ingeniería de contexto, y es la que recomendamos en textos largos. En la industria, sin embargo, sigue dominando el término en inglés —igual que ocurrió antes con prompt engineering— y por eso lo mantenemos como término técnico canónico.
Las cuatro capas del contexto
Cuando se desarma qué recibe efectivamente un modelo en una tarea productiva, aparecen cuatro capas distintas. Cada una requiere decisiones propias.
1. Sistema o rol. Quién es la IA en esta interacción. No es lo mismo pedirle algo a un asistente genérico que a un editor con criterios de estilo definidos. Ejemplo: "Sos un editor de contenidos B2B que prioriza claridad sobre adornos y nunca usa frases motivacionales."
2. Conocimiento. Los datos, documentos y archivos a los que la IA accede para esta tarea: archivos markdown del repositorio, fragmentos recuperados por RAG, hojas con datos del cliente, manuales internos. Ejemplo: pasarle el documento de marca antes de que escriba un email, en vez de describirle la marca en el prompt.
3. Memoria. El historial relevante de la conversación o del proyecto. Qué decisiones se tomaron antes, qué versiones se rechazaron, qué quedó pendiente. Ejemplo: que el modelo recuerde que el cliente pidió eliminar dos términos puntuales del lenguaje y no los proponga de nuevo.
4. Herramientas. Qué acciones puede ejecutar el modelo: buscar en la web, leer un archivo del repositorio, llamar a una API, correr código. Ejemplo: darle acceso de lectura al sistema de archivos del proyecto para que consulte criterios reales en vez de inventarlos.
El prompt es la pregunta. El contexto es el escenario. El context engineering es construir ese escenario a propósito.
Context engineering vs prompt engineering
La mejor manera de entender la diferencia es ubicarlas en planos distintos, no en oposición.
Prompt engineering opera al nivel del mensaje: qué palabras usar, qué orden seguir, qué ejemplos incluir, cómo formatear la instrucción. Es valioso y sigue siendo necesario. Context engineering opera al nivel del sistema: qué documentos tiene la IA a mano antes de leer la pregunta, qué herramientas puede usar mientras la responde, qué rol asume, qué historial recuerda.
En un experimento puntual, un buen prompt alcanza. En un sistema productivo —algo que se usa todas las semanas, por más de una persona, sobre casos distintos— lo que sostiene la calidad es el contexto. Un prompt brillante con contexto pobre produce resultados inestables. Un prompt razonable con contexto bien diseñado produce resultados consistentes.
Cómo se aplica en práctica
Un caso concreto. Manu lidera marketing en PedidosYa y necesitaba reducir el tiempo de producción de emails de marketing en Braze, que le llevaba días por sesión.
El instinto inicial habría sido escribir el prompt perfecto: una instrucción larga que le explicara a la IA cómo es PedidosYa, qué tono usar, qué emails ya se mandaron, qué métrica importa. Habría funcionado una vez.
Lo que armamos en su lugar fue trabajo de context engineering. Tres carpetas con archivos markdown: una con el tono y los criterios de marca, otra con plantillas HTML que ya pasaron QA en Outlook, Gmail y Apple Mail, y una tercera con los pasos del flujo interno (qué firma legal, qué firma brand). Cuando Manu necesita un email nuevo, la IA recibe el brief del caso más los archivos relevantes como contexto. El prompt es corto. El contexto es lo que hace el trabajo. De días a 10 minutos.
Context engineering en español
Esto importa especialmente en LATAM por una razón concreta. Las herramientas de IA llegan en inglés y los modelos están entrenados con corpus mayoritariamente en inglés. Cuando se les pide algo en español sin contexto adicional, la salida tiende a sonar a traducción automática: estructuras calcadas del inglés, formalidad neutralizada, referencias culturales fuera de lugar.
La forma de corregir eso no es escribir un prompt más insistente. Es construir contexto en el español que se quiere ver en la salida. Documentos de marca escritos en rioplatense (o paisa, o chilango). Ejemplos reales de comunicación interna. Lineamientos sobre qué traducciones aceptar y cuáles rechazar.
Cuando una empresa argentina, colombiana o mexicana incorpora context engineering como disciplina, la IA empieza a hablarle a sus clientes en su voz —no en una voz traducida. Esa diferencia es la que separa una herramienta utilizable de una que se nota a la legua.
Relación con file system y folder structure
Context engineering es la disciplina. File system para IA y folder structure son cómo se materializa esa disciplina en el repositorio. Las tres ideas operan en niveles distintos: el principio (qué contexto recibe la IA), la forma física (cómo se organizan los archivos), y los archivos concretos (qué dice cada uno). En la práctica se trabajan juntas, pero conviene mantenerlas separadas conceptualmente para no confundir el qué con el cómo.
Construir contexto en español no es un detalle de localización. Es la diferencia entre una IA que sirve a la región o le suena ajena.
En síntesis
Context engineering reemplaza al prompt engineering como categoría útil para pensar IA en sistemas reales. Sus cuatro capas —sistema, conocimiento, memoria, herramientas— son los frentes donde se gana o se pierde la calidad del output. En español, además, es la herramienta que permite que la IA deje de sonar a traducción y empiece a hablar como hablan los equipos que la usan.
No es teoría. Es lo que separa un experimento de un sistema. Y es lo que se trabaja, semana a semana, en cada build.
Learn by Doing. 🧉