Prompts de IA para programar: depura, refactoriza y entrega más rápido

Pídele a un modelo que "arregle esta función", pega veinte líneas y obtendrás una reescritura verosímil que puede tocar o no el bug real. Pídele lo mismo con el error completo, la entrada que lo dispara, la versión del framework y lo que esperabas que ocurriera, y normalmente tendrás el arreglo a la primera. La distancia entre esos dos resultados es toda la habilidad. Los buenos prompts de IA para programar no son conjuros ingeniosos. Son el mismo contexto que le pasarías a un compañero antes de pedirle que mire tu pantalla.

Así se construye ese contexto para el trabajo que de verdad hace quien programa: depurar, refactorizar, tests, explicaciones, andamiaje y la parte honesta en la que revisas lo que te ha devuelto el modelo.

El contexto que necesita todo prompt de programación

Los mejores prompts de IA para programar comparten una misma columna vertebral: contexto suficiente para que el modelo no adivine. No puede abrir tu repo, ejecutar el test que falla ni comprobar a qué versión de una librería estás fijado. Solo ve lo que pegas. Así que déjalo por escrito. Todo buen prompt de programación lleva cinco cosas:

• Lenguaje y versión — "Python 3.12", no "Python". El comportamiento cambia entre versiones, y también las APIs a las que recurre el modelo.
• Framework y su versión — React 18 frente a 19, Django 4 frente a 5, la línea fijada de tu lockfile. Solo esto elimina la mitad de las respuestas con APIs obsoletas.
• El código real — la función de verdad, no una paráfrasis. Incluye a quien la llama si el bug pudiera estar ahí.
• Comportamiento esperado frente al real — "debería devolver las sesiones activas del usuario; en cambio devuelve una lista vacía cuando el usuario tiene exactamente una".
• Restricciones — sin dependencias nuevas, debe mantener la compatibilidad hacia atrás, tiene que correr en una Lambda con un límite de 512 MB.

Si te saltas la versión, recibes código para una API que cambió hace dos releases. Si te saltas el esperado-frente-al-real, el modelo se inventa su propia definición de "roto". Si un prompt parece poco específico y no sabes qué le falta, pasar un borrador por un optimizador de prompts saca a la luz los huecos enseguida.

Depuración: pega el error entero, no un resumen

El error más habitual es reescribir un fallo como "dice algo de undefined". Pega el stack trace completo. Los números de línea, la cadena de llamadas, el tipo de excepción: ese es el mapa. Luego dale al modelo una forma de reproducirlo.

Pedir primero la causa raíz es deliberado. La depuración con IA se tuerce cuando el modelo salta a un parche que silencia el síntoma: un try/except envuelto alrededor del problema real. Fuerza el diagnóstico y podrás juzgar si el arreglo ataca la causa o solo el fallo. Para bugs enredados donde el razonamiento importa, un prompt de cadena de pensamiento que obliga al modelo a recorrer la lógica paso a paso pilla cosas que una respuesta de un solo tiro se salta.

Refactorización y revisión de código

Las peticiones de refactor vagas dan resultados vagos. "Limpia esto" invita al modelo a renombrar un par de variables y darlo por hecho. Di qué significa "mejor" para este código y marca límites para que el comportamiento no se desvíe.

Esa última línea convierte un refactor en una revisión. A menudo el modelo señalará un error que se tragaba en silencio o un fallo de uno-en-uno que habías dejado de ver. Para una revisión pura, dile que actúe como revisor con una checklist —corrección, casos límite, nombres, seguridad— y que ordene los hallazgos por gravedad para que no te ahogues en detalles de estilo. Las técnicas avanzadas de prompting que vale la pena aprender aquí son la asignación de rol y la estructura de salida explícita. Ambas convierten el resultado de la revisión en algo sobre lo que puedes actuar.

Tests que el modelo no puede falsear

Los modelos escriben tests rápido, y justo por eso hay que guiarlos. A su aire, prueban el camino feliz y afirman lo que el código ya hace, bugs incluidos. En su lugar, apúntalos al comportamiento y a los límites.

Lee los tests antes de fiarte de ellos. Un test que pasa contra código roto es peor que no tener test. Si estás reescribiendo las mismas convenciones de testing en cada prompt, esa es la señal para guardar una instrucción reutilizable: mejorar tus prompts con el tiempo consiste sobre todo en convertir lo que funcionó en una plantilla a la que vuelves una y otra vez.

Explicar código que no escribiste

¿Has heredado un archivo de 400 líneas sin comentarios y con el autor ya fuera de la empresa? Un modelo explica realmente bien, siempre que le pidas la altura adecuada.

El punto cuatro es el que más sorprende. Saca a la luz las suposiciones que sostienen el código, de las que depende pero que nunca dice en voz alta. Unos buenos prompts de programación para empezar el onboarding también preguntan "qué se rompe si cambio X", lo que traza el radio de impacto antes de tocar una sola línea.

Boilerplate, andamiaje y conversión entre lenguajes

Aquí es donde los modelos ahorran horas de verdad. Montar el andamiaje de un endpoint CRUD, un parser de configuración, una GitHub Action, un Dockerfile: trabajo repetitivo, muy trillado y con una forma conocida. Los mejores prompts de IA para programar de esta categoría nombran el stack exacto para que el resultado encaje sin reescribirlo.

Para las conversiones, trata al modelo como un traductor que necesita un glosario. Portar de Python a Go no es línea a línea; los modismos son distintos.

Ese último requisito es el que más importa: un hueco semántico silencioso entre dos lenguajes es justo donde el código convertido te muerde semanas después. Si montas estos a menudo desde cero, arrancar de una base estructurada con un generador de prompts para ChatGPT o un generador de prompts para Claude es mejor que mirar una caja vacía. Muchos desarrolladores guardan una carpeta de prompts de ChatGPT para programar reutilizables, uno por cada tipo de proyecto.

Revisar lo que el modelo te devuelve

Cada línea que escribe una IA es una sugerencia, no una respuesta. Los modos de fallo son concretos, y conocerlos al dedillo es parte del trabajo:

• Bugs de lógica sutiles — código que corre, pasa un test superficial y está mal en un caso límite que no probaste. Fallos de uno-en-uno, operadores de comparación dados la vuelta, condiciones invertidas.
• Agujeros de seguridad — SQL concatenado con strings, entrada sin validar, un secreto hardcodeado en una constante, un verify=False que desactiva sin avisar las comprobaciones de TLS. Los modelos reproducen los patrones inseguros con los que se entrenaron.
• APIs obsoletas — un método marcado como deprecated hace tres versiones, porque los datos de entrenamiento tiran a viejos. Por eso la línea de la versión en tu prompt se gana su sitio.
• Librerías alucinadas — un paquete que suena plausible pero no existe, o una función que no está en la API real. Si no la encuentras en la documentación, da por hecho que no existe.

Ejecuta el código. Léelo como leerías el pull request de un desconocido, porque eso es lo que es. Quienes de verdad sacan partido a los prompts de IA para programar no son quienes se fían del resultado, sino quienes aportan contexto suficiente para conseguir un primer borrador sólido y luego lo verifican a fondo antes de publicarlo.

Referencias

• Anthropic — Guía de ingeniería de prompts
• OpenAI — Guía de ingeniería de prompts