Una primera revisión de tu propio diff antes de que lo vean humanos
El tiempo de los revisores es escaso, y la forma más rápida de respetarlo es detectar tú mismo los problemas evidentes. Cada vez más desarrolladores pasan su propio diff por un modelo como primera pasada, pero solo alrededor del 17% usa IA para la revisión de código y la mayoría mantiene a los humanos firmemente en el proceso, porque los revisores de IA tanto pasan por alto como inventan problemas. Usado como lista de verificación previa a la revisión, detecta problemas de nomenclatura, casos límite y pruebas faltantes antes de que un colega tenga que hacerlo.
Eres un revisor de código senior meticuloso. Revisa el diff de abajo como lo harías en un pull request, pero eres una primera pasada antes de un revisor humano, no un reemplazo. Qué pretende hacer este cambio: {{intent}} Lenguaje/stack y convenciones relevantes del equipo: {{stack}} Diff: {{diff}} Organiza tu revisión así: - Corrección: errores de lógica, off-by-one, manejo de nulos, condiciones de carrera, manejo de errores incorrecto. - Casos límite y entradas: qué entradas o estados inusuales romperían esto. - Seguridad: inyección, deserialización insegura, secretos en el código, autorización o validación faltantes. - Pruebas: qué queda sin probar que debería estarlo, con un caso concreto para cada carencia. - Legibilidad y mantenibilidad: nomenclatura, código muerto, intención poco clara. Para cada hallazgo indica: severidad (bloqueante / debería corregirse / detalle menor), el archivo y la línea, y una corrección sugerida concreta. Reglas: - Comenta solo sobre líneas presentes en el diff. No asumas el comportamiento de código no mostrado; si un hallazgo depende de código no visto, márcalo "necesita contexto" y formúlalo como pregunta. - No inventes números de línea, nombres de funciones ni citas de estándares. Si no estás seguro de que un hallazgo sea real, dilo y baja su severidad. - Omite lo que un linter o formateador detectaría; concéntrate en lo que le importaría a un revisor humano.
Rellena tus datos y el prompt se actualiza al instante — luego cópialo.
Corrección — debería corregirse — services/auth.js línea 20: verifyToken devuelve undefined en un token expirado en lugar de lanzar una excepción, así que quien la llama trata el token expirado como válido. Sugiere lanzar un AuthError. Casos límite — bloqueante — la expresión regular del correo rechaza direcciones con un tag más (user+tag@example.com); agrega una prueba para direcciones con tag. Pruebas — debería corregirse — ninguna prueba cubre la rama de resultado vacío agregada en la línea 42; agrega una que verifique que se devuelve un conjunto vacío. Seguridad — necesita contexto — confirma que req.body.role no puede ser establecido por el cliente; si puede, esto es un salto de autorización.
El flujo de trabajo completo
- Genera el diff con git diff y confirma que no contiene secretos ni código restringido antes de pegarlo
- Dale al modelo la intención del cambio para que pueda juzgar la corrección, no solo el estilo
- Prioriza tú mismo los hallazgos: descarta los falsos positivos y corrige los reales
- Envía el cambio mejorado a un revisor humano; la pasada de IA complementa la revisión, no la reemplaza
Cuidado con
Los revisores de IA tanto pasan por alto errores reales como inventan otros que no existen: alrededor de una cuarta parte de los desarrolladores estima que aproximadamente una de cada cinco sugerencias de IA es incorrecta o engañosa, e incluso los desarrolladores que rara vez ven errores no fusionan sin revisión humana. Nunca dejes que una pasada de IA sustituya a un revisor humano o a tu propio criterio.
No pegues código cubierto por un acuerdo de confidencialidad, datos de clientes o credenciales en una herramienta de consumo para obtener una revisión. Usa una herramienta empresarial aprobada, y recuerda que el diff fusionado es tu responsabilidad, no del modelo.
El modelo puede citar una buena práctica o un estándar de codificación que no existe. Verifica cualquier regla que invoque contra una fuente real antes de actuar sobre ella.
De dónde sale esto
Cada caso de uso de este sitio se basa en relatos reales de los desarrolladores de software en activo — no lo inventamos nosotros.
Más casos de uso de IA para los desarrolladores de software
Explica código desconocido antes de modificarlo
automatizaciónGenera pruebas unitarias y luego verifícalas contra la especificación
análisisDepuración por pato de goma para un problema que no logras resolver
redacciónConvierte una decisión en un ADR o en la documentación que dejaste pendiente
comunicaciónRedacta mensajes de commit y descripciones de PR a partir de tu diff
← Los 6 casos de uso: cómo los desarrolladores de software usan la IA