La revisión de código en la era de la IA

• La IA no eliminó la revisión de código; más bien, aclaró la carga de la prueba
• Los cambios deben desplegarse adjuntando evidencia como validación manual o pruebas automatizadas, y luego la revisión debe identificar riesgo, intención y responsabilidad
• Mientras los desarrolladores individuales dependen de la automatización para seguirle el ritmo a la velocidad de la IA, los equipos construyen contexto compartido y sentido de responsabilidad mediante la revisión
• Si un PR no incluye evidencia de funcionamiento, no es un despliegue rápido sino simplemente mover el trabajo aguas abajo; solo los desarrolladores con un sistema de validación logran tener éxito con el desarrollo acelerado por IA
• El cuello de botella de la revisión de código se desplazó de escribir código a demostrar que funciona, y aunque la IA acelera el trabajo mecánico, la responsabilidad sigue siendo humana

Cambios en la revisión de código en la era de la IA

• A inicios de 2026, más del 30% de los desarrolladores senior ya estaban desplegando principalmente código generado por IA. La IA sobresale para redactar funciones, pero expone vulnerabilidades en lógica, seguridad y casos límite, incluyendo un aumento del 75% en errores lógicos
• Los desarrolladores solitarios despliegan rápido con velocidad de inferencia (inference speed) y usan suites de pruebas como red de seguridad, mientras que los equipos mantienen la revisión humana para preservar contexto y cumplimiento
• Si se hace bien, ambos pueden usar la IA como acelerador, pero la diferencia está en quién valida qué y cuándo
• Si no verificaste personalmente que el código funciona, entonces no funciona de verdad
  • La IA solo refuerza esta regla; no la invalida

Cómo revisan los desarrolladores al usar IA

• Verificación ad-hoc con LLM: antes de hacer commit, pegan el diff en Claude, Gemini o GPT para detectar rápido bugs o problemas de estilo
• Integración en el IDE: usan herramientas como Cursor, Claude Code o Gemini CLI para obtener sugerencias en línea y refactorizaciones mientras programan
• Bots de PR y escáneres: con GitHub Copilot o agentes personalizados marcan automáticamente posibles problemas en los PR, y complementan con herramientas de análisis estático y dinámico como Snyk para revisar seguridad
• Loops de pruebas automatizadas: usan IA para generar y ejecutar pruebas, y fijan más del 70% de cobertura como condición para hacer merge
• Revisión con múltiples modelos: revisan código con varios LLM para detectar sesgos de cada modelo (por ejemplo, generar con Claude y auditar con un modelo especializado en seguridad)

Desarrollador individual vs. equipo: comparación

• Desarrollador individual
  • Enfoque de revisión: pruebas automatizadas + revisiones puntuales limitadas
  • Intercambio con la velocidad: rapidez basada en el tiempo de inferencia, corrigiendo problemas en un loop iterativo
  • Herramienta clave: pruebas agénticas (por ejemplo, loops con Claude Code)
  • Principio: Demuéstralo tú mismo (Prove it yourself)
• Equipo
  • Enfoque de revisión: revisar contexto y seguridad con criterio humano
  • Intercambio con la velocidad: mantener PR pequeños para evitar cuellos de botella en la revisión
  • Herramienta clave: combinación de bots + políticas (por ejemplo, etiquetar PR generados por IA)
  • Principio: Compartir la prueba con el equipo (Share the Proof)

Desarrollador individual: desplegar con “velocidad de inferencia”

• Los desarrolladores individuales suelen confiar en la “vibra” del código generado por IA, verifican solo las partes clave y publican funciones rápido usando pruebas para detectar problemas
• Tienden a tratar a los agentes de programación como becarios muy capaces que pueden encargarse solos de grandes refactorizaciones
• Declaración de Peter Steinberger: “Ya no leo mucho código. Veo el stream y, de vez en cuando, reviso solo las partes importantes”
• El cuello de botella del desarrollo dejó de ser teclear y pasó a ser el tiempo de inferencia (esperar la salida de la IA)
• Precaución: sin pruebas sólidas, la mejora de velocidad percibida desaparece
  • Saltarse la revisión no elimina el trabajo; solo lo pospone
  • La clave para tener éxito con desarrollo acelerado por IA no es la confianza ciega, sino construir un sistema de validación
• Los desarrolladores individuales responsables usan pruebas automatizadas extensivas como red de seguridad y apuntan a una cobertura superior al 70%
• Las pruebas independientes del lenguaje y basadas en datos cumplen un papel decisivo
  • Si hay suficientes pruebas, el agente puede generar, modificar y validar implementaciones sin importar el lenguaje
  • Al iniciar un proyecto, la IA redacta un borrador de spec.md; tras aprobarlo, repite el loop de escribir → probar → corregir
• Incluso el desarrollador individual realiza pruebas manuales y juicio crítico en la etapa final
  • Ejecuta personalmente la aplicación, hace clic en la UI y usa la funcionalidad
  • Si el riesgo es alto, lee más código y hace validaciones adicionales
  • Aunque desarrolle rápido, limpia el código desordenado apenas lo detecta
• Principio clave: la misión del desarrollador es “entregar código cuyo funcionamiento haya demostrado personalmente”

Equipos: la IA desplaza el cuello de botella de la revisión

• En entornos de equipo, la IA es un gran apoyo para la revisión de código, pero no puede reemplazar el juicio humano necesario para calidad, seguridad y mantenibilidad
• Cuando colaboran varios ingenieros, el costo de los errores y la vida útil del código se vuelven factores mucho más importantes
• Muchos equipos usan bots de revisión con IA en las primeras etapas del PR, pero la aprobación final sigue requiriendo a una persona
• Declaración de Greg Foster de Graphite: “Los agentes de IA nunca reemplazarán la aprobación de PR por parte de un ingeniero humano real”
• El mayor problema práctico no es que los revisores de IA omitan temas de estilo, sino que la IA aumenta el volumen de código y traslada la carga de revisión a los humanos
  • Con la adopción de IA, el tamaño de los PR aumentó alrededor de 18%
  • Los incidentes por PR aumentaron alrededor de 24%
  • La tasa de fallas por cambio aumentó alrededor de 30%
• Si la velocidad de generación supera la capacidad de validación, el proceso de revisión se convierte en el factor que limita la velocidad de todo el flujo de desarrollo
• Foster también señaló: “Desplegar código que otro ser humano no puede leer o entender es un gran riesgo”
• En equipos, como la IA produce grandes volúmenes de salida, hace falta aplicar desarrollo incremental y dividir la salida del agente en commits que sí se puedan revisar
• La aprobación final humana no desaparece; en cambio, evoluciona para centrarse en las áreas que la IA no ve (alineación con el roadmap, contexto organizacional e institucional que la IA no puede captar)

Seguridad: vulnerabilidades predecibles de la IA

• La seguridad es un área donde el juicio humano es absolutamente necesario
• Se encontraron fallas de seguridad en alrededor del 45% del código generado por IA
• La tasa de errores lógicos es 1.75 veces mayor que en código escrito por humanos
• La frecuencia de vulnerabilidades XSS es 2.74 veces mayor
• Además de los problemas del código en sí, las herramientas basadas en agentes y los IDE integrados con IA abren nuevas vías de ataque
  • prompt injection, filtración de datos y vulnerabilidades de RCE
• Dado que la IA amplía la superficie de ataque, un enfoque híbrido resulta eficaz
  • La IA marca posibles problemas y el humano hace la validación final
• Regla: el código que maneja autenticación, pagos, secretos o entradas no confiables debe tratar a la IA como a un becario veloz y exigir revisión humana de modelado de amenazas e inspección con herramientas de seguridad antes del merge

Transferencia de conocimiento mediante la revisión

• La revisión de código es un medio clave para que el equipo comparta el contexto del sistema
• Si la IA escribió el código pero nadie puede explicarlo, aumenta el costo de on-call
• Si se envía código generado por IA que nadie entiende por completo, se rompe el mecanismo de transferencia de conocimiento que le da resiliencia al equipo
• Si el autor no puede explicar por qué funciona el código, el ingeniero de guardia no podrá depurarlo a las 2 de la mañana
• Hubo un caso en el que un maintainer de OCaml rechazó un PR de 13,000 líneas generado por IA
  • La calidad del código no necesariamente era mala, pero no había suficiente ancho de banda de revisión para cambios de ese tamaño
  • Revisar código generado por IA exige una carga cognitiva mayor que revisar código escrito por humanos
• Lección: la IA puede producir mucho código, pero los equipos deben controlar el tamaño de los cambios para evitar cuellos de botella en la revisión

Cómo usar herramientas de revisión con IA

• La experiencia de uso con herramientas de revisión basadas en IA está claramente dividida
• Lado positivo: en algunos casos, detectan más del 95% de los bugs, como excepciones por puntero nulo, faltas de cobertura de pruebas y antipatrones
• Lado negativo: algunos desarrolladores perciben los comentarios de revisión con IA como “ruido de texto”, observaciones generales sin valor
• Lección: las herramientas de revisión con IA requieren una configuración cuidadosa
  • ajustar sensibilidad, desactivar tipos de comentarios poco útiles y establecer políticas claras de opt-in y opt-out
• Si se configuran bien, los revisores con IA pueden detectar el 70–80% de los problemas fáciles, y los humanos pueden concentrarse en arquitectura y lógica de negocio
• Aunque la IA pueda generar cambios gigantes de una sola vez, muchos equipos siguen recomendando PR pequeños y acumulables
• Los cambios deben registrarse con frecuencia y gestionarse como commits o PR separados, cada uno como una unidad autocontenida con un mensaje claro
• Los equipos mantienen límites claros sobre la responsabilidad humana
• Sin importar cuánto haya contribuido la IA, la responsabilidad final recae en las personas
• Máxima de formación de IBM: “Una computadora nunca puede asumir responsabilidad. La responsabilidad es de la persona dentro del loop”

El contrato del PR: la obligación del autor frente al revisor

• Tanto para individuos como para equipos, la mejor práctica común que está surgiendo es tratar el código generado por IA como un borrador útil que necesita validación
• Existe un framework simple que comparten los equipos más exitosos

• Componentes del contrato del PR

  1/. What/Why: resumir en 1–2 oraciones la intención del cambio y por qué se hizo 2/. Evidencia de funcionamiento: resultados de pruebas superadas y pasos de validación manual (capturas de pantalla, logs) 3/. Riesgo + rol de la IA: indicar el nivel de riesgo del cambio y qué parte fue generada por IA (por ejemplo, pagos = alto riesgo) 4/. Enfoque de revisión: señalar 1–2 áreas donde hace falta revisión humana (por ejemplo, arquitectura)
• Esto no es burocracia, sino una forma de respetar el tiempo del revisor y dejar clara la responsabilidad del autor
• Si no puedes escribir esto, entonces todavía no entiendes lo suficiente tu propio cambio como para pedirle a otra persona que lo apruebe

Principios clave

• Exigir evidencia, no promesas: tomar como línea base el “código que funciona”, pedirle al agente de IA que ejecute el código o corra pruebas unitarias después de generarlo, revisar evidencia como logs, capturas o resultados, y no abrir un PR sin nuevas pruebas o una demo funcional
• Usar la IA como primer revisor, no como árbitro final: tratar la salida de revisión de IA como asesoría, hacer que una IA escriba código y otra lo revise mientras una persona coordina la dirección de los cambios; usar la revisión por IA al nivel de un corrector ortográfico, no como editor
• La revisión humana debe enfocarse en lo que la IA no detecta: si se introdujeron vulnerabilidades de seguridad, si se duplicó código existente (un defecto común de la IA), si el enfoque es mantenible; la IA filtra lo fácil y los humanos toman las decisiones difíciles
• Aplicar desarrollo incremental: dividir el trabajo en unidades pequeñas para que la IA lo genere fácilmente y los humanos lo revisen con facilidad, usar commits pequeños con mensajes claros como checkpoints y nunca hacer commit de código que no puedas explicar
• Mantener estándares altos de pruebas: los desarrolladores que aprovechan bien los agentes de programación sostienen prácticas sólidas de testing y le piden a la IA borradores de pruebas para generar tests de casos límite que una persona podría pasar por alto

Perspectiva futura: el cuello de botella se mueve

• La IA está llevando la revisión de código de una puerta de control línea por línea hacia una gestión de calidad de alto nivel, pero el juicio humano sigue siendo un requisito esencial de seguridad
• Esto es una evolución del flujo de trabajo, no la eliminación de la revisión de código
• El alcance de la revisión ya no incluye solo el diff del código, sino también la conversación o el plan entre la IA y el autor
• El rol del revisor humano se acerca cada vez más al de un editor o arquitecto, concentrado en decisiones importantes y confiando en la automatización para las verificaciones rutinarias
• Para los desarrolladores individuales, el camino que viene es interesante, pero aunque aumenten las herramientas, los buenos desarrolladores seguirán con la idea de “confiar, pero verificar”
• En equipos grandes, se espera un fortalecimiento de la gobernanza de IA
  • formalizar políticas sobre contribuciones de IA y exigir aprobación que confirme revisión directa por parte del personal
  • aparición de roles como “auditor de código de IA”
  • las plataformas empresariales evolucionarán para soportar mejor el contexto multi-repositorio y la aplicación de políticas personalizadas
• El principio central no cambia: la revisión de código asegura que el software cumpla requisitos, sea seguro, robusto y mantenible
• La IA no cambia esa base; solo cambia la forma de llegar a ella
• El cuello de botella del desarrollo se mueve de escribir código a demostrar que funciona
• Los grandes revisores de código de la era de la IA aceptan este cambio, pero mantienen la línea de la responsabilidad mientras permiten que la IA acelere el trabajo mecánico
• La IA puede acelerar (accelerate) el proceso, pero no debe hacer que renunciemos (abdicate) a la responsabilidad
• Los ingenieros valorarán cada vez más “pruebas por encima de vibes (proof over vibes)”
• La revisión de código no desapareció; está asumiendo un papel más estratégico
• Ya sea un desarrollador individual desplegando a las 2 de la mañana o un líder técnico aprobando cambios críticos en sistemas importantes, hay un hecho común: la responsabilidad final por los resultados creados por IA recae en los humanos
• Adopta la IA, pero mantén el hábito de volver a comprobar el trabajo

[tested]

https://www.coderabbit.ai/
¿Alguien ha usado CodeRabbit? El precio es bastante alto, pero no sé si realmente vale lo que cuesta.

[developerjhp]

Si usas la extensión de Chrome de abajo, puedes pedirle cómodamente a GPT una revisión basada en el diff del PR de GitHub~!
https://github.com/developerjhp/Diffinity

[crawler]

Si lo hiciste tú mismo, creo que sería mejor publicarlo en Show GN.

Hasta hace 5 meses lo publicabas bien en Show GN, ¿pero por qué promocionarlo en los comentarios? T_T...