Noviembre de 2023. OpenAI lanzó la API de function calling con soporte estable, y sin que nadie hiciera un anuncio formal, el oficio del “prompt engineer” comenzó su declive. No porque los prompts dejaran de importar, sino porque dejaron de ser lo que más importaba.
En Soamee llevamos años construyendo productos con LLMs. Hemos pasado por la fase de los prompts mágicos, por la fe ciega en que la redacción perfecta del mensaje era el secreto del éxito. Y hemos aprendido, a veces de forma dolorosa, que esa fe estaba equivocada.
Este artículo es mi opinión directa sobre lo que ha pasado, por qué el prompt engineering como disciplina aislada ha muerto, y qué es lo que verdaderamente mueve la aguja en los productos de IA en 2026.
La era de los prompts mágicos (2022-2024)
Cuando GPT-3 llegó al mainstream y GPT-4 lo popularizó, el mundo tech se dividió en dos grupos: los escépticos que pensaban que era todo humo, y los entusiastas que creían haber encontrado el oráculo definitivo. Los entusiastas tenían razón en algo: los LLMs eran genuinamente poderosos. Pero sacaron la conclusión equivocada sobre por qué funcionaban.
La narrativa dominante era: “La clave está en saber hablarle al modelo.” Surgieron cursos de “prompt engineering” a cientos de dólares. Aparecieron repositorios con miles de estrellas llenos de “prompts definitivos”. LinkedIn se llenó de perfiles que se autodenominaban “Prompt Engineer” como si fuera una profesión del futuro.
El problema no era que los prompts no importaran. El problema era la conclusión que se extraía: que la diferencia entre un producto de IA excelente y uno mediocre residía en haber encontrado la formulación correcta del mensaje. Que había prompts mágicos esperando ser descubiertos.
Esta idea era incorrecta. Y el mercado tardó entre 18 y 24 meses en darse cuenta.
Qué mató al prompt engineering
1. Los structured outputs hicieron obsoletos los prompts de formato
Durante años, una parte importante del trabajo de “prompt engineering” era conseguir que el modelo respondiera en el formato correcto. Pedías JSON y a veces obtenías JSON, a veces texto con JSON dentro, a veces algo que parecía JSON pero no lo era. Existían librerías enteras dedicadas a parsear y corregir la salida de los modelos.
Hoy, OpenAI, Anthropic y Google soportan nativamente structured outputs: defines un esquema JSON y el modelo garantiza que su respuesta cumple ese esquema. No hay magia, no hay redacción perfecta. Hay un contrato técnico.
# Antes: rezar para que el modelo respondiera en JSON
response = client.messages.create(
model="claude-3-5-sonnet",
messages=[{"role": "user", "content": "Extrae el nombre y email. Responde SOLO en JSON con campos 'nombre' y 'email'. NO incluyas texto adicional."}]
)
# Resultado: impredecible
# Ahora: definir el contrato
class ExtractedContact(BaseModel):
nombre: str
email: str
response = instructor.from_anthropic(client).messages.create(
model="claude-3-5-sonnet",
response_model=ExtractedContact,
messages=[{"role": "user", "content": "Extrae el contacto del texto"}]
)
# Resultado: garantizadoEl prompt de formato ha muerto. Lo ha matado la ingeniería.
2. El tool use hizo obsoletos los prompts de acción
El segundo gran pilar del prompt engineering era conseguir que el modelo tomara las decisiones correctas: “Si el usuario pregunta X, haz Y. Si pregunta Z, haz W.” Prompts con condicionales, árboles de decisión escritos en lenguaje natural.
El function calling lo reemplazó con elegancia. En lugar de intentar que el modelo simulara lógica de negocio mediante texto, le das herramientas reales y dejas que decida cuándo usarlas. El modelo es bueno tomando decisiones de alto nivel; el código es bueno ejecutando acciones con precisión.
tools = [
{
"name": "buscar_pedido",
"description": "Busca un pedido por ID o email del cliente",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"tipo": {"enum": ["id", "email"]}
}
}
},
{
"name": "actualizar_estado",
"description": "Actualiza el estado de un pedido",
"input_schema": {
"type": "object",
"properties": {
"pedido_id": {"type": "string"},
"nuevo_estado": {"enum": ["procesando", "enviado", "cancelado"]}
}
}
}
]No necesitas escribir “Si el usuario menciona un número de pedido, búscalo primero antes de responder.” El modelo lo infiere del contexto de las herramientas. Lo que antes era un párrafo de instrucciones en el prompt ahora es una definición de función.
3. El context engineering importa más que la redacción del prompt
Aquí está el insight que más nos ha costado interiorizar como industria: lo que metes en el contexto importa mucho más que cómo redactas la pregunta.
Puedes tener el prompt más elegante del mundo, pero si el modelo no tiene acceso a la información relevante, va a alucinar o va a dar respuestas genéricas. Y puedes tener un prompt básico, casi telegráfico, pero si le das la información correcta, el modelo va a rendir bien.
El context engineering es la disciplina de diseñar qué llega al modelo antes de que responda:
- RAG bien implementado: No solo embeddings y cosine similarity. Selección de chunks relevantes, reranking, filtrado por metadatos, contexto suficiente sin exceder el límite.
- Few-shot examples dinámicos: No ejemplos estáticos en el prompt. Ejemplos seleccionados dinámicamente según la consulta actual.
- Gestión del contexto conversacional: Qué turnos previos conservar, cuáles comprimir, cuáles descartar.
- Datos estructurados vs. texto: A veces es mejor darle al modelo una tabla bien formateada que un párrafo explicando los datos.
En nuestros proyectos, el 80% de las mejoras de calidad han venido de mejorar el contexto, no de reescribir el prompt.
4. La evaluación reemplazó al instinto
El prompt engineering clásico era fundamentalmente vibes-driven. Probabas una variación, parecía mejor, la publicabas. No había forma rigurosa de medir si realmente era mejor en todos los casos o solo en los que habías testeado manualmente.
La madurez del campo ha traído las evals: conjuntos de casos de prueba con criterios de evaluación explícitos, a menudo evaluados por otro LLM. Frameworks como RAGAS, LangSmith, Braintrust o PromptFoo permiten hacer esto sistemáticamente.
Cuando tienes evals, puedes hacer lo que hacías con el código: medir antes de cambiar, comparar versiones, detectar regresiones. El prompt deja de ser un artefacto artesanal que nadie toca por miedo a romper algo y se convierte en código versionado con tests.
Esto cambia la naturaleza del trabajo. No es intuición, es ingeniería.
Lo que ha reemplazado al prompt engineering: LLM Engineering
Lo que está emergiendo no es el prompt engineering evolucionado. Es una disciplina completamente diferente que toma prestado el nombre de software engineering porque eso es, esencialmente, lo que es.
El LLM engineering trata el modelo de lenguaje como un componente de sistema más: con interfaces definidas, contratos de datos, tests automatizados, observabilidad y despliegue continuo. El prompt es un archivo de configuración versionado en git, no un texto guardado en una variable de entorno que solo toca el experto del equipo.
Los pilares de esta disciplina:
System prompts como especificaciones de software: Versionados en git, revisados en pull requests, con tests de regresión. Si alguien cambia el system prompt, el pipeline de CI corre las evals y bloquea el merge si la calidad baja.
Structured outputs como contratos de API: El modelo es un servicio interno con una interfaz definida. Lo que devuelve tiene un schema. El resto del sistema confía en ese schema, no en parsear texto libre.
Tool use como arquitectura de agentes: En lugar de intentar que el modelo haga todo, le das herramientas especializadas y dejas que orqueste. La lógica de negocio vive en las herramientas (código testeable), no en el prompt.
Observabilidad y trazabilidad: Cada llamada al modelo se registra con su contexto completo, tokens usados, latencia, resultado. Cuando algo falla en producción, hay un trace que te dice exactamente qué pasó.
Evals como CI/CD para prompts: Antes de desplegar cualquier cambio al sistema prompt o a la arquitectura RAG, corres el suite de evals. Si la puntuación baja, no se despliega.
Dónde el prompting sigue importando
Sería deshonesto decir que los prompts no importan en absoluto. Importan. Pero en contextos específicos:
Tareas creativas: Cuando quieres que el modelo genere texto con un estilo particular, la redacción del prompt sigue siendo un arte. “Escribe en el estilo de un periodista de The Economist cubriendo tecnología” produce resultados distintos a “Escribe un artículo sobre tecnología”. Aquí la matiz del lenguaje importa.
Prototipado rápido: Cuando estás validando una idea en un par de horas, no tiene sentido construir toda la infraestructura de evals y structured outputs. Un prompt bien redactado en Cursor o en la consola de Anthropic es perfectamente válido para explorar la viabilidad.
Edge cases y comportamiento de razonamiento: Para tareas que requieren razonamiento en cadena (chain-of-thought), la manera en que estructuras el problema en el prompt sigue teniendo impacto. “Piensa paso a paso” y sus variaciones no son magia, pero sí son instrucciones que afectan al proceso de razonamiento.
Modelos sin tool use o structured outputs: Si por alguna razón trabajas con modelos más pequeños o desplegados localmente que no soportan estas capacidades, el prompting clásico sigue siendo relevante.
Lo que ha muerto no es el prompt en sí. Lo que ha muerto es la idea de que el prompt es el artefacto central alrededor del cual gira todo lo demás.
Qué debería aprender tu equipo
Si estás construyendo productos con LLMs en 2026, estas son las habilidades que realmente importan:
1. Diseño de schemas JSON: Saber definir estructuras de datos claras para los outputs del modelo. Pydantic, Zod, JSON Schema. Esto es más importante que saber redactar prompts.
2. Arquitecturas de agentes: Entender cómo diseñar sistemas donde el LLM orquesta herramientas especializadas. Patterns como ReAct, Plan-and-Execute, y cuándo usar cada uno.
3. RAG de producción: No el tutorial de 5 minutos con ChromaDB y embeddings básicos. RAG real incluye chunking estratégico, reranking, evaluación de relevancia, y monitorización de calidad.
4. Diseño y ejecución de evals: Saber definir qué significa “bueno” para tu caso de uso, construir conjuntos de prueba representativos, y ejecutar evaluaciones de forma sistemática.
5. Observabilidad de LLMs: Tracing, logging, monitorización de costes y latencia. Herramientas como LangSmith, Langfuse, o Helicone. No puedes mejorar lo que no puedes medir.
6. Gestión de contexto: Entender los límites del contexto, cuándo y cómo comprimir, cuándo usar memoria externa vs. contexto in-context.
Los prompts son parte de todo esto. Pero son un componente más, no el centro.
Conclusión: construye sistemas, no prompts
La diferencia entre un equipo que usa IA de forma productiva y uno que no no está en quién sabe escribir mejores prompts. Está en quién ha construido la infraestructura correcta alrededor del modelo: los contratos de datos, las herramientas, el pipeline de evaluación, la observabilidad.
El prompt engineer que solo sabe redactar mensajes es el equivalente a un frontend developer que solo sabe copiar código de Stack Overflow sin entender por qué funciona. Útil para tareas puntuales, insuficiente para construir productos de calidad.
Lo que el mercado demanda ahora son ingenieros que entiendan los LLMs como componentes de sistema: sus capacidades, sus limitaciones, y cómo integrarlos en arquitecturas de software reales.
En Soamee llevamos tiempo trabajando exactamente así. No vendemos prompts mágicos ni talleres de ChatGPT. Construimos productos de inteligencia artificial con la misma disciplina de ingeniería con la que construiríamos cualquier otro sistema de software: con contratos definidos, tests, observabilidad y despliegue continuo.
Si tu empresa está evaluando cómo integrar IA de forma seria, más allá del prototipo inicial, nos lo cuentas. Agenda una consultoría gratuita y hablamos de arquitectura, no de prompts.