Prompts para programadores en 2027: 15 prompts probados para legado, pruebas, debug y SQL

Estos son 15 prompts para programadores que funcionan en el día a día de un equipo de producto y de un freelance: legado, pruebas, debug, tu propio PR, SQL y el cliente. Cada uno trae cuándo usarlo, el texto para copiar y, en cinco de ellos, la respuesta real de la IA. Funcionan en ChatGPT, Claude, Gemini y Copilot.

Una regla antes de copiar cualquiera: nada de secretos, tokens, .env ni datos reales de clientes en el prompt. Cámbialos por valores ficticios.

Por qué estos prompts funcionan

Un prompt de código que sirve tiene cuatro cosas: stack y versión, el código o el error de verdad, el formato de la respuesta y lo que la IA no puede hacer. La última es la que más falta: sin ella, pides que te explique una función y recibes la función reescrita.

Entender código que no es tuyo

1. Explicar legado separando certeza de suposición

Cuándo usarlo: un ticket en un archivo viejo y sin pruebas.

Explica la función de abajo para un dev que la va a modificar mañana. Lenguaje: [LENGUAJE Y VERSIÓN].
Responde en 4 partes:
1. Qué calcula, en 3 frases
2. Entradas y salida, con el tipo probable de cada una
3. Comportamientos raros o peligrosos (conversión de tipos, orden de las reglas, números mágicos)
4. Preguntas que tengo que responder antes de tocarla
Marca con [CERTEZA] lo que está en el código y con [SUPOSICIÓN] lo que deduces por el nombre. No reescribas la función.

[CÓDIGO]

Respuesta real, para una función de envío en PHP 7.2 de una tienda en línea mexicana:

function calcEnvio($p, $cp, $tp) {
  $f = 0;
  if (intval(substr($cp, 0, 2)) <= 16) { $f = 99; } else { $f = 149; }
  if ($p > 5) $f = $f + ($p - 5) * 18;
  if ($tp == 2) $f = $f * 1.5;
  if ($f > 650) $f = 650;
  return round($f, 2);
}

1. Qué calcula. El costo de envío a partir del peso, el código postal y el tipo de envío. Hay una tarifa base por zona, un cargo por kilo extra, un multiplicador para el tipo 2 y un tope de 650. [CERTEZA]

2. Entradas y salida. $p: peso, probablemente en kg (el corte en 5 lo sugiere) [SUPOSICIÓN]. $cp: código postal; solo importan los dos primeros dígitos [CERTEZA]. $tp: tipo de envío, y el 2 parece ser exprés [SUPOSICIÓN]. Salida: número con 2 decimales [CERTEZA].

3. Puntos peligrosos. (a) Los códigos de 01 a 16 son de la Ciudad de México y pagan 99; el resto, 149 [CERTEZA]. (b) Código postal vacío: intval('') da 0, que es menor o igual a 16, así que un CP vacío paga la tarifa más barata [CERTEZA]. (c) Si el CP se guarda como número, 06600 se vuelve 6600, empieza con 66 y un cliente de la Ciudad de México paga como foráneo [CERTEZA sobre el efecto]. (d) El tope se aplica después del multiplicador, así que un exprés pesado cuesta lo mismo que uno normal pesado [CERTEZA].

4. Preguntas antes de tocarla. ¿El tope aplica al exprés? ¿El CP llega como texto y validado? ¿Hay otros valores de $tp? ¿Quién más llama a esta función?

Los puntos (b) y (c) son bugs que nadie busca. El (c) explica más de una queja de "me cobraron envío foráneo y vivo en la Roma".

2. Mapa de impacto antes del cambio

Cuándo usarlo: con un agente que ve el repositorio (Claude Code, Codex, Copilot en modo agente), antes de abrir cualquier archivo.

Voy a cambiar [FUNCIÓN/CLASE] para [CAMBIO]. Sin editar nada, lista:
- todos los puntos del repositorio que la llaman o dependen de ella, con archivo y línea
- las pruebas que ya cubren ese comportamiento
- lo que puede romperse en cada punto
Termina con un plan de cambio en pasos chicos, cada uno con la prueba que demuestra que funcionó.

Pruebas

3. Casos límite antes de la prueba

Cuándo usarlo: una función con regla de negocio (dinero, fechas, permisos) que va a tener pruebas.

Lista 6 entradas que pueden romper la función de abajo, de la más probable a la menos probable. Para cada una: la entrada, el resultado esperado y por qué es peligrosa. Después escribe las pruebas en [FRAMEWORK DE PRUEBAS], una por caso, con nombres descriptivos en español. No modifiques la función.

[CÓDIGO]

Respuesta real, para una función JavaScript dividirEnMeses(monto, n) que calcula los pagos de una compra a meses sin intereses con Math.round(monto / n * 100) / 100:

1. División que no cierra: dividirEnMeses(100, 3) debe sumar 100.00 y regresar 33.33 + 33.33 + 33.34. Hoy regresa tres pagos de 33.33 y se pierde 1 centavo.

2. Punto flotante: dividirEnMeses(0.3, 3) regresa tres pagos de 0.1, pero su suma en float da 0.30000000000000004. Trabaja en centavos enteros.

3. Monto menor que los pagos: dividirEnMeses(0.05, 10) daría pagos de 0.005. Esperado: error o pago mínimo.

4. n igual a cero: la división regresa Infinity. Esperado: error.

5. n negativo o no entero: dividirEnMeses(100, -3) y dividirEnMeses(100, 2.5). Esperado: error; solo deberían aceptarse tus plazos (3, 6, 9, 12).

6. Un solo pago: dividirEnMeses(99.99, 1) debe regresar exactamente [99.99].

El caso 1 es un bug real: el cliente ve en su estado de cuenta que pagó 99.99 por algo de 100.

4. Prueba de caracterización

Cuándo usarlo: antes de refactorizar legado.

Escribe pruebas de caracterización para la función de abajo en [FRAMEWORK]. El objetivo es registrar el comportamiento ACTUAL, incluido lo que parece bug. En cada comportamiento raro deja un comentario "comportamiento actual, confirmar con negocio". Cubre todas las ramas del código.

[CÓDIGO]

Debug

5. Del stack trace a las hipótesis

Cuándo usarlo: un error nuevo en Sentry y ninguna pista.

Error en producción, [LENGUAJE/FRAMEWORK Y VERSIÓN]. Abajo están el stack trace y el fragmento de código.
Dame 3 hipótesis de la causa, de la más probable a la menos probable. Para cada una: por qué podría ser, cómo confirmarla en menos de 10 minutos y la corrección. No sugieras un try/except o una revisión de null que solo esconda el error sin atender la causa.

STACK TRACE:
[PEGA]

CÓDIGO:
[PEGA]

Respuesta real, para un KeyError: 'rfc' en una vista de Django que recibe el webhook de pagos, en la línea rfc = payload["customer"]["rfc"]:

Hipótesis 1 (la más probable): el cliente no pidió factura. Muchas pasarelas solo mandan el RFC si el comprador lo captura; si compra como público en general, la llave no viene. Confirmar: registra payload["customer"].keys() en los próximos webhooks con error. Corrección: tratar la ausencia de RFC como un caso válido (venta a público en general, que después entra en la factura global con el RFC genérico XAXX010101000), no como un error.

Hipótesis 2: cambió la versión del webhook. Ahora llega un objeto tax_id. Confirmar: compara un payload viejo con uno de hoy. Corrección: fijar la versión y adaptar el parser.

Hipótesis 3: otro evento llega a la misma URL. Reembolsos o contracargos llegan sin el bloque del cliente. Corrección: filtrar por tipo de evento y responder 200 a los que no procesas.

Fíjate que ninguna de las tres correcciones es payload.get("rfc"). Ese arreglo esconde el error y el problema reaparece cuando el contador pide la factura global del mes.

6. El bug que pasa solo a veces

Cuándo usarlo: una prueba que falla 1 de cada 20 veces o un error que desaparece cuando pones un log.

Tengo un bug intermitente: [SÍNTOMA], pasa [FRECUENCIA], solo en [ENTORNO]. Lista las causas típicas de ese patrón (concurrencia, caché, zona horaria, orden de las pruebas, dependencia externa) que encajan con el código de abajo y, para cada una, un experimento que la confirme o la descarte. Todavía no propongas corrección.

[CÓDIGO]

Revisión y PR

7. Revisar tu propio diff antes de abrir el PR

Cuándo usarlo: antes de pedirle revisión al senior y pasar vergüenza con lo obvio.

Revisa este diff como un senior exigente pero justo. Busca solo: fallas de seguridad, bugs probables, consultas malas y pruebas faltantes. Ignora estilo y formato. Para cada problema: archivo, línea, gravedad (bloquea, importante, sugerencia) y la corrección. Máximo 8 puntos. Si no hay nada serio, dilo en una línea.

[DIFF]

En un equipo, este mismo texto se convierte en el revisor automático del agente de IA para programadores, que corre en cada PR sin que lo pidas.

8. Una descripción de PR que el revisor sí lee

Escribe la descripción de este PR a partir del diff y del ticket. Secciones: Por qué (2 frases, desde el ticket), Qué cambió (lista corta), Cómo probar (pasos que otra persona pueda seguir), Riesgos y lo que no se hizo. Sin frases genéricas como "mejoras generales".

TICKET: [PEGA]
DIFF: [PEGA]

Base de datos

9. Consulta lenta con EXPLAIN

Cuándo usarlo: la pantalla que tarda o el reporte que tumba la base a fin de mes.

Base: [POSTGRES/MYSQL Y VERSIÓN]. La consulta de abajo está lenta. Van el esquema de las tablas, los índices que existen y la salida de EXPLAIN ANALYZE.
Explica por qué está lenta, propón la consulta reescrita y los índices que crearías, y di el costo de cada índice (escritura, espacio). No inventes columnas que no estén en el esquema.

CONSULTA: [PEGA]
ESQUEMA E ÍNDICES: [PEGA]
EXPLAIN ANALYZE: [PEGA]

Respuesta real, para SELECT * FROM pedidos WHERE DATE(creado_en) = '2026-10-20' AND estatus = 'pagado' ORDER BY creado_en DESC en Postgres 16, con índice solo en creado_en y 4 millones de filas:

Por qué está lenta: DATE(creado_en) aplica una función sobre la columna, así que el índice de creado_en no se puede usar para el filtro y el plan hace una lectura secuencial de toda la tabla.

Consulta reescrita: SELECT id, cliente_id, total, creado_en FROM pedidos WHERE creado_en >= '2026-10-20' AND creado_en < '2026-10-21' AND estatus = 'pagado' ORDER BY creado_en DESC;

Índice: CREATE INDEX CONCURRENTLY idx_pedidos_estatus_creado ON pedidos (estatus, creado_en DESC); Atiende el filtro por estatus y ya entrega el orden. Costo: un poco más de escritura en cada pedido nuevo y algunas decenas de MB.

Atención: si creado_en es timestamptz, el "día 20" depende de la zona horaria de la sesión. Pasa el rango ya en la hora de la Ciudad de México ('2026-10-20 00:00-06') para no perder los pedidos de la noche.

La nota de la zona horaria es la que más vale: un servidor en UTC corta el día a las 6 de la tarde de México.

10. Migración que no tumba producción

Necesito [CAMBIO EN EL ESQUEMA] en la tabla [TABLA], que tiene [N] filas y recibe escrituras todo el tiempo, en [BASE Y VERSIÓN]. Arma el plan en etapas que no bloqueen la tabla: migraciones en orden, qué cambia en el código entre cada etapa, cómo revertir cada una y qué vigilar durante el despliegue.

Documentación

11. README para el primer día

Con base en los archivos de configuración de abajo (package.json, docker-compose, .env.example, Makefile), escribe el README que necesita un dev nuevo el primer día: cómo levantar el proyecto desde cero, cómo correr las pruebas, las variables de entorno y para qué sirve cada una, y los 3 problemas más probables en la primera ejecución. No inventes comandos que no estén en los archivos.

[PEGA LOS ARCHIVOS]

12. Registro de decisión (ADR)

Escribe un ADR corto sobre la decisión de [DECISIÓN]. Contexto, opciones ([OPCIÓN A], [OPCIÓN B]) con pros y contras para nuestro caso ([EQUIPO, VOLUMEN, PLAZO]), decisión, consecuencias y cuándo revisarla. Máximo una página.

Cliente y carrera

13. Cotizar un freelance sin olvidar la mitad

Cuándo usarlo: el cliente mandó "quiero una app como Rappi pero para mi colonia" y te pidió precio para mañana.

Un cliente pidió: [PEDIDO DEL CLIENTE, CON SUS PALABRAS]. País: [PAÍS]. Divídelo en módulos y subtareas. Para cada subtarea: estimación en horas con rango (mínimo y máximo) y el riesgo que puede alargar el plazo. Después lista lo que el cliente NO dijo pero va a necesitar (login, correos, panel de administración, aviso de privacidad, facturación electrónica, hosting, tiendas de apps, mantenimiento). No des precio.

14. Avisarle al cliente de un retraso sin que suene a pretexto

Escribe un mensaje de WhatsApp para un cliente no técnico avisando que la entrega de [ENTREGA] se va a retrasar [PLAZO]. Motivo real: [MOTIVO]. Explica el motivo en palabras simples, di lo que ya está listo, la nueva fecha y lo que necesito de él (si aplica). Sin tecnicismos, sin pedir perdón tres veces, máximo 90 palabras.

Respuesta real, para un retraso de 4 días porque la pasarela de pagos tenía que verificar la cuenta del propio cliente:

Hola, Ernesto. Te actualizo sobre la tienda: el registro, el catálogo y el carrito ya están listos y probados. Lo que se atoró fue el cobro con tarjeta: la empresa de pagos tiene que verificar tu cuenta antes de activar las ventas, y esa revisión sigue en proceso. Por eso la entrega pasa del viernes al martes 3. Para que no se retrase más, necesito que hoy mismo les contestes el correo con el acta constitutiva y tu comprobante de domicilio. Cualquier duda, me marcas.

Dice qué está listo, por qué se atrasó y qué tiene que hacer él. Antes de mandarlo, confirma qué documentos pide la pasarela: la IA los supuso.

15. Junior estudiando con el código del trabajo

Cuándo usarlo: aceptaste una sugerencia de la IA, funcionó y no sabes por qué.

Soy dev junior. El código de abajo funciona, pero no entiendo [FRAGMENTO]. Explícamelo como un compañero senior sentado a mi lado: qué hace cada parte, por qué se escribió así, una alternativa más simple (si existe) y qué fallaría si borro cada línea. Al final hazme 2 preguntas para ver si entendí.

[CÓDIGO]

En la guía de IA para programación explico cómo un junior y un senior usan la IA de formas distintas.

Errores comunes con prompts de código

• No decir la versión. Sin "Python 3.12" o "React 19", la IA mezcla sintaxis de versiones distintas.
• Pedir la corrección sin pedir la causa. Recibes un if que esconde el síntoma. Pide hipótesis primero (prompt 5).
• Aceptar un paquete nuevo sin revisarlo. Confirma en npm o PyPI que exista y quién lo mantiene.
• Quedarte con la primera respuesta. "Ahora critica tu respuesta y dime su punto más débil" mejora casi todo.

¿Quieres más? El pack en PDF trae más de 50 prompts que no están aquí, de arquitectura, DevOps, seguridad, entrevista técnica y trato con clientes.

¿Quieres saltarte esta parte?

Agentes de IA listos para devs y equipos de software: sin montar nada, sin prompts, ya trabajan por ti.

• Primera revisión de cada PR, con comentarios en la línea y etiqueta de riesgo
• Clasificación de bugs de soporte directo al backlog, con pasos para reproducir
• Reglas de seguridad y de datos personales ya configuradas, sin permiso para aprobar ni hacer merge

Quiero los agentes listos