El fin del prompt engineering

Hubo un momento, entre 2023 y 2025, en que saber "hablarle" a un modelo parecía una habilidad profesional con futuro. Cursos, plantillas mágicas, colecciones de trucos. En 2026 esa habilidad se está evaporando, y conviene entender por qué.

Qué era realmente el prompt engineering

En la práctica, el "prompt engineering" manual resolvía tres carencias de los modelos:

• No sabían pedir aclaraciones, así que había que anticiparlas.
• No mantenían el formato de salida, así que había que insistir con ejemplos.
• No razonaban en pasos, así que había que forzar el "piensa paso a paso".

Las tres carencias ya casi no existen

Los modelos actuales piden contexto cuando falta, respetan esquemas de salida estructurada de forma nativa y razonan sin que se lo supliques. Los trucos que antes daban un salto de calidad hoy no mueven la aguja o incluso la empeoran.

Lo que lo reemplaza

1. Especificación de producto. Describir bien el problema, los casos límite y los criterios de aceptación. Esto siempre importó; ahora es casi todo.
2. Ingeniería de contexto. Decidir qué documentos, datos y herramientas ve el modelo en cada momento. El reto es de recuperación y permisos, no de redacción.
3. Evaluación sistemática. Conjuntos de pruebas con casos reales, métricas y regresiones. Sin evals, cualquier cambio es una apuesta.
4. Diseño de herramientas. Un modelo con buenas herramientas y malas instrucciones rinde mejor que al revés.

El prompt dejó de ser el artefacto central. El artefacto central es el sistema que rodea al prompt: los datos, las herramientas, los límites y las pruebas.

Un ejemplo del cambio de mentalidad

Antes, un equipo pasaba una tarde afinando frases. Hoy, ese mismo esfuerzo se invierte en un archivo de evaluación:

cases = [
    {"input": "factura sin IVA", "field": "tax_rate", "expected": 0.0},
    {"input": "factura intracomunitaria", "field": "reverse_charge", "expected": True},
]

def score(model):
    ok = sum(1 for c in cases if run(model, c["input"])[c["field"]] == c["expected"])
    return ok / len(cases)

El prompt se vuelve una variable más que se ajusta contra score, no una obra de artesanía que se defiende por intuición.

Y en los sistemas con agentes, aún menos

En un flujo con herramientas, el modelo pasa la mayor parte del tiempo leyendo resultados de funciones, no tu instrucción inicial. Puedes escribir el mejor prompt del mundo: si una herramienta devuelve un error confuso o un JSON gigante sin filtrar, el agente se pierde igual. El trabajo de mejora está en la herramienta, en el formato de su salida y en el presupuesto de contexto, no en añadir una frase más al mensaje de sistema.

Qué habilidades conservan valor

No todo se pierde. Sigue siendo útil:

• Entender cómo falla un modelo y por qué (sesgos, alucinación, sensibilidad al orden).
• Saber cuándo un problema necesita un agente y cuándo una simple llamada.
• Comunicar con precisión, que es una forma de pensar con precisión.

La diferencia es que estas habilidades son de ingeniería y de producto, no un gremio aparte llamado "prompting".

Conclusión

El prompt engineering no desaparece porque fuera inútil, sino porque se integró en disciplinas más amplias. Escribir la instrucción perfecta importa cada vez menos; construir el sistema que hace que la instrucción importe poco es el nuevo trabajo. Si tu currículum dice "experto en prompts", cámbialo por "diseño sistemas alrededor de modelos y los evalúo con datos".