Convierte la IA en un revisor exigente en legibilidad, bugs y seguridad, y afina tu juicio defendiendo tus decisiones frente a sus observaciones.
Abrir esta lección en KodokonLa revisión de código entre pares es uno de los aceleradores del crecimiento mejor documentados del oficio, y uno de los más difíciles de conseguir cuando trabajas en solitario. La IA ofrece un revisor disponible a cualquier hora, con una condición: tienes que configurarlo. Por defecto, un modelo es complaciente: elogia tu esfuerzo, señala dos nimiedades y concluye que "en conjunto, es un buen trabajo". Eso no es una revisión, es una palmadita en la espalda. El error simétrico es pedir "reescribe mi código de forma limpia": obtienes código que nunca razonaste, y no aprendes nada. El enfoque correcto: exigir una crítica estructurada (legibilidad, bugs, seguridad) con severidad calibrada y justificaciones.
Eres un revisor sénior exigente, como en la revisión de código de un equipo. Tu objetivo es hacerme mejorar, no ser blando conmigo.
Aquí está mi código ([lenguaje], contexto: [para qué sirve, las restricciones del proyecto]):
[pega el código]
Analízalo según tres ejes:
1. Legibilidad: nombres, estructura, complejidad innecesaria, intención poco clara.
2. Bugs: casos límite no gestionados, errores silenciosos, estados incoherentes, concurrencia.
3. Seguridad: entradas sin validar, inyecciones, datos sensibles expuestos, permisos.
Formato de salida: para cada observación, la línea o el bloque afectado, el eje, la severidad (bloqueante / importante / menor) y el PORQUÉ en una o dos frases.
Restricciones: no reescribas mi código. Como máximo 8 observaciones, las más graves primero. Si una decisión discutible puede defenderse según el contexto, dilo explícitamente en lugar de contarla como un defecto.Fíjate en el límite de 8 observaciones ordenadas por severidad: sin él, obtienes 25 minucias donde una validación de entrada ausente pesa lo mismo que una preferencia de nombres. Fíjate también en la cláusula sobre las decisiones defendibles: obliga al modelo a distinguir el defecto objetivo de la convención discutible. Luego llega la parte más formativa, la que casi todo el mundo se salta: defender tus decisiones. Una revisión no es un veredicto que aplicar, es un diálogo. Cuando una observación te parezca injustificada, replica. O tus razones se sostienen y por fin las has explicitado, o se desmoronan y descubres que esa "decisión" no era más que una costumbre.
Volvamos a tu observación número [X]: consideras que [reformula la observación].
No estoy de acuerdo, y estas son mis razones: [tus argumentos: restricción de rendimiento medida, coherencia con el resto del código, simplicidad deliberada, plazo...].
1. Evalúa honestamente cada uno de mis argumentos: cuáles se sostienen, cuáles son racionalizaciones.
2. Dame el contraargumento más fuerte posible frente a mi postura, como haría un colega experimentado que no estuviera de acuerdo.
3. Concluye: en MI contexto específico, ¿merece el cambio lo que cuesta? Responde sí o no, y luego justifícalo en tres frases como máximo.
No intentes darme la razón: si mis argumentos son débiles, dilo sin rodeos.Dos trampas clásicas de la revisión por IA. Primera trampa: falsas alarmas servidas con aplomo; el modelo señala una race condition imposible en tu arquitectura, o un "bug" que no lo es en tu versión del lenguaje. Trata cada observación como si viniera de un colega brillante que no tiene acceso a todo el contexto: plausible, por verificar. Segunda trampa: el teatro de seguridad. La IA es muy buena detectando patrones clásicos (inyección SQL, XSS, secretos en texto plano) pero se le escapan los fallos de lógica de negocio: una comprobación de autorización ausente en una ruta, un estado intermedio explotable. Una revisión por IA complementa; no sustituye ni una auditoría ni tu conocimiento del dominio.