En casi cualquier canal de Slack de ingeniería aparece este año la misma frase: "ingeniería de contexto es lo único que importa ahora, olvídate de los prompts". Es una afirmación categórica, del mismo tono que la ola anterior de hype alrededor del prompt engineer que iba a quedar obsoleto de un día para el otro. Y sin embargo, esta vez algo real cambió debajo del ruido.
La pregunta que vale la pena hacerse no es qué término gana la discusión de nomenclatura, sino qué construyó realmente ese cambio de vocabulario y qué necesitas saber si trabajas con LLMs en producción.
De dónde viene el término y por qué empezó a circular
La ingeniería de prompts emergió cuando los modelos de lenguaje se volvieron lo suficientemente capaces como para que la forma en que les hablaras realmente importara. La intuición era correcta: el mismo modelo puede dar respuestas completamente diferentes dependiendo de cómo estructures la instrucción. Aprender a enmarcar prompts, usar ejemplos, definir el tono y formato esperados, encadenar instrucciones… todo eso es trabajo real con impacto medible.
El problema es que el campo se mezcló rápido con contenido de bajísima calidad. Hilos prometiendo "el prompt definitivo para ser 10x más productivo". Tutoriales enseñando a escribir "actúa como un experto en X" como si fuera una técnica sofisticada. El término se diluyó al punto de que cuando alguien lo menciona en una entrevista técnica, hay que hacer un esfuerzo consciente para no asumir que está hablando de algo superficial.
La ingeniería de contexto llega, en parte, como respuesta a esa degradación. Pero también llega porque los sistemas reales que usan LLMs se volvieron considerablemente más complejos, y la forma de pensar sobre ellos tuvo que evolucionar en consecuencia.
Qué significa realmente la ingeniería de contexto en la práctica
Si la ingeniería de prompts se enfoca en cómo le hablas al modelo, la ingeniería de contexto se enfoca en qué información le das y cómo el sistema organiza esa información antes de que el modelo la procese. Es una distinción que parece sutil hasta que empiezas a construir algo que tiene que funcionar de manera confiable a escala.
En un sistema en producción con RAG, la calidad de los resultados no depende principalmente de cómo redactaste la instrucción del sistema. Depende de cuánto contexto relevante puedes meter en la ventana de contexto, cómo fragmentaste los documentos, qué tan bien funciona tu recuperación, cómo priorizas información cuando hay más de lo que cabe, cómo manejas el contexto conversacional a través de múltiples turnos. Esos son problemas de ingeniería en el sentido completo, no problemas de redacción.
Las decisiones concretas que entran en ingeniería de contexto incluyen:
- Estrategia de fragmentación: cómo divides los documentos para que la recuperación sea relevante sin perder coherencia semántica.
- Gestión de la ventana de contexto: qué incluyes, qué descartas, en qué orden, con qué prioridad cuando la información compite por espacio.
- Memoria a largo vs. corto plazo: qué persiste entre sesiones, qué se descarta, cómo se actualiza sin introducir ruido.
- Construcción dinámica de prompts: cuando el contenido del contexto cambia según el estado del sistema o del usuario, el prompt es un output del sistema, no un input fijo.
- Evaluación y trazabilidad: cómo sabes que el contexto que estás inyectando produce el comportamiento esperado del modelo.
Ninguna de esas decisiones es sobre escritura. Son decisiones arquitectónicas con compromisos reales, exactamente como cualquier otra decisión de sistemas distribuidos.
Dónde se superpone con ingeniería de prompts, y dónde no
La superposición existe y es real. Un prompt bien construido sigue siendo importante dentro de un sistema de ingeniería de contexto. Las instrucciones del sistema, los ejemplos few-shot, la estructura de los mensajes: todo tiene impacto. La diferencia es que en sistemas complejos, esos elementos son una pequeña parte de la superficie total de decisiones que afectan la calidad del output.
Una analogía que funciona: la ingeniería de prompts es como aprender a escribir consultas SQL limpias. La ingeniería de contexto es como diseñar el esquema, definir los índices, decidir qué normalizar y qué denormalizar, y entender cómo el query planner va a ejecutar lo que escribiste. Saber escribir una buena consulta sigue siendo parte del trabajo, pero el impacto de las decisiones arquitectónicas es de órdenes de magnitud mayor.
Lo que la ingeniería de contexto no resuelve, y vale la pena decirlo, es la calidad del razonamiento del modelo en tareas que no dependen de información externa. Si el problema es que el modelo no puede manejar un tipo particular de razonamiento abstracto, más contexto no lo va a arreglar. La técnica relevante ahí sigue siendo otra: fine-tuning, chain-of-thought, selección de modelo.
Por qué este debate importa más allá de la terminología
El mercado laboral de ingeniería de IA está en un momento interesante. Hay muchas personas que aprendieron a usar LLMs a nivel de herramienta, pero pocas con experiencia real construyendo sistemas que escalen, que fallen de manera predecible y que sean debuggeables. Esa brecha es visible en cualquier entrevista técnica seria.
Cuando un equipo de producto en Estados Unidos busca a alguien para trabajar en su capa de IA, la diferencia entre un candidato que "sabe ingeniería de prompts" y uno que puede razonar sobre arquitectura de contexto es grande y detectable desde la primera conversación técnica. No porque uno sea superior al otro en abstracto, sino porque los problemas que un sistema real de IA presenta en producción son problemas de ingeniería de sistemas, no de redacción.
Dicho esto, tampoco vale la pena caer en el extremo opuesto: descartar todo lo relacionado con prompts como trabajo de bajo valor. Evaluar outputs de LLMs, construir evals sistemáticas, diseñar instrucciones que produzcan comportamiento consistente: eso requiere rigor y tiene impacto directo en la calidad del producto. El punto no es que una disciplina sea más válida que la otra, sino que son capas diferentes del mismo problema.
Dónde enfocarse si estás construyendo en este espacio
Si ya estás trabajando con LLMs en alguna capacidad (integrando APIs, construyendo features de RAG, diseñando agentes), la pregunta práctica es: ¿en qué capa de la arquitectura están los problemas más difíciles de resolver? Si la respuesta es "el modelo no entiende lo que le pido", el trabajo está en los prompts. Si la respuesta es "el sistema no recupera la información correcta", "el contexto se contamina entre sesiones" o "no puedo predecir cuándo va a fallar", esos son problemas de ingeniería de contexto.
Las habilidades que se vuelven relevantes en ese segundo grupo incluyen:
- Diseñar pipelines de recuperación y evaluar relevancia.
- Gestión de estado en sistemas agénticos de múltiples pasos.
- Estrategias de fallback cuando el contexto disponible es insuficiente o contradictorio.
- Observabilidad de sistemas LLM: trazas, logs, evals automatizadas.
- Entender cómo diferentes modelos manejan la ventana de contexto y sus límites.
Nada de esto requiere abandonar lo que ya sabes sobre prompts. Requiere agregar una capa de pensamiento arquitectónico que, si tienes experiencia en sistemas distribuidos o diseño de APIs, te va a parecer bastante natural.
La ingeniería de contexto no mató a la ingeniería de prompts. La dejó como una pieza más, más chica, dentro de una caja de decisiones mucho más grande. Si esa caja es la que te interesa construir, en Howdy conectamos ingenieros con equipos de producto en Estados Unidos que trabajan exactamente en esa capa. La conversación empieza en howdylatam.com.
