# El prompt engineering está muerto. Yo nunca lo hice. La industria pasó dos años buscando las palabras mágicas que susurrarle al modelo. Ahora declara en voz baja que el 'prompt engineering' está muerto y lo reemplaza por context engineering y harness engineering. Lo que pasa es esto: no son trucos nuevos, son simplemente ingeniería, el trabajo que la gente de sistemas de verdad venía haciendo todo el tiempo. Por qué las palabras nunca fueron el punto, y qué es lo que de verdad hace funcionar a un agente. - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, methodology, ai-native - **Source:** https://fedorthinks.com/es/blog/prompt-engineering-is-dead --- 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ó](https://x.com/tobi/status/1935533422589399127) 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ó](https://simonwillison.net/2025/Jun/27/context-engineering/) 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](https://www.anthropic.com/engineering/harness-design-long-running-apps) 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"**](https://atlan.com/know/what-is-harness-engineering/) — 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](/work/astrolinkers)), 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](/blog/specs-are-the-artifact), [evals para saber si hubo una regresión](/blog/evals-or-it-didnt-ship). 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.