Revisiones de código en la era de los agentes de codificación
Los agentes de IA pueden generar código, pero la revisión humana sigue siendo esencial; la pregunta es cuánto y cómo.
Para la mayor parte de mi carrera, la revisión de código ha sido una práctica sencilla: un ingeniero escribe, abre un pull request y otro revisa antes de mergear. El segundo revisa bugs, decisiones de diseño y sugiere mejoras. En la actualidad, un agente de codificación puede implementar una característica completa, ejecutar pruebas, corregir fallos y preparar el PR. El ingeniero que abre el PR pasa la mayor parte del tiempo dirigiendo al agente en lugar de escribir código. ¿Todavía tiene sentido el proceso tradicional?
El propósito original de la revisión era añadir un segundo par de ojos. Se descubren defectos, se cuestionan abstracciones, se identifican casos extremos y se fomenta la propiedad compartida. Cuando el autor es un agente, esa lógica cambia. Un agente es como un colega rápido e inmaduro: produce mucho, pero carece de contexto del sistema y puede cometer errores obvios. Por eso, al abrir un PR, el ingeniero ya actúa como revisor: revisa, entiende y asume la responsabilidad.
¿Cuántas aprobaciones son suficientes?
En un flujo clásico: A escribe → B revisa → merge. En un flujo con agente: Agente escribe → A revisa → A abre PR → merge. Si A ha revisado y se siente cómodo con el cambio, ¿qué aporta una segunda aprobación humana genérica? El evento decisivo es la revisión de A, no el hecho de abrir el PR. Por eso la cantidad de botones de aprobación no siempre refleja la verificación real. Si el proceso exige una revisión humana, la política debe adaptarse al riesgo: migraciones de base de datos o cambios de autenticación merecen más revisión que un ajuste de UI.
Cultura de propiedad y confianza
Cuando un ingeniero revisa, abre PR y afirma "me lo asumo", debe tomarse en serio. La cultura debe pasar de “necesitamos aprobación” a “te confío, asume la responsabilidad”. La responsabilidad y la autoridad deben alinearse. No se trata de confiar ciegamente, sino de ajustar la verificación al nivel de riesgo.
El problema del volumen
Los agentes reducen el coste de generar código, lo que incrementa el volumen. Si un agente produce diez veces más código, simplemente añadir revisores humanos no es sostenible; la atención humana se convierte en el nuevo cuello de botella. Necesitamos ser más selectivos sobre dónde invertimos esa atención.
En resumen, la revisión de código sigue siendo necesaria, pero el enfoque debe evolucionar: la confianza en el ingeniero que revisa, la adaptación de las políticas a la criticidad del cambio y la priorización frente al aumento de volumen de código generado por agentes.
