Ingeniería de prompts vs ingeniería de contexto: no un cambio de marca, un cambio en lo que optimizas

La ingeniería de prompts es redactar bien una instrucción. La ingeniería de contexto es decidir qué ve el modelo en absoluto. El término fue popularizado en junio de 2025 por Tobi Lutke de Shopify y amplificado por Andrej Karpathy, que lo describió como el arte de llenar la ventana de contexto con justo la información adecuada para el siguiente paso. La distinción más limpia viene de Philipp Schmid: el contexto es todo lo que el modelo ve antes de generar una respuesta, y eso es un sistema, no una cadena.

Los dos no son rivales; la ingeniería de prompts es un subconjunto. Cuando escribes un buen prompt de sistema, eso es ingeniería de prompts. Cuando decides qué tres documentos recuperar, qué herramientas exponer, cuánto historial conservar, qué resumir y descartar, y qué esquema de salida exigir, todo bajo un presupuesto de tokens, eso es ingeniería de contexto. La propia guía de Anthropic lo encuadra como gestionar todo el estado del contexto a lo largo de los turnos, y su frase más afilada es la que vale la pena conservar: el contexto es un recurso finito con rendimientos marginales decrecientes.

La razón por la que la ingeniería de contexto se volvió una disciplina con nombre es que la suposición fácil se rompió bajo la medición. La suposición era que los modelos de contexto largo te dejan atiborrar la ventana y dejar de pensar. El estudio Context Rot de Chroma probó 18 modelos frontera en julio de 2025 y encontró que cada uno degrada a medida que crece la entrada, a menudo de formas no uniformes: el modelo no maneja el diezmilésimo token de forma tan fiable como el centésimo. El hallazgo más antiguo de lost-in-the-middle apuntaba en la misma dirección.

Dos fuerzas hicieron de la carga, no del prompt, la cosa a ingenierizar. Primero, los agentes, el uso de herramientas, el retrieval y la memoria significan que el contexto lo ensambla a lo largo de muchos turnos un sistema, no se escribe a mano una vez. Segundo, la economía: en producción en Manus, la proporción de tokens de entrada a salida ronda 100 a 1, y reutilizar la caché clave-valor genera una gran diferencia de coste, así que lo que pones en la ventana es una decisión de coste tanto como de calidad. Más contexto no es mejor; el contexto presupuestado y relevante lo es. Esta es la columna vertebral empírica bajo nuestro recorrido anterior por la ingeniería de contexto y por qué importa.

Despojada de la etiqueta, la ingeniería de contexto es un conjunto de prácticas comprobables, no susurros de prompt. Las técnicas nombradas se repiten en Anthropic, LangChain y el artículo de producción de Manus:

• Retrieval. Trae los pocos documentos relevantes en el momento en que se necesitan, en lugar de pegar todo. Esta es la disciplina detrás de la generación aumentada por recuperación.
• Compactación y resumen. Comprime turnos viejos en un resumen rodante para que el presupuesto se gaste en lo que está vivo, no en la transcripción.
• Memoria y toma de notas. Descarga el estado a notas o archivos externos que el agente pueda releer, en lugar de arrastrarlo en la ventana.
• Curación de herramientas. Mantén de tres a cinco herramientas centrales cargadas y trae el resto justo a tiempo. Cargar cada herramienta diluye la señal y rompe la caché.
• Salidas estructuradas. Exige un esquema para que el modelo gaste tokens en la respuesta, no en la prosa de formato.
• Aislamiento. Reparte el trabajo entre subagentes para que cada uno vea solo el contexto que necesita.

LangChain encuadra el mismo conjunto como escribir, seleccionar, comprimir y aislar. El punto es que cada una de estas es medible: puedes hacer A/B a un recuperador, un umbral de compactación o un conjunto de herramientas, que es exactamente lo que hace de esto ingeniería en lugar de fraseo.

En parte, y está bien. Sí, los buenos ingenieros ya curaban lo que el modelo ve; el valor del nombre es que apunta la optimización a la carga y al sistema, no a la frase, que es donde viven de verdad la fiabilidad y el coste. El debate vivo es más útil que la discusión terminológica. En junio de 2025, Cognition argumentó contra los sistemas multiagente, con el fundamento de que compartir contexto con limpieza entre agentes es difícil, y recomendó mantener el trabajo de un solo agente y compartir trazas completas. La misma semana, Anthropic describió un sistema de investigación multiagente que depende de un aislamiento de contexto disciplinado. Misma disciplina, conclusión arquitectónica opuesta.

Para un equipo que construye con LLM, las conclusiones son llanas. Presupuesta tokens como presupuestas cómputo, porque más no es gratis ni siempre mejor. Trata el trabajo como fontanería (calidad del retrieval, compactación, memoria, curación de herramientas, salidas estructuradas), no como fraseo. Y elige tu arquitectura según lo fiablemente que puedas compartir contexto, en lugar de por qué enfoque suena más avanzado. El nombre seguirá mutando, algunos ya llaman a la siguiente capa ingeniería de harness, pero el objeto es estable: el sistema que decide qué puede ver el modelo.