- La cuestión de si es válido que el código escrito por IA sea revisado por IA es una pregunta interesante
- Bots como Devin AI ya son quienes más PRs escriben, y también están aumentando los casos en los que la revisión la realiza IA
- También existe el argumento de que los LLM no tienen estado (
stateless) y que, como su estructura interna difiere al revisar y al escribir, es posible separar los roles
- El código generado por IA provoca tipos de bugs distintos a los de las personas, y la IA es más efectiva para encontrar esos bugs
- En conclusión, la revisión con IA tiene ventaja para detectar errores reales frente a la revisión humana, aunque el criterio arquitectónico y las guías de estilo humanas siguen siendo importantes
¿Puede la IA revisar su propio código?
- La mayoría de las empresas mantienen el principio de autor ≠ revisor
- Sin embargo, la IA basada en LLM no tiene estado y evalúa cada solicitud desde cero
- Es decir, incluso usando el mismo motor, es posible ver la escritura y la revisión como “autos” distintos
Scaffolding: la estructura de la revisión con IA
- La IA para revisión sigue un flujo de trabajo específico como el siguiente:
- análisis del diff de código
- detección de bugs
- redacción de comentarios y evaluación de severidad
- referencia a documentación del codebase y archivos relacionados
- En cambio, la IA de generación de código opera en un contexto completamente distinto, por lo que revisar y generar son funciones diferentes
Los humanos también son, en el fondo, “el mismo motor”
- Aunque el autor del PR y el revisor sean distintos, ambos provienen de la misma inteligencia humana
- Comparten conocimientos y experiencias similares dentro de la misma empresa y con una formación parecida
- Al final, tanto la IA como los humanos se parecen en esto de ser “el mismo motor, casos distintos”
El código con IA necesita una revisión más precisa
-
La calidad del código con IA es un poco menor
- La IA es rápida, pero por las limitaciones del prompt, la transmisión de requisitos puede ser imprecisa
- Incluso los buenos desarrolladores no revisan el código generado por IA con el mismo cuidado que el suyo propio
- Como resultado, la calidad general tiende a nivelarse hacia abajo y converge en un nivel intermedio
-
Los bugs de IA son difíciles de encontrar para las personas
- Los bugs que crea la IA son del tipo que los humanos normalmente no generan
- Ej.: cambios inesperados de líneas, errores sutiles en condicionales, etc.
- Según pruebas internas de Greptile:
- IA (Sonnet) encontró 32 de 209 bugs “Hard”
- Desarrolladores humanos encontraron en promedio solo 5 a 7
Conclusión
- Que la IA revise su propio código es técnicamente posible y tiene sentido
- La IA supera a los humanos en la detección de bugs y resulta realmente útil en revisión
- Sin embargo, la interpretación de intenciones, el criterio de diseño y el juicio sobre el estilo del código siguen siendo importantes en manos humanas
- El criterio tradicional de autor ≠ revisor necesita reinterpretarse en el caso de la IA
3 comentarios
Me pregunto qué tal sería ir cambiando de modelo LLM mientras se hace la revisión. Por ejemplo, revisar con los modelos B, C o D el código escrito con el modelo A.
Ah, en nuestra empresa lo hacemos así: cuando hacemos un PR del código escrito con Cursor (Claude), lo revisamos con ChatGPT. Y les decimos: ahora sí, péleense entre ustedes. Desde
o4-mini, la gente hasta se queda impresionada. También se puede hacer directo desde Cursor cambiando el modelo al hacer la solicitud.Opiniones de Hacker News
Quiero enfatizar esta parte: los ingenieros no revisan con el mismo nivel de detalle el código generado por IA que el código que escriben ellos mismos. La razón es que los LLM generan código mucho más rápido de lo que uno puede teclear. Entonces, cuando escribes el código tú mismo, lo revisas de forma natural, pero cuando lo genera la IA, ese proceso se omite. Curiosamente, para un ingeniero promedio, la IA incluso puede mejorar la calidad del código. Cuanto más se use la IA, más se irá pareciendo el nivel de código que producen los buenos y los malos ingenieros. Siempre es interesante cómo cambia la forma de pensar en cada etapa: revisión de código, diseño y escritura
Cada persona interactúa de forma distinta, así que hay métodos que le acomodan mejor a cada quien. A mí me resulta más fácil revisar código que escribirlo. Cuando escribo, tengo que pensar en mucho contexto además del codebase, pero al revisar puedo concentrar ese contexto solo en el codebase y hacer pattern matching más rápido. Por desgracia, como el nivel del LLM es como el de un ingeniero junior, revisar sus PR requiere más esfuerzo y energía
Muchas veces un buen ingeniero no necesariamente es un buen programador
Si usas bots y prompts distintos para revisar código con IA y para escribirlo, puedes encontrar muchos más errores. Incluso repitiendo varias veces con la misma herramienta a veces aparecen problemas nuevos. Ni los humanos ni la IA logran hacer código perfecto de una sola vez. Las herramientas de IA han mejorado hasta el punto de probar su propio código y hacer una prerevisión, pero sigo creyendo que nunca está de más que tanto humanos como IA revisen el código del PR. Incluso con una herramienta que hice yo mismo, llamada Kamara, a menudo encontré problemas en código que había escrito yo. También hubo problemas como en el ejemplo de greptile, donde sugería ubicaciones de código completamente equivocadas, pero poco a poco lo estamos controlando. Todavía no existe una herramienta 100% perfecta y siento que aún falta un poco para que la IA lo takeover todo
Cuando empezamos OpenHands (antes llamado OpenDevin), los PR creados por IA aparecían con el nombre de una cuenta de IA. Eso causó dos problemas graves: 1) la persona que invocó la IA podía hacer merge sin revisar el código, así que podía desplegarse código no verificado, 2) no había un responsable claro del PR, así que si no se hacía merge o surgía un problema, no estaba claro a quién pedirle cuentas. Por eso cambiamos la estrategia para que todos los PR tuvieran a una persona como owner, y solo los commits quedaran con el nombre de la IA. El PR en sí es totalmente responsabilidad humana
Me pareció interesante la parte de que los LLM detectan bien bugs. Me pregunto cuántos falsos positivos hubo para lograr una tasa real alta de detección de bugs. En mi experiencia, los LLM muchas veces dicen que hay bugs aunque no los haya
Totalmente de acuerdo. Cuando le pregunto algo a ChatGPT y no me convence su sugerencia, si le digo “¿seguro de esa parte?”, cambia la respuesta de inmediato. En realidad, la primera respuesta podría haber sido correcta, pero si el usuario no muestra seguridad, se tambalea fácilmente. Por eso no es nada fácil validar bien estas herramientas
En este caso, cada archivo tenía exactamente un solo bug y al bot se le pidió encontrar exactamente uno. Todos fueron casos de falsos positivos: inventó bugs en lugares donde no había ningún problema
La diferencia entre varias herramientas de revisión de código con IA que hay en el mercado está justo en cómo ajustan la relación señal/ruido. Algunas herramientas son mucho más precisas y tienen menos falsos positivos
Como programador, la responsabilidad más importante es producir código que funcione bien y en el que uno tenga confianza. No importa si usaste un LLM. Lo importante es subir un PR con la actitud de “estoy seguro de que este cambio resuelve el problema y puedo poner mi reputación en juego”. Por eso, ya sea una persona o una IA, un PR siempre necesita un segundo revisor
Creo que la reputación es la clave. No aplica solo al código; también pasa con los textos en lenguaje natural. Estamos entrando en una época en la que no el autor, sino quien publica, es decir, el editor o publicador, debe hacerse responsable del contenido. Da igual si fue 5% chatbot o 95% chatbot: si hay un problema, deben criticarme a mí, que fui quien publicó el texto. La excusa de “lo hizo el chatbot” no sirve
Solo se estaba hablando como ejemplo de un ingeniero totalmente automatizado como Devin; es una situación un poco distinta de la de un ingeniero común
Últimamente muchos ingenieros están aventando sin responsabilidad código chafa hecho por IA, esperando que otros compañeros detecten los problemas. Antes eso pasaba menos porque generar el código en sí ya requería esfuerzo
Me identifico mucho con la idea de que tu responsabilidad es producir código confiable. Pero incluso antes de la IA, el buen código ya no se cuidaba tanto. Terminamos viendo la programación solo como una herramienta o como una forma de ganar dinero. Antes existía el placer de “resolver problemas y cambiar el mundo”. Pero ahora nos enfocamos más en “ganar dinero rápido o levantar barreras”. Lo importante no es si el código es bonito, sino si resolvió el problema con elegancia. La IA puede empeorar esta cultura, pero al final todo depende de cómo se use
Tengo curiosidad: si un PR resuelve todos los problemas y solo trae bugs menores, ¿hay algún ejemplo en el que ese PR sí se consideraría una pérdida de tiempo?
La revisión de código es la etapa más lenta en ingeniería. Yo también puedo escribir código rápido sin IA, pero la revisión no se acelera. Por eso hago una revisión previa con IA antes del review, para ahorrar tiempo a mis colegas, atrapar bugs desde antes y reducir incluso varios días el tiempo hasta el despliegue. La IA ha detectado bugs obvios y errores ocultos, e incluso me ha llegado a encontrar bugs realmente profundos. Uso un workflow en el que copio el diff con git cli y xclip, y lo pego en un modelo de lógica como o3 para que lo revise
Una de las ventajas de la IA es que puede escribir muchísimas pruebas unitarias mucho más rápido que una persona. Y también puede corregir por sí sola los problemas que detecta. El workflow ideal no sería solo revisión de código, sino que la IA también ejecute pruebas automáticamente por su cuenta y verifique que todo cumpla cierta especificación. Demasiadas pruebas pueden dificultar el refactor más adelante (por ejemplo, pruebas que dependen de detalles de implementación), y si da flojera, siempre puedes tirar aparte las pruebas que escribió la IA
Me encanta poder regenerar pruebas unitarias cada vez que las necesito. Me da mucha satisfacción ver el tamaño del diff al subir una revisión, y me ahorro el tiempo aburrido de escribir pruebas para poder hacer más cosas
Incluso hoy la programación sigue teniendo tareas tediosas, pero idealmente la IA debería reducir esas ineficiencias y permitir que los humanos se enfoquen en lo creativo. Sin embargo, en la práctica la IA está empezando a meterse cada vez más en trabajos creativos de alto nivel
En realidad, incluso sin IA, también se pueden generar pruebas automáticas con muchísimos valores de entrada usando frameworks de property-based testing
Tengo una regla al revisar código: si no me siento capaz de mantenerlo yo mismo después, no lo apruebo. Si usaras LLM tanto para escribir como para revisar código, podría decirse que aplicas el mismo principio de responsabilidad a la herramienta. Pero, sinceramente, no me veo aguantando mucho tiempo en una situación así
Me pregunto si alguien ha probado un pipeline donde un LLM genera scripts Gherkin a partir de requisitos, luego otro LLM genera código a partir de esos scripts, y después Cucumber valida el resultado. De todos modos habría que revisar tanto los scripts Gherkin como el código, pero me gustaría saber qué tipos de código no podrían construirse de esta forma. Estoy viendo a la IA como si fuera un desarrollador más, y supongo que, igual que un desarrollador humano, debe haber áreas en las que claramente no se le da bien
Al final, el autor que sube el PR debe hacerse responsable del impacto y las consecuencias de su propio código. Con la popularización de la programación con IA y el aumento de ingenieros junior, esta responsabilidad se volvió todavía más importante. Tiene sentido que la IA haga una primera pasada de revisión, pero hace falta que un revisor humano aporte una perspectiva externa, entienda mejor el codebase y detecte problemas de más alto nivel. En conclusión, lo ideal es que la IA haga la primera revisión, otro ingeniero revise el código desde el contexto o la colaboración, y que al final el autor asuma la responsabilidad por todos los resultados