Llevamos dos años escuchando que la IA va a multiplicar la productividad de los programadores. GitHub Copilot presume de un 55% más rápido. Las demos muestran a desarrolladores generando código en segundos. Los benchmarks de agentes suben cada semana.

Pero cuando METR —el mismo laboratorio que hoy evalúa los riesgos de la IA frontier— decidió medir el impacto real con programadores de verdad trabajando en sus propios repositorios, el resultado fue el contrario: los desarrolladores tardaron un 19% más cuando usaban IA. Sí, has leído bien: un 19% más lentos.

Cómo se hizo el estudio

METR reclutó a 16 desarrolladores con años de experiencia en proyectos open-source de gran escala (más de un millón de líneas de código cada uno). Cada participante eligió issues reales de sus repositorios —bugs, features, refactors— que sumaron 246 tareas en total.

Luego asignaron cada issue al azar a uno de dos grupos: los que podían usar IA y los que no. Cuando se permitía IA, los desarrolladores usaban las herramientas que quisieran (principalmente Cursor Pro con Claude 3.5/3.7 Sonnet, los modelos frontier de ese momento). Cuando no, trabajaban sin asistencia generativa.

Cada tarea duraba unas dos horas de media. Los participantes grababan su pantalla y reportaban el tiempo real de implementación. Y cobraban 150$ por hora por participar, para que no hubiera incentivos a apresurarse o alargarse.

El resultado: 19% más lento

Los números son tozudos. Con IA, los desarrolladores tardaron más en completar las mismas tareas. No es que la IA no ayudara —ayudaba en cosas concretas— pero el tiempo que se ahorraba generando código se perdía en otras partes:

• Verificar el código generado. Cada fragmento que producía la IA había que leerlo, entenderlo y validarlo. Eso lleva tiempo.
• Depurar errores inyectados. La IA genera código con bugs sutiles. Bugs que un humano no habría cometido pero que ahora tiene que encontrar y arreglar.
• Context switching constante. El desarrollador pasaba de pensar en su solución a revisar la de la IA, y viceversa. Ese ir y venir tiene un coste cognitivo real.
• Prompt engineering implícito. Redactar bien el prompt, ajustarlo, añadir contexto. Todo cuenta como tiempo de desarrollo.

METR lo resume así: "cuando los desarrolladores usan herramientas de IA, tardan un 19% más que sin ellas". Un resultado estadísticamente significativo que contradice casi todo lo que leemos en las noticias.

Por qué los benchmarks no cuentan toda la historia

Los benchmarks tipo SWE-bench miden tareas autocontenidas: coge un issue, genera un parche, evalúa. Son útiles para comparar modelos, pero no reflejan la realidad de un desarrollador trabajando en su código base.

En el mundo real, el desarrollador conoce el contexto, ha escrito parte del código, sabe por qué se tomaron ciertas decisiones. Y también sabe que si introduce un bug, él será quien lo depure. Esa responsabilidad cambia cómo usas la IA: no te limitas a copiar y pegar. Validas cada línea.

Lo que la IA sí hace bien

No todo son malas noticias. El estudio también observó que la IA destacaba en tareas muy específicas: generar código boilerplate, escribir tests, explorar APIs desconocidas. En esos casos, los programadores sí notaban un impulso.

El problema es que esas tareas suelen ser una fracción pequeña del trabajo real de desarrollo. La mayor parte del tiempo no escribes código nuevo: lees código existente, entiendes cómo encaja, depuras, pruebas, revisas. Y ahí la IA, al menos en 2025, no solo no ayudaba: ralentizaba.

METR publicó una actualización en febrero de 2026 con herramientas más modernas. Los resultados mejoraron, pero el patrón se mantiene: la IA acelera tareas cortas y descontextualizadas, pero el trabajo de integración y validación sigue siendo humano.

Qué significa para el día a día

Si eres desarrollador y usas IA a diario, esto no significa que debas dejarla. Significa que deberías usarla con más criterio:

• Para boilerplate y exploración: adelante. La IA es una máquina de generar esqueletos y ejemplos.
• Para lógica de negocio crítica: piensa primero tú, escribe tú el núcleo, y usa la IA solo para tareas auxiliares.
• Mide tu propio tiempo: prueba una semana sin IA y otra con IA en tareas similares. Igual te llevas una sorpresa.

La IA en programación es como un copiloto de avión: útil en vuelo crucero, pero si delegas el aterrizaje sin supervisión, acabas estampado. El mejor uso de la IA no es escribir más código, sino escribir el código correcto con menos esfuerzo repetitivo.

Y a veces, eso significa escribir menos código, pero pensarlo más.