- A medida que la cantidad y la escala del código generado por IA aumentan exponencialmente, el método tradicional de revisión manual de código ya no resulta válido
- Los equipos con alta adopción de IA aumentaron en 21% el trabajo completado y en 98% los PR fusionados, pero se produjo una paradoja: el tiempo de revisión de PR aumentó 91%
- En lugar de revisar el código directamente, el rol humano debe desplazarse hacia una validación más upstream: revisar las especificaciones y los criterios de aceptación (Acceptance Criteria)
- En vez de una sola compuerta de validación, se necesita una estructura de confianza en capas basada en el modelo del queso suizo: competencia entre múltiples agentes, guardrails deterministas, BDD, sistemas de permisos y validación adversarial
- El enfoque de "desplegar rápido, observarlo todo y revertir aún más rápido" sustituye el antiguo paradigma de revisión lenta seguida de depuración en producción
Los humanos ya no pueden sostener la revisión de código
- La realidad es que los PR quedan abandonados durante días, se aprueban de forma ritual y los reviewers apenas ojean un diff de 500 líneas
- La revisión de código suele considerarse una compuerta de calidad, pero existen equipos que han publicado software durante décadas sin revisión línea por línea, y la revisión de código solo se volvió masiva alrededor de 2012~2014
- Incluso con revisión siguen ocurriendo incidentes, y por eso se han construido sistemas como feature flags, despliegues graduales y rollback inmediato
Hay que renunciar a leer todo el código
- En los equipos con alta adopción de IA, tanto la cantidad de cambios como el tamaño de los cambios están creciendo exponencialmente al mismo tiempo
- Basado en datos de 1,255 equipos y más de 10,000 desarrolladores (análisis de Faros)
- Los desarrolladores perciben que revisar código generado por IA requiere más esfuerzo que revisar código escrito por colegas
- La revisión manual no puede ganar esta batalla, y la revisión de código es una compuerta de aprobación heredada que ya no encaja con la forma actual de trabajar
La revisión de código con IA sigue siendo solo 'revisión'
- Si la IA escribe código y otra IA lo revisa, no hay razón para mostrar una interfaz bonita de review
- Las herramientas de revisión de código con IA solo compran tiempo, y este tipo de revisión terminará moviéndose hacia la izquierda del ciclo de desarrollo (shift left)
- No tiene sentido desperdiciar recursos de CI ni gestionar versiones entre ciclos de revisión
- En un entorno donde los agentes escriben código, "ojos frescos" no son más que otro agente con los mismos puntos ciegos; el valor no está en la compuerta de aprobación sino en el bucle iterativo
- El instinto de pensar "vi una vez a la IA hacer una tontería, así que siempre hay que revisar" era razonable cuando la validación manual era posible, pero a esta escala ya no es ejecutable
Pasar de revisar código a revisar la intención (Intent)
- Hay que mover el checkpoint humano más upstream
- Ya existe un precedente de este tipo de cambio en desarrollo de software: de las firmas de aprobación en waterfall → integración continua (CI)
- El desarrollo guiado por especificaciones (spec-driven development) está emergiendo como forma principal de colaboración con IA
- Los humanos deben revisar especificaciones, planes, restricciones y criterios de aceptación, no un diff de 500 líneas
- En el nuevo paradigma, la especificación se convierte en la fuente de verdad (source of truth) y el código pasa a ser un producto derivado de ella
- Ya no se revisa el código, sino los pasos y las reglas de verificación (verification rules), el contrato que el código debe cumplir
- La aprobación human-in-the-loop cambia de "¿esto está correctamente escrito?" a "¿estamos resolviendo el problema correcto con las restricciones correctas?"
- El juicio humano más valioso se ejerce no después de generar el código, sino antes de que se genere la primera línea
Construir confianza en capas — modelo del queso suizo
- Los LLM no siguen bien las instrucciones, se desvían con frecuencia y ni siquiera son confiables al autoevaluarse (responden con seguridad que "funciona" mientras el código se está incendiando)
- La solución no es pedirle al LLM que valide, sino hacer que escriba scripts de validación — pasar del juicio al artefacto
- La confianza se construye por capas y, siguiendo el modelo del queso suizo, se superponen filtros imperfectos para que sus agujeros no se alineen
Capa 1: comparación entre múltiples opciones
- En lugar de pedirle a un solo agente la respuesta correcta, se puede hacer que tres agentes intenten resolverlo de formas distintas y elegir el mejor resultado
- La selección no tiene que ser manual: se puede rankear según el que pase más pasos de validación, el diff más pequeño o el que no agregue nuevas dependencias
- El costo de generar opciones está en su nivel más bajo de toda la historia de la ingeniería de software
Capa 2: guardrails deterministas
- Se necesitan métodos deterministas para validar el trabajo: tests, type checks, validación de contratos, es decir, mecanismos que traten hechos y no opiniones
- En vez de preguntarle al LLM "¿ya quedó?", hay que definir pasos de validación que produzcan una serie de artefactos de pass/fail
- Jerarquía de guardrails:
- Guías de codificación — pueden implementarse con linters personalizados
- Reglas invariantes de toda la organización — no negociables, como prohibir credenciales hardcodeadas, API keys o tokens
- Contratos de dominio — reglas por framework, servicio o área del codebase (por ejemplo, en el dominio de pagos todos los montos deben usar el tipo Money)
- Criterios de aceptación (Acceptance Criteria) — criterios únicos para cada tarea
- Los pasos de validación deben definirse antes de escribir el código; no deben crearse después solo para confirmar lo que ya existe
- Si el agente escribe tanto el código como los tests, solo se trasladó el problema; los criterios de validación deben surgir de la especificación, no de la implementación
Capa 3: los humanos definen los criterios de aceptación
- El lugar donde los humanos realmente agregan valor es upstream, definiendo qué significa tener éxito
- El BDD (Behavior-Driven Development) vuelve a cobrar relevancia
- Describe el comportamiento esperado en lenguaje natural y luego lo automatiza como tests
- Antes, como también había que escribir el código, redactar especificaciones se sentía como trabajo extra; en un entorno con agentes, la especificación es el artefacto primario
- Si el humano escribe la especificación, el agente implementa y el framework de BDD valida; mientras no falle, no hace falta leer la implementación
- Lo que los humanos hacen bien: definir la "corrección", codificar lógica de negocio y casos límite, y pensar en lo que podría salir mal
- Los criterios de aceptación escritos por humanos y verificados por máquinas son la compuerta que realmente importa
Capa 4: sistemas de permisos como arquitectura
- Debe ser una decisión arquitectónica qué puede tocar un agente y qué requiere escalamiento
- La mayoría de los frameworks de agentes tratan los permisos como all-or-nothing, pero la granularidad es clave
- Un agente que corrige un bug en una función utilitaria no necesita acceso a la configuración de infraestructura
- Un agente que escribe tests no necesita permiso para modificar el pipeline de CI
- El alcance debe ser lo más estrecho posible siempre que permita al agente hacer un trabajo útil
- Por ejemplo, si la tarea es "corregir un bug de parseo de fechas en
utils/dates.py", debería permitirse acceso solo a ese archivo y a sus archivos de test
- También importan los disparadores de escalamiento: modificar lógica de autenticación, cambiar el esquema de la base de datos o agregar una nueva dependencia deben activar automáticamente una revisión humana, independientemente del nivel de confianza del agente
Capa 5: validación adversarial
- Separación de responsabilidades: un agente realiza la tarea y otro agente la valida — la clave es que no confíen entre sí
- Es un patrón antiguo, como que QA no debería reportarle al gerente de ingeniería o que solo quien escribió el código no debería ser quien lo revise
- Puede imponerse a nivel arquitectónico: el agente que programa no sabe qué va a verificar el agente validador, y el agente validador no puede modificar el código — adversariales por diseño
- Incluso se puede ir más allá y usar un tercer agente para intentar romper lo que creó el primero, apuntando a casos límite y modos de fallo — automatizar red team/blue team para cada cambio
Está cambiando el significado de "buen código"
- Los incentivos de los sistemas de agentes son simples: completar la tarea dada y satisfacer a quien dio la instrucción; la exactitud a largo plazo o los requisitos de negocio no son una motivación intrínseca
- El papel humano es codificar eso dentro de las restricciones
- En un mundo donde los agentes generan el código y otros agentes lo leen, la forma del "buen código" será más estandarizada, y habrá menos necesidad de orientar cómo debe hacerse en un codebase nuevo
- La dirección futura es: "desplegar rápido, observarlo todo y revertir más rápido"
- Lo contrario: "revisar lento, igual dejar pasar bugs y depurar en producción"
- No se puede ganar leyendo más a las máquinas; hace falta pensar mejor que ellas upstream, donde las decisiones realmente importan
- Si los agentes pueden manejar bien el código, deja de importar si los humanos pueden leerlo o no
25 comentarios
Qué chistosa y novedosa la idea de que, como la revisión de código es un cuello de botella, mejor dejemos de hacer revisiones de código jajajajaja
Me pregunto si antes de la IA realmente les funcionaba bien a todos la revisión de código.
De por sí eran muy pocas las organizaciones que hacían revisión de código de forma rápida y con dedicación.
Incluso antes de la IA, para muchos desarrolladores la revisión de código ya era algo desatendido, atrasado y descuidado.
Por mi experiencia, las empresas tecnológicas de EE. UU. seguían las buenas prácticas, pero en otros países, incluido el nuestro, era un desastre.
Dicho al revés, cuanto más rigurosa era la revisión, mayor era el estrés laboral, y las revisiones desordenadas eran relativamente más relajadas
Creo que la desaparición de las revisiones es el resultado de cómo se recompensa el comportamiento.
Si lo que la empresa exige
es una baja tasa de errores, entonces va a exigir las revisiones con más fuerza;
si lo que quiere es lanzar funcionalidades rápido, entonces las revisiones se irán omitiendo poco a poco.
Que se hable de que las revisiones están desapareciendo me hace pensar que lo que las empresas prefieren es lanzar funcionalidades rápido.
Pero bueno, si yo fuera inversionista, creo que también pediría eso, jaja
No estoy muy seguro. Pensar que, porque la revisión se volvió un cuello de botella, entonces no habría que hacer revisión, me da la impresión de que es olvidarse de lo esencial. Más bien, creo que una mejor forma sería asignar obligatoriamente tiempo de revisión en la misma medida en que se redujo el tiempo de implementación.
Es una idea que vale la pena considerar, pero parece que todavía predomina la visión de que es demasiado pronto.
¿Seguimos apilando cajas negras?
La idea es tratar el código como una caja negra y mirar solo el resultado... pero no sé si de verdad esa sea una dirección deseable. Yo creo que en algún momento sin duda llegará el día en que haya que rehacer por completo todo el código escrito por IA existente.
Es una cuestión que puede pensarse de forma parecida a decir: "Como el FSD se volvió más inteligente, el conductor puede dormirse."
Técnicamente, sí parece que poco a poco llegará una era así, pero lo importante será cómo se va a superar la barrera de la responsabilidad.
Yo diría que la revisión de código no deja de ser un dispositivo mínimo de seguridad.
Entonces, ¿por qué una persona hace la validación de intención, que es un concepto de nivel más alto..?
De hecho, ni siquiera hace falta hacer que programen en un lenguaje de programación.
Si se le diera el mismo prompt a la IA, me hace pensar que revisar ese resultado sería algo parecido a poner a prueba el rendimiento del modelo, ¿no?
Parece que primero fijó la conclusión y luego le pidió al LLM que la escribiera. Un sofisma.
Parece que no tiene nada de experiencia en producción
La verdad, suena como un sueño.
Con el tiempo, hasta la documentación pierde sentido y más bien terminan haciendo revisiones estrictas, ¿no?
Claro~ con solo un texto pensado para generar este tipo de debate, la intención ya quedaba bastante clara.
Es una traducción: https://rosetta.page/post/…
Pero ese es un problema que desde el principio se puede filtrar en la etapa de planificación.
En el proceso de escribir código a mano, el desarrollador de forma natural también planifica, diseña, explora, comprende, prueba y hace una auto-revisión, y al mismo tiempo, de manera implícita y en paralelo, anticipa cómo responder después cuando surgen problemas, por lo que cada aspecto termina ajustándose de manera orgánica. Por eso creo que, incluso si faltaban pruebas o revisión, de alguna manera igual funcionaba hasta cierto punto.
Pero si eliminamos el proceso de escribirlo a mano, hay que trazar límites explícitos para esos procesos que antes existían de forma implícita. Como quien escribe el código y quien lo revisa quedan mucho más separados, aumenta la ineficiencia en la comunicación. Como también cae más la confianza en quien produce el código, el costo de revisión igualmente aumenta.
Creo que es algo parecido al concepto de
doorman's fallacy.Este también es un tema en el que yo pensaba seguido en la empresa, está muy bueno; personalmente debería intentar implementarlo también en el arnés que estoy creando.
Creo que poco a poco iremos moviéndonos hacia una dirección en la que las revisiones se simplifiquen cada vez más y las pruebas se vuelvan mucho más estrictas.
Parece que no se trata simplemente de eliminar las revisiones de código, sino de revisar entregables de un nivel más alto que permitan verificar explícitamente la intención y si esa intención funciona correctamente.
En este momento, creo que es deseable mantener como una caja negra los detalles de implementación del código, siempre que no estemos hablando del nivel de diseño o arquitectura.
Creo que esa caja negra podría seguir acumulándose hasta llegar al punto en que ni siquiera la IA pueda meter mano como corresponde. Siento que todos están demasiado embriagados por la comodidad. Creo que algún día va a ocurrir un accidente grande.
Yo también coincido con la opinión de arriba. ¿Qué pasaría si un día, de repente, se descubriera que el modelo aprendió mal alguna parte del código humano y nos diéramos cuenta de que eso se ha estado reflejando en el código todo este tiempo? Ese podría ser el día en que todo se ponga patas arriba..
Por más que el modelo más reciente sea increíble, si no puede sacar "siempre" una puntuación perfecta en el benchmark de SWE (6 nueves, 0.999999), creo que la posibilidad sigue estando abierta.
Revisión por intención. Qué buena expresión.
Estuve pensando cómo responder en esta era que avanza más rápido gracias a la IA,
¡y este es un muy buen artículo que ofrece una nueva perspectiva sobre la revisión de código!