El prompt engineering está muerto. Yo nunca lo hice.

Durante unos dos años, internet estuvo lleno de hechizos mágicos. "Actúa como un ingeniero senior." "Respira hondo y resuelve esto paso a paso." "Te doy $200 de propina por una mejor respuesta." La gente intercambiaba estos conjuros como si fueran códigos secretos, como si el modelo fuera un genio y la frase correcta fuera la palabra mágica que liberaba la buena respuesta escondida adentro.

Hasta había un puesto de trabajo dedicado a eso: prompt engineer. La premisa era que la habilidad de la era de la IA sería la redacción: encontrar la frase mágica.

Esa era está terminando, y vale la pena entender por qué, porque lo que la reemplaza no es un mejor hechizo. Es darse cuenta de que nunca hubo ningún hechizo.

La industria está enterrando el término en silencio

A mediados de 2025, el CEO de Shopify, Tobi Lütke, publicó algo que mucha gente ya venía sintiendo:

Me gusta mucho más el término "context engineering" que prompt engineering. Describe mejor la habilidad central: el arte de proveer todo el contexto para que la tarea sea plausiblemente resoluble por el LLM.

En menos de una semana, Andrej Karpathy lo respaldó y agregó la metáfora que lo hace encajar: el LLM es el CPU, y su ventana de contexto es la RAM. Tu trabajo no es susurrarle las palabras correctas, es cargar las cosas correctas en memoria antes de que el modelo corra.

Para 2026 esto se había endurecido hasta volverse la habilidad de consenso. Como lo expresó una guía de campo muy compartida, la redacción es solo alrededor del 10% del problema. El context engineering se queda con el otro 90%: qué información ve el modelo, en qué forma, en qué momento — memoria, documentos recuperados, salidas de herramientas, estado, y qué descartar a medida que la ventana se llena.

El replanteo es correcto. Pero fíjate en lo que en realidad es: el campo miró "encontrar palabras mágicas", decidió que eso nunca fue el trabajo real, y le puso a la disciplina el nombre de lo que siempre importó: la ingeniería de los inputs.

Las palabras nunca fueron el punto

Acá está el porqué el prompt engineering siempre iba a morir: un truco de prompt está atado a un modelo específico en un día específico. La frase ingeniosa que le sacó una mejor respuesta a un modelo es inútil — o activamente dañina — en el siguiente. Estabas construyendo sobre arena. Cada nuevo modelo barría con tus conjuros, y salías a cazar otros.

Un sistema no se pudre así. Si la razón por la que tu agente da una buena respuesta es que le diste los hechos correctos, las herramientas correctas y una tarea clara, entonces un mejor modelo lo vuelve mejor, no roto. Nunca dependiste de una frase mágica; dependiste de buenos inputs. Los buenos inputs sobreviven a las actualizaciones de modelo. Las frases mágicas no.

Esta es toda la diferencia entre un truco y una práctica de ingeniería. Un truco es algo que descubrís y atesorás. Una práctica de ingeniería es algo sobre lo que podés razonar, que podés testear, y en lo que podés confiar a través de los cambios. El prompting era lo primero haciéndose pasar por lo segundo.

Qué es lo que de verdad rompe un agente (no es la redacción)

Mirá fallar a un agente real en producción y casi nunca vas a ver "el prompt estaba mal redactado". Vas a ver algo mucho más aburrido y estructural.

Vas a ver context rot (context rot — la degradación del contexto): el equipo de ingeniería de Anthropic describe cómo un modelo razona cada vez peor a medida que su ventana de contexto se llena de historial viejo y ruidoso. Vas a ver al agente desviarse del rumbo después de cincuenta pasos, perder el hilo de la tarea original, llamar a una herramienta con la forma equivocada, o actuar sobre un estado que ya no es cierto. Un análisis de fallas de IA empresarial rastreó el 65% de ellas hasta "defectos del harness" — deriva de contexto, desalineación de esquema, degradación de estado — no al modelo y no al prompt.

Hay una frase de ese trabajo que le repito a la gente: una mejora del uno por ciento en un benchmark no significa nada si el agente se desvía del rumbo después de cincuenta pasos. Ninguna redacción de prompt arregla eso. No es un problema de palabras. Es un problema de sistemas: qué se le permite al agente ver, retener, hacer y olvidar a lo largo de una tarea larga.

Esa es la capa que la industria ahora llama harness engineering: el entorno alrededor del modelo — sus herramientas, su memoria, sus restricciones, sus bucles de retroalimentación, cuándo compactar el contexto y reinyectar el objetivo. El prompt es una pieza diminuta de eso. El harness es todo el resto.

Esto siempre fue solo ingeniería

Quitale el vocabulario nuevo y mirá lo que el context engineering y el harness engineering en realidad te piden hacer:

• Decidir qué inputs recibe el sistema, desde fuentes confiables, en una forma limpia.
• Gestionar el estado a lo largo del tiempo — qué conservar, qué descartar, qué persistir afuera del modelo.
• Definir límites — qué herramientas, qué se les permite hacer, cuáles son los contratos.
• Construir bucles de retroalimentación — chequeos, evals, recuperación cuando algo se desvía.

Eso no es una disciplina nueva de IA. Eso es ingeniería. Inputs, estado, límites, retroalimentación — es el mismo trabajo ya sea que el componente del medio sea una función, un servicio o un modelo de lenguaje. El modelo es inusual en un sentido (es un adivinador no determinista, que es por lo que lo anclás con grounding), pero todo lo que lo rodea es trabajo de sistemas común y corriente.

Así que cuando me preguntan qué hago con los prompts, la respuesta honesta es: lo menos posible. Nunca tuve una fase de prompt engineering. El trabajo siempre fue construir el sistema — fuentes deterministas que el modelo no puede sobrescribir, contratos tipados en los bordes, la tarea capturada en una spec en lugar de un prompt, evals para saber si hubo una regresión. El prompt era la parte menos interesante, y yo quería que siguiera siendo así. Cuanto más depende tu resultado de la redacción exacta, más frágil es.

Por qué esto es una buena noticia

Es tentador leer "el prompt engineering está muerto" como el piso moviéndose otra vez bajo los pies de todos — otra habilidad obsoleta, a aprender lo nuevo. Es lo contrario. La muerte del prompt engineering es el campo de la IA admitiendo que la habilidad duradera nunca fue una bolsa de trucos específicos de cada modelo. Fue ingeniería desde siempre — y a la ingeniería no se la lleva el próximo lanzamiento. El razonamiento que hacés hoy sobre inputs, estado y límites sigue valiendo cuando el modelo de abajo se vuelve el doble de bueno.

Las palabras mágicas nunca funcionaron como la gente esperaba. El sistema alrededor del modelo siempre lo hizo. El prompt engineering no está muerto porque encontramos mejores hechizos — está muerto porque al fin admitimos que nunca hubo ningún hechizo, solo la ingeniería que deberíamos haber estado haciendo todo el tiempo.