Doce formas de equivocarse sobre la programación asistida por IA

 (third-bit.com)
5 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El valor de la programación asistida por IA es difícil de reducir a cifras simples como líneas de código, número de tickets o satisfacción, y la conclusión puede distorsionarse según cómo se evalúe
  • Las líneas de código y la cantidad de commits, Pull Requests o tickets solo miden actividad; en cuanto se vuelven un objetivo, se manipulan con facilidad y no distinguen la calidad
  • La tasa de aceptación y la tasa de adopción solo señalan que las sugerencias parecían plausibles o que la herramienta fue desplegada, pero no garantizan exactitud, seguridad ni mantenibilidad
  • Las tareas de juguete, las comparaciones antes/después sin grupo de control, la comparación entre usuarios voluntarios y las líneas base débiles dificultan separar el efecto del LLM del sesgo de selección
  • Para juzgar la productividad se necesitan métricas a nivel sistema que incluyan revisión, depuración, seguridad, deuda técnica, cuellos de botella del equipo y cambios de largo plazo

Qué se evalúa y bajo qué supuestos

  • Al intentar demostrar el valor frente al costo de suscripción de las herramientas de programación asistida por IA, las líneas de código generadas, los tickets completados y las encuestas de satisfacción de desarrolladores pueden llevar a conclusiones equivocadas de maneras distintas
  • El punto central no es el valor en sí de la programación asistida por LLM, sino lo fácil que es equivocarse al evaluar su efecto
  • La misma crítica también puede aplicarse, con pocos cambios, a afirmaciones sobre desarrollo ágil, desarrollo guiado por pruebas y otras prácticas de desarrollo de software
  • Esto lleva a la conclusión de que, si la ingeniería de software hubiera adoptado de verdad los métodos de investigación de las ciencias humanas, estaría mucho más adelantada en el estudio de estos fenómenos

Métricas de productividad equivocadas

  • Contar líneas de código generadas

    • Las líneas de código se han usado desde hace mucho como una métrica sustituta de la productividad, que es difícil de medir directamente
    • Los LLM pueden producir más código, pero eso no garantiza mejores resultados
    • Un equipo en el que las líneas de código por desarrollador aumentaron 40% tras adoptar un LLM quizá no midió productividad, sino verbosidad
    • Reemplazar 2000 líneas de lógica enredada por 200 líneas limpias parece una pérdida bajo una métrica de líneas de código
    • Más código aumenta lo que hay que leer, mantener y depurar, y la carga futura que deja la IA no aparece en el conteo de líneas

  • Contar commits, Pull Requests y tickets

    • En 2023, McKinsey propuso medir la productividad individual de desarrolladores por la cantidad de actividades como commits, Pull Requests y revisiones de código
    • Como dice la ley de Goodhart, cuando una medida se vuelve un objetivo, deja de funcionar como una buena medida
    • Si se rastrea la cantidad de commits, los desarrolladores harán commits más pequeños y más numerosos; si se rastrea la cantidad de tickets, los tickets se fragmentarán
    • Los números pueden verse mejor sin que el trabajo de fondo mejore
    • La actividad no es resultado, y el resultado tampoco se convierte automáticamente en valor

  • Tomar la tasa de aceptación de sugerencias como señal de calidad

    • La alta tasa de aceptación de sugerencias de los asistentes de programación con LLM suele presentarse como evidencia de que la herramienta es útil
    • La tasa de aceptación solo mide si el código generado parecía lo bastante plausible como para que el desarrollador presionara Tab, no si era correcto, seguro o mantenible
    • Los desarrolladores bajo presión de tiempo aceptan más sugerencias, incluidas sugerencias inseguras
    • Un estudio corporativo con 400 desarrolladores encontró una tasa de aceptación promedio de 33% y alta satisfacción, pero no siguió la exactitud ni la seguridad del código aceptado
    • Una métrica que recompensa lo que parece convincente no es una métrica que recompense lo que realmente es bueno

  • Tomar la tasa de adopción como métrica de éxito

    • Decir “alcanzamos una tasa de adopción de herramientas de IA de 90% en toda la organización de ingeniería” describe un logro de compra y despliegue, no de productividad
    • La tasa de adopción solo mide si la herramienta fue instalada y abierta; no dice si las sugerencias son útiles, si el desarrollador las acepta sin criterio o si lo aceptado es correcto
    • Si una alta adopción se combina con baja calidad de sugerencias, los desarrolladores pueden terminar gastando tiempo en gestionar la herramienta en vez de obtener beneficios
    • En un estudio de IBM sobre asistentes corporativos de programación con IA, la herramienta a menudo generó aumentos netos de productividad, pero esos beneficios no fueron uniformes entre todos los usuarios
    • La adopción es más fácil de medir que el beneficio, y precisamente por eso es más fácil de reportar

Errores de diseño experimental

  • Cronometrar tareas artificiales

    • El estudio ampliamente citado sobre GitHub Copilot encontró que los usuarios completaron una tarea 55% más rápido que quienes no lo usaban
    • La tarea consistía en implementar desde cero un servidor HTTP en JavaScript, con un límite de 90 minutos y sin otras obligaciones ese día para los desarrolladores
    • El desarrollo de software real incluye explorar grandes bases de código que uno no escribió, entender requisitos ambiguos de tickets, coordinarse con colegas y asistir a reuniones
    • La velocidad en tareas de juguete greenfield no predice la velocidad en ese trabajo real
    • En un ensayo controlado aleatorizado con desarrolladores expertos de open source, dar acceso a herramientas de IA aumentó 19% el tiempo de finalización de tareas, contra lo que esperaban los participantes

  • Comparaciones antes/después sin grupo de control

    • Si un equipo empezó a usar LLM en enero y en junio desplegaba Pull Requests más rápido, puede parecer que la herramienta causó el efecto
    • Pero si en ese mismo periodo contrató 12 ingenieros, refactorizó el pipeline de CI y cambió de proveedor cloud, no se puede aislar la causa
    • Sin un grupo que no haya adoptado la herramienta, es difícil distinguir el efecto del LLM de otros cambios que ocurrieron al mismo tiempo
    • La validez interna requiere un contrafactual confiable que permita saber qué habría pasado sin la herramienta

  • Comparar quienes sí la usan con quienes no

    • Si se comparan desarrolladores que eligieron usar LLM con quienes eligieron no hacerlo, no se están comparando dos condiciones, sino dos grupos distintos
    • Quienes adoptan temprano tienen más probabilidad que los adoptantes tardíos o los no adoptantes de estar más dispuestos a experimentar, familiarizados con herramientas nuevas y de ya tener alto desempeño
    • Por el sesgo de selección, la diferencia observada puede reflejar características de las personas y no de la herramienta
    • Como este método es el más barato de ejecutar, se ha vuelto un defecto de diseño común en reportes industriales sobre productividad con IA
    • Un estudio longitudinal de dos años sobre el uso de Copilot en una gran organización tecnológica mostró que los usuarios ya eran consistentemente más activos que los no usuarios antes de adoptar la herramienta

  • Comparar IA contra ‘nada’

    • Comparar desarrolladores asistidos por IA contra un grupo de control que no usa ninguna herramienta elige una línea base que no existe en el trabajo real
    • Incluso sin un asistente LLM, los desarrolladores usan documentación, colegas y tiempo para pensar por sí mismos
    • La pregunta importante es si la herramienta LLM es mejor que las alternativas que el desarrollador ya tiene, y esa comparación rara vez se hace
    • Si se elige una línea base débil, cualquier herramienta se ve bien, pero eso no significa que sea realmente útil

Lo que queda fuera de la medición

  • Medir solo la mitad fácil

    • Los LLM pueden acelerar la generación de código, y esa parte es fácil de medir
    • La mitad más difícil es el tiempo de revisión del código generado por LLM, el tiempo perdido depurando sugerencias equivocadas pero confiadas, las vulnerabilidades de seguridad creadas por código plausible pero inseguro y la deuda técnica creada por soluciones improvisadas que ignoran el diseño circundante
    • Estudios sobre código de GitHub Copilot encontraron vulnerabilidades de seguridad en una parte importante del código generado, y que los desarrolladores bajo presión de tiempo aceptaban sugerencias inseguras con mayor frecuencia
    • En una evaluación de 2025 de cinco LLM principales, ningún modelo logró producir código de aplicaciones web que cumpliera con estándares industriales de seguridad
    • Un análisis a gran escala de más de 300 mil commits escritos por IA encontró que más de 15% introdujo al menos un problema de calidad y casi una cuarta parte de ellos permaneció a largo plazo en la base de código
    • Si solo se mide el aumento en entradas y se ignoran los costos que crecen al mismo tiempo, eso no es medición sino marketing

  • Hay que medir el sistema, no solo al individuo

    • La velocidad individual de codificación se mide con frecuencia porque es lo más fácil de medir
    • Aunque una herramienta de IA haga que un desarrollador escriba código 30% más rápido, si el lead time del equipo desde ticket hasta producción no cambia, entonces el cuello de botella no estaba en escribir código
    • Si aumenta el código generado, también aumenta el código que hay que revisar, y si la IA solo aumenta el volumen de código sin aumentar la capacidad de revisión, el cycle time puede empeorar
    • En estudios empíricos con desarrolladores profesionales, las herramientas de IA aumentaron la producción de contribuyentes menos experimentados, pero los desarrolladores senior vieron caer su productividad 19% porque la carga de revisión por código generado por IA aumentó 6.5%
    • Optimizar una sola etapa del pipeline e ignorar el resto es un fracaso del pensamiento sistémico que se hace pasar por investigación de productividad

Distorsiones por efecto del tiempo

  • Preguntar a los desarrolladores si sienten que aumentó su productividad

    • Resultados de encuestas como “87% de los desarrolladores siente que es más productivo con herramientas de IA” se citan con frecuencia como evidencia de que la herramienta funciona
    • El autorreporte puede generar malentendidos sistemáticos por tres razones
    • Por el efecto Hawthorne, la gente trabaja distinto cuando sabe que está siendo observada o evaluada
    • Las herramientas nuevas generan un efecto novedad por ser nuevas y por eso parecen más rápidas, pero esa sensación suele desaparecer en pocas semanas
    • Por el sesgo de deseabilidad social, los encuestados tienden a responder lo que creen que la encuesta quiere oír, sobre todo si la dirección eligió la herramienta

  • Medir solo durante el periodo de novedad

    • Si un estudio de 4 semanas encontró una mejora de productividad, entonces solo encontró una mejora de productividad de 4 semanas
    • Como los desarrolladores se involucran más con una herramienta nueva al principio, el desempeño observado puede estar inflado frente a la línea base de largo plazo
    • Los efectos realmente importantes aparecen a lo largo de meses, no de semanas
    • La degradación de habilidades en tareas delegadas a la IA, la deuda técnica que se acumula por sugerencias erróneas y los cambios en la colaboración del equipo requieren observación de largo plazo
    • Los estudios diseñados para detectar beneficios de corto plazo no dicen qué pasa después de que termina el estudio
    • Un análisis de 807 repositorios open source que adoptaron Cursor encontró que la velocidad de desarrollo aumentó de forma marcada pero temporal tras la adopción, mientras que la complejidad del código y las advertencias de análisis estático aumentaron de forma importante y sostenida

Conclusión para una mejor interpretación

  • La medición de productividad es difícil de reducir a una sola cifra o a métricas sustitutas fáciles
  • Para juzgar el efecto de la programación asistida por LLM hay que mirar no solo la velocidad de escritura de código, sino también revisión, depuración, seguridad, mantenibilidad, deuda técnica, cuellos de botella del equipo y cambios de largo plazo
  • Sin grupo de control, líneas base realistas, control del sesgo de selección, observación de largo plazo y métricas a nivel sistema, es difícil distinguir el efecto de las herramientas de IA del efecto de otros cambios
  • Los valores fáciles de medir son fáciles de reportar, pero no sustituyen a los valores importantes
  • Para evaluar prácticas de desarrollo de software, hace falta tomarse mucho más en serio los métodos de investigación de las ciencias humanas

Principales fuentes citadas

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Opiniones de Lobste.rs

  • El autor es uno de los fundadores de Software Carpentry, así que es alguien que lleva pensando en mejores formas de medir la productividad de software desde mucho antes de que aparecieran los LLM.
    El estudio de METR citado es más interesante de lo que suele sugerir la razón más común. Para mucha gente, el titular fue “la IA volvió a las personas más lentas”, y eso puede rebatirse diciendo que los LLM estilo 2025 todavía están mejorando.
    Pero el resultado más interesante es que, al mirar después, las estimaciones que ellos mismos hicieron ni siquiera coincidían con la dirección de lo que realmente pasó. Parece que aquí hay un factor que la mayoría de las empresas ignora y que crea una dificultad fundamental para cualquier medición.
    Ni siquiera se puede confiar en la sensación vaga de que una herramienta vuelve a la gente más productiva. La gente no lo sabe por sí misma.
    El estudio de seguimiento que vino después básicamente fracasó por sesgo de selección.

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    Que los desarrolladores se nieguen a trabajar sin IA podría significar que la herramienta funciona bien, o podría significar que, al depender cada vez más de la herramienta, su capacidad para hacer tareas más difíciles se ha atrofiado por completo.

    • Mi hipótesis es que la gente tiende a depender más de los LLM en las partes que realmente no quiere hacer, y cuando uno hace algo que no quiere hacer, el tiempo siempre se siente mucho más lento.

  • La frase “una herramienta nueva se siente más rápida porque es nueva, y esa sensación normalmente desaparece en unas semanas” me parece al revés.
    Una herramienta nueva siempre me vuelve más lento porque no estoy familiarizado con ella. Claro, se ve el potencial de volverse más rápido, pero todavía no sé usarla de forma efectiva.

    • Hay otro efecto relacionado. En especial las personas que se ofrecen a probar herramientas nuevas suelen tener entusiasmo, así que también trabajan más fuera del horario laboral para compensar lo que les falta.
      Durante un tiempo eso se ve impresionante, pero al final desaparece de forma natural cuando vuelven a su manera normal de trabajar.

  • Medir es difícil. En cierto sentido, intentar medir la programación asistida por IA podría ser en sí mismo un error.
    Está claro que hay tareas que sí acelera, y casi con certeza también hay maneras de usarla para que realmente acelere más.
    La pregunta más importante es cuáles son esas maneras y qué se pierde en el proceso.

    • Productividad y aumentar la velocidad de trabajo no son lo mismo. Aunque una tarea se haga más rápido, si esa tarea no era el cuello de botella o si la mejora de velocidad tiene un costo, puede que no haya un impacto positivo en la productividad.
      El texto original también lo trata como “medir solo la mitad fácil”.

  • Ante la pregunta “si la próxima semana tu gerente te pide demostrar que la herramienta de IA para programar por la que la empresa paga vale lo que cuesta la suscripción, ¿vas a medir líneas de código generadas o tickets cerrados?”, Claude ya mide desde la facturación la cantidad de líneas de código, la tasa de aceptación y el uso de tokens.
    La cantidad de tickets cerrados sería la velocidad del equipo, pero la salida de la IA es solo uno de sus componentes, y Jira mide la velocidad del sprint.
    De todos modos, esta pregunta puede manipularse fácilmente según lo que uno crea que el gerente quiere como resultado, y probablemente ya esté pasando.

  • Me parece que el autor dejó fuera una pregunta muy importante: “¿Qué daños causa el uso de IA?”.
    Creo que esa pregunta es más fundamental que cualquier otra. Además, el daño es mucho más fácil de medir. Basta con levantar una forja Git y ver cómo los rastreadores se lanzan sobre ella como tiburones al oler sangre.
    Que los scrapers hagan DDoS a todo internet es un problema medible, y para quien aloja sus propios servicios es una realidad que se siente en carne propia.
    ¿Esos supuestos beneficios de la IA, que ni siquiera logramos medir bien, realmente valen la pena como para tolerar el daño muy real que causan los rastreadores?
    ¿Y qué pasa si además sumamos la energía necesaria para operar esos rastreadores y procesar sus solicitudes, el costo del entrenamiento, el costo de la inferencia y la necesidad de centros de datos cada vez más grandes?
    Creo que es mucho más importante preguntar si esos supuestos beneficios de la IA valen el sacrificio de todo eso.

    • Lo que siempre me frustra en estos temas de “deberíamos estar hablando de X” es que, en artículos sobre daño ecológico, he visto exactamente el argumento contrario.
      Siguen pasándolo por alto con cosas como “aunque esto no consumiera energía, igual produce mal código, así que eso es mucho más importante” o “por qué hablar de programación, el daño real es que se usa para vigilancia”.