La ingeniería de prompts para programar marca la diferencia entre un agente que entrega un pull request que funciona y uno que rompe algo en producción sin que nadie se dé cuenta. Lo aprendimos por las malas: una instrucción vaga en nuestro propio pipeline llegó a generar 54 páginas duplicadas en producción antes de que alguien lo notara. Hoy un setup de 16 agentes de Claude Code escribe, traduce y publica nuestro contenido, y los prompts que lo mueven no se parecen en nada a las listas de 50 plantillas que aparecen en la primera página de Google. Aquí están los 7 patrones que escribimos todos los días, cada uno con un antes y después real.
Respuesta rápida: Los buenos prompts de programación comparten una misma forma. Indicas el objetivo y qué significa "terminado", nombras los archivos exactos que entran en juego, obligas a un plan antes de cualquier edición, entregas los tests y exiges evidencia en vez de un "se ve bien". Haz eso y un agente moderno (Claude Code, Cursor, GitHub Copilot) escribe código que pasa la revisión a la primera con mucha más frecuencia. Sáltatelo y obtienes basura convincente y con apariencia plausible.
Los 7 patrones, en el orden en que recurrimos a ellos:
- Encuadre de la tarea: objetivo, restricciones y "terminado" desde el principio
- Selección de contexto: nombra los archivos, acota el resto
- Plan primero: haz que proponga antes de editar
- Tests primero: pon los tests de aceptación en el prompt
- Depuración: error más reproducción más resultado esperado, causa raíz antes del fix
- Refactor: cambia la estructura, mantén el comportamiento, muestra el diff
- Revisión: una checklist contra la que hacer grep, más evidencia
Ingeniería de Prompts para Programar vs. Archivos de Configuración: Qué Va Dónde
Los archivos de configuración y los prompts por tarea cumplen funciones distintas, y confundirlos es el error más común en este terreno. Un archivo CLAUDE.md o .cursor/rules es la política permanente que el agente lee en cada sesión: tu stack, tus convenciones de nombres, tu comando de test. Un prompt es la tarea concreta que le entregas justo ahora. Las reglas duraderas van en la configuración; la tarea va en el prompt.
La mayoría de los recopilatorios de "prompts para programar" difuminan esto y te dicen que pegues un prompt de persona gigante en .cursorrules. Eso infla la configuración que el agente carga en cada tarea y, aun así, no logra encuadrar el trabajo concreto que tiene delante. Mantén ambas cosas separadas:
| Archivo de configuración (CLAUDE.md, .cursor/rules) | Prompt por tarea | |
|---|---|---|
| Contiene | Reglas permanentes: stack, estilo, comando de test, límites de seguridad | La tarea concreta: qué construir o arreglar, ahora mismo |
| Se carga | Automáticamente, en cada sesión | Una vez, cuando lo escribes |
| Cambia | Rara vez, se revisa como código | En cada tarea |
| Ejemplo | "Ejecuta pnpm test antes de dar algo por terminado" | "Corrige el redondeo de impuestos en cart.ts para pedidos de más de $1,000" |
Si quieres hacer bien la parte de configuración, la cubrimos a fondo en nuestra guía de mejores prácticas de CLAUDE.md y en la guía de reglas de Cursor. Este artículo es la otra mitad: los prompts que escribes desde cero cada vez. Ambos se apoyan en nuestra guía de ingeniería de prompts más amplia, si prefieres ver los fundamentos primero.
Ingeniería de Prompts para Programar: los 7 Patrones que Usamos a Diario
Cada patrón de abajo tiene la versión débil que la gente realmente escribe y la versión fuerte que consigue código que funciona. El salto de débil a fuerte casi siempre es el mismo movimiento: cambiar un deseo por una especificación.
1. Encuadre de la Tarea: Indica el Objetivo, las Restricciones y "Terminado"
El encuadre de la tarea significa escribir el objetivo, las restricciones y cómo se ve "terminado" antes de que el agente toque una sola línea. Un agente optimiza para lo que le pediste literalmente, así que una petición difusa se gana un parche difuso. Nombra el archivo, el comportamiento que quieres, la prueba de aceptación y las cosas que no debe cambiar.
Este es el patrón que nos costó 54 páginas. Nuestra vieja instrucción de traducción era básicamente un deseo:
Débil: Vuelve a traducir este artículo al alemán y mantén los nombres de marca.Ahí no se dice nada sobre qué le está permitido hacer al slug. Así que, en una nueva ejecución, el agente "mejoró" el slug de la URL, y como un slug nuevo significa un documento nuevo, terminamos con dos páginas en alemán activas para el mismo artículo. Multiplica eso por idiomas y artículos antiguos y obtienes 54 duplicados y un montón de exclusiones por contenido duplicado. La solución fue una especificación, no un deseo más amable:
Fuerte: Vuelve a traducir este artículo al alemán.
- Si ya existe un archivo en alemán, copia su slug existente tal cual. Nunca
lo vuelvas a derivar ni lo "mejores".
- Antes de crear cualquier documento, busca el existente por su referencia
canónica y reutiliza ese registro.
- Si el slug que generarías difiere del que ya está publicado, DETENTE y
avísame. Un slug distinto crea una segunda URL activa para la misma
página.El prompt fuerte nombra en voz alta el modo de fallo. Ese único hábito, decir qué no debe pasar y por qué, es el cambio más valioso que la mayoría de los equipos puede hacer. También terminamos cada prompt de tarea con un contrato de salida explícito ("tu mensaje final debe reportar el recuento de palabras, la puntuación de validación y cualquier archivo tocado"), para que el agente sepa qué produce "terminado", no solo qué hacer.
2. Selección de Contexto: Nombra los Archivos, Acota el Resto
La selección de contexto significa decirle al agente exactamente qué archivos leer y cuáles dejar en paz, en vez de dejar que haga grep a su aire y llene su ventana de ruido. La propia guía de Anthropic es directa sobre el motivo: la ventana de contexto se llena rápido y la calidad baja a medida que se llena, así que la mayoría de las buenas prácticas existen para protegerla (buenas prácticas de Claude Code).
Débil: Arregla el bug en el flujo de checkout.
Fuerte: Lee solo src/checkout/cart.ts y src/checkout/tax.ts. El redondeo de
impuestos está mal para pedidos de más de $1,000 (redondea cada línea del
pedido en vez del total). Corrige el redondeo. No toques nada fuera de
src/checkout/.Nosotros acotamos con dureza. Una línea real de nuestros prompts de agente dice: "no escribas en url-mapping.json, pipeline.md ni config.json, y nunca toques ningún archivo fuera de tu directorio scratchpad." Esa sola frase ha evitado más daño accidental que cualquier cantidad de limpieza posterior. Cuando la tarea realmente necesita documentos en vivo o herramientas extra, los añadimos de forma deliberada mediante servidores MCP en lugar de esperar que el agente tropiece con el archivo correcto. Y si ese contexto viene de fuera de tu repositorio, trátalo como no confiable: revisa nuestra nota sobre prevención de prompt injection antes de pegar una página scrapeada en un agente de programación.
3. Plan Primero: Haz que Proponga Antes de Editar
El plan-first hace que el agente te entregue un enfoque antes de editar nada. En Claude Code, el Plan Mode es un estado de solo lectura duro y forzado, no un educado "piensa primero" que el modelo pueda esquivar, así que literalmente no puede escribir hasta que apruebas el plan. Separar la investigación y la planificación de la ejecución es la práctica en la que más se apoya Anthropic para evitar resolver el problema equivocado.
Débil: Añade limitación de tasa (rate limiting) a la API.
Fuerte: Antes de escribir código, dame un plan numerado: qué middleware,
dónde viven los contadores, cómo manejas la respuesta 429 y sus cabeceras,
y qué tests vas a añadir. Espera mi aprobación antes de editar.Por qué funciona: el plan es barato de leer y barato de corregir. Arreglar un plan equivocado cuesta una frase; arreglar código equivocado cuesta un ciclo de revisión. Esto encaja de forma natural con pedirle al modelo que razone paso a paso primero (mira chain-of-thought prompting), y es la columna vertebral de los workflows de Claude Code de varios pasos que usamos para cualquier cosa no trivial.
4. Tests Primero: Pon los Tests de Aceptación en el Prompt
El test-first pone los criterios de aceptación en el prompt como entradas y salidas concretas, para que el agente escriba código contra un objetivo que tú definiste y no contra uno que él adivinó. Pega el test que falla, o una pequeña tabla de resultados esperados, y di "haz que esto pase sin editar el test."
Débil: Escribe una función para parsear fechas ISO 8601.
Fuerte: Haz que pase este test que ahora falla, sin modificar el test:
parseIso("2026-07-20T15:00:00Z") -> Date en ese instante UTC exacto
parseIso("2026-07-20") -> Date en 2026-07-20T00:00:00Z
parseIso("not-a-date") -> lanza RangeError
parseIso("") -> lanza RangeError
Devuelve solo la función y sus imports.Los ejemplos concretos ganan a los adjetivos siempre. "Maneja los casos extremos" es una esperanza; cuatro filas de entrada a salida son una especificación que el modelo puede cumplir de verdad, y puedes ejecutarlas en el momento en que el código aterriza.
5. Depuración: Error, Reproducción, Resultado Esperado, Causa Raíz Antes del Fix
Un prompt de depuración le da al agente el texto del error, la entrada que lo dispara y lo que esperabas, y luego pide la causa antes de cualquier fix. Sáltate eso y el agente parchea el síntoma, así que el bug simplemente se muda a un lugar más tranquilo.
Débil: Esto está lanzando un error, arréglalo.
Fuerte: Esto falla en el checkout. Aquí está el stack trace: [pegar]. Ocurre
solo cuando el carrito tiene un código de descuento Y una tarjeta regalo
(reproducir: añade ambos y haz checkout). Esperado: se aplican los dos, la
tarjeta regalo al final. Encuentra la causa raíz y explícala en una frase
antes de cambiar nada. No la envuelvas en un try/catch que oculte el error.La línea "explica la causa en una frase primero" hace un trabajo real. Obliga al modelo a comprometerse con un diagnóstico que puedes verificar, en vez de entregar un fix cuya lógica nunca ves. La línea "no lo ocultes en un try/catch" cierra la vía de escape más común.
6. Refactor: Cambia la Estructura, Mantén el Comportamiento, Muestra el Diff
Un prompt de refactor restringe el alcance con dureza: cambia la estructura, mantén el comportamiento idéntico y muestra el diff. Sin una acotación, los agentes "ordenan" cosas que nunca pediste, y pierdes la capacidad de revisar el cambio que sí importaba.
Débil: Limpia este archivo.
Fuerte: Extrae la lógica de validación de submitOrder() en una función pura
validateOrder(). Mantén cada firma pública y todo el comportamiento
idénticos. No cambies nada más en este archivo. Muéstrame un diff
antes/después y una línea explicando por qué cada cambio preserva el
comportamiento.Esta es la otra cara de la separación configuración-versus-prompt de antes: tus reglas de estilo permanentes viven en las reglas de Cursor, pero el alcance de este refactor pertenece al prompt. "No cambies nada más" es la frase que mantiene los refactors revisables.
7. Revisión: una Checklist Contra la que Hacer Grep, más Evidencia
Un prompt de revisión le entrega al agente una checklist contra la que hacer grep y exige evidencia, no un veredicto. "Se ve bien" no vale nada; el comando que ejecutó y el resultado que obtuvo sí. Anthropic lo dice sin rodeos: haz que el agente muestre evidencia (la salida del test, el comando y su resultado) en vez de afirmar el éxito, porque leer evidencia es más rápido que volver a verificarlo tú mismo.
Débil: Revisa mi PR.
Fuerte: Revisa este diff contra exactamente estos cinco puntos:
1. No se añadieron secretos ni API keys
2. Cada función nueva tiene un test
3. Ningún cambio de comportamiento fuera de src/checkout/
4. Las rutas de error devuelven errores tipados, no strings
5. No queda ningún console.log
Para cada punto, cita la línea que lo cumple o lo viola. Luego ejecuta la
suite de tests y pega el resultado. No digas "listo"; muéstramelo.Nuestro propio gate de revisión está construido exactamente así. Antes de que un agente pueda reportar un artículo como publicado, hace grep del borrador contra una lista de palabras prohibidas (un bloqueo duro, cero tolerancia) y ejecuta una consulta para confirmar que el cuerpo del documento no está vacío. El agente no puede afirmar el éxito; tiene que producir la salida de la comprobación. Para roles de revisor que reutilizas mucho, convierte la checklist en una persona guardada, y ahí es donde entran los ejemplos de system prompt.
Claude Code vs. Cursor vs. Copilot: Dónde Vive Cada Patrón
Los tres agentes principales de 2026 admiten todos los patrones anteriores, pero la superficie cambia. Claude Code se apoya en el Plan Mode y los subagentes, Cursor en el Agent mode y su ventana de Agents, y GitHub Copilot en el agent mode más archivos de instrucciones. Elige la herramienta en la que vive tu equipo; los patrones se trasladan sin fricción.
| Patrón | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| Reglas permanentes | CLAUDE.md | .cursor/rules | .github/copilot-instructions.md, AGENTS.md |
| Plan primero | Plan Mode (solo lectura forzado) | Paso de plan en el Agent mode | Vista previa del plan antes de aplicar |
| Trabajo acotado/paralelo | Subagentes, cada uno con su propio contexto | Ventana de Agents, worktree por agente | Tareas de agente en la nube |
| Reglas por ruta | CLAUDE.md anidado por directorio | Globs de reglas | .instructions.md con applyTo |
Algunos detalles actuales que vale la pena conocer. El Plan Mode de Claude Code es un bloqueo de solo lectura genuino, y sus subagentes corren cada uno en un contexto aislado con sus propias herramientas (documentación de subagentes). La línea 2026 de Cursor añadió una ventana de Agents que lanza agentes en paralelo, cada uno en su propio git worktree (Cursor 2.0). El agent mode de GitHub Copilot lee instrucciones personalizadas desde .github/copilot-instructions.md, además de archivos .instructions.md acotados por ruta con un campo applyTo (instrucciones personalizadas de Copilot). Si Cursor es tu herramienta de cada día, mira nuestro artículo sobre cómo usar Cursor de forma más eficiente.
Cómo Damos Instrucciones a Nuestros Agentes de Código en Techsy
Gestionamos un pipeline de contenido como un equipo de 16 agentes de Claude Code: un researcher, un redactor de briefs, un redactor de contenido, nueve traductores, un validador y un publisher, coordinados mediante mensajes de tarea. Dos convenciones de ese sistema se trasladan a cualquier equipo de programación.
Primero, cada prompt de tarea termina con un contrato de salida. La última línea siempre es alguna versión de "tu mensaje final debe reportar X, Y y Z". Un agente que conoce la forma exacta de "terminado" se desvía mucho menos que uno al que solo se le dijo por dónde empezar.
Segundo, nunca dejamos que un agente se corrija sus propios deberes en prosa. Generación y verificación son pasos separados, y la verificación es un comando con salida, no una opinión. Esa separación entre construir y comprobar es central en cómo Anthropic plantea la construcción de agentes fiables, y por eso nuestro gate de revisión hace grep y consultas en vez de confiar en un "se ve bien".
Esto también es nuestro trabajo diario. En Techsy construimos agentes de IA y automatización para equipos B2B, y una disciplina de prompts como esta es gran parte de lo que separa una demo de algo que puedes poner delante de un cliente. Si quieres montar bien un workflow de código o de agentes, nuestro servicio de integración de IA es exactamente donde hacemos eso, y puedes reservar una consulta gratuita para repasar tu stack.
Una Plantilla de Prompt para Copiar y Adaptar
Aquí está el esqueleto del que partimos para cualquier tarea de programación no trivial. Borra las secciones que no necesites, pero mantén el orden, porque refleja los siete patrones.
OBJETIVO
Una frase: qué debe ser verdad cuando termines.
CONTEXTO
Lee solo: <archivos exactos>. Ignora todo lo demás.
Datos relevantes: <restricciones, versiones, qué dispara el bug>.
PLAN PRIMERO
Antes de editar, dame un plan numerado y espera mi aprobación.
TESTS / LISTO
Listo significa: <pega el test que falla o las filas entrada->salida>.
No cambies los tests.
RESTRICCIONES
Mantén todas las firmas públicas y el comportamiento idénticos salvo que
se indique lo contrario.
No toques <archivos/áreas>. Nombra cualquier suposición que hagas.
SALIDA
Muestra un diff antes/después, ejecuta los tests y pega el resultado.
No digas "listo"; muestra la evidencia.Guárdala como snippet, o mejor, divídela: las restricciones permanentes van en tu archivo de configuración, y el objetivo, el contexto y los tests van en el prompt. Esa división es todo el sentido.
Sobre el Autor
Mert Batur Gürbüz es Cofundador de Techsy.io, donde el equipo entrega agentes de IA, sistemas de automatización y pipelines de voz/SDR para clientes B2B. Estudia en la University of Birmingham y escribe sobre el stack de herramientas LLM que el equipo de Techsy realmente usa en producción.
Credenciales: Cofundador, Techsy.io, University of Birmingham. Conecta en LinkedIn.
Preguntas Frecuentes
¿Qué es la ingeniería de prompts para programar?
La ingeniería de prompts para programar es la práctica de escribir instrucciones que llevan a un agente de IA a producir código correcto y revisable. En la práctica significa indicar el objetivo y la definición de "terminado", nombrar los archivos en juego, forzar un plan antes de editar, aportar tests y exigir evidencia. Se parece más a escribir una especificación que a escribir una frase ingeniosa.
¿En qué se diferencia de escribir un archivo CLAUDE.md o .cursor/rules?
Los archivos de configuración contienen la política permanente que el agente lee en cada sesión: tu stack, tus convenciones y el comando de test. Un prompt por tarea es el trabajo concreto que le entregas justo ahora. Pon las reglas duraderas en la configuración y la tarea en el prompt. Pegar prompts de tarea enteros en un archivo de configuración infla cada sesión y aun así no logra encuadrar la tarea individual.
¿Cuál es la mejor estructura de prompt para agentes de IA que programan?
Usa secciones etiquetadas en lugar de un solo párrafo: OBJETIVO, CONTEXTO, PLAN, TESTS, RESTRICCIONES y SALIDA. Los agentes parsean prompts estructurados de forma más fiable que muros de texto. Indica los criterios de éxito desde el principio, da de uno a tres ejemplos concretos en vez de adjetivos, y especifica el formato de salida exacto que quieres recibir.
¿Cómo escribo un buen prompt de depuración?
Dale al agente cuatro cosas: el error exacto o el stack trace, la entrada que lo reproduce, lo que esperabas, y una petición de la causa raíz antes de cualquier fix. Añade "explica la causa en una frase antes de cambiar nada" para poder comprobar el diagnóstico, y "no lo ocultes en un try/catch" para que arregle el bug en vez de enmascararlo.
¿Debería incluir tests en mis prompts de programación?
Sí, siempre que puedas. Pegar el test que falla o una pequeña tabla de filas de entrada a salida convierte una petición vaga en un objetivo que el modelo puede alcanzar de verdad, y puedes ejecutar el resultado de inmediato. Dile al agente que haga pasar los tests sin editarlos, para que no pueda mover la portería y hacer que su propio código parezca correcto.
¿Estos prompts también funcionan en Cursor y GitHub Copilot?
Sí. Los patrones son independientes de la herramienta. Claude Code los expone mediante el Plan Mode y los subagentes, Cursor mediante el Agent mode y su ventana de Agents con un worktree por agente, y GitHub Copilot mediante el agent mode más .github/copilot-instructions.md. La superficie cambia; el encuadre de la tarea, la selección de contexto, el plan primero y la revisión basada en evidencia no.
¿Cuánto debería medir un prompt de programación?
Lo suficientemente largo para ser una especificación, lo suficientemente corto para mantenerse enfocado. La calidad del razonamiento se degrada a medida que se llena el contexto, así que prioriza la estructura sobre el volumen: un prompt etiquetado de 150 a 300 palabras con los archivos y tests correctos gana a uno divagante. Mueve a tu archivo de configuración todo lo que aplique a cada tarea, en vez de repetirlo.
¿Cómo evito que un agente de IA cambie código que no pedí?
Acota el alcance en el prompt. Di exactamente qué archivos puede editar, añade "no cambies nada más", y exige "mantén todas las firmas públicas y el comportamiento idénticos salvo que diga lo contrario". Para refactors, pide un diff antes/después con una línea sobre por qué cada cambio preserva el comportamiento, para que cualquier edición no solicitada sea obvia en la revisión.
¿Valen la pena las bibliotecas de prompts para copiar y pegar?
Como punto de partida, a veces. Como herramienta terminada, casi nunca. Una biblioteca de 50 prompts te da formas de decir las cosas, pero no puede conocer tus archivos, tus tests ni tus restricciones, que es donde realmente vive la corrección. Aprende los patrones, conserva una plantilla adaptable, y rellena los detalles específicos de la tarea que tienes delante.