Prompt Engineering en 2026: 10 Técnicas Que Siguen Funcionando (y 4 Que Murieron con los Modelos de Razonamiento)

El prompt engineering no murió en 2026. Se dividió en dos. La propia documentación de razonamiento de OpenAI ahora te dice que dejes de escribir "piensa paso a paso", y un paper de arXiv de 2024 (2410.21333) midió caídas de precisión de hasta el 36,3% cuando el chain-of-thought se forzaba en la tarea equivocada. Esa es la parte rara. La mitad casual del prompt engineering se volvió más fácil, mientras que la mitad de producción, la que corre en GPT-5 y Claude, se volvió mucho más rigurosa. Esta guía separa las 10 técnicas que aún merecen tu tiempo de los 4 hábitos que los modelos de razonamiento jubilaron.

Puntos clave:

• En 2026, el prompt engineering se dividió en prompting casual (más fácil) y prompting de producción (más riguroso).
• En los modelos de razonamiento, forzar "piensa paso a paso" es redundante y puede reducir la precisión. OpenAI dice que lo evites.
• Cuatro hábitos jubilados: forzar el chain-of-thought, el few-shot pesado por reflejo, el prefilling de respuestas y el ajuste manual de budget_tokens.
• Lo que sigue ganando: la claridad, los structured outputs, la descomposición de tareas y la iteración guiada por evaluación.

Qué Es Realmente el Prompt Engineering en 2026

El prompt engineering es la práctica de diseñar y refinar las instrucciones que le das a un modelo de lenguaje de gran tamaño para obtener resultados precisos y relevantes. Las técnicas principales incluyen zero-shot, few-shot, chain-of-thought y role prompting. En 2026 se divide en dos trabajos: el prompting casual en un chat y el prompting de producción dentro de un sistema.

Esto es lo que nadie decía en voz alta hasta este año: son dos habilidades distintas. Conseguir una buena respuesta en ChatGPT ahora es casi trivial, porque los modelos perdonan una redacción descuidada. Conseguir una respuesta fiable de un sistema que corre mil veces al día, en diez idiomas, sin nadie vigilando, no lo es. De ese segundo trabajo trata esta guía.

Escribimos para la franja de producción: developers e ingenieros de IA que necesitan instrucciones que aguanten en GPT-5, Claude Opus 4.8 y Gemini. La introducción, esta definición y las preguntas frecuentes siguen siendo legibles para todos los demás. Si quieres la taxonomía neutral de cada técnica con nombre propio, la referencia de promptingguide.ai de dair-ai sigue siendo la mejor enciclopedia de la web. En 2026, el prompt engineering ya no es una sola habilidad. Son dos.

Prompt Engineering vs Context Engineering: ¿Cuál Es la Diferencia?

El prompt engineering consiste en redactar la instrucción. El context engineering consiste en diseñar todo lo que entra en la ventana de contexto que la rodea: retrieval, memoria, herramientas, orden. El prompt engineering es un subconjunto del context engineering. Esta guía cubre la mitad de redacción del prompt; la guía enlazada cubre el resto.

Entonces, ¿cuál necesitas? Si tu contexto es estático y cabe en un solo mensaje, con prompt engineering te sobra. En el momento en que tu input cambia con cada petición, ya entraste en el terreno del context engineering, y el prompt engineering pasa a ser una herramienta más dentro de él. Ya cubrimos esa imagen completa en nuestra guía completa de context engineering; este artículo se queda del lado de la redacción de prompts.

Una nota para los coleccionistas de entidades: el autocompletado de Google ya está estirando esto hacia una división en cuatro disciplinas de "engineering", y nosotros cubrimos las dos primeras: prompt y context. Dicho de forma simple, el prompt engineering es elegir las palabras correctas para la pregunta; el context engineering es decidir qué hay sobre la mesa antes de que se haga la pregunta.

Las 10 Técnicas Principales de Creación de Prompts (Ordenadas por ROI en 2026)

Las diez técnicas que vale la pena conocer en 2026, ordenadas más o menos por retorno sobre el esfuerzo: zero-shot, few-shot, role prompting, chain-of-thought, descomposición de tareas, prompt chaining, self-consistency, structured outputs, plantillas de prompts y meta-prompting. Algunas son herramientas de uso diario; dos se comportan distinto en los modelos de razonamiento, algo que resuelve la siguiente sección.

Los nombres de abajo siguen la taxonomía de "The Prompt Report", una revisión sistemática de más de 50 técnicas de prompting. Trata esto como una caja de herramientas de la que echas mano, no como una checklist que sigues de arriba a abajo.

1. Zero-shot prompting

Zero-shot significa que das una instrucción clara y ningún ejemplo, y dejas que el modelo lo resuelva. En los modelos de 2026 este es tu primer movimiento por defecto, porque una instrucción precisa y específica suele ganarle a una recargada. El truco no es una redacción mágica, es eliminar la ambigüedad: di qué output quieres, en qué formato, y para quién.

# Target: GPT-5 / Claude Opus 4.8
Classify this support ticket as: billing, technical, or account.
Return only the single lowercase label.

Ticket: "My card was charged twice this month."

2. Few-shot prompting

Few-shot significa que incluyes de dos a cinco ejemplos para moldear el formato o el comportamiento que quieres. Es la forma más rápida de fijar un estilo de output del que el modelo se sigue desviando. Una advertencia: en los modelos de razonamiento, las buenas prácticas de razonamiento de OpenAI dicen que pruebes primero con zero-shot y añadas ejemplos solo si ayudan de forma medible. En los modelos de 2026, zero-shot es la opción por defecto y few-shot es el respaldo, no al revés.

# Target: GPT-5
Extract the product and sentiment. Follow the examples.

Input: "The battery dies in an hour." -> product: battery, sentiment: negative
Input: "Setup took two minutes, loved it." -> product: setup, sentiment: positive
Input: "The screen is gorgeous but it's heavy." ->

3. Prompting de rol o persona

El role prompting define quién es el modelo antes de que responda, lo que moldea el tono, el vocabulario y el formato más de lo que moldea el razonamiento en bruto. "Eres un contador senior revisando una declaración de impuestos" saca un lenguaje distinto al de un prompt en blanco. Mantenlo funcional, no teatral. El rol debería codificar restricciones reales: audiencia, formato, qué omitir. Nuestra próxima colección de ejemplos de system prompts reunirá los patrones que más reutilizamos.

# Target: Claude Opus 4.8
You are a senior tax accountant. Review the figures below for a
small-business owner who is not an accountant.
Format: 3 bullet points, plain English, flag any number that looks wrong.

4. Chain-of-thought (CoT)

El chain-of-thought le pide al modelo que muestre sus pasos de razonamiento antes de la respuesta final. En los modelos clásicos estilo GPT sigue siendo uno de los trucos de mayor valor para matemáticas, lógica y problemas de varios pasos. Pero en los modelos de razonamiento puede ser redundante o incluso perjudicial, algo que la siguiente sección cubre con números reales. Nuestro próximo análisis a fondo sobre chain-of-thought prompting recorrerá la técnica completa. Por ahora, recuerda que ya no es un reflejo que apliques a todo.

5. Descomposición de tareas

La descomposición significa partir una petición grande en subtareas ordenadas que el modelo maneja de una en una. En lugar de "escribe un plan de lanzamiento", pides primero la audiencia, luego los canales, luego el calendario. Pasos más pequeños significan menos lugares donde algo puede salir mal, y una depuración más fácil cuando sí sale mal.

# Target: any 2026 model
Task: draft a product launch email.
Work in order and label each step:
1) Identify the audience and their main objection.
2) Write one subject line that answers that objection.
3) Write a 90-word body.
4) End with a single CTA.

6. Prompt chaining

El chaining alimenta el output de un prompt como input del siguiente. Es la descomposición hecha realidad en código: el prompt A extrae los datos clave, el prompt B redacta a partir de esos datos, el prompt C revisa el borrador contra una regla. Cada eslabón es simple, testeable e intercambiable. Cuando un paso falla, arreglas ese eslabón en lugar de desenredar un prompt monolítico gigante.

7. Self-consistency

El self-consistency muestrea la misma pregunta varias veces y se queda con la respuesta mayoritaria. Cambia tokens por fiabilidad en razonamientos difíciles donde una sola pasada es inestable, pero terminas pagando por tres a cinco completions para quedarte con una. En modelos de razonamiento potentes, la ganancia suele reducirse, así que resérvalo para tareas genuinamente ambiguas donde acertar importa más que la factura.

8. Formato del output / structured outputs

Structured outputs significa restringir la respuesta a un schema en lugar de esperar que el modelo devuelva un JSON limpio por las buenas. Esta técnica se gana su propia sección más abajo. La versión de una línea: no le supliques JSON al modelo en el prompt, restríngelo a un schema y deja de adivinar.

9. Plantillas de prompts y variables

Las plantillas convierten un buen prompt puntual en un activo parametrizado y reutilizable: instrucciones fijas más espacios para las partes variables. Así es como los prompts dejan de ser texto improvisado y pasan a ser artefactos versionados que puedes testear, que es la historia del pipeline más abajo. Los archivos de reglas de proyecto reutilizables, como las cursor rules que los developers guardan en sus repos, son plantillas de prompts vivas con otro nombre.

10. Meta-prompting

El meta-prompting es usar un modelo para escribir o mejorar tu prompt. Se ha convertido en el camino más rápido desde una caja en blanco hasta un borrador sólido, y tiene datos reales detrás, que cubrimos justo abajo. Versión corta: parte de un borrador mejorado por el modelo y después edítalo a mano.

¿Qué Técnicas de Prompting Volvieron Opcionales (o Rompieron) los Modelos de Razonamiento?

Cuatro hábitos que antes eran buenos consejos ahora se vuelven en contra en los modelos de razonamiento como la serie o de OpenAI, GPT-5 y los modos thinking de Claude: forzar el chain-of-thought explícito, apilar few-shot pesado por defecto, el prefilling de respuestas y ajustar budget_tokens a mano. Los modelos de razonamiento ya piensan internamente, así que guionizar los pasos es redundante, y a veces peor que redundante.

Cada uno murió por una razón distinta.

Forzar el chain-of-thought. Las buenas prácticas de razonamiento de OpenAI son directas: "Evita los prompts de chain-of-thought", porque estos modelos razonan internamente, así que decirles que "piensen paso a paso" es "innecesario" y "puede no mejorar el rendimiento (y a veces puede perjudicarlo)". El paper de arXiv 2410.21333 le puso un número a la desventaja: hasta un 36,3% menos de precisión absoluta para o1-preview frente a GPT-4o en una tarea donde pensar paso a paso de forma deliberada de verdad perjudica. Un segundo estudio, 2412.21187, muestra que los modelos de razonamiento gastan de más en cómputo en problemas triviales. Dejamos de añadir "piensa paso a paso" a los prompts de modelos de razonamiento hace meses, y nada empeoró.

El few-shot pesado por reflejo. La guía de OpenAI es "mantén los prompts simples y directos" y "prueba primero zero-shot, luego few-shot si hace falta". Amontonar ejemplos por defecto ahora cuesta tokens y puede encasillar a un modelo capaz. Añade ejemplos cuando ayuden de forma medible, no como un ritual de calentamiento.

El prefilling de respuestas. Poner palabras en boca del modelo para forzar un formato solía ser un truco estándar. En Claude 4.6+, Fable 5 y Mythos 5, los turnos de assistant precompletados ya no se soportan y devuelven un error 400, según las buenas prácticas de prompting de Anthropic. Usa structured outputs en su lugar, algo que cubre la siguiente sección.

La micro-gestión manual de budget_tokens. Configurar a mano un presupuesto de tokens de pensamiento también está deprecado (un error 400 en Opus 4.7+ y versiones más nuevas). Los modelos de Anthropic ahora usan thinking adaptativo, y diriges el esfuerzo con el parámetro effort en lugar de guionizar un número. OpenAI hizo el mismo movimiento: los developer messages son los nuevos system messages, y el esfuerzo de razonamiento es una opción de configuración. El truco clásico, "pensemos paso a paso", ahora, en los modelos de razonamiento, a veces es justo lo que los empeora.

¿Cómo Consigues JSON Fiable de un LLM en 2026?

Structured outputs restringidos por schema, no súplicas en el prompt. En 2026 el camino fiable es darle al modelo un JSON schema y dejar que la API garantice un output válido contra ese schema. Escribir "por favor devuelve JSON" en el prompt es frágil; el truco deprecado del prefill ya no existe. Tanto OpenAI como Anthropic ofrecen una función de structured outputs justo para esto.

¿Por qué es tan frágil "por favor devuelve JSON válido"? Porque le estás pidiendo a un sistema probabilístico que sea perfectamente sintáctico bajo el sistema de honor. Un comentario suelto o una coma sobrante y tu parser explota. Structured Outputs arregla esto a nivel de API: pasas un schema, y el modelo queda restringido a cumplirlo. Anthropic señala que los modelos más nuevos "pueden igualar de forma fiable schemas complejos cuando se les indica".

Aquí tienes un schema de respuesta pequeño y realista para un clasificador de tickets de soporte:

{
  "name": "ticket_classification",
  "schema": {
    "type": "object",
    "properties": {
      "category": { "type": "string", "enum": ["billing", "technical", "account"] },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "summary": { "type": "string", "maxLength": 120 }
    },
    "required": ["category", "priority", "summary"],
    "additionalProperties": false
  }
}

Pásale eso al structured outputs de OpenAI o de Anthropic y obtienes JSON parseable cada vez, sin bucle de reintentos. Para el patrón completo entre proveedores, incluida la validación con Pydantic y Zod, revisa nuestra guía para conseguir JSON fiable de cualquier LLM. En 2026 no le pides JSON a un modelo. Lo restringes a un schema y dejas de tener esperanzas.

Meta-Prompting: Deja Que el Modelo Escriba Tu Prompt

El meta-prompting significa usar un LLM para redactar o refinar el prompt que vas a ejecutar de verdad. Es la forma más rápida de pasar de una idea tosca a un prompt que funciona, y el tooling ya viene integrado: tanto el prompt improver de Anthropic como el prompt optimizer de OpenAI reescriben tu borrador siguiendo las mejores prácticas. Parte de la versión de la máquina y luego edítala a mano.

¿De verdad ayuda, o es un truco de fiesta? Anthropic sacó sus propios números: su prompt improver logró una ganancia de precisión del 30% en una prueba de clasificación multietiqueta y un cumplimiento del 100% del límite de palabras en una tarea de resumen, según su propio artículo. El prompt optimizer de OpenAI hace el mismo trabajo.

El flujo que nos gusta: describe la tarea, deja que la herramienta produzca un primer borrador estructurado, y luego ajústalo a mano para tus datos. Esa última edición manual es la razón por la que los prompts todavía necesitan a una persona y una prueba. La forma más rápida de llegar a un mejor prompt en 2026 es dejar que el modelo reescriba el tuyo y luego editarlo. No quedarte mirando una caja en blanco.

Chuleta de Prompting por Modelo (OpenAI vs Anthropic vs Google)

Mismo trabajo, tres dialectos. OpenAI quiere developer messages y nada de chain-of-thought forzado. Anthropic quiere etiquetas XML, thinking adaptativo y el parámetro effort. El Gemini de Google quiere un presupuesto de pensamiento (thinking budget). Los modelos de razonamiento son tus planificadores; los modelos clásicos estilo GPT son tus caballos de batalla. Ajusta la técnica al nivel del modelo.

Las diferencias son pequeñas, pero muerden. En OpenAI, los developer messages reemplazaron al viejo system message para la serie o en adelante, y la documentación te aleja del CoT explícito. En Anthropic, las etiquetas XML siguen siendo la forma recomendada de estructurar un prompt complejo, y el thinking es adaptativo por defecto. Los archivos de prompts a nivel de proyecto, como los archivos CLAUDE.md que los equipos de desarrollo guardan en sus repos, concentran buena parte de este cableado específico de cada proveedor. En Gemini, le entregas al modelo un presupuesto de pensamiento.

Del Prompt al Pipeline: Plantillas, Versionado y Evaluación

En producción, el prompt engineering deja de tratarse de la redacción y se convierte en una disciplina empírica. Versionas los prompts como si fueran código, los filtras con evals y añades tests de regresión para que un cambio que rompe el output en silencio se detecte antes de que lo vean tus usuarios. Aquí es donde el prompt engineering se encuentra con la evaluación, y es la parte que de verdad decide si tu app funciona.

Así es como se ve eso en un sistema real. Este blog corre sobre un pipeline de contenido impulsado por Claude con 17 subagentes especializados, cada uno un rol con su propio prompt: un researcher, un brief-creator, un content-writer, un validator, un language-translator, un sanity-publisher, un image-handler y más. En tres de esas etapas, brief, writer y validator, aplicamos 8 reglas de guardarraíles anti-detección. El validator revisa cada borrador contra una lista negra de 52 frases prohibidas, y un solo acierto bloquea la publicación, respaldado por un script de revisión léxica aparte. Ese pipeline ya ha publicado cerca de 194 artículos en inglés en 4 sitios, cada uno traducido a hasta 10 idiomas por agentes paralelos por idioma.

Nada de eso vino de una redacción ingeniosa. Vino de tratar los prompts como artefactos versionados y filtrados por evals, y dos incidentes nos enseñaron por qué.

El primero fue un bug de diacríticos. Nuestro prompt de traducción devolvía de forma intermitente ASCII en lugar de Unicode, así que la palabra turca "karşılaştırma" volvía como "karsilastirma". Silencioso, feo y fácil de pasar por alto a escala. El arreglo no fue una mejor frase, fue una instrucción reforzada más una puerta de grep que cuenta caracteres nativos y vuelve a ejecutar la traducción automáticamente si el conteo llega a cero. Un test de regresión, sobre un prompt.

El segundo fue peor. Un prompt de re-traducción empezó a acuñar slugs localizados ligeramente distintos, así que el publisher creaba un documento completamente nuevo mientras el viejo se quedaba en vivo. Eso produjo 54 documentos duplicados en vivo, que activaron las exclusiones por duplicado de Google Search Console. El arreglo fue un guardarraíl en el prompt que fuerza la reutilización del slug existente, más una regla de resolver-antes-de-crear en el publisher.

La lección caló hondo: el prompt que publicó 194 artículos en diez idiomas no ganó por su redacción. Ganó porque una puerta de grep lo volvía a ejecutar en el momento en que se desviaba. Eso es la evaluación de LLM en acción, y por eso emparejamos cada prompt importante con herramientas de gestión de prompts para versionarlos y poder revertirlos. Para un prefijo estable que se repite en miles de llamadas, lo cacheamos para reducir el costo. Este es exactamente el tipo de pipeline de prompts y evals que construimos para clientes.

Errores Comunes de Prompt Engineering (y las Soluciones de 2026)

Los errores costosos en 2026 no son errores tipográficos. Son estructurales: instrucciones vagas, sobre-guionizar modelos de razonamiento, publicar sin un ciclo de evals, ignorar el comportamiento específico de cada modelo, saturar el prompt cuando el problema real es el contexto, y confiar en input que no es confiable. Cada uno tiene una solución clara, y la mayoría no cuesta nada más que atención.

Repasa la lista y sé honesto sobre cuáles de estos cometes:

• Instrucciones vagas. "Hazlo mejor" no le da al modelo nada hacia dónde apuntar. Di qué significa "mejor": más corto, más amable, JSON válido, menos de 120 palabras.
• Sobre-guionizar modelos de razonamiento. Forzar "piensa paso a paso" en un modelo de la serie o o en un modelo thinking es el error que cubrimos arriba. Déjalo razonar; sube el esfuerzo en su lugar.
• Sin ciclo de evals. Si no puedes saber si un cambio en el prompt ayudó o perjudicó, estás adivinando. Añade casos de prueba y una verificación de pasa/no pasa.
• Ignorar el comportamiento específico de cada modelo. El prompt que brilla en GPT-5 puede necesitar etiquetas XML en Claude. Lee la chuleta de arriba.
• Saturar el prompt. Meter más y más en una sola instrucción cuando la brecha real es de retrieval o memoria significa que necesitabas context engineering, no un prompt más largo.
• Confiar en input que no es confiable. El contenido de usuarios y los documentos recuperados pueden llevar instrucciones ocultas. Añade guardrails a su alrededor; nuestro próximo análisis a fondo sobre prevención de prompt injection cubre el lado de seguridad por completo.

El error de prompt más caro en 2026 no es un error tipográfico. Es publicar sin un eval que hubiera detectado la regresión.

¿Está Muerto el Prompt Engineering? Una Respuesta Honesta para 2026

No. El prompt engineering no está muerto, se bifurcó. El prompting casual se volvió más fácil porque los modelos se volvieron más inteligentes y más tolerantes. El prompting de producción se volvió más difícil, porque la fiabilidad, los structured outputs y la evaluación ahora importan más que una redacción ingeniosa. La palabra "engineering" por fin significa lo que dice.

Entonces, ¿por qué todo el mundo lo sigue declarando muerto? Porque la mitad visible, escribir una petición en ChatGPT, de verdad se volvió trivial. La mitad que no se volvió más fácil, publicar un prompt que aguanta en miles de llamadas y diez idiomas, no genera titulares. La verdadera habilidad de 2026 no es una frase mágica. Es la evaluación, la elección de nivel de modelo (planificador vs. caballo de batalla), y saber cuándo un problema le quedó grande al prompt y se convirtió en context engineering. La mitad fácil se volvió más fácil y la mitad difícil se volvió más difícil, y solo una de las dos genera titulares.

Si hay una sola conclusión: 10 técnicas siguen ganándose su lugar, 4 hábitos viejos ahora te cuestan caro en los modelos de razonamiento, y la evaluación es la habilidad que separa una demo de un producto. ¿Estás construyendo algo donde los prompts tienen que aguantar en producción? Consigue una consultoría gratuita y te ayudamos a montar primero el ciclo de evals.

Preguntas Frecuentes

¿Qué es el prompt engineering en el contexto de la IA generativa?

El prompt engineering es la práctica de diseñar y refinar las instrucciones que le das a un modelo de lenguaje de gran tamaño para obtener un output preciso y relevante. Cubre técnicas como zero-shot, few-shot, chain-of-thought y role prompting. En 2026 se divide en prompting casual de chat y prompting de producción riguroso dentro de un sistema.

¿Está muerto el prompt engineering en 2026?

No, el prompt engineering no está muerto en 2026, se bifurcó. El prompting casual se volvió más fácil a medida que los modelos se hicieron más tolerantes. El prompting de producción se volvió más riguroso, porque los structured outputs, la evaluación y la fiabilidad ahora importan más que una redacción ingeniosa. La habilidad no desapareció; la mitad fácil simplemente dejó de necesitarte.

¿Cuál es la diferencia entre prompt engineering y context engineering?

El prompt engineering redacta la instrucción; el context engineering diseña todo lo demás en la ventana de contexto: retrieval, memoria, herramientas y orden. El prompt engineering es un subconjunto del context engineering. Necesitas context engineering en cuanto tus inputs cambian con cada petición, como en agentes y sistemas RAG.

¿Sigues necesitando chain-of-thought prompting con los modelos de razonamiento?

Normalmente no. En los modelos de razonamiento como la serie o de OpenAI, GPT-5 y los modos thinking de Claude, forzar "piensa paso a paso" es redundante porque razonan internamente, y OpenAI dice que puede perjudicar el rendimiento. El chain-of-thought todavía ayuda en los modelos clásicos estilo GPT, así que ajusta la técnica al nivel del modelo.

¿El prompt engineering requiere programar?

No, no para empezar. Cualquiera puede escribir instrucciones claras y conseguir mejores respuestas de ChatGPT o Claude. Pero el prompt engineering de producción, versionar prompts, conectar structured outputs y construir ciclos de evals, es una disciplina de developers. La mitad casual no necesita código; la mitad profesional sí.

¿Cuál es la diferencia entre zero-shot y few-shot prompting?

El zero-shot prompting da una instrucción clara sin ejemplos; el few-shot incluye de dos a cinco ejemplos para moldear el formato o el comportamiento del output. En los modelos de 2026, empieza con zero-shot porque siguen bien las instrucciones, y añade few-shot solo cuando los ejemplos mejoran los resultados de forma medible. Few-shot es el respaldo, no la opción por defecto.

¿Cómo consigo que un LLM devuelva JSON de forma fiable?

Usa structured outputs restringidos por schema, no súplicas en el prompt. En lugar de escribir "por favor devuelve JSON", pasa un JSON schema a través de la función de Structured Outputs de OpenAI o de Anthropic, que restringe al modelo a un output válido y parseable. El viejo truco del prefill ahora devuelve un error 400 en los modelos más nuevos de Claude.

¿Qué es el meta-prompting?

El meta-prompting es usar un modelo para redactar o mejorar el prompt que vas a ejecutar. Herramientas como el prompt improver de Anthropic y el prompt optimizer de OpenAI reescriben tu borrador siguiendo las mejores prácticas; Anthropic midió una ganancia de precisión del 30% en una prueba. Genera un primer borrador y después edítalo a mano para tus datos.

¿Es el prompt engineering una carrera o un trabajo real?

Sí, es una habilidad real, aunque el título independiente de "prompt engineer" se está diluyendo dentro de roles más amplios de AI engineering. Los empleadores quieren gente que sepa redactar prompts y también diseñar evals, structured outputs y pipelines de contexto. Como carrera, es más sólida como una parte del kit de herramientas de un AI engineer.

¿En qué se diferencia el prompting entre ChatGPT, Claude y Gemini?

El trabajo es el mismo; el dialecto cambia. OpenAI usa developer messages y te aleja del chain-of-thought explícito en los modelos de razonamiento. El Claude de Anthropic prefiere etiquetas XML, thinking adaptativo y el parámetro effort. El Gemini de Google usa un thinking budget. Los modelos de razonamiento son planificadores; los modelos clásicos estilo GPT son caballos de batalla.

Sources

• OpenAI: Reasoning best practices
• OpenAI: Structured Outputs
• OpenAI: Prompt optimizer
• Anthropic: Claude prompting best practices
• Anthropic: Structured Outputs
• Anthropic: Prompt improver (docs)
• Anthropic: Prompt improver announcement
• arXiv 2410.21333: Mind Your Step (by Step)
• arXiv 2412.21187: Do NOT Think That Much for 2+3?
• arXiv 2406.06608: The Prompt Report
• Prompt Engineering Guide (dair-ai)