Prompts para desarrolladores: del bug a la revisión de código

Pegas una stack trace, escribes «corrige» y el asistente te devuelve una función reescrita que silencia el error. El test pasa, a veces porque el try/except añadido se traga la excepción. El síntoma ha desaparecido, el bug no.

Un desarrollador no necesita que le expliquen qué es un prompt. Necesita sobre todo reflejos para impedir que la IA se lance hacia la primera solución plausible. Las plantillas de abajo fuerzan ese freno, y funcionan tanto en un chat como en un asistente de código.

Depurar: separar el diagnóstico de la corrección

La instrucción más rentable cabe en una línea: nada de código antes del diagnóstico. Evita validar una corrección basada en una causa supuesta.

Bug en [LENGUAJE/FRAMEWORK, VERSIÓN SI IMPORTA].

Comportamiento esperado: [LO QUE DEBERÍA PASAR]
Comportamiento observado: [LO QUE PASA]
Reproducción: [PASOS O TEST]
Error completo:
[STACK TRACE]

Código afectado:
[EXTRACTOS]

Lo que ya he probado o descartado: [LISTA]

No propongas todavía una corrección.
1. Enumera 3 hipótesis ordenadas por probabilidad.
2. Para cada una, indica la observación del código o de la traza que la respalda.
3. Indica la comprobación más rápida para confirmarla o descartarla (log concreto, consulta, test mínimo).

Ejecutaré esas comprobaciones y te daré los resultados. Si te falta un archivo para razonar, pídelo en lugar de suponer su contenido.

Piensa en un desarrollador de Rails ante una factura creada por duplicado: aquí las hipótesis tendrán posibilidades de apuntar a un doble envío del formulario, un webhook reenviado o un job relanzado, y cada una se comprueba en pocos minutos en los logs. Esta división en dos tiempos retoma el principio del razonamiento paso a paso, con un humano que además aporta los hechos entre los dos pasos.

Revisar un diff, no un archivo entero

Una revisión pedida sin orientación devuelve sobre todo comentarios de estilo. Da el diff, di lo que debe hacer el cambio y precisa qué te interesa.

git diff main...HEAD > diff.txt

Vas a revisar esta pull request.

Objetivo del cambio: [TICKET O DESCRIPCIÓN]
Contexto: [STACK, CONVENCIONES, RESTRICCIONES DE RENDIMIENTO]
Diff:
[PEGA EL DIFF]

Busca en este orden:
1. Los bugs: casos límite, errores no gestionados, concurrencia, valores nulos.
2. La seguridad: inyección, control de acceso, datos sensibles en los logs.
3. Las desviaciones respecto al objetivo: lo que falta y lo que se sale del alcance.

Para cada problema, da el archivo y la línea del diff, el escenario concreto que lo desencadena y la gravedad (bloqueante, a corregir, menor). Ignora el formato y los nombres, de eso se encarga un linter. Si el diff te parece correcto en un eje, dilo sin más en lugar de inventar un problema.

La última frase importa. Sin ella, un modelo al que se le piden problemas tiende a encontrarlos a toda costa, incluso en código sano.

Asegurar código legacy antes de tocarlo

Tienes que modificar una función de 300 líneas sin tests, escrita por alguien que se fue. Pedir «refactoriza» equivale a perder los comportamientos no documentados. La secuencia correcta empieza por tests de caracterización, que fijan lo que el código hace hoy, bugs incluidos.

Aquí tienes una función sin tests, en producción:
[CÓDIGO]

Framework de test: [PYTEST, JEST, PHPUNIT...]

Antes de cualquier refactorización:
1. Describe el comportamiento real de este código, caso por caso, incluidos los comportamientos que te parezcan bugs.
2. Escribe tests de caracterización que documenten este comportamiento actual, sin corregirlo. Marca con un comentario los casos que parezcan bugs.
3. Enumera las dependencias que hay que simular (base de datos, reloj, API) y las zonas que no puedes cubrir sin cambiar el código.

No modifiques la función. La refactorización vendrá en un segundo momento, en pequeños pasos, con los tests en verde entre cada uno.

Lanza estos tests sobre el código actual antes de seguir adelante. Si fallan con el código actual, es que el modelo se equivocó sobre el comportamiento, y esas diferencias son justo lo que querías descubrir. Divide después la refactorización en una cadena de prompts: una extracción por mensaje, un commit por paso.

Escribir tests que ataquen el código

Cuando se le piden tests después de mostrarle una implementación, la IA suele escribir tests que describen esa implementación. Pasan y no prueban gran cosa. Oriéntala hacia la especificación y hacia los puntos de ruptura.

Especificación de la función: [REGLAS DE NEGOCIO]
Firma: [FIRMA]
Ejemplo real de entrada y salida: [EJEMPLO]

Escribe los tests a partir de la especificación, sin intentar reflejar una implementación.
Cubre los límites, las entradas inválidas, los duplicados, las zonas horarias y los redondeos si procede.
Para cada test, indica en una línea qué bug realista detectaría.
Descarta los tests que solo podrían fallar si el propio lenguaje estuviera roto.

Para una aplicación de reservas de restaurante, este prompt tiene buenas probabilidades de sacar a la luz la franja horaria que cae a caballo del cambio de hora, el tipo de caso que se suele olvidar.

Migración SQL: hacer que busque lo que puede salir mal

Una migración funciona en local y bloquea la tabla en producción. La IA es un buen revisor pesimista siempre que conozca el volumen y el motor.

Motor y versión: [POSTGRESQL, MYSQL...]
Tamaño de las tablas afectadas: [FILAS]
Tráfico: [LECTURAS/ESCRITURAS, VENTANA DE MANTENIMIENTO]
Migración:
[SQL]
Código de la aplicación que lee estas columnas: [EXTRACTOS]

Analiza:
1. Los bloqueos que adquiere cada instrucción y su efecto probable con este volumen.
2. La compatibilidad durante el despliegue, cuando el código antiguo y el nuevo funcionan a la vez.
3. El plan de marcha atrás, y lo que no se puede deshacer.
4. Una versión en varios pasos si es necesario.

Si un comportamiento depende de la versión del motor, dilo e indica qué debo comprobar en la documentación.

Tres precauciones antes de fiarte del código generado

Comprueba que lo que se cita existe. Un modelo puede inventarse un método, una opción o un paquete. El riesgo es real en seguridad: un tercero malintencionado puede registrar el nombre de un paquete inventado. Antes de instalar, mira el registro, el autor y la actividad del proyecto:

npm view [paquete]
pip index versions [paquete]

No pegues lo que no puedas compartir. Claves de API, cadenas de conexión, datos de clientes y código sujeto a un acuerdo de confidencialidad no tienen nada que hacer en una herramienta no validada por tu empresa. Mira las condiciones de tu plan, porque varían de un producto a otro, y pasa un escáner de secretos sobre lo que envías.

Conserva la responsabilidad de la revisión. El código generado se revisa como el de un compañero, con la cuestión añadida de las licencias si se trata de un producto comercial. Si trabajas con un agente que ejecuta comandos por su cuenta, sus instrucciones merecen tanto cuidado como tu código: todo está en nuestra guía de instrucciones para agentes.

Abre tu último ticket de bug resuelto, vuelve a dárselo a tu asistente con el primer prompt y compara sus hipótesis con la causa real. Sabrás enseguida lo que vale tu herramienta con tu base de código.