Prompts para revisar código con IA sin aceptar todo a ciegas

Un asistente de IA puede leer tu código en segundos, señalar errores y proponer mejoras. También puede inventar funciones que no existen, ignorar el contexto de tu proyecto y sugerir parches que rompen otra cosa. La diferencia entre aprovecharlo y sufrirlo está en cómo le pedís las cosas y, sobre todo, en cómo verificás lo que te devuelve.

Esta guía propone un protocolo de revisión en cuatro pasos, ocho prompts listos para copiar y un ejemplo trabajado con un error real. La regla que ordena todo: la IA propone, vos verificás. Ninguna sugerencia entra al repositorio sin una prueba que la respalde.

Por qué una IA no reemplaza la revisión humana

Un modelo de lenguaje predice texto plausible. En código, "plausible" no significa "correcto":

• No conoce tu dominio. No sabe que en tu negocio un pedido cancelado no debe contar en la facturación.
• No ve todo el proyecto. Revisa el fragmento que le pegás, no las dependencias ni los efectos secundarios.
• Tiende a complacer. Si le pedís "encontrá el error", va a encontrar algo, aunque no haya un error relevante.
• Alucina APIs. Puede llamar funciones con parámetros que no existen en tu versión de la biblioteca.
• No asume el costo de equivocarse. Un parche mal aplicado en producción lo pagás vos.

Nada de esto lo inutiliza. Solo define su lugar: es un primer revisor incansable, no el responsable final del código.

El protocolo de cuatro pasos

Cada vez que quieras revisar código con IA, seguí este orden fijo:

1. Contexto. Explicá qué hace el código, en qué entorno corre, qué versión del lenguaje y qué restricciones tenés. Sin contexto, la respuesta es genérica.
2. Riesgo. Pedí explícitamente que busque un tipo de problema por vez: errores lógicos, casos borde, seguridad, rendimiento o legibilidad. Revisar todo junto produce observaciones superficiales.
3. Parche mínimo. Pedí el cambio más pequeño posible que resuelva el problema, no una reescritura completa. Las reescrituras ocultan cambios y rompen cosas.
4. Verificación. Antes de aceptar, reproducí el problema, aplicá el cambio y ejecutá tus pruebas. Si no hay pruebas, escribí una primero.

Este protocolo convierte una conversación difusa en un proceso repetible.

Ocho prompts listos para copiar

1. Resumen de intención

Actúa como revisor de código senior. Lee este fragmento y describí en cinco líneas qué hace, qué datos recibe y qué devuelve. No propongas cambios todavía. Si algo es ambiguo, preguntame antes de asumir.

Sirve para confirmar que el código hace lo que creés que hace.

2. Caza de errores lógicos

Revisá esta función buscando únicamente errores de lógica: condiciones invertidas, valores mal inicializados, casos que devuelven vacío, comparaciones incorrectas. Para cada hallazgo, mostrame un ejemplo de entrada que produce el resultado equivocado. Si no encontrás errores lógicos, decilo explícitamente.

El pedido de "si no hay errores, decilo" reduce el sesgo de complacencia.

3. Casos borde

Listá los casos borde que debería probar para esta función: valores vacíos, cero, negativos, límites, textos con acentos y entradas inesperadas. Para cada caso, indicá el resultado esperado y por qué.

4. Seguridad

Revisá este fragmento como si fueras un atacante. Buscá inyección, datos sin validar, credenciales hardcodeadas, rutas de archivos construidas con entrada del usuario y errores que revelen información interna. Para cada riesgo, indicá el impacto y una mitigación concreta.

5. Rendimiento

Analizá el costo de esta función en términos de operaciones sobre los datos. Señalá bucles anidados, consultas dentro de bucles y estructuras ineficientes. Propone la mejora más simple que no cambie el comportamiento. No optimices antes de medir.

6. Refactor mínimo

Propone el cambio más pequeño que haga esta función más fácil de leer: nombres, extracción de una constante, eliminación de duplicación. No cambies el comportamiento ni agregues abstracciones nuevas.

7. Generar pruebas

Escribe pruebas con pytest para esta función usando arrange, act, assert. Incluí los límites y un caso de error. No modifiques la función; solo agregá pruebas que pasen con el comportamiento actual.

8. Revisión previa al pull request

Este es el diff de mi cambio. Revisalo como si fueras a aprobar un pull request: ¿el cambio hace lo que dice la descripción?, ¿falta una prueba?, ¿hay algo que rompa compatibilidad?, ¿el mensaje del commit explica el porqué? Devolvé una lista corta de bloqueos y otra de sugerencias opcionales.

El último prompt es el más rentable de todos: aplicar una revisión antes de pedir revisión humana ahorra tiempo al equipo y mejora tu reputación.

Ejemplo trabajado: encontrar y corregir un error real

Supongamos esta función que calcula el total de un carrito:

def total_carrito(items):
    total = 0
    for item in items:
        if item["cantidad"] > 0:
            total += item["precio"] * item["cantidad"]
    return total

Le pedimos el prompt 2 (caza de errores lógicos). Una respuesta útil sería:

El error está en el redondeo: sumás precios con decimales y devolvés el acumulado sin redondear, lo que produce diferencias de centavos según el orden de los items. Además, el descuento por item no se considera.

Le pedimos entonces el parche mínimo y una prueba que falle primero:

def test_total_no_pierde_centavos():
    items = [{"precio": 0.1, "cantidad": 3}, {"precio": 0.2, "cantidad": 3}]
    assert total_carrito(items) == 0.9

La prueba falla antes del cambio y pasa después. Ese es el punto: la IA encontró algo, pero la prueba demuestra que el arreglo funciona. Sin prueba, tenés una opinión.

Y hay una segunda parte importante: el error que la IA no ve, porque no conoce tu negocio. Si en tu sistema los productos con cantidad cero deben aparecer en el detalle pero no sumar, el código ya lo hace bien; si los cupones se aplican después de impuestos, tu contexto debe decirlo. El prompt 1 ayuda a que el asistente pregunte antes de asumir.

Cómo comprobar una sugerencia en tres minutos

1. Reproducí primero. Escribí la entrada exacta que produce el problema y confirmá que el resultado es incorrecto.
2. Aplicá el cambio aislado. Un cambio por vez. Si aplicás cinco sugerencias juntas y algo falla, no sabés cuál fue.
3. Ejecutá tus pruebas. Si no hay, escribí la mínima que cubra el caso.
4. Revisá el diff completo. Los asistentes suelen eliminar comentarios, cambiar formato o introducir dependencias sin que lo notes.

Riesgos que conviene tener presentes

• Datos sensibles. No pegues credenciales, datos de clientes, información médica ni código propietario en herramientas públicas. Consultá la política de tu empleador antes de usar asistentes en el trabajo.
• Licencias. Si el asistente reproduce un fragmento de código con licencia, copiarlo puede tener consecuencias legales. En proyectos comerciales, preferí sugerencias conceptuales.
• Dependencia excesiva. Si no podés revisar el código sin asistencia, tu criterio no crece. Alterná: primero resolvé vos, después pedí revisión.
• Falsa confianza. Una respuesta bien redactada parece más correcta de lo que es. La única evidencia válida es ejecutar y probar.
• Cambios silenciosos. Un "refactor mínimo" puede alterar el orden de las operaciones y romper un caso raro.

Limitaciones

• La IA no conoce el historial del proyecto. No sabe por qué esa función tiene una condición aparentemente innecesaria; probablemente el motivo esté en un incidente antiguo.
• No puede validar requisitos. Si el requisito está mal, el código puede estar "bien" y seguir siendo un error de producto.
• Su calidad varía por lenguaje y dominio. Va muy bien en Python y JavaScript genéricos; falla más en configuración de infraestructura o código muy específico.
• No reemplaza pruebas de integración. Un fragmento correcto puede romper el sistema completo.
• No mide impacto en producción. Rendimiento, memoria y comportamiento bajo carga necesitan medición real.

Preguntas frecuentes

¿Los prompts funcionan igual en cualquier asistente? La estructura sí; los resultados varían. Cuanto más específico seas con el contexto y el formato esperado, mejor la respuesta, en cualquier herramienta.

¿Debo pegar todo el archivo o solo una función? Solo lo necesario, con el contexto que importa. Archivos largos dispersan la revisión; fragmentos sin contexto producen generalidades.

¿Es válido usar IA para aprobar mis propios cambios? Como primer filtro, sí. Como única revisión, no. El código que llega a producción necesita una prueba y, en equipos, otra persona.

¿Cómo evito que me reescriba todo? Pedí explícitamente "parche mínimo" y "no cambies el comportamiento ni el estilo". Si igual reescribe, pedile el diff unificado.

¿Qué hago si el asistente insiste con una función inexistente? Verificá la versión de la biblioteca y su documentación oficial. Si la función no existe, descartá la sugerencia completa: puede arrastrar más suposiciones falsas.

¿Sirve para revisar SQL? Sí, y funciona especialmente bien para detectar joins mal armados y nulos. Pedile que te explique la consulta antes de que la modifique.

Siguiente paso

Si querés profundizar en cómo se escriben instrucciones efectivas, la guía de prompt engineering práctico ordena los conceptos y la biblioteca de prompts tiene plantillas para trabajo real. Para el hábito de verificar cambios con pruebas, te sirve la guía de testing con pytest; y para escribir código asistido sin perder criterio, revisá vibe coding: programar con IA. Si querés practicar con acompañamiento, mirá los cursos de Cursalo, empezando por ChatGPT para Principiantes, y la categoría Herramientas y comparativas.