Revisión de Código en la Era de la IA: Qué Realmente Importa Cuando la IA Escribe el Código

Comparto aquí mi experiencia personal de los últimos meses trabajando con código producido por humanos y agentes de IA, revisando manualmente y usando agentes como Copilot o Cursor. Aún no tengo conclusiones pero el tema se está volviendo súper interesante. Espero que algo de esto sea útil mientras encontrás tu propio enfoque.

Qué Cambió (Y Qué No)

La semana pasada aprobé un PR que se veía perfecta, el código estaba limpio, los tests pasaban, y los cambios en el código estaban relacionados con el problema. Pero unos días después me encontré luchando con los mismos problemas que la PR debía solucionar, los cambios no fueron realmente útiles. Tal vez el código de IA era demasiado humano y nunca entró realmente en el valle inquietante (uncanny valley). El revisor quedó atrapado por una solución convincente y código bonito pero se perdió el punto principal.

El objetivo de la revisión de código para mí siempre fue sobre comunicación, quiero saber que los cambios están alineados con las necesidades que motivaron la pull request, merge request o cualquier otra solicitud de cambio. Además de eso, quiero estar seguro de que los cambios no están afectando partes del sistema que no están destinadas a cambiar y otros criterios de mantenibilidad. Hay dos escenarios, revisar mi propio código y revisar el código producido por otra persona. Ahora tenemos una tercera variable que duplica el número de casos, revisar el código producido por IA para mis propias instrucciones y revisar código producido por IA para instrucciones de un compañero.

Estoy cambiando la forma en que hago revisiones al código producido por IA, porque ahora siento que necesito verificar primero el enfoque, luego la lógica, y finalmente el formato y estilo (ya era algo bien gestionado por herramientas de linting, pero ahora necesitamos verificarlo de nuevo). Revisar mi propio trabajo siempre fue defectuoso por definición, no soy completamente imparcial. Ahora estoy revisando código producido por IA para mis propias instrucciones. Esta es la parte más divertida del trabajo para mí, cuando encuentro una solución tonta en el código es principalmente sobre un mal prompt.

Por otro lado, revisar cambios a soluciones de un compañero es más complicado, los agentes de IA tienden a generar código más verboso y código para tests (la IA no es perezosa como lo soy yo). Casi siempre tiendo a confiar demasiado en el código producido por IA. Es inusual encontrar bugs obvios, lo que hace que los bugs sutiles sean más difíciles de detectar.

La Nueva Lista de Revisión: Qué Buscar

Algo totalmente nuevo es la necesidad de verificar cambios totalmente no relacionados con el objetivo. No es tan difícil descubrir que el agente está modificando otras partes del sistema por razones desconocidas.

Una solución que funciona no es lo mismo que una solución correcta, queremos una solución que pueda ser parte de nuestro codebase, idealmente el mismo tipo de código que escribiría yo mismo. Esto requiere que los cambios sigan nuestro estilo previsto, responsabilidades asignadas a módulos, clases y funciones. La organización del código y el nombrado deben ser consistentes con el resto del codebase, algunos frameworks y librerías son más opinados y estrictos que otros.

Verificar el enfoque arquitectónico es imprescindible, quiero saber si los cambios están alineados con el diseño del sistema. Dependiendo del agente que está programando, tu documentación y tu codebase, podrías necesitar verificar más o menos cosas. Recientemente he estado haciendo más y más uso de documentos markdown simples dentro del repositorio para describir el diseño del sistema, reglas de negocio, todos los detalles sobre las herramientas y procedimientos para operar el sistema. Prefiero hacer este tipo de revisión justo después de la fase de planificación. Esta es una revisión que podemos realizar sobre la documentación y el plan para el agente, antes de escribir la primera línea de código ejecutable. Cambiar el plan o arreglar la documentación es mucho más barato que lidiar con cambios en código en muchos archivos. Por eso es importante para mí asegurar que los cambios estén alineados con los documentos, cualquier cambio en esos documentos o decisiones contra esos principios debe estar justificado y no ser resultado de alucinaciones.

Verificar la lógica de negocio parece ser la parte fácil, una buena organización del código, buen nombrado y la documentación hace que todo sea más simple de revisar. Los tests son uno de los temas que todavía estoy tratando de entender, son súper importantes para evitar regresiones y proporcionar límites claros a los agentes. El problema es que revisar los tests es súper aburrido, mucho código repetitivo, muchos casos de prueba triviales, definitivamente es un trabajo para un bot no para un humano. Todavía estoy buscando buenas formas de usar agentes para revisar, resumir y criticar los casos de prueba.

Seguridad, rendimiento y casos límite requieren una buena revisión. No es por falta de competencia del agente sino por optimización, cuando los requisitos no son claros o demasiado específicos a veces el código producido es realmente genial para los casos conocidos pero también queremos código que anticipe la evolución más probable.

El Problema del Conocimiento: Cuando Menos Código Significa Menos Comprensión

El código escrito por IA a veces es más compacto u optimizado (más difícil de leer), a veces es más largo (toma más tiempo leerlo). En cualquier caso leemos menos código cuando está escrito por IA. Y leer menos código significa que vamos a aprender menos sobre el codebase, el sistema y el problema.

Soy un firme creyente de que el código que funciona es (¿era?) la mejor documentación. Esta nueva era nos está forzando a hacer más fuerte el vínculo entre humanos e IA, la documentación textual parece ser una buena forma de hacerlo. Sí, el texto siempre es ambiguo y propenso a malinterpretaciones. Pero podemos tener un ciclo de retroalimentación ajustado desde la documentación al código generado, cuando el código está mal refinamos la documentación y lo intentamos de nuevo. Los docs se convierten en la fuente de verdad, no algo para escribir después de que el código funciona.

El año 2026 recién está comenzando y los LLMs están evolucionando más rápido que los humanos, he encontrado muchos casos donde implementaciones de hace algunos meses pueden ser mucho mejores ahora. Tener la documentación como fuente de verdad nos permite usar un modelo y agente más nuevo para re-implementar una parte por un costo mínimo. Dependiendo del tamaño y alcance de los cambios, esto podría ser un refactor puro manteniendo los tests sin cambios y asegurando que no surgirán regresiones. Estos cambios requieren un tipo diferente de proceso de revisión, enfocándose en la intención y la lógica de negocio.

Mantener Estándares de Calidad: El Dilema del Profesional

Hace algunos meses, podíamos decir con confianza "el código de IA no puede considerarse listo para producción". Hoy en día, estamos mucho más cerca de lo opuesto. Usar un archivo AGENTS.md o CLAUDE.md bien elaborado te da código que coincide con tus estándares la mayor parte del tiempo. El diablo está en los detalles, tener un buen estándar no significa que algo peligroso no se va a colar en el codebase.

Revisar el código escrito por IA es nuestra última defensa para mantener la calidad. Al mismo tiempo, porque reescribir código con IA es más rápido y barato, deberíamos reconsiderar algunas mejores prácticas aún consideradas. Por ejemplo, DRY (Don't Repeat Yourself) puede no ser tan importante ya que la IA puede manejar la repetición mucho mejor que nosotros porque no se aburrirá de reescribir las 500 líneas de código una y otra vez. Algo que necesitamos considerar es el costo, código repetido significa más costo para tokenizar y menos contexto disponible para otras cosas.

Entonces, podemos agregar calidad después, como agregar un topping a un helado, ¿verdad? Probablemente no, pero podemos asumir algo de deuda y trabajar en ello más tarde. Como siempre, depende del contexto y la fase del proyecto. Ciertamente, ahora estamos cambiando la dinámica del desarrollo de productos, podemos experimentar mucho más y más rápido. Podemos iterar en el producto y el codebase con mucha más frecuencia. Entonces, en caso de que una nueva funcionalidad no funcione como se esperaba, podemos eliminarla sin la culpa habitual del costo hundido. En caso de que algo esté funcionando bien podemos rehacerlo para que se ajuste a nuestros estándares.

Estrategias Prácticas: Hacer que la Revisión Funcione en la Era de la IA

En mi experiencia, las instrucciones a los agentes para seguir ciertas reglas, estándares y mejores prácticas funcionan de manera limitada. La revisión post-codificación es la mejor forma de asegurar que el código esté alineado con las expectativas.

Mis conclusiones sobre esto son:

• Usar IA para revisar el código, después de que creaste un PR o MR antes de enviarlo para revisión por pares.
• Revisar código generado por IA de la misma forma que revisas el tuyo.
• Usar IA para revisar código enviado a vos para revisión por pares.
• Revisar manualmente el código después de la revisión de IA, para asegurar que la IA no se perdió nada.

¿Cómo usar IA para revisar el código?

• Estoy usando Cursor y Copilot para revisión de código. Estoy seguro de que encontraremos mejores herramientas en el futuro, pero por ahora estas son las que estoy usando.
• Usar un modelo y/o herramienta diferente para revisar el código es una buena idea porque mirará los cambios desde una perspectiva diferente.

Conclusión

La revisión de código es más importante, no menos, en la era de la IA. El enfoque cambia de sintaxis a arquitectura, intención y transferencia de conocimiento. El diablo está en los detalles: necesitamos ser más cuidadosos con el código que escribimos y el código que revisamos.

Esto todavía está evolucionando, aún no hay una solución perfecta. Todavía estamos descubriendo dónde la IA ayuda más y dónde los humanos siguen siendo esenciales.

Cada equipo es diferente, cada proyecto es diferente, cada codebase es diferente. Necesitamos experimentar y encontrar lo que funciona para nosotros.