⏱️ Lectura: 12 min
En 2026, los principales proveedores de herramientas de IA coinciden en un mensaje: la inteligencia artificial ya escribe la mayor parte del código. Google habla de un 75%, Anthropic y OpenAI rondan el 80%, y Cursor presume más de 100 millones de líneas empresariales al día. Suena impresionante. El problema es qué miden esas cifras.
📑 En este artículo
- TL;DR
- Qué pasó: el año del “80% del código lo escribe la IA”
- Antes medíamos resultados, ahora medimos volumen
- Lo que no aparece en la valla publicitaria
- Métricas de IA: cuando el volumen reemplaza al resultado
- Vanidad reempaquetada: las escaleras de “madurez”
- Por qué importa: presupuestos, expectativas y despidos
- Qué significa para desarrolladores en LATAM
- Preguntas frecuentes
- Referencias
Hace una década aprendimos que contar líneas de código o pull requests era una pésima forma de evaluar a un desarrollador. Las métricas de IA que dominan los titulares de este año son, en el fondo, lo mismo: volumen con mejor relaciones públicas.
TL;DR
- Google afirma que el 75% de su código nuevo es generado por IA; Anthropic y OpenAI hablan de cerca del 80%.
- Cursor presume más de 100 millones de líneas de código empresarial por día: todas son métricas de volumen.
- En 2022, GitHub medía resultados: Copilot hacía tareas un 55% más rápidas, una afirmación falsable.
- El estudio de METR (2025) halló que devs experimentados fueron 19% más lentos con IA, creyendo ser 20% más rápidos.
- En febrero de 2026 METR matizó: probablemente hay aceleración, pero ya no se puede medir con limpieza.
- GitClear documentó que en 2024 el código duplicado superó por primera vez al refactorizado.
- Una encuesta NBER a unos 6.000 ejecutivos: 69% usa IA, pero casi 9 de cada 10 no ven impacto medible.
- Block recortó más del 40% de su plantilla y Atlassian un 10%, con la IA como tesis explícita.
Qué pasó: el año del “80% del código lo escribe la IA”
Durante 2026, casi todos los grandes proveedores de IA para programación sacaron su gran cifra del año, y todas tienen la misma forma. Google declaró que el 75% de su código nuevo es generado por IA. Anthropic dijo que cerca del 80% del código de producción que se fusiona lo escribe Claude, y que sus ingenieros entregan “8 veces más código por trimestre”. OpenAI mencionó un número parecido, alrededor del 80%. Cursor, por su parte, optó por la métrica más grande posible: “más de 100 millones de líneas de código empresarial escritas por día”.
Cada una de esas afirmaciones es una medida de volumen. Ninguna dice nada sobre si el software resultante es más rápido, más confiable, más barato de mantener o más útil para los usuarios. “Porcentaje de código escrito por IA” no es un indicador de impacto: es la cantidad de líneas de código con un publicista mejor pagado. Y conviene recordar quién las publica: todas vienen de empresas que venden, precisamente, IA. Inflar la adopción es parte del negocio.
Antes medíamos resultados, ahora medimos volumen
El detalle interesante no es que el número creció, sino que cambió de naturaleza. Retrocedamos un par de años. La cifra estrella de GitHub era distinta: los desarrolladores completaban tareas un 55% más rápido con Copilot. Se puede discutir ese estudio cuanto se quiera —muchos lo hicieron—, pero era una afirmación sobre un resultado. Era audaz, falsable y trataba sobre valor: si era falsa, alguien podía demostrar que lo era.
Las afirmaciones de 2026 no pueden fallar, y ahí está su genialidad comercial. “El 80% de nuestro código lo escribe la IA” puede ser cierto y seguirá subiendo, mejore o no algo concreto: entregas más rápidas, menos incidentes en producción, clientes más contentos. Un número de volumen solo te decepciona si la adopción se estanca, y la adopción es lo único en lo que casi todos estamos de acuerdo. Así, las cifras se hicieron más grandes y, a la vez, dijeron menos.
graph TD
A["Métrica de volumen"] --> B["'% de código escrito por IA'"]
B --> C["Solo decepciona si la adopción se estanca"]
D["Métrica de resultado"] --> E["'Tareas 55% más rápidas'"]
E --> F["Falsable: refutable con datos"]
C --> G["No prueba que algo mejoró"]
F --> G💭 Clave: Una métrica que solo puede subir no es evidencia de mejora: es evidencia de adopción. Y la adopción se vende sola.
Lo que no aparece en la valla publicitaria
¿Qué ocurrió entre el claim de resultado de 2022 y el claim de volumen de 2026? Que la evidencia de impacto se volvió incómoda. El resultado más fuerte a favor de la adopción sigue siendo el de Cui y colegas: casi 5.000 desarrolladores, +26% de tareas completadas, con las mayores ganancias para los perfiles junior. Eso casi nadie lo discute.
Pero después llegaron los matices. GitClear mostró que, conforme se profundizaba la adopción de Copilot, el churn de código subía y el refactor se desplomaba: el porcentaje de líneas “movidas” (refactorizadas) cayó del 24,1% en 2020 al 9,5% en 2024, y 2024 fue el primer año en que la introducción de código duplicado superó a la actividad de refactor. Luego METR publicó el estudio que muchos citaron: desarrolladores open source experimentados fueron un 19% más lentos con IA en sus propios repos, mientras creían que iban un 20% más rápido.
Y aquí viene el giro: en febrero de 2026, METR matizó su propio hallazgo. Su seguimiento estimó una posible aceleración —con barras de error enormes— y abandonó el diseño del estudio, porque los desarrolladores hoy se niegan a trabajar sin IA y ya no pueden reportar de forma fiable el tiempo que tardan en tareas agénticas. Su posición actual: la IA probablemente acelera a los desarrolladores en 2026, pero ya no se puede medir con limpieza cuánto.
Métricas de IA: cuando el volumen reemplaza al resultado
A nivel de empresa el panorama es igual de gris. Una encuesta del NBER a unos 6.000 ejecutivos encontró que el 69% de las firmas usa IA de forma activa, y cerca de nueve de cada diez reportan ningún impacto medible en productividad. El consenso entre estudios sitúa la ganancia organizacional en torno al 10%. No es nada despreciable, y sigue siendo enormemente útil, pero está muy lejos del territorio de “ya no necesitas desarrolladores”.
El caso más revelador es el de Anthropic, que sostiene los dos extremos de la cuerda a la vez. Por un lado, el claim de marketing de “8 veces más código entregado”. Por otro, uno de los estudios más rigurosos del año: un ensayo controlado aleatorizado (RCT) que encontró que los desarrolladores asistidos por IA puntuaron un 17% menos en comprensión del código que acababan de entregar, sin una ganancia de productividad estadísticamente significativa. Las dos cosas son verdad al mismo tiempo: el área de investigación actualiza mientras el área de marketing cuenta líneas. Y ese contraste es exactamente el punto.
Vanidad reempaquetada: las escaleras de “madurez”
No es solo cosa de los proveedores. Han proliferado los “modelos de madurez de adopción de IA”: cinco niveles, ocho dimensiones, lanzados con estadísticas del tipo “el 95% de las organizaciones no ve retornos”. También están las “8 etapas del desarrollo asistido por IA” de Steve Yegge, que te clasifican según qué herramientas usás y cuánta supervisión les das. Casi todos esos rankings comparten un detalle: el peldaño más alto suele ser, casualmente, “usá más de nuestro producto”.
Estas escaleras miden intensidad de adopción y la llaman madurez. Es la misma sustitución de siempre, con mejor empaque. El dato favorito de este género: la empresa Augment encuestó a 219 líderes de ingeniería y les pidió definir “ingeniería nativa de IA”. Obtuvieron 219 respuestas distintas. Si nadie se pone de acuerdo en qué es, difícilmente puedas medir cuánto la tenés.
⚠️ Ojo: Cuando un proveedor te vende un “nivel de madurez de IA”, revisá cuál es el peldaño más alto. Si la cima es comprar más de su herramienta, no estás midiendo madurez: estás midiendo gasto.
Por qué importa: presupuestos, expectativas y despidos
Estos números no son decorativos. Mueven presupuestos, expectativas de desempeño y planes de contratación. En febrero de 2026, Block —la empresa detrás de Square, Cash App y Afterpay— recortó más del 40% de su plantilla, unas 4.000 personas, con la IA como tesis central y explícita. Jack Dorsey lo escribió sin rodeos: “Un equipo significativamente más pequeño, usando las herramientas que estamos construyendo, puede hacer más y hacerlo mejor”.
El detalle que más inquieta: en el mismo anuncio, Dorsey reconoció que el negocio iba fuerte y que la ganancia bruta crecía (subió 24% interanual en el trimestre). Es decir, no fue un recorte por crisis financiera. Poco después, Atlassian recortó cerca del 10% (unas 1.600 personas), admitiendo que sería deshonesto “pretender que la IA no cambia la mezcla de habilidades que necesitamos ni el número de roles requeridos”. Cuando la narrativa de “la IA escribe el 80% del código” llega a la sala de juntas, deja de ser una métrica de vanidad y empieza a costar empleos.
Qué significa para desarrolladores en LATAM
Para quienes trabajamos en equipos hispanohablantes —muchos en consultoras, software factories o startups que venden a clientes de Estados Unidos— el riesgo es importar las métricas de IA equivocadas. Si tu liderazgo empieza a pedir “qué porcentaje de nuestro código lo escribe la IA” como KPI, está midiendo adopción y llamándolo productividad. El antídoto no es rechazar la IA (es genuinamente útil), sino volver a medir resultados.
En la práctica, eso significa apoyarse en indicadores ya conocidos y falsables, como los de DORA: frecuencia de despliegue, tiempo de entrega de cambios (lead time), tasa de fallos en cambios y tiempo de recuperación. Acá un esqueleto mínimo para empezar a pensar en outcomes en lugar de líneas:
from dataclasses import dataclass
@dataclass
class MetricasEquipo:
despliegues_semana: int # frecuencia de entrega
lead_time_horas: float # de commit a produccion
tasa_fallos_pct: float # % de cambios que rompen
mttr_horas: float # tiempo de recuperacion
def es_saludable(m: MetricasEquipo) -> bool:
# Outcomes verificables, no conteo de lineas generadas por IA
return (
m.lead_time_horas < 24
and m.tasa_fallos_pct < 15
and m.mttr_horas < 4
)
antes = MetricasEquipo(3, 30.0, 18.0, 6.0)
despues = MetricasEquipo(8, 14.0, 12.0, 2.5)
print("Mejoro de verdad:", es_saludable(despues) and not es_saludable(antes))La pregunta correcta no es “¿qué porcentaje escribió la IA?”, sino “¿estamos entregando mejor software, más rápido y con menos incidentes que el trimestre pasado?”. Esa cifra sí puede fallar, y por eso vale la pena medirla.
💡 Tip: Si te piden reportar adopción de IA, acompañá siempre el dato con un outcome verificable (lead time, tasa de fallos). Un número de volumen sin un número de resultado al lado es marketing interno.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué significa que “el 80% del código lo escribe la IA”?
Significa que, según el proveedor, esa proporción de líneas fue generada o sugerida por un modelo. Es una métrica de volumen: no dice si ese código es de buena calidad, si redujo incidentes o si aceleró las entregas. Puede ser cierta y crecer sin que nada haya mejorado.
¿La IA hace más productivos a los desarrolladores?
La evidencia es mixta. Estudios como el de Cui y colegas muestran +26% de tareas completadas, sobre todo en juniors. Otros, como el de METR (2025), encontraron un 19% de ralentización en devs senior. El consenso organizacional ronda un 10% de ganancia: útil, pero lejos de los titulares.
¿Qué encontró el estudio de METR?
En 2025 halló que desarrolladores open source experimentados tardaban 19% más usando IA en sus propios repositorios, aunque creían ir un 20% más rápido. En febrero de 2026 matizó el resultado: probablemente hay aceleración, pero ya no se puede medir con limpieza porque los devs se niegan a trabajar sin IA.
¿Por qué se habla de “métricas de vanidad”?
Porque miden cantidad (líneas, porcentaje generado, adopción) en lugar de impacto (velocidad de entrega, fallos, satisfacción del cliente). Son atractivas porque casi siempre suben, pero no permiten saber si el producto realmente mejoró.
¿Esto significa que no debo usar IA para programar?
No. Las herramientas son genuinamente útiles y la mayoría de los equipos las adoptaron por buenas razones. El punto es no confundir adopción con resultado: usá la IA, pero medí su efecto con indicadores falsables como los de DORA.
¿Cómo medir el impacto real de la IA en mi equipo?
Apoyate en outcomes verificables: frecuencia de despliegue, lead time de cambios, tasa de fallos y tiempo de recuperación. Compará trimestre contra trimestre. Si esas cifras mejoran, la IA está aportando; si solo sube el “porcentaje generado por IA”, estás midiendo marketing.
Referencias
- Lines of Code Got a Better Publicist — David Curlewis — artículo original que inspiró este análisis.
- METR (2025) — estudio que halló un 19% de ralentización en desarrolladores experimentados.
- METR (2026) — actualización donde el equipo rediseña el experimento y matiza el hallazgo.
- GitClear (2025) — datos sobre churn de código, duplicación y caída del refactor.
- CNN Business — Block recorta ~40% de su plantilla citando a la IA como tesis central.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios