Cómo usar la IA para programar: flujos de trabajo que reducen el riesgo

Reglas para que la IA te ayude a programar sin riesgos

La mejor forma de usar la IA para programar es obligarla a ir más despacio justo en los momentos en los que adivinar sale caro. La IA puede explicarte código que no conoces, convertir errores en hipótesis, redactar pruebas, revisar diffs y proponer refactors. También puede inventar APIs, pasar por alto dependencias ocultas, sobreajustarse al fragmento que pegaste o producir un parche que parece limpio mientras cambia un comportamiento que querías conservar.

Aplica esta regla: la IA propone, pero tu repositorio decide. La fuente de verdad es el código, la reproducción que falla, la suite de pruebas, los logs de ejecución, los requisitos de producto y la revisión humana. Un buen copiloto de IA debería ayudarte a razonar a partir de esos artefactos en lugar de sustituirlos.

Regla	Por qué importa	Qué pedirle al modelo
Reproduce primero	Evita parches al azar	"Repite el comportamiento que falla y la evidencia antes de sugerir código."
Mantén el alcance pequeño	Reduce el riesgo de regresión	"Propón el cambio seguro más pequeño y lista los archivos que tocas."
Preserva el comportamiento	Protege a los usuarios y a los contratos	"Nombra las invariantes que este cambio no puede romper."
Exige pruebas	Hace verificable la respuesta	"Escribe pruebas que fallen antes del arreglo y pasen después."
Revisa antes del merge	Detecta errores dichos con mucha seguridad	"Revisa este diff buscando fallos de corrección, seguridad y casos límite que falten."

Esto vale para cualquier modelo. OpenAI, Anthropic y otros proveedores publican documentación que describe capacidades distintas, ventanas de contexto y patrones de uso de herramientas. Esas capacidades son útiles, pero no sustituyen a un flujo de trabajo disciplinado. En trabajo de ingeniería, juzga a los modelos con el mismo criterio con el que juzgarías a un compañero de equipo: ¿piden el contexto que falta, reducen la incertidumbre, respetan las restricciones y dejan un rastro que puedas verificar?

Flujo de trabajo para depurar

Un flujo fiable para depurar con IA tiene cinco etapas: reproducir, aislar, formular hipótesis, parchear y verificar. No empieces con "arregla esto". Empieza con la evidencia. Dale al modelo el comando que falla, el error exacto, el comportamiento esperado, el comportamiento observado, el código relevante, los detalles del entorno y cualquier cambio reciente que haya podido causar el problema.

Etapa 1: captura la reproducción. Para código de backend, incluye la petición, la respuesta, el código de estado, los logs y la prueba que falla. Para código de frontend, incluye la ruta, la acción del usuario, el error de la consola del navegador, la respuesta de red, el estado del componente y una descripción de la captura de pantalla si viene al caso. Para problemas de build, incluye el comando, el gestor de paquetes, la versión de Node y el error completo alrededor del primer fallo.

Etapa 2: pide hipótesis antes que código. Un modelo cuidadoso debería ordenar las causas probables y decir qué evidencia respalda cada una. Si no puede distinguir entre causas, pídele el paso de diagnóstico más pequeño. Puede ser un log, una prueba enfocada, una comprobación de tipos o leer un archivo más.

Etapa 3: pide el parche más pequeño. Dile al modelo que no renombre variables, no reescriba el código de alrededor, no introduzca dependencias y no cambie el comportamiento público salvo que pueda justificar por qué. Pídele que devuelva la causa raíz, el esquema del parche, los archivos tocados, las pruebas y el riesgo.

Etapa 4: ejecuta las pruebas en local. La salida de la IA no es un paso de verificación. El paso de verificación es el comando o el recorrido de usuario que demuestra el comportamiento. Si no existe ninguna prueba automatizada, pide al modelo que cree primero una prueba de regresión y después implemente el arreglo.

Prompt para depurar:

Actúa como un compañero cuidadoso de depuración. Todavía no escribas código. Primero repite la reproducción, el comportamiento esperado, el comportamiento observado y las tres causas raíz más probables. Ordena cada causa según la evidencia. Después sugiere el paso de diagnóstico más pequeño. Bug: [describe]. Comando o acción del usuario: [pega]. Error/logs: [pega]. Código relevante: [pega]. Restricciones: [stack, archivos que no se deben tocar, comportamiento a preservar].

Prompt para el arreglo:

Con la causa raíz ya confirmada, propón el arreglo seguro más pequeño. Devuelve: causa raíz, archivos/funciones a cambiar, esquema del parche, pruebas que fallen antes y pasen después, casos límite y riesgo de rollback. No refactorices código que no tenga que ver. Contexto: [pega].

Flujo de trabajo para revisar código

A menudo la IA rinde mejor como revisora que como primera autora. Cuando le pides que revise un diff, puede buscar casos límite olvidados, problemas de seguridad, suposiciones caducadas, huecos de pruebas y cambios de comportamiento. La clave está en hacer que la revisión sea específica. Si preguntas "¿esto se ve bien?", recibirás una aprobación amable. Si preguntas por el riesgo de corrección, es mucho más probable que recibas objeciones útiles.

Dale al modelo el diff, el comportamiento previsto, las pruebas relacionadas y cualquier restricción. Pídele que ignore el estilo menor salvo que afecte a la mantenibilidad. Quieres que la revisión priorice bugs, no quisquillosidades para lucirse.

Área de revisión	Preguntas que la IA debe responder
Corrección	¿El diff cumple realmente el requisito?
Riesgo de regresión	¿Qué comportamiento existente podría cambiar sin querer?
Seguridad	¿Se manejan entradas, autenticación, secretos, permisos y riesgos de inyección?
Manejo de errores	¿Qué pasa con nulos, timeouts, reintentos, respuestas malas o estado parcial?
Pruebas	¿Qué afirmaciones sobre el comportamiento quedan sin cubrir?
Mantenibilidad	¿Sigue los patrones del proyecto y mantiene el cambio comprensible?

Prompt para revisar código:

Revisa este diff como un mantenedor estricto pero práctico. Céntrate en corrección, riesgo de regresión, seguridad, casos límite y pruebas que falten. Ignora el estilo menor salvo que cree un riesgo real de mantenimiento. Devuelve una tabla con problema, prioridad, evidencia del diff, arreglo sugerido y prueba necesaria. Comportamiento previsto: [pega]. Diff: [pega]. Pruebas existentes: [pega].

Para cambios de alto riesgo, usa un flujo de comparación de arreglos entre modelos en Whizi. Ejecuta el mismo prompt de revisión en dos o tres modelos. Si un modelo encuentra un posible problema, no lo aceptes a ciegas; comprueba si el problema existe de verdad en el código. El objetivo no es acumular más opiniones. El objetivo es ampliar la superficie de revisión antes del merge.

Flujo de trabajo para refactorizar y probar

Refactorizar con IA es arriesgado porque muchos refactors se juzgan por lo que no cambia. El modelo puede dejar el código más bonito mientras altera sutilmente el comportamiento, el manejo de errores, los tiempos o los contratos públicos. Un flujo de refactor más seguro empieza definiendo las invariantes antes de tocar la implementación.

Paso 1: describe el objetivo del refactor. Ejemplos: reducir duplicación, dividir un componente grande, aislar el acceso a datos, simplificar ramificaciones, migrar un wrapper de API o mejorar la testabilidad. Después declara qué debe seguir igual: firmas de funciones públicas, comportamiento de las rutas, nombres de eventos, formas de respuesta, analítica, permisos, comportamiento de accesibilidad y expectativas de rendimiento.

Paso 2: pide un plan por etapas. Un buen plan de refactor hecho con IA debe ser reversible. Cada etapa debería tocar un área pequeña, incluir pruebas y dejar un estado intermedio que funcione. Evita las reescrituras de una sola pasada salvo que el código sea diminuto y esté bien cubierto.

Paso 3: escribe pruebas de caracterización. Antes de cambiar el código, pide a la IA que identifique el comportamiento actual y redacte pruebas que fijen los casos importantes. Estas pruebas son especialmente útiles en código heredado, donde la intención no está clara. Deben incluir entradas normales, entradas límite, caminos de fallo y un caso de regresión ligado al motivo del refactor.

Paso 4: implementa una etapa cada vez. Después de cada etapa, ejecuta las pruebas y pide una revisión enfocada. Si el modelo propone una abstracción amplia, hazle demostrar que esa abstracción elimina duplicación o riesgo reales. Si no, deja el código aburrido y local.

Prompt para planificar un refactor:

Crea un plan de refactor por etapas. Objetivo: [objetivo]. Código actual: [pega]. Restricciones: preservar el comportamiento público, minimizar el churn, seguir los patrones existentes, evitar dependencias nuevas y mantener cada etapa testeable. Devuelve: invariantes, mapa de dependencias, etapas, archivos tocados, pruebas por etapa, riesgo de rollback y lista de verificación para la revisión.

Prompt para pruebas unitarias:

Escribe pruebas antes de cambiar la implementación. Usa el estilo de pruebas existente que se muestra aquí: [pega]. Comportamiento a preservar: [pega]. Código bajo prueba: [pega]. Devuelve nombres de prueba, preparación, entrada, resultado esperado y por qué importa cada prueba. Incluye camino feliz, caso límite, caso de error y caso de regresión.

Plantillas de prompts

Los buenos prompts para programar no son largos por alarde. Son lo bastante largos como para eliminar la ambigüedad. El modelo necesita rol, tarea, contexto, restricciones, formato de salida y criterios de verificación. Guarda los prompts que funcionan para que la IA se convierta en un flujo de ingeniería repetible y no en una conversación suelta.

Prompt para explicar código:

Explica este código para un desarrollador que se incorpora al proyecto. Cubre propósito, entradas, salidas, flujo de datos, dependencias, modos de fallo y pruebas que aumentarían la confianza. Separa los hechos visibles en el código de las suposiciones. Código: [pega].

Prompt para código seguro:

Revisa este código en busca de riesgos de seguridad. Céntrate en autenticación, permisos, inyección, secretos, validación, redirecciones inseguras, manejo de archivos, riesgo de dependencias y exposición de datos sensibles. Devuelve solo los problemas, con evidencia, impacto, arreglo sugerido y prueba o comprobación manual. Código/diff: [pega].

Prompt para comparar arreglos entre modelos:

Estoy comparando modelos de IA para una tarea de programación. Usa solo el contexto proporcionado. Devuelve causa raíz, el arreglo seguro más pequeño, pruebas, riesgos, suposiciones y preguntas. Califica tu confianza del 1 al 5 y enumera qué evidencia cambiaría tu respuesta. Tarea: [pega]. Contexto: [pega].

Lista de control antes de aceptar código generado por IA:

• El modelo repitió la tarea correctamente.
• El parche es más pequeño que el problema, no más grande.
• El comportamiento y los contratos públicos están nombrados.
• Las pruebas cubren directamente el bug o el objetivo del refactor.
• Los casos límite y los caminos de fallo están listados.
• Las entradas sensibles a la seguridad están revisadas.
• El diff sigue los patrones existentes del proyecto.
• Ejecutaste la prueba, el lint, el build o la reproducción manual que corresponde.
• Una persona revisó el diff final.

Whizi te sirve cuando quieres comparar arreglos sin cambiar la tarea. Pega el mismo prompt de depuración o de revisión en varios modelos y después puntúa los resultados por evidencia, alcance, pruebas y riesgo. Empieza por alternativas a ChatGPT para programar si quieres una guía de selección de modelo, compara planes en precios o crea una cuenta para ejecutar el flujo sobre tu propio código.