# Cómo revisar código generado por IA sin que se te escape nada > Guía para revisar código de agentes: la técnica de tres pasadas, CodeRabbit como primer filtro y los fallos típicos que la IA comete con seguridad. - Canonical: https://serchai.com/guias/revisar-codigo-ia/ - Site: Serchai (https://serchai.com) — AI tools comparator - Language: es - Updated: 2026-07-25 --- ## Herramientas que vas a usar - [CodeRabbit](https://serchai.com/opiniones/coderabbit/) — Revisión automática de pull requests con contexto: comenta antes de que llegue un humano. - [Claude Code](https://serchai.com/opiniones/claude-code/) — El agente de código de Anthropic: trabaja en tu terminal, tu IDE y la web. - [GitHub Copilot](https://serchai.com/opiniones/github-copilot/) — El asistente de código integrado en GitHub y en tu IDE, desde 10 dólares. ## Los pasos, en resumen 1. **Deja que la máquina cace lo mecánico primero** — Un revisor automático de pull requests filtra los errores obvios antes de gastar tu atención. 2. **Revisa con la técnica de tres pasadas** — Perímetro del cambio, pruebas y lectura fina de la lógica, en ese orden. 3. **Conoce los fallos característicos del código de IA** — Los agentes fallan con patrones reconocibles, y saberlos convierte tu revisión en búsqueda dirigida. 4. **Convierte cada hallazgo en prevención** — Lo que caces en revisión vuelve al fichero de instrucciones para que no se repita. > **TLDR:** El código de agente llega en volumen y con una seguridad que invita a confiar, y ahí está la trampa: la IA falla con patrones propios que la revisión clásica no busca. El sistema: CodeRabbit como primer filtro automático de cada pull request, tu revisión en tres pasadas (perímetro, pruebas, lógica) y cada hallazgo convertido en instrucción permanente. La revisión no es el peaje del agente: es tu mitad del trabajo. Esta guía es para desarrolladores que ya delegan en agentes y notan que el cuello de botella se ha movido: ya no es escribir, es revisar. Es la consecuencia natural del sistema montado en la guía del [primer proyecto con agentes](https://serchai.com/guias/primer-proyecto-agentes-ia/), y merece su propia técnica. El principio que lo preside: el volumen de código generado no rebaja el estándar de lo que se fusiona. Cambia cómo se revisa, no cuánto importa. ## 1. Deja que la máquina cace lo mecánico primero La primera pasada no deberías hacerla tú. [CodeRabbit](https://serchai.com/opiniones/coderabbit/) revisa cada pull request al abrirse: resume qué cambia, señala errores probables, casos borde y problemas evidentes de seguridad, y comenta línea a línea con contexto del proyecto. Gratis para código abierto y desde unos 24 dólares por desarrollador en repositorios privados. El efecto sobre tu revisión es de filtro: cuando llegas, lo mecánico está señalado y tu atención va a lo que la máquina no ve. Y hay una simetría que funciona: que una IA revise a otra no es redundancia, porque el revisor no arrastra el contexto ni las decisiones del generador, y ve el cambio con ojos limpios. Si tu equipo ya vive en GitHub con [Copilot](https://serchai.com/opiniones/github-copilot/), su revisión de pull requests integrada cubre una parte de este filtro sin coste añadido: menos profunda, misma función de primera pasada. ## 2. Revisa con la técnica de tres pasadas La revisión eficaz de código de agente tiene un orden, y el orden es lo que la hace sostenible en volumen. Primera pasada, el perímetro: mira la lista de ficheros tocados antes que ninguna línea. ¿El cambio toca lo que la tarea pedía y nada más? El desvío clásico del agente es el arreglo que aprovecha para "mejorar" cosas que nadie pidió, y ese exceso se detecta en diez segundos mirando el perímetro, no leyendo diffs. Segunda pasada, las pruebas: ¿existen, pasan y prueban lo que importa? La prueba generada tiene su patología propia: la que verifica que el código hace lo que hace (tautológica) en lugar de lo que debe hacer. Leer las aserciones con esa sospecha concreta es la vacuna. Tercera pasada, la lógica: ahora sí, la lectura fina del código nuevo, con especial atención a los bordes (vacíos, nulos, errores, concurrencia) que es exactamente donde el código generado más confía y menos comprueba. ## 3. Conoce los fallos característicos del código de IA El código de agente no falla como el humano, y conocer su patología dirige la búsqueda. Los clásicos: la invención plausible (la función de la librería que no existe, el parámetro que suena bien), la seguridad de bordes (el caso feliz impecable y el borde sin manejar), la duplicación silenciosa (reimplementar lo que el proyecto ya tenía, por no haberlo encontrado), y la obsolescencia confiada (el patrón de hace tres versiones de la librería, escrito con total seguridad). Cada uno tiene su detector barato: las dependencias e imports se verifican en segundos, los bordes se preguntan sistemáticamente (¿y si viene vacío?), la duplicación se caza con una búsqueda del nombre, y lo obsoleto sale al ejecutar las pruebas de verdad. La ventaja de esta patología conocida: tu revisión deja de ser lectura general y pasa a ser búsqueda dirigida, que es más rápida y caza más. ## 4. Convierte cada hallazgo en prevención La revisión que solo corrige es la mitad del sistema. Cada fallo cazado es información sobre lo que el agente no sabía de tu proyecto, y su destino natural es el fichero de instrucciones del repositorio: la convención que violó, la librería que debía usar, el patrón de manejo de errores de la casa. Ese ciclo (fallo, corrección, instrucción) es lo que hace que el mismo error no vuelva, y explica por qué los equipos con meses de agente revisan cada vez menos de lo mismo. El fichero de instrucciones maduro es revisión acumulada. Con la revisión resuelta, el sistema escala hacia el volumen: la guía de [agentes en paralelo](https://serchai.com/guias/agentes-paralelo-ia/) multiplica el trabajo con la revisión como límite consciente, y la de [seguridad del código generado](https://serchai.com/guias/seguridad-codigo-generado-ia/) profundiza en la pasada que no admite atajos. Todo el sector, en [IA para desarrollo de software](https://serchai.com/ia-para/desarrollo-software/). ## Errores comunes Aprobar por confianza acumulada. Es el fallo terminal de la revisión de agentes: cada éxito erosiona la disciplina, y el coste llega concentrado el día que tocaba leer. Leer el diff línea a línea desde el principio. Sin la pasada de perímetro previa, gastas la atención en cambios que quizá ni debían estar, y llegas cansado a la lógica que importaba. Fiarse de que las pruebas pasan. La prueba tautológica pasa siempre: verifica las aserciones, no el color verde. Corregir sin actualizar las instrucciones. El mismo fallo volverá en la siguiente sesión, porque la conversación se olvida y el fichero no. ## Preguntas frecuentes ### ¿Cuánto tiempo debería llevar revisar el trabajo de un agente? Con el filtro automático y las tres pasadas, una tarea mediana se revisa en minutos. Si la revisión te lleva más que hacer la tarea, la tarea estaba mal troceada o el peldaño de confianza mal elegido. ### ¿La revisión con IA no es un círculo vicioso? No: el revisor automático no comparte el contexto ni las decisiones del generador, así que ve el cambio con ojos limpios. La combinación de generador, revisor automático y humano es redundancia bien construida. ### ¿Qué fallo de IA es el más peligroso? La invención plausible en dependencias y APIs, porque compila mal o falla en ejecución de formas raras, y la seguridad con que está escrita desarma la sospecha. La verificación de imports y funciones es la pasada más rentable. ### ¿Puedo saltarme la revisión en tareas triviales? Puedes decidir peldaños de confianza con revisión ligera, y aun ahí el perímetro y las pruebas se miran. El día que la tarea trivial toca un fichero que no debía, esa mirada de diez segundos es la que lo caza.