Por qué la revisión de código con IA no puede ser una objeción válida

• La solución de que una persona revise todos los errores frecuentes de las herramientas de programación con LLM difícilmente puede garantizar al mismo tiempo calidad y productividad debido al límite de capacidad del code review
• Según estudios empíricos, una revisión efectiva tiene como tope alrededor de 1 hora y 400 LOC por vez; al superar eso, el cansancio y la pérdida de concentración reducen rápidamente la eficacia para detectar defectos
• Si se aplica este criterio, por cada 400 LOC escritos por un LLM se necesita 1 hora de revisión concentrada por parte de un desarrollador con experiencia, por lo que una capacidad diaria realista podría ser de menos de 1,000 LOC
• Hay evidencia inicial de que los humanos encuentran menos defectos en código generado por LLM y, aun así, muestran más confianza en su evaluación, por lo que es difícil sostener que la revisión por sí sola pueda filtrar suficientemente los errores
• Se necesitan estudios empíricos que midan y reproduzcan directamente la tasa de detección de defectos, la velocidad de revisión y el volumen diario sostenible del código LLM para evaluar la eficacia real de estas herramientas con base en evidencia y no en anécdotas

---

Por qué veo con escepticismo las herramientas de programación con LLM

• El foco del problema no está en la propiedad intelectual, el costo ecológico, el consumo de recursos ni en afirmar que todos los resultados de los LLM sean malos
• Con la evidencia científica actual, es difícil confirmar de qué manera las herramientas de programación con LLM ayudan a los desarrolladores a escribir código mejor o más rápido
• Las posturas a favor no abordan directamente los problemas ni la evidencia relacionada, y a veces sus respuestas al escepticismo incluso refuerzan el problema
• Aunque es un texto escrito hace alrededor de un año y usa la expresión Coding Assistants, hoy ya casi reemplazada, se mantiene porque no se encontró otro término que abarque todos los distintos usos de la IA generativa para programar

La metáfora del “intern” y la solución de revisar todo

• Las herramientas de programación con LLM tienen un riesgo de error relativamente alto por su forma de funcionar y por su interfaz de interacción, entre otras razones
  • Pueden alucinar o cometer errores tipográficos
  • Pueden dar resultados no relacionados con la solicitud o avanzar por una ruta distinta
• Los usuarios suelen comparar estas herramientas con un intern
  • Hay que asumir que el resultado tendrá cierto grado de error
  • Hay que considerarlo como alguien que trabaja sin entender bien lo que está haciendo
• Una respuesta muy común es que una persona con experiencia revise todo el resultado, como haría con el código de un intern o de un desarrollador junior
  • Se basa en la idea de que el humano sabe más y además tiene la responsabilidad final
  • También va acompañada de la lógica de que todo código que entra al codebase de todos modos debería pasar por revisión

El nivel de revisión necesario para supervisar un LLM

• En la industria y en la literatura académica, review abarca varias prácticas distintas
• Una revisión ligera y distribuida entre varias personas sirve para compartir conocimiento sobre los cambios y aplicar reglas superficiales, pero no basta como criterio para supervisar código generado por LLM
• No hace falta llegar al extremo de las revisiones tipo comité del pasado, donde se inspeccionaba dolorosamente cada línea durante horas, pero sí se necesita un code review bastante profundo y completo
• Como un LLM puede escribir código complejo y los defectos pueden esconderse en los detalles del software, una verificación superficial no es suficiente

Los límites empíricos que enfrenta el code review

• Los principales límites de una revisión efectiva confirmados por estudios empíricos son los siguientes
  • Una sola sesión de revisión se vuelve excesiva si supera 1 hora
  • La cantidad que puede revisarse eficazmente en ese tiempo es de alrededor de 400 LOC como máximo
• Una revisión de más de 1 hora pierde efectividad rápidamente sin importar el tamaño del código
  • No es solo porque ya se haya revisado la mayor parte
  • Mantener un alto nivel de concentración durante 1 hora produce cansancio y aburrimiento, por lo que se necesita descanso
• No se encontraron estudios que investiguen el tiempo de recuperación necesario entre sesiones de 1 hora
  • Como límite extremo, podrían suponerse varias al día
  • Como promedio posible, se proponen unas 2 al día, pero no es una cifra definitiva
• La cantidad de líneas de código que pueden revisarse por hora varía mucho según el contexto y el tipo de código, así como la experiencia y conocimiento de quien revisa
• No es una regla absoluta, pero en los datos empíricos casi no hay casos de revisiones más rápidas que 400 LOC/H que hayan detectado y marcado defectos de forma efectiva, así que puede verse como una velocidad máxima útil

Cálculo de capacidad aplicado al código LLM

• Si se quiere resolver mediante revisión los problemas del código LLM, incluso en el mejor de los casos se necesita 1 hora de un desarrollador experimentado por cada 400 LOC generados
• Un desarrollador podría disponer de unas 10 a 40 sesiones de revisión por semana, y entre cada sesión se requiere un tiempo de recuperación cuya duración no se conoce
  • Ese tiempo de recuperación podría ser de al menos 1 a 2 horas, pero no hay estudios directos que lo respalden
• Ese tiempo de concentración también debe usarse para reuniones, diseño, respuesta a incidentes y pensar en el código que uno mismo va a escribir
• En el mejor escenario, un desarrollador que use LLM podría escribir, revisar y hacer commit de varios miles de LOC por día
• En escenarios realistas, la capacidad diaria podría ser de menos de 1,000 LOC
  • Eso incluye boilerplate, pruebas, migraciones y archivos de configuración
  • Incluso un solo archivo de pruebas puede superar las 400 LOC
• Aun en las mejores condiciones, donde la mayor parte del código es simple y fácil de revisar, la revisión actúa como límite superior de la mejora de productividad

Diferencias entre revisar código humano y código LLM

• La evidencia existente proviene de situaciones donde revisores humanos encuentran defectos en código escrito por humanos, y no hay pruebas de que esa misma eficiencia se aplique al código LLM
• La evidencia inicial muestra una tendencia en la que quienes revisan código generado por LLM encuentran menos defectos, pero al mismo tiempo creen con más fuerza que los encontraron todos
• En comparación con la combinación de autor humano y revisor humano, la combinación de herramienta de programación con LLM y revisor humano puede producir resultados de menor calidad, mientras que este último podría evaluar su propio desempeño de forma más favorable
• La revisión total no solo limita la ventaja de productividad del LLM, sino que además falta evidencia sólida de que realmente resuelva sus errores frecuentes

Costos que aparecen antes de corregir defectos

• Este cálculo no incluye el costo de corregir los defectos encontrados
• Solo trata la capacidad y el costo de que un desarrollador profesional revise código en un entorno de trabajo y marque problemas
• Independientemente de cuántos defectos produzca el LLM o de su gravedad, el costo de revisar el código generado existe
• Incluso si una herramienta de programación con LLM produjera código de muy alta calidad, si se exige revisar todos los resultados seguirían existiendo el mismo costo y los mismos límites de productividad

La contradicción de delegar el código más difícil de revisar

• Quienes defienden los LLM presentan como ventaja que la herramienta pueda producir el código que a una persona le resultaría tedioso escribir
• Un caso propone que en adelante el 100% del código Bash necesario sea escrito por un LLM
• Los scripts de shell tienen parsing flexible y una semántica excesivamente superpuesta, por lo que un simple error de puntuación puede ser inofensivo o terminar borrando toda la computadora
• Ese tipo de código es fácil de romper, difícil de entender y revisar, y también difícil para detectar errores fatales
• Poner el código más difícil de revisar en manos de una herramienta que falla de forma aleatoria y luego decir que un humano lo verificará no demuestra primero que la salida del LLM sea realmente un objeto de revisión eficaz
• El problema es tomar como caso de uso representativo el código más difícil de revisar sin responder si la revisión resuelve los errores ni si sigue quedando una mejora suficiente de productividad

Tareas empíricas que deben validarse

• La primera tarea es medir qué tan bien los revisores humanos encuentran defectos en código generado por LLM
  • Capacidad de detección de defectos
  • Velocidad de revisión
  • Volumen de revisión sostenible durante un día
• Se necesitan datos sobre humanos revisando código LLM, igual que existen estudios sobre código escrito por humanos
• Como los experimentos y datos empíricos actuales son limitados en escala y contexto, hacen falta más estudios de replicación
• Los datos científicos actuales apuntan a que los humanos no revisan bien los resultados del LLM o tienen dificultades para detectar sus problemas
  • Esto podría coincidir con el hecho de que los LLM se entrenan para evitar la detección
  • También hay que verificar la posibilidad de que los resultados actuales hayan sido casuales
• La segunda tarea es confirmar si revisar artefactos generados por LLM es un problema cualitativamente distinto a revisar artefactos escritos por humanos
  • Si la diferencia fuera tan grande que la investigación actual sobre code review no aplicara, la crítica actual podría derrumbarse
  • Sin embargo, la evidencia inicial apunta a que revisar código generado por LLM podría ser más difícil, no más fácil, y en ese caso la crítica se reforzaría aún más

Evaluación empírica de herramientas profesionales, no anécdotas

• Si se toma en cuenta lo que se sabe sobre code review, es difícil ver qué beneficio aportan hoy a los desarrolladores profesionales las herramientas LLM con sus interfaces y procesos actuales
• Más que el hecho de que los proveedores sigan ofreciendo herramientas y procesos que chocan con la evidencia, la mayor molestia proviene de que traten a los escépticos como si fueran anormales sin abordar el problema
• En TDD, sistemas de tipos, separación entre pruebas y desarrollo, CI/CD y DevOps también se ha repetido un patrón donde las anécdotas predominan sobre la evidencia empírica
• En vez de apoyarse en casos de “esta vez me funcionó”, hace falta realizar investigación real siguiendo la forma en que se construyó la evidencia empírica sobre code review
• Si se quiere tratar las herramientas de programación con LLM como herramientas profesionales de desarrollo, hay que validar su efectividad y sus límites con base en ergonomía y evidencia empírica

[GN⁺]

Comentarios en Lobste.rs

• La velocidad no tiene por qué ser el único objetivo. Las correcciones de bugs pueden separarse en commits preparatorios independientes para revisarlas por separado, se pueden arreglar las estructuras de tipos que permiten representar estados inválidos y, si la confianza en las pruebas es insuficiente, se puede experimentar con pruebas basadas en propiedades, fuzzing y métodos formales.
  Antes, este tipo de trabajo se metía todo en un solo commit o quedaba como TODO de deuda técnica, pero ahora el costo marginal de hacerlo bien se volvió sorprendentemente bajo. Los LLM son herramientas abiertas, así que devuelven utilidad en la medida de los valores que el usuario prioriza.
  Claro que también existe el riesgo de que aumenten los prototipos que nunca se terminan ni llegan a producción, pero en general son de gran ayuda para una ingeniería que valora el rigor.

  • Aunque coincido mucho con esta evaluación, creo que lo que realmente pasa en la mayoría de las empresas es distinto. Aunque los LLM pueden aumentar el rigor, a menudo se usan en una carrera por el MVP de menor calidad.
    Puede ser un problema de cultura empresarial, pero es decepcionante, y espero que la industria reaccione y construya software de mayor calidad.

• Si se lanza un agente sobre proyectos antiguos con un solo prompt, sigue encontrando bugs reales sin mucho esfuerzo. Los humanos también somos descuidados y yo también cometo errores, pero los LLM son rápidos y, en varios sentidos, más torpes, por eso el problema aparece antes.
  Los errores se acumulan, así que si se deja que un agente cambie código sin control, todo se rompe rápido; pero también es una evaluación perezosa concluir que la herramienta en sí no sirve solo porque un uso ingenuo sea inestable.
  Ahora, con cada cambio, ejecuto automáticamente cinco revisiones expertas que incluyen arquitectura, mantenibilidad, confiabilidad y seguridad, y las organizo en un sistema de documentos de diseño para mejorar mucho la toma de decisiones del agente. No es perfecto, pero es mejor que el enfoque ingenuo, y que todavía haya margen para mejorarlo también es parte de lo divertido de trabajar con herramientas nuevas.

  • Aquí solo se habló de generación y revisión de código, no del uso de análisis probabilístico de texto para encontrar patrones de bugs.

• Aunque se genere más rápido con prompts, luego toma más tiempo verificarlo y entenderlo, y uno termina preguntándose si habría sido más rápido escribirlo directamente desde el principio. Decidir cuál opción es mejor también consume tiempo y energía, y preferiría usar esos recursos en otra cosa.
  Dicho eso, si quien envía el PR asume la propiedad y la responsabilidad, no importa si usó un LLM o no. Si cumple los criterios de calidad, exactitud y consistencia, que elija el método más rápido; la responsabilidad sigue siendo del autor humano.
  Personalmente, la IA me parece buena para aprender y ampliar y profundizar la comprensión, pero si considero no solo el tiempo de entrada sino todo el proceso, por ahora sigo siendo más productivo escribiendo el código yo mismo.

• El problema empieza por el hecho de que el texto fue escrito hace casi un año. En los últimos seis meses, y especialmente en los últimos tres, la utilidad de los modelos cloud pagos de última generación aumentó mucho.
  Hay que verificar si existen controles que bloqueen categorías completas de fallas, como los principios MFIC desarrollados en trabajos de auditoría: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
  También hacen falta herramientas como https://github.com/pmarreck/dirtree y https://github.com/pmarreck/codescan, que mantienen el código existente y la estructura del proyecto en el contexto; esto también es útil para desarrolladores humanos que olvidaron una base de código o no están familiarizados con ella.
  Al final, uno puede aprovechar bien esto y obtener ventajas, o escribir código a medida manualmente mientras también crea bugs y vulnerabilidades de seguridad, y ser superado por competidores más rápidos. Como alguien que pasó 2 años-persona en una base de código Ruby on Rails abandonada de un millón de líneas de Desk.com, creo que el código empresarial es temporal, así que encaja bien con código generado por LLM.
  Si se tratara de la implementación interna de Erlang, sería difícil confiar, pero se le puede pedir que escriba a nivel de función y luego revisarlo; a veces será mejor de lo esperado. Lo ideal no es elegir solo entre agujas de tejer y un telar, sino usar ambos según la situación.

  • No hablo de implementaciones internas; yo también trabajo con código empresarial y soy la persona que limpia el código dejado por usuarios de LLM. Lo que acabas de decir no refuta ninguna frase del texto original; más bien la respalda.
  • Eso de que mejoró mucho en los últimos seis o tres meses se viene repitiendo desde hace al menos dos años.

• Por mi experiencia personal y la de desarrolladores senior confiables a mi alrededor, los LLM han permitido programar mejor y más rápido de forma repetida, así que me cuesta tomar en serio un texto que afirma que, según la evidencia científica, no pueden ayudar.
  Aunque no haya papers revisados por pares, ya vi suficiente, y no voy a cambiar mi juicio previo solo porque un estudio de METR contradiga las estimaciones de mejora de productividad de los desarrolladores.

  • Para alguien que se llama investigador, decir que la experiencia personal basta es un estándar de evidencia sorprendentemente bajo.
  • La experiencia personal también fue usada por médicos que se negaban a lavarse las manos o defendían las sangrías. La ciencia se construyó sobre la historia de matar personas por confiar en esas experiencias.
    Estoy dispuesto a cambiar de opinión si se muestra, con rigor y una metodología válida, en qué difiere esto de la investigación empírica sólida existente. Pero la experiencia personal o una docena de anécdotas sin explicación no alcanzan.
    La ciencia y la ingeniería mejoraron la vida de miles de millones de personas, y no podemos descartarlas solo porque alguien crea que le va mejor.
  • Si alguien pidió evidencia para convencer a otros y la respuesta es que uno ya está convencido y no necesita más, entonces no se respondió la pregunta.
    No quiero llamar sectario a nadie en particular, pero tomar como algo personal un desafío a una creencia y, al mismo tiempo, no saber cómo convencer a otros se parece a la forma de comunicación de los grupos sectarios.
  • Sigo teniendo reservas sobre los LLM para generación de código, pero no importa si quien escribe un PR es humano o máquina: deben aplicarse los mismos estándares de calidad.
    Aunque un PR esté hecho mayormente con LLM, quien lo envía debe hacerse responsable y dividirlo en un contexto y tamaño que otras personas puedan entender. El código sigue siendo la especificación final del software, y no cambia el hecho de que el desarrollador debe poseerlo y entenderlo.

• Es cierto que hace un año los agentes de IA cometían muchos errores, pero no está claro si eso sigue siendo así, y alrededor de noviembre del año pasado sentí un punto de inflexión en los modelos de frontera.
  Es verdad que los LLM aumentan la cantidad de código y ejercen nueva presión sobre la capacidad de revisión, pero los ingenieros deben ponerle freno y asegurar que el volumen de revisión se ajuste a la capacidad real de procesamiento.

  • Siguen cometiendo errores arquitectónicos importantes. Por ejemplo, no detectan situaciones en las que se puede extraer y reutilizar un comportamiento compartido, y agregan código nuevo.
    Lo peor es que el código nuevo generalmente funciona, así que es muy probable que se fusione sin limpieza.

• Me resulta extraño que, aunque los modelos de frontera escriben una cantidad enorme de código, no se explore seriamente la contribución negativa de proponer eliminar código. Si pudieran desentrañar y reducir la complejidad de bases de código infladas por capas de abstracción, y proponer borrado de líneas, como en “The Best Code is No Code At All” - Jeff Atwood, sería algo novedoso.
  Quizás ya sea posible, pero todavía no lo vi directamente.

• Para corregir: la sección “The Limits Of Reviews” plantea como velocidad máxima eficiente 400 líneas por hora, no 400 líneas por revisión como pensé al principio.
  Aun así, sigo teniendo curiosidad por saber exactamente de qué paper sobre revisión de código salieron las cifras de 1 hora y 400 líneas. Si no guardaste el nombre del paper, no hace falta gastar mucho tiempo en volver a buscarlo.

  • Tengo materiales relacionados guardados en algún lado, así que puedo revisarlo. La mayoría propone un límite de 100 a 200 líneas por hora, pero muchos son estudios antiguos, de una época en la que los lenguajes de programación eran más propensos a bugs que ahora.
    Estoy de viaje, así que recuérdamelo en unos días.
  • Como 400 líneas por hora me parecía sospechoso, hice el cálculo con mis registros de trabajo. En los últimos seis meses revisé 173 PR equivalentes a 139 mil líneas modificadas.
    Si la revisión ocupa el 25% de una semana de 40 horas, serían unas 540 líneas por hora; si ocupa el 15%, 900 líneas; si ocupa el 5%, 2700 líneas. Estimo que el rendimiento real está en torno a 500 a 1000 líneas por hora, lo que se acerca bastante a la cifra sin fuente indicada.

• Me cuesta entender la lógica de que el código generado por IA deba revisarse más o menos que el código escrito por humanos. Como el criterio de aprobación es el mismo, se revisa al mismo nivel.