Las líneas de código consiguieron un mejor publirrelacionista
(curlewis.co.nz)- La evaluación de la productividad de los desarrolladores debe juzgarse por métricas de resultado como valor para el cliente, ingresos y confiabilidad, no por la cantidad de código
- Las cifras promocionales recientes sobre programación con IA de Google, Anthropic, OpenAI y Cursor se enfocan todas en afirmaciones cuantitativas como el porcentaje de código generado o el número de líneas de código
- La afirmación pasada de GitHub Copilot de una mejora del 55% en la velocidad de trabajo era un resultado verificable, pero el “porcentaje de código escrito por IA” puede crecer sin relación alguna con si hubo mejora o no
- La investigación real es mixta: desde +26% en tasa de finalización en Cui et al. hasta el “19% más lento” de METR y su posterior retractación, además de encuestas donde el 90% de las empresas no mide efectos; el efecto a nivel organizacional ronda el 10%
- Adoptar IA es necesario, pero medir resultados debe basarse en criterios probados como las métricas DORA, la confiabilidad, la velocidad de cambios significativos, los ingresos y el valor para el cliente
El regreso de la métrica de líneas de código
- Hace 15 años, en una empresa SaaS, no se podía concluir que uno de dos desarrolladores senior fuera mejor que el otro solo porque escribía 40% más código
- Lo que realmente importa es qué se envió a producción (ship) y cómo contribuyó a clientes, ingresos y estabilidad; las líneas de código y la cantidad de PR llevan décadas considerándose malas formas de medición
- En 2026, las cifras emblemáticas que presume la industria se concentran todas en el porcentaje de código escrito por IA
- Google: la IA genera el 75% del código nuevo
- Anthropic: Claude escribió cerca del 80% del código de producción fusionado, y los ingenieros despliegan “8 veces más código” por trimestre
- OpenAI: igualmente cerca del 80%
- Cursor: “más de 100 millones de líneas de código empresarial escritas al día”
- Todas estas cifras son afirmaciones de volumen, y el “porcentaje de código escrito por IA” no es más que las líneas de código con un mensaje publicitario más sofisticado
- El hecho de que todas esas empresas sean vendors de IA hace que inflar la adopción sea un incentivo importante
Antes se afirmaban resultados
- Hace unos años, la cifra clave no era distinta en escala, sino en naturaleza
- La afirmación principal de GitHub era que con Copilot las tareas se completan 55% más rápido
- Recibió muchas críticas, pero era una afirmación de resultado (outcome): audaz, falsable y relacionada con valor; si estaba mal, se podía demostrar
- Las afirmaciones de 2026 están estructuradas para no poder fallar
- “El 75% del código fue escrito por IA” puede ser cierto y seguir subiendo sin relación con mejoras reales como desplegar más rápido, reducir incidentes o aumentar la satisfacción del cliente
- Las métricas de volumen solo decepcionan cuando la adopción se estanca, y casi todos coinciden en que la adopción sí es real
- Las afirmaciones crecieron, pero dicen menos
Lo que no aparece en los espectaculares
- Lo que pasó entre tanto es que la evidencia de resultados se volvió más compleja
-
Resultados que apoyan la adopción
- Cui et al.: entre unos 5,000 desarrolladores, +26% en trabajo completado, con la mayor mejora especialmente en desarrolladores junior; casi no hay discusión al respecto
-
Evidencia en sentido contrario
-
El cambio de postura de METR
- En febrero de 2026, METR básicamente retiró esa postura: una estimación posterior se invirtió a mejora de velocidad (speedup), aunque con márgenes de error muy amplios
- Como los desarrolladores ya se niegan a trabajar sin IA y no pueden auto-reportar de forma confiable cuánto tarda el trabajo con agentes, se desechó el diseño mismo del estudio
- La postura más reciente: en 2026, es muy probable que la IA sí acelere a los desarrolladores, pero no se puede medir limpiamente cuánto
-
Efecto a nivel empresa
- Encuesta del NBER a unos 6,000 ejecutivos: 69% de las empresas usa IA, pero cerca de 9 de cada 10 reportan no ver efectos medibles en productividad
- El consenso entre estudios apunta a una mejora de alrededor de 10% a nivel organizacional: útil, pero no al grado de “ya no se necesitan desarrolladores”
- Quienes todavía citan solo el “19% más lento” desde el escepticismo también están haciendo cherry-picking; la investigación sigue actualizándose y la industria solo cambió el objeto de medición
La versión en IA de las métricas de vanidad
- No es un problema exclusivo de las afirmaciones de los vendors de IA
-
Modelos de madurez y escaleras
- Carnegie Mellon SEI y Accenture lanzaron hace unos días el AI Adoption Maturity Model: 5 niveles, 8 dimensiones, usando para marketing la estadística de que “95% de las organizaciones no obtiene retorno”
- Los “8 levels of AI-assisted development” de Steve Yegge clasifican según qué herramienta usas y cuánta supervisión haces
- Todos los vendors de herramientas lanzan su propia escalera de madurez, y la parte más alta normalmente es “usar más nuestro producto”
- Estas escaleras miden la intensidad de adopción mientras la llaman madurez; es el mismo sustituto con otro empaque
-
Confusión de definiciones
- Cuando Augment preguntó a 219 líderes de ingeniería qué era la “ingeniería AI-native”, obtuvo 219 respuestas distintas
-
Las dos caras de Anthropic
- Al mismo tiempo que afirma “8 veces más código enviado”, también presentó uno de los estudios más rigurosos del año
- El RCT mostró que los desarrolladores asistidos por IA obtuvieron una puntuación 17% menor en comprensión del código recién enviado, sin una mejora de productividad estadísticamente significativa
- El área de investigación actualiza la evidencia mientras marketing cuenta volumen: ambas cosas pueden ser ciertas al mismo tiempo
Por qué prestar atención a este problema
- Estas cifras no son decoración: mueven presupuestos, expectativas de desempeño y planes de personal
-
Recortes de personal con la IA como justificación
- En febrero, Jack Dorsey recortó más del 40% de la plantilla de Block (más de 4,000 personas), presentando la IA explícitamente como argumento central: “equipos más pequeños pueden hacer más y mejor con las herramientas que estamos construyendo”
- Semanas después, Atlassian recortó 10% (unas 1,600 personas), reconociendo que “no sería honesto fingir que la IA no cambia la combinación de habilidades o la cantidad de roles necesarios”
- Dorsey también dijo en el mismo anuncio que el negocio estaba sólido y que la ganancia bruta seguía creciendo
-
Dudas sobre las afirmaciones de productividad
- Si “la IA hace a todos más productivos y por eso se necesita menos gente”, entonces habría que ver esa evidencia, pero aquí se sostiene que hoy no existe
- Habría que demostrar que una parte del personal realmente está ociosa o subutilizada; y como las empresas de producto/SaaS tienen roadmaps interminables, lo normal sería usar esa capacidad extra en valor para el cliente y velocidad, algo que debería verse en MAU, conversión e ingresos
- Elegir recortes sugiere que la afirmación de productividad está funcionando como PR para una decisión ya tomada por otras razones, como sobrecontratación o presión de inversionistas
- A veces los recortes por eficiencia sí están justificados, pero en ese caso se deben usar los sistemas individuales de evaluación de desempeño que ya operan, no la cantidad de tokens, el “porcentaje de código escrito por IA” o una calificación en una escalera de madurez
- Si el criterio de selección es una métrica de vanidad, entonces esa selección no es más que “una lotería con labial”
Conclusión
- Esto no es anti-IA; la postura es que todos los ingenieros deberían usar IA todos los días
- Ya sea AI-first o AI-proficient, sin importar el nombre, hace falta probar con curiosidad nuevas herramientas y los modelos más recientes
- La industria ya absorbió lenguajes de alto nivel, IDE, autocompletado, agile y devops; siempre hubo nostálgicos que resistieron, pero al final se sumaron
- Lo distinto esta vez es la velocidad: la adopción de “la nube” se podía postergar años y aun así sobrevivir, pero con la IA podrían ser solo meses
- La adopción de IA es la línea de salida, no el marcador
- Ya sabemos cómo medir el desempeño de ingeniería: métricas DORA, confiabilidad, proporción de cambios significativos y, en última instancia, ingresos y valor para el cliente
- No hay razón para abandonar métodos probados y reemplazarlos por puntajes de vanidad sobre IA
- La pregunta que hay que lanzar en pitches de vendors, revisiones ejecutivas y el feed de LinkedIn es: “¿eso es resultado o volumen?”
- La forma de trabajar debe ser AI-first; la forma de medir debe ser probada en batalla (battle-tested)
1 comentarios
Comentarios en Hacker News
Parece que esta extraña tendencia llegó a su punto máximo con una publicación del blog de OpenAI de febrero de 2026 [1]. Es un post que llegó recientemente a portada [2], y trata sobre el proceso de crear algo escrito al 100% por un agente
Pero no explica qué es exactamente esa cosa ni qué valor aporta a los usuarios. La descripción más cercana es algo como: “este producto lo han usado internamente cientos de personas, y también hay usuarios avanzados internos que lo usan a diario”
Aun así, el hecho de que tenga 1 millón de líneas de código se repite dos veces en los primeros cientos de palabras
[1] https://openai.com/index/harness-engineering/
[2] https://news.ycombinator.com/item?id=48416264
Si además tiene “1 millón de líneas de código” y “fue escrito 100% por agentes”, entonces todavía más. O tal vez sea un menú en JS para la wiki del departamento que en realidad vuelve a implementar jquery en MS JScript y lo transpila a JS 5
Por muy potentes que sean los LLM, tampoco parece que eso vaya a ser mantenible
https://github.com/openai/symphony
En una entrevista de podcast dicen que es una app de Electron que los usuarios descargan, y por eso generan builds nuevas periódicamente. Ver la sección “Autonomous Merging Flow” aquí: https://www.latent.space/p/harness-eng
No dejo de acordarme de que alguien de Microsoft publicó algo como “queremos 1 millón de líneas de código por ingeniero al mes”. Para la mayoría de los ingenieros con los que hablé sonaba a sátira, pero en realidad no era sátira en absoluto, y parecía reflejar bastante bien la actitud de muchos CEOs hacia la generación de código con LLM
Aun así, en los últimos meses da la impresión de que se ha enfriado un poco esa fiebre por producir cantidades inmantenibles de líneas de código. Se están compartiendo públicamente visiones más prácticas y realistas, y parece que poco a poco incluso están llegando a algunas de las personas de más alto nivel en empresas tecnológicas. Tal vez todavía no esté todo perdido
En la práctica, la mayor parte del código no estaba probada
1 millón de líneas al mes / 25 días al mes / 8 horas al día / 60 minutos por hora
Eso parece un problema bastante serio para quien tenga que hacer code review
Hacer que cada ingeniero produzca 1 millón de líneas de código al mes, sin pensar en cómo esas líneas le iban a generar dinero a la empresa ni cuántos tokens se iban a quemar y a qué costo en el proceso, claramente no parecía un plan muy bien pensado
En cambio, deuda técnica no logró impactar a la gerencia del mismo modo. La deuda suele verse como algo que podría convertirse en problema, pero que no hace falta evitar ni resolver hasta que efectivamente se vuelva un problema, así que se sigue postergando
He visto esto en las dos empresas pequeñas donde trabajo. Hace unos meses nos dieron Claude Cowork y todos estaban emocionadísimos; todavía lo usan todos los días, pero creo que en general han quedado bastante decepcionados frente a la magia que esperaban
Se quejan de que el resultado es mediocre y verboso, se equivoca hasta en cosas muy básicas, se topa constantemente con los límites de tokens y al final es más rápido hacerlo uno mismo, así que vuelven a hacerlo manualmente
Al principio puede haber algo de mal uso de la herramienta, pero la gente se está dando cuenta de que sigue habiendo una brecha entre lo que dicen los CEOs de IA, los vendedores de humo de LinkedIn y los vendedores de suplementos de IA en YouTube, y la realidad
Si una empresa dice que “la IA hizo a todos más productivos y por eso se necesita menos gente”, me gustaría ver la evidencia. A día de hoy no creo que esa evidencia exista
En la práctica están diciendo tonterías y usando la IA como excusa para revertir la sobrecontratación de la era del covid. Al mismo tiempo, eso les hace parecer ante los inversionistas como una organización más ágil y eficiente en costos por adoptar la última tecnología de moda
Yo pensaba que a los inversionistas les importaban más las ganancias que adoptar la última tecnología de moda
Y además, una empresa que dice “¡nosotros también usamos la tecnología brillante que puede usar cualquier idiota en su cuarto!” es también una empresa completamente sin ventaja competitiva
Siempre me ha parecido infinitamente ridículo que nuestra industria se pasara décadas explicando que “lo que hacemos es complejo y toma mucho tiempo, así que la productividad no puede medirse fácilmente”, y que en cuanto apareció la IA de repente se empezaran a venerar cosas como las líneas de código, multiplicadores de N veces o la cantidad de tickets por semana como si fueran métricas útiles u objetivas
Las razones por las que rechazábamos métricas como las líneas de código no han cambiado. Lo importante no es cuánto código produces, sino la calidad del resultado. La IA también hereda los mismos problemas humanos. Y aun así, por alguna razón, estamos tirando por la borda lo que aprendimos, lo cual da un poco de vergüenza
Porque siempre han existido jefes poco involucrados pero agresivos y exigentes. Incluso los jefes cuyo trabajo principal es exprimir más esfuerzo de los empleados y que no aportan nada a la coordinación tienen, tristemente, valor económico
Por eso siempre ha existido una nube de dos enfoques superpuestos: el rendimiento real y mediciones como las líneas de código
La IA les da todas las herramientas para satisfacer a ese tipo de jefe poco involucrado pero muy demandante. Así que ahora habrá más gente a la que le gusten como métricas las líneas de código y la suma de funcionalidades. Porque ahora eso es más fácil
Si un desarrollador senior A+ pasa 8 meses creando una funcionalidad y al final no se lanza o el MVP se descarta, entonces ese senior A+ fue un desperdicio, y su productividad pasa a ser igual a la de dos ingenieros B+ en el mismo proyecto
Este es en realidad un problema muy común, pero normalmente se ignora en contratación o en la asignación de recursos de proyecto. La IA no va a cambiar eso de manera significativa
Puede que el equipo termine el trabajo mucho más rápido, pero es muy probable que la capa burocrática de arriba siga igual, y entonces las ganancias de la programación con IA serán mínimas. Para adaptarse de verdad a la IA, habría que rehacer la empresa desde arriba, y eso casi nunca va a pasar
El empuje a la IA al final es extrañamente infundado. No hay razones, ni objetivos, ni argumentos sobre beneficios; es más bien un “simplemente usa IA, los desarrolladores tienen que aceptar lo nuevo”
Incluso en textos que he leído recientemente, había una crítica breve a la IA con poco contexto que al final terminaba como un anuncio de IA, sin nada que conectara ambas cosas
Los inversionistas y los grandes clientes también se lo van a pensar dos veces antes de firmar contratos importantes
Así que hay que usar IA. No hay que ponerse a medir mezquinamente costos y beneficios. El mundo va en esa dirección, y si quieres vivir del desarrollo de software, tú también tienes que ir en esa dirección
También se siente rara la parte de “la diferencia esta vez es la velocidad. Con el cloud podías sobrevivir aunque lo adoptaras unos años tarde. Con la IA pueden ser unos meses”
El autor parece entender que las afirmaciones pro-IA que hacen las empresas de IA sobre lo indispensable de sus productos son imposibles de refutar, y acto seguido retrocede con un “espera, no vayan a pensar que soy anti-IA”
¿En qué sentido esa afirmación es más rigurosa que los argumentos de productividad que critica en el resto del texto? ¿Eso de que si no adoptas IA en cuestión de meses no vas a “sobrevivir”?
No es verdad cuando lo dice el CEO de una empresa de IA, y tampoco pasa a ser verdad cuando alguien que señala las tonterías de los CEO de IA dice exactamente lo mismo por alguna razón
Decir que despiden gente por culpa de la IA deja demasiado margen de interpretación y además traslada la responsabilidad de ellos hacia la IA. Siendo realistas, no deberíamos culpar a la IA por algo que hizo el CEO. También podían haber reentrenado a sus empleados para adaptarlos a la IA, pero no lo hicieron. ¿Por qué será? Tal vez porque no fue por la IA
De hecho sí lo escribí yo mismo; no lo hice como “AI slop”, como se suele decir por ahí, así que probablemente al final se volvió “sloppy” en un sentido muy humano
Tienes razón en que no logré sustentar bien la parte de “espera”, pero aun así mantengo la idea de que la gente debería probar la IA. Deberían experimentar y encontrar formas en que les sirva. Incluso entre ingenieros parecidos, el espectro de formas de obtener valor era muy amplio
El costo de probar de verdad las herramientas es casi nulo, y la postura de “adóptala con intención y mídela con métodos aburridos pero comprobados” no es lo mismo que “si no la adoptas, te mueres”
Cuando una empresa dice: “la IA hizo a todos más productivos, así que necesitamos menos gente”, implícitamente está diciendo que no quiere volverse más productiva
quiere pagarle menos a un grupo más productivo para obtener la misma productividad
¿Por qué existe ese desequilibrio entre el dinero que recibe el empleador por unidad de producción y el dinero que recibe el empleado?
si obtienes la misma producción con menos personas, la productividad de la empresa o del país mejoró
si tienes la misma productividad con menos personas, entonces la producción también se reduce en proporción, así que no hay beneficio para la empresa, e incluso podría ser peor si hay costos fijos
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
Yo veo las líneas de código como algo no muy distinto del tiempo pasado en la oficina. Antes de la pandemia siempre decían: “si no están en la oficina, ¿cómo sabemos que están trabajando?”
Fácil. Mirando qué aportan al negocio con las métricas de resultados que se usan para evaluar a todos los empleados
Creo que nosotros, los ingenieros, tenemos buena parte de la culpa de que las líneas de código sigan viéndose como un activo y no como una deuda. Nos enorgullece lo que construimos, pero para explicar qué tan “grande” es algo necesitamos una métrica y al final volvemos a la más fácil de contar
Hay que cambiar la terminología. En particular, deberíamos usar mucho más expresiones como “...y el costo fue N líneas de código”. También hay que decir en qué se gastaron esas líneas de código
“Implementé la nueva funcionalidad X y solo costó 200 líneas”
“Ese bug fue muy difícil de encontrar, pero al final solo costó 6 líneas de código”
“En el caso X hacíamos algo que en el caso Y no hacíamos, pero resultó que esa distinción ni siquiera era necesaria. Así que al corregir el problema, además ahorré 20 líneas de código”
Las líneas de código son el precio que pagamos. No presumimos haber gastado 200 dólares sin decir qué compramos. ¿Por qué sí lo hacemos con las líneas de código?
“Me inscribí tarde y tuve que pagar 200 dólares más” y “compré un colgante de lámpara de cerámica artesanal pintado a mano por solo 200 dólares; uno hecho en fábrica en Amazon cuesta más de 1,200 dólares” son cosas completamente distintas, y en el código corresponde exactamente a la misma diferencia