No, la IA no debería revisar su propio código

La idea más tentadora de la IA (y por qué no la usamos)

«Ya que la IA escribe el código, que la IA también lo revise.» Es la idea más tentadora del momento. Y, para nosotros, la más peligrosa.

Desde que en Macro Securities adoptamos la metodología de Agentic Engineering, la capacidad de generar código del equipo se multiplicó gracias a los LLMs: duplicamos la cantidad de código que producimos por sprint. Ganamos productividad y calidad, pero destapamos un problema que nadie esperaba: cada línea que genera un LLM es una línea que alguien tiene que entender, cuestionar y hacerse responsable antes de que llegue a producción.

El cuello de botella se mudó. Ya no cuesta escribir el código: cuesta revisarlo. Y las code reviews siempre fueron una de las actividades más problemáticas de la ingeniería de software: tareas que demoran su entrega por idas y vueltas en la revisión. Hace unos años grabé un video sobre cómo las Pull Requests hacen que te demores (Pull Requests are dragging you down), y eso era en la época previa a la IA. Ahora el problema se exacerbó todavía más.

Comparación del tiempo de un cambio antes y después de la IA: antes el 65% del tiempo se iba en escribir código y el 35% en revisarlo; con IA se invierte a 30% escribir y 70% revisar, que pasa a ser el nuevo cuello de botella.

¿La solución fácil? Que la IA se revise a sí misma. Pero como escribí reflexionando sobre Agentic Engineering, necesitamos hacernos responsables del código que desplegamos en producción, y no podemos hacerlo a menos que realmente lo entendamos y nos aseguremos de que es correcto. En un banco, esa responsabilidad no se delega en un modelo. Después de todo, a pesar de lo poderosos que son, los LLMs se equivocan.

Para resolver este problema, encaramos la solución desde distintos ángulos que nos ayuden a:

  • Evitar demoras innecesarias
  • Mejorar la experiencia del autor y del revisor del código

Es por eso que nos enfocamos en cambios metodológicos y la incorporación de asistencia de IA para eficientizar las revisiones.

Cambios metodológicos

Lo primero que hicimos fue cambiar la forma en que hacíamos las code reviews.

  • En lugar de tener un canal de Pull Requests para que las tome alguien del equipo que pueda, asignamos las PRs a reviewers en el momento de la planning. Esto permite tener responsables bien claros de hacer que la tarea progrese.
  • Teniendo responsables de code review, podemos también establecer tiempos límites para la primera pasada.
  • Fomentamos el stacking de PRs. Esto es, en lugar de crear un PR muy grande, se crean pequeños PRs encadenados entre sí que sirvan para dividir el trabajo en bloques lógicos.
  • Fomentamos las reuniones de code review, para código complejo que necesita que el autor y el revisor se junten para poder comprender lo que se hizo.

Asistencia de IA

Lo otro que hicimos fue utilizar la IA para mejorar y agilizar el proceso de la revisión. Todos los devs de Macro Securities usan IA para asistirlos a revisar el código, pero luego es necesario que ellos revisen también por su cuenta para evitar errores. La UI de GitHub tiene algunas limitaciones para revisar el código de forma eficiente:

  • Muestra los archivos en orden alfabético.
  • No permite agruparlos en un orden lógico para la PR.
  • Muestra los archivos sin ningún tipo de contexto. Por ejemplo: archivos de configuración o de tests, muy difíciles de revisar si uno no sabe exactamente por qué se modificaron o se crearon.

Es por eso que creamos el PR Visualizer. Esta tool utiliza la IA para generar una visualización de PRs con las siguientes características:

Pipeline del PR Visualizer: el ticket de Jira y el PR de GitHub se combinan en un fetch + system prompt, pasan por un LLM, se ensamblan y se sirven en una React App que visualiza el PR con los archivos agrupados lógicamente y diagramas.
  • Obtiene contexto de la tarea leyendo la descripción del PR y el ticket de Jira.
  • Agrupa los archivos de forma lógica, agregando notas de por qué se agrupan y explicando brevemente cuál es el propósito de los cambios.
  • Agrega comentarios en los archivos que pueden ser considerados o descartados por el revisor.
  • Crea diagramas útiles para la revisión:
    • Un mapa mental para poder revisar los archivos
    • Diagramas de Entidad-Relación para nuevos cambios en base de datos
    • El LLM considera si es necesario crear diagramas de flujo, estados, etc, para ayudar al revisor con la tarea de entender lo que hace el código.
Comparación de la misma PR: en la vista de GitHub los archivos aparecen en orden alfabético y sin contexto; en el PR Visualizer los mismos archivos están agrupados por lógica (Autenticación, Base de datos, Configuración) con una nota que explica cada grupo.

Al destrabar el cuello de botella de la revisión, protegemos algo que nos importa de verdad: seguir entregando valor cada semana.