Prompt engineering para desarrolladores: técnicas avanzadas con Claude y GPT

Prompt engineering: la habilidad que separa a los desarrolladores buenos de los excelentes

En 2026, saber programar ya no es suficiente. Los equipos de desarrollo más productivos dominan el prompt engineering: la capacidad de comunicarse eficazmente con modelos de IA para obtener código preciso, arquitecturas coherentes y soluciones optimizadas. No se trata de «hablar con un chatbot», sino de diseñar instrucciones que maximicen la calidad del output.

Nota de actualización (julio de 2026): hemos revisado y ampliado esta guía. Las referencias de modelos están actualizadas a la generación actual —Claude Opus 5 y Sonnet 5 de Anthropic, y la familia GPT-5.6 de OpenAI— y añadimos las técnicas que se han consolidado en los últimos meses: flujos agénticos, context engineering, plantillas listas para usar y seguridad del prompt.

Técnicas fundamentales que todo dev debería conocer

Chain of thought (cadena de pensamiento): en lugar de pedir directamente «escribe una función que…», pide al modelo que primero razone sobre el enfoque, luego diseñe la estructura y finalmente implemente. Con Claude, esto se activa pidiendo «piensa paso a paso» y produce código significativamente más robusto.

Few-shot con ejemplos: proporcionar 2-3 ejemplos del patrón que esperas antes de la tarea principal. Tanto GPT como Claude responden mejor cuando ven el formato, estilo de código y convenciones que quieres mantener. Esto es especialmente útil cuando trabajas con APIs de un CRM como SuiteCRM y quieres que el modelo respete la estructura de datos existente.

System prompts específicos: definir el rol del modelo con precisión. «Eres un senior backend developer especializado en Python/Django que trabaja con SuiteCRM API v8» produce resultados muy diferentes a «escribe código Python».

Técnicas avanzadas con Claude

Claude Opus 5 responde especialmente bien a prompts estructurados con XML tags. Envolver el contexto en etiquetas como <codebase>, <requirements> y <constraints> permite al modelo separar claramente qué es código existente, qué debe implementar y qué limitaciones respetar.

Otra técnica potente es el artifact thinking: pedir a Claude que primero genere un plan de implementación como artefacto separado, revisarlo, y luego pedir la implementación. Esto reduce drásticamente los ciclos de «esto no es lo que quería».

Técnicas avanzadas con GPT

GPT-5.6 responde muy bien al meta-prompting: pedirle que primero genere el mejor prompt para la tarea que necesitas resolver, y luego ejecutar ese prompt. También destaca con instrucciones que especifican el output esperado de forma muy concreta: «Genera un componente React en TypeScript con props tipadas, tests con Jest y Storybook stories».

Del prompt suelto al flujo agéntico

El cambio más importante desde que publicamos este artículo no es ninguna técnica de redacción: es que el prompt ha dejado de ser una conversación aislada para convertirse en la pieza de un flujo agéntico. Herramientas como Claude Code —que ya usa una parte enorme de los equipos de desarrollo, como contamos al analizar por qué Claude Code se ha convertido en el asistente de referencia— no responden a un prompt: ejecutan tareas completas, leen el repositorio, lanzan tests y corrigen sus propios errores.

Esto cambia dónde vive el prompt engineering. Además del mensaje puntual, ahora escribes instrucciones persistentes en ficheros como CLAUDE.md o AGENTS.md en la raíz del repositorio: convenciones de código, comandos de build y test, arquitectura del proyecto, límites que el agente no debe cruzar. Un buen fichero de instrucciones es el system prompt de todo tu equipo, versionado en Git como cualquier otro artefacto. Las skills —instrucciones empaquetadas para tareas recurrentes (desplegar, revisar una PR, generar un informe)— siguen la misma lógica: prompt engineering convertido en infraestructura reutilizable.

Dos consecuencias prácticas. Primera: el retorno de invertir una tarde en escribir un buen CLAUDE.md supera al de cualquier truco de prompting individual, porque se aplica a cada tarea que el agente ejecute a partir de entonces. Segunda: la especificidad sigue mandando, pero ahora se expresa en criterios verificables («los tests deben pasar», «respeta el linter del proyecto») que el agente puede comprobar solo, cerrando el bucle sin intervención humana.

Context engineering: el prompt es solo la mitad

La generación actual de modelos maneja ventanas de contexto de un millón de tokens, y eso ha desplazado el foco del «qué escribo» al «qué le enseño». Context engineering es decidir qué información entra en el contexto y en qué forma: el fichero correcto del repositorio vale más que tres párrafos describiéndolo, y un contexto saturado de ruido degrada la calidad de la respuesta aunque el prompt sea impecable.

Tres prácticas concretas. Uno: pasa código real, no descripciones —los modelos respetan mejor las convenciones que ven que las que les cuentas—. Dos: mantén la documentación funcional al día, porque es el mejor contexto posible; de hecho, la propia IA ayuda a generarla, como vimos en nuestra guía de documentación funcional de proyectos IT con IA. Tres: cuando el conocimiento no cabe en el contexto —catálogos, histórico de tickets, normativa interna—, la respuesta es RAG: recuperar solo los fragmentos relevantes e inyectarlos en el prompt en el momento de la consulta.

Plantillas listas para usar

Tres plantillas que usamos a diario en proyectos reales, adaptables a cualquier stack:

Revisión de código:

Actúa como revisor senior de [stack]. Revisa este diff centrándote en: seguridad (inyección, validación de entrada, secretos), rendimiento (consultas N+1, memoria) y mantenibilidad. Para cada hallazgo: severidad, línea, explicación en una frase y propuesta de corrección. No comentes estilo, de eso se encarga el linter.

Refactor seguro:

Refactoriza [fichero] para [objetivo]. Restricciones: no cambies la API pública, mantén compatibilidad con los tests existentes, un solo cambio conceptual por commit. Antes de tocar código, lista los pasos y los riesgos de cada uno. Espera mi confirmación.

Depuración dirigida:

Este es el error: [stacktrace]. Este es el código relevante: [ficheros]. Formula 3 hipótesis ordenadas por probabilidad, indica qué evidencia confirmaría o descartaría cada una, y propón el experimento más barato para discriminar entre ellas. No propongas soluciones todavía.

Fíjate en el patrón común: rol, contexto real, tarea acotada, formato de salida y —la parte que casi todo el mundo olvida— qué no debe hacer.

Errores comunes que cometen los devs

El error más frecuente es ser demasiado vago. «Haz un API» no produce lo mismo que «Diseña un endpoint REST POST /api/leads que reciba nombre, email y teléfono, valide los campos, cree un Lead en SuiteCRM vía API REST v8, y retorne el ID del lead creado con status 201». La especificidad es la clave.

Otro error común: no iterar. Los mejores resultados vienen de conversaciones iterativas donde refinas el output paso a paso, no de un solo prompt mágico.

Prompt engineering por tipo de tarea

No todas las tareas de desarrollo se benefician igual de las mismas técnicas. Un resumen de lo que mejor funciona en cada frente:

Frontend y componentes. Aquí mandan los ejemplos: pásale un componente existente del proyecto como referencia de estilo y pide variaciones sobre él. Especifica framework, sistema de tipos y librería de estilos en el rol, y exige accesibilidad (ARIA, navegación por teclado) en las restricciones, porque los modelos la omiten si no se pide.

Backend y APIs. El contrato es el rey: proporciona el esquema OpenAPI, los modelos de datos o las migraciones antes que ninguna descripción en prosa. Pide manejo de errores explícito y casos límite en el mismo prompt; si los pides después, el modelo tenderá a parchear en lugar de diseñar.

SQL y datos. Pasa siempre el esquema real de las tablas (un SHOW CREATE TABLE vale más que tres párrafos) y los volúmenes aproximados, porque la consulta óptima para mil filas y para diez millones no es la misma. Pide el plan de ejecución esperado y los índices necesarios junto a la consulta.

Tests. Invierte el orden: pide primero la lista de casos que habría que cubrir —incluidos los límite y los de error— y revísala antes de generar el código de los tests. Generar tests directamente produce cobertura aparente: muchos asserts, pocos escenarios que importen.

DevOps y scripting. Máxima precaución: exige que todo script sea idempotente, con modo de simulación (--dry-run) y sin credenciales embebidas. Es el terreno donde un error del modelo sale más caro, así que el prompt debe pedir explícitamente confirmación antes de acciones destructivas.

Seguridad: el prompt también es superficie de ataque

Cuanto más poder le das al modelo, más importa lo que puede salir mal. Tres frentes a vigilar en 2026:

Prompt injection. Si tu aplicación inyecta contenido externo en el prompt —webs, emails, documentos de usuarios—, ese contenido puede contener instrucciones maliciosas que el modelo ejecute como si fueran tuyas. Trata todo texto externo como datos, no como órdenes: delimítalo claramente, valida las salidas y no des al agente permisos que no necesita. Es el equivalente moderno de la inyección SQL, y se mitiga con la misma mentalidad que aplicamos a la seguridad de las APIs REST: mínimo privilegio y validación en la frontera.

Fuga de datos. Cuidado con pegar en el prompt credenciales, datos personales de clientes o código propietario en cuentas personales sin acuerdo empresarial. Define en el equipo qué se puede compartir con qué herramienta, igual que harías con cualquier proveedor externo; si tu empresa gestiona la seguridad de la información con un marco tipo ISO 27001, el uso de IA generativa debe entrar en ese perímetro.

Código generado sin revisar. El modelo escribe rápido, pero la responsabilidad del merge es tuya. Los estudios siguen mostrando tasas relevantes de vulnerabilidades en código generado cuando nadie lo audita: mantén la revisión humana y los tests como puerta de entrada, exactamente igual que con un desarrollador junior brillante pero sin experiencia en tu dominio.

Cómo saber si tus prompts funcionan

El prompt engineering profesional se mide, no se intuye. No hace falta un framework de evaluación completo para empezar: guarda los prompts que funcionan en un repositorio compartido del equipo, define 3-5 casos de prueba representativos para los prompts críticos (los que están en producción o en flujos agénticos), y cuando cambies un prompt, pásalo contra esos casos antes de desplegarlo. Es el mismo principio que los tests de regresión: barato de montar, y te avisa cuando una «mejora» rompe lo que ya funcionaba. Para prompts de aplicación (chatbots, RAG, automatizaciones), añade una métrica de negocio: tasa de respuestas útiles, escalados a humano, tiempo ahorrado por ticket.

Aplicación práctica en proyectos reales

En nuestros proyectos de vibe coding y prototipado con IA, usamos prompt engineering para acelerar cada fase: desde el diseño de la arquitectura hasta la implementación de integraciones con sistemas de gestión comercial. La diferencia entre un prompt bien diseñado y uno genérico puede ser de horas de trabajo ahorradas por sprint.

Elegir modelo con cabeza: coste, latencia y tarea

Parte del prompt engineering moderno es decidir qué modelo ejecuta qué. Los modelos punteros (Claude Opus 5, GPT-5.6 en sus variantes altas) brillan en arquitectura, refactors complejos y depuración difícil, pero son más caros y lentos; los modelos ligeros (Haiku, las variantes mini) resuelven perfectamente tareas mecánicas como generar boilerplate, escribir mensajes de commit, clasificar tickets o transformar formatos de datos. En flujos automatizados, esa diferencia se multiplica por miles de ejecuciones al mes: enrutar cada tarea al modelo más barato que la resuelve bien puede reducir la factura de API en un orden de magnitud sin pérdida de calidad apreciable.

La regla práctica que aplicamos en proyectos: empieza el diseño con el modelo grande, estabiliza el prompt y las plantillas, y después prueba si el modelo pequeño mantiene la calidad con esos mismos prompts ya pulidos. Un prompt bien estructurado —rol, contexto, ejemplos, formato— es precisamente lo que permite a un modelo modesto rendir por encima de su categoría; los prompts vagos, en cambio, solo los salva el modelo caro.

Preguntas frecuentes

¿Sigue mereciendo la pena aprender prompt engineering en 2026?

Sí, pero ha cambiado de forma. Los modelos actuales perdonan mejor los prompts mediocres, así que el retorno ya no está en trucos de redacción sino en estructurar contexto, instrucciones persistentes y criterios verificables para flujos agénticos. Es menos «ingeniería del prompt» y más ingeniería del entorno en el que trabaja la IA.

¿Qué modelo es mejor para programar, Claude o GPT?

Ambas familias están en un nivel altísimo y la respuesta cambia cada pocos meses. En nuestra experiencia, más importante que el modelo es el flujo: un equipo con buen contexto versionado, plantillas compartidas y revisión sistemática obtiene mejores resultados con cualquier modelo que un equipo que improvisa prompts con el mejor modelo del mercado.

¿Debo escribir los prompts en inglés o en español?

Los modelos actuales rinden muy bien en español, y para instrucciones de negocio o dominio es preferible la lengua del equipo. En tareas de código puro, el inglés sigue teniendo una ligera ventaja porque el corpus de entrenamiento técnico es mayoritariamente anglófono; muchos equipos mezclan ambos sin problema.

¿Cómo introduzco esto en mi equipo sin generar caos?

Empieza por un repositorio de prompts compartido y un fichero de instrucciones por proyecto, y acuerda las reglas de seguridad (qué datos no se pegan nunca en un chat). Después forma al equipo en las técnicas base: son las skills de IA que todo equipo técnico necesita y se aprenden en semanas, no meses.

¿Sirven estas técnicas para herramientas tipo Copilot o Cursor?

Sí: el autocompletado también lee el contexto abierto en el editor, así que nombres descriptivos, comentarios de intención y ficheros de instrucciones mejoran sus sugerencias igual que mejoran un chat. La diferencia es de grado, no de naturaleza: cuanto más agéntica es la herramienta, más rentable es invertir en contexto persistente.

¿La IA va a escribir todo el código pronto?

Escribe cada vez más, pero el cuello de botella se ha movido, no ha desaparecido: especificar bien el problema, revisar con criterio e integrar con seguridad siguen siendo trabajo de ingeniería. Los equipos que mejor rinden no son los que más delegan, sino los que mejor dirigen.

Conclusión

El prompt engineering de 2026 ya no es una lista de trucos: es una disciplina de equipo que combina especificidad, contexto real, instrucciones persistentes y verificación. Las técnicas fundamentales de esta guía —chain of thought, few-shot, roles precisos— siguen vigentes, pero su efecto se multiplica cuando se convierten en infraestructura: ficheros de instrucciones versionados, plantillas compartidas y criterios que la propia IA puede comprobar. Empieza por ahí, mide los resultados y trata cada prompt que funciona como lo que es: un activo del proyecto: se versiona, se revisa, se prueba y se mejora. Y si necesitas ayuda para aterrizarlo en tu equipo —de la formación inicial a los flujos agénticos en producción—, en Keliam lo hacemos cada semana con equipos como el tuyo.