Hace unos meses, "ingeniería de prompts" era la habilidad de la que todo el mundo hablaba. Cursos, certificaciones, hilos en Twitter explicando cómo escribir instrucciones para que el modelo te devuelva algo útil. Luego, casi sin anuncio, empezó a aparecer otro término: ingeniería de contexto. Más serio, más técnico, con olor a arquitectura real. Y con él vino la pregunta inevitable: ¿es esta una evolución genuina en cómo pensamos el trabajo con LLMs, o es el mismo concepto con un nombre que se ve mejor en un CV?
La respuesta honesta es que las dos cosas son parcialmente verdaderas, y entender por qué importa bastante si estás trabajando con sistemas de IA en producción, o pensando en cómo posicionarte en ese mercado.
De dónde viene el término y por qué empezó a circular
La ingeniería de prompts emergió como disciplina cuando los modelos de lenguaje se hicieron lo suficientemente capaces como para que la forma en que les hablabas realmente importara. La intuición detrás 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 esperado, encadenar instrucciones, todo eso es trabajo real con impacto medible.
El problema es que "ingeniería de prompts" como campo empezó a mezclarse con contenido de muy baja calidad. Hilos prometiendo "el prompt definitivo para ser 10x más productivo". Tutoriales enseñando a la gente 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, tienes que hacer un esfuerzo consciente para no asumir que están 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 debe funcionar de manera confiable a escala.
En un sistema en producción con RAG, por ejemplo, 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, cuán 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 de la palabra, no problemas de redacción.
Las decisiones concretas que entran en ingeniería de contexto incluyen cosas como:
- 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 basado en 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 aún 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 ejecutará lo que escribiste. Saber cómo escribir una consulta buena 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 cosa: 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 un gran número de personas que han aprendido a usar LLMs a nivel de herramienta, pero relativamente pocas con experiencia construyendo sistemas de IA que funcionen de manera confiable en producción, que escalen, que fallen fácilmente, que sean debuggeables. Esa brecha es visible en conversaciones técnicas durante cualquier proceso de selección serio.
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 en la primera entrevista técnica. No porque uno sea moralmente superior al otro, sino porque los problemas que un sistema real de IA te 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, todo eso requiere rigor e 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, ya sea integrando APIs, construyendo features de RAG, o diseñando agentes, la pregunta práctica es: ¿en qué capa de la arquitectura residen 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 está recuperando la información correcta", "el contexto se contamina entre sesiones", "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 ya tienes experiencia en sistemas distribuidos o diseño de APIs, te va a parecer bastante natural.
La distinción entre ingeniería de contexto e ingeniería de prompts no es puramente semántica, aunque parte del ruido alrededor es. Lo que el término más nuevo describe es un conjunto real de problemas de ingeniería que emergen cuando los sistemas basados en LLMs crecen en complejidad. Si esos son los problemas en los que estás trabajando, o en los que querés trabajar, en Howdy conectamos ingenieros con equipos de producto en Estados Unidos que están construyendo exactamente en esa capa. La conversación empieza en howdylatam.com.
