- En la era en que la IA escribe código, la forma de revisar pull requests (PR) debe cambiar de raíz, y el proceso actual de revisión no encaja con los flujos de trabajo de programación con IA
- Cuando el revisor pregunta "¿por qué se hizo así?", el desarrollador vuelve a preguntárselo a la IA y pega la respuesta, lo que genera la ineficiencia de que el humano se quede solo como intermediario (middleman)
- El registro de decisiones (decision log) de la IA debe incluirse en el control de código fuente junto con el código, para que el revisor pueda verificar el contexto directamente
- Ya es posible un flujo de trabajo en el que la IA reciba directamente los comentarios del revisor y genere automáticamente parches y respuestas mediante la combinación de webhooks de GitHub/GitLab y un servidor MCP
- Los documentos de diseño y los diagramas de arquitectura también deben incluirse en el control de código fuente en formatos que un LLM pueda parsear, como Markdown o Mermaid; "el contexto es rey"
Problemas de la revisión de código en la era de la IA
- Al hacer preguntas durante una revisión de PR, vuelven respuestas que parecen generadas por IA, porque en realidad quien escribió el código fue la IA
- Ante la pregunta "¿por qué se eligió esta librería?", el desarrollador humano no puede responder, así que vuelve a preguntarle a la IA y copia la respuesta para compartirla
- Antes de la IA, se le preguntaba directamente al desarrollador que escribió el código, no a su gerente, así que hay que eliminar al intermediario
- Todos los autores del código deben participar en la revisión, y hacer que un agente de IA separado reconstruya después las razones de una decisión para contestar preguntas de revisión es un enfoque completamente equivocado
La necesidad de un registro de decisiones
- Cuando se le pregunta a un humano "¿por qué?", en realidad se le está pidiendo el proceso interno de pensamiento que no está incluido en el PR
- El chain-of-thought de la IA es externamente auditable y el registro de interacciones con la IA también puede auditarse, así que ese contexto debe incorporarse a la revisión y al control de código fuente
- No es necesario hacer commit de todos los tokens generados durante la creación del PR; inspirándose en el concepto de episodes de Random Labs, basta con incluir la transcripción de las llamadas exitosas a herramientas y las conclusiones
- También puede escalar en entornos de agent swarm, enlazando los registros de decisiones antes de la etapa del PR y aplicando el formateo final
Los límites de los comentarios inline
- Los cambios en archivos fuente requieren volver a ejecutar el pipeline de build (linting, compilación, pruebas) incluso si solo se modifica un comentario
- Las transcripciones de decisiones son mucho más extensas que lo que normalmente permiten los comentarios inline
- Los comentarios existentes explican cómo funciona actualmente el código, no el proceso que llevó a esa decisión
Flujo de revisión integrado con IA
- Cuando el revisor deja un comentario, la IA del desarrollador debería poder recibirlo directamente y generar automáticamente parches y respuestas
- Esto ya puede implementarse hoy con la combinación de webhooks de GitHub/GitLab y un servidor MCP
- De forma similar a Devin AI o Claude Code via GitLab Duo
- Puede configurarse para que el desarrollador primero autorice a la IA, o para que la IA decida por sí sola y actúe de inmediato
- El desarrollador humano también puede seguir haciendo comentarios y modificaciones por su cuenta
- Esto puede reducir en gran medida el problema de que los comentarios de revisión se reflejen horas o días después, o ni siquiera se atiendan
Requisitos de herramientas para revisores
- El revisor también debería poder examinar el PR haciéndole preguntas directamente a una IA, igual que explora el codebase
- Para eso es clave que el registro de decisiones esté versionado junto con el código
- Manteniendo la interfaz actual de PR, debería integrarse al lado una ventana para conversar con Codex o Claude, como en un entorno de desarrollo IDE
- Aún no existe una herramienta pulida para esto, así que sería bueno que alguien la construyera
- En un diff, el revisor puede consultar en privado con una IA sobre librerías desconocidas, lenguajes poco familiares o mejores prácticas, y luego decidir si hace falta un comentario de revisión
- Si hace falta un comentario, eso es señal de que hay un vacío (gap) en el registro de decisiones, por lo que debe actualizarse el log antes de aprobar el PR
La importancia de los documentos de diseño y del contexto
- En una revisión integrada con IA, para el revisor también se vuelve mucho más fácil proponer parches directamente
- Los documentos de diseño, registros de decisiones (decision records) y diagramas de arquitectura deben añadirse al control de código fuente en formatos que un LLM pueda parsear, como Markdown o Mermaid
- "El contexto es rey (Context is king)"
10 comentarios
Parece que la razón por la que murió el PR no es tanto el PR en sí, sino la comunicación descuidada de los vibe coders.
¿Cómo se implementó en ese flow? ¿Qué otras alternativas había y por qué no se eligieron? ¿Por qué tiene que cambiar
package.lock? ¿No son todas cosas que deberían explicarse primero?Parece mejor que desaparezcan los coders que te obligan a preguntar, a pesar de que bastaría con escribirlo en la descripción del PR.
Coincido. Antes, un PR daba la sensación de que yo me hacía responsable del resultado que había creado,
pero el PR de un vibe coder se siente más como: "ni siquiera sé qué fue lo que hice, pero de todos modos aquí está el resultado, así que tú evalúalo y encuentra los problemas".
Estoy de acuerdo.
Primero se habla y luego todo termina yendo hacia una forma donde nadie se hace responsable.
Coincido. Es lo suficientemente irritante como para sacar de quicio.
Estoy de acuerdo.
En un PR cambian 500 archivos de una sola vez, pero quien lo envió se queja mucho porque no se lo revisaron en 30 minutos. En la descripción ponen cinco o seis líneas y ya, así que ¿se supone que solo debo confiar en esto y aprobarlo...?
¿Ya probaste todo?
Sí
Bueno, hagámoslo bien
¿Por qué dicen a cada rato que algo murió?
¡Así nos vamos a morir todos!
Como ya hay demasiados artículos con títulos de que algo murió apenas pasa cualquier cosa,
se siente bastante cansador.
Yo también creo que ya deberían dejar de matar cosas.
"Murió; larga vida"
Sí que se están volviendo demasiado comunes este tipo de textos. Pero sí reconozco que la IA lo está cambiando todo.