Prompt Engineering ha muerto. Viva el Context Engineering.
Durante un par de años, el Prompt Engineering se vendió como la nueva habilidad imprescindible.
Cursos, certificaciones, puestos de trabajo, hilos enteros llenos de "frases mágicas" que supuestamente desbloqueaban mejores respuestas en cualquier modelo.
Escríbelo así, no de esta otra forma. Añade "piensa paso a paso". Dale un rol. Prométele una propina si hace un buen trabajo.
Yo también me lo creí un poco, al menos al principio.
Pero si habéis pasado tiempo de verdad usando Coding Agents sobre un proyecto real, no sobre un ejemplo de juguete, ya sabéis hacia dónde va esto.
El prompt era perfecto. El resultado no.
Hace un tiempo le pedí a un Coding Agent que implementase una feature bastante sencilla.
No improvisé el prompt. Describí la feature con detalle, el comportamiento esperado, incluso un par de edge cases que quería cubiertos.
Según cualquier manual de "Prompt Engineering", era un buen prompt.
Y aun así, el agente añadió una nueva abstracción donde un helper ya existente resolvía el problema dos archivos más allá. Ignoró una convención del proyecto que sigo desde hace años. Se inventó una dependencia que nunca pedí.
No había nada mal en el prompt. Lo que faltaba no estaba en el prompt en absoluto: era todo lo que había alrededor y que nunca le di al agente. Nada de eso vivía en un CLAUDE.md, en una Skill, ni en ningún otro sitio al que el agente pudiera acceder de verdad. Solo vivía en mi cabeza.
El Prompt Engineering optimizaba la capa equivocada
El Prompt Engineering parte de la idea de que el cuello de botella está en cómo preguntas.
La redacción, los ejemplos, el role-play, los trucos de formato, las instrucciones "paso a paso". Todo eso puede mejorar de verdad una respuesta aislada.
Pero un proyecto de software real no es una respuesta aislada. Es arquitectura, convenciones, historia, compromisos técnicos, restricciones que viven solo en la cabeza de las personas, y decisiones que nadie escribió porque "todo el equipo ya lo sabe".
Un agente que solo recibe un prompt bien escrito se queda sin todo eso. Y ninguna redacción ingeniosa arregla la información que falta.
La verdadera palanca es el contexto, no la redacción
Lo que realmente cambia la calidad de lo que produce un agente es si sabe:
- Qué estáis intentando construir, más allá del ticket inmediato.
- Qué restricciones existen ya en el proyecto.
- Qué arquitectura se espera que respete.
- Qué convenciones sigue el proyecto.
- Qué herramientas puede usar.
- Qué límites no debe cruzar.
- Qué validaciones debe ejecutar antes de dar algo por terminado.
Nada de eso cabe en un solo prompt. Tiene que vivir en algún sitio al que el agente pueda acceder de forma constante — y hoy ese "algún sitio" tiene nombres concretos. Un archivo CLAUDE.md o AGENTS.md para convenciones, arquitectura y límites. Skills para procedimientos que quieres que se sigan siempre igual, en lugar de reexplicarlos en cada sesión. Servidores MCP para las herramientas y datos externos que el agente tiene permitido tocar. Hooks para validaciones que se ejecutan automáticamente, para que la corrección no dependa de que el agente se acuerde de comprobarlo.
Ese es el salto del Prompt Engineering al Context Engineering: de "cómo redacto esta petición" a "qué necesita saber el agente, y dónde debe vivir ese conocimiento, para tomar buenas decisiones sin mí".
Más contexto no es automáticamente mejor contexto
Aquí viene la parte que sorprende a quien empieza a tomarse esto en serio: meterle a un agente más documentos, más herramientas y más instrucciones no mejora el resultado de forma fiable.
Un muro de reglas desactualizadas en AGENTS.md es peor que no tener el archivo. Diez servidores MCP conectados porque "algún día podrían ser útiles" son peores que tres que el agente realmente sabe cuándo usar. Dos Skills que se solapan y se contradicen en silencio son peores que una sola clara. Un contexto que se contradice a sí mismo es peor que ningún contexto, porque ahora el agente tiene que adivinar qué parte creerse.
El Context Engineering no consiste en maximizar la cantidad de información. Consiste en seleccionarla: mantenerla precisa, relevante y fácil de usar para el agente.
Diseñar el espacio de decisión, no solo la petición
Esta es la parte que creo que más cambia el papel de un ingeniero senior.
El Prompt Engineering trata al agente como una máquina expendedora: metes la moneda correcta, sale el snack correcto.
El Context Engineering lo trata más bien como el onboarding de una nueva incorporación. No le darías a un desarrollador nuevo un ticket de una línea y te irías. Le darías el código, la guía de estilo, un par de ejemplos de PRs aceptadas y por qué, y una lista clara de lo que no debe tocar.
Eso es exactamente lo que hago ahora en los proyectos donde uso Coding Agents en serio: instrucciones de proyecto en un CLAUDE.md, Skills para los patrones que quiero que se repitan exactamente igual, permisos explícitos de herramientas para que el agente no pueda ir más allá de sus MCPs autorizados, y una lista corta de comprobaciones — tests, lint, un paso de revisión — que debe ejecutar antes de poder dar algo por terminado.
El prompt sigue ahí. Simplemente ya no es lo importante.
El segundo trabajo que corre en paralelo: mantener al agente, no solo darle prompts
Cuando el contexto pasa a vivir en archivos, Skills y configuraciones de herramientas en lugar de en tu cabeza, aparece un tipo de trabajo nuevo — uno que el Prompt Engineering nunca tuvo que contemplar, porque asumía que todo pasaba dentro de un único turno de chat.
Una sesión con un Coding Agent no es solo: escribir el prompt, esperar el resultado, validarlo y pasar a la siguiente tarea. Por debajo, cada iteración te obliga en silencio a preguntarte también:
- ¿Está el agente bien definido para este tipo de tarea, o estoy improvisando contexto sobre la marcha otra vez?
- ¿Debería actualizar sus instrucciones — el
CLAUDE.md, elAGENTS.md? - ¿Esta tarea necesita una Skill nueva, o le falta un caso a una que ya existe y que acabo de encontrar?
- ¿Está el agente usando la Skill o el MCP correctos, o eligiendo la herramienta equivocada porque dos de ellas se parecen?
- ¿Acaba de cruzar un límite que yo creía que ya había fijado — y si es así, dónde debería vivir realmente ese límite?
Nada de eso es escribir un prompt. Es mantener el sistema en el que trabaja el agente, sesión tras sesión.
Y aquí es donde se vuelve caro: cuando el resultado está mal, siempre hay dos salidas.
La rápida es reexplicárselo en el chat — reformular, añadir el detalle que faltaba, corregirlo sobre la marcha y seguir adelante. Funciona, para esa sesión.
La buena es arreglarlo donde de verdad se va a quedar: actualizar la regla del CLAUDE.md, editar la Skill, ajustar la descripción de una herramienta en un MCP, añadir el ejemplo que faltaba. Cuesta más ahora mismo, pero se amortiza en cada una de las sesiones siguientes.
Yo mismo me he pillado más de una vez tomando el atajo — explicando la misma restricción de arquitectura por tercera vez en una semana, en lugar de dedicar cinco minutos a que sea imposible volver a pasarla por alto.
El tiempo que ahorras escribiendo código lo inviertes definiendo al agente
Este es el trade-off que nadie menciona cuando se habla de "productividad 10x con IA".
Los Coding Agents sí ahorran tiempo escribiendo, en boilerplate y en primeros borradores. Pero si te tomas esto en serio, ese tiempo no desaparece: se desplaza. Se desplaza a escribir y mantener Skills, a seleccionar qué entra en AGENTS.md, a decidir qué servidores MCP merecen de verdad una conexión permanente, y a revisar si el agente eligió la herramienta adecuada para el trabajo.
El Context Engineering no es una configuración que haces una vez antes de empezar "el trabajo de verdad". Es trabajo de configuración continuo que compite por las mismas horas que el agente supuestamente te iba a liberar.
Los ingenieros que sacan verdadero valor de esto no son los que redactan bien el prompt en el momento. Son los que tratan cada mal resultado como una señal sobre el sistema, no solo sobre esa petición concreta — y que están dispuestos a reinvertir parte de su tiempo ahorrado en arreglarlo ahí.
Conclusión
El Prompt Engineering no está mal. Simplemente está incompleto, y cada vez es más irrelevante por sí solo.
La habilidad que realmente separa un resultado útil de ruido caro es diseñar — y mantener continuamente — el contexto en el que opera un agente: el CLAUDE.md que lee, las Skills a las que puede recurrir, los MCPs que puede invocar y las comprobaciones que debe superar. Ese mantenimiento es trabajo real, y ahí es donde acaban yendo a parar las horas que la IA supuestamente te iba a ahorrar.
En el próximo artículo de esta serie profundizaré en el Harness Engineering: los sistemas, herramientas y comprobaciones que construimos alrededor de un agente para que el contexto deje de ser un prompt puntual y se convierta en el entorno en el que siempre trabaja.
Hasta entonces, la pregunta que merece la pena hacerse no es:
¿Cuál es el mejor prompt para esto?
Es:
¿Qué necesita saber este agente — y dónde debería vivir realmente ese conocimiento — para tomar la misma decisión que tomaría yo?
Si estáis construyendo workflows parecidos alrededor de Coding Agents, me encantaría comparar notas — no dudéis en escribirme.