IA en el desarrollo: qué muestran realmente los datos

Casi todos los equipos de desarrollo ya adoptaron alguna herramienta de IA. La pregunta que casi nadie responde con datos es la más incómoda: ¿está realmente entregando software más rápido? Existen estudios controlados sobre el tema, y sus conclusiones no coinciden entre sí. Entender por qué divergen es mucho más útil que elegir el número que nos gusta.

Dos estudios, dos resultados opuestos

En 2023, un experimento controlado pidió a 95 desarrolladores freelance implementar un servidor HTTP en JavaScript. El grupo con acceso a GitHub Copilot terminó 55,8% más rápido que el grupo de control. Es uno de los números más citados del sector, y es real.

En 2025, METR realizó otro experimento controlado: 16 desarrolladores open source experimentados, 246 tareas reales, dentro de los repositorios maduros que ellos mismos mantienen. El resultado: con acceso a las herramientas de IA de principios de 2025, fueron alrededor de 19% más lentos.

Ambos estudios son metodológicamente serios. No se contradicen: midieron cosas distintas.

Qué explica la diferencia

La variable decisiva no es la herramienta, es el contexto de la tarea.

El estudio de 2023 usó una tarea greenfield, autocontenida y bien especificada, resuelta por personas sin familiaridad previa con ese código. Ese es el escenario donde un modelo brilla: el patrón es común, el contexto necesario cabe en la ventana y no hay historia que respetar.

El estudio de METR fue el extremo opuesto: una base de código grande y madura, con convenciones implícitas, trabajada por desarrolladores que ya conocían cada rincón. Aquí el modelo carece de contexto que no puede obtener, y la persona gasta tiempo revisando, corrigiendo y descartando sugerencias. El costo de verificar empieza a competir con la ganancia de generar.

La lectura práctica: la ganancia de IA es alta en código nuevo y periférico, y cae (puede volverse negativa) en código central y antiguo que sus mantenedores conocen a fondo.

La percepción engaña, incluso la tuya

El detalle más incómodo del estudio de METR no es el 19%. Es que los participantes creían haber sido unos 20% más rápidos, cuando en realidad fueron más lentos. Antes de empezar, pronosticaban una mejora del 24%.

Es decir: la sensación de velocidad sobrevivió intacta a la evidencia en contra. Eso importa porque la mayoría de las decisiones corporativas de adopción de IA se apoyan justamente en esa sensación, recogida en una encuesta interna de satisfacción. La percepción es un dato legítimo, pero no es una medida de throughput.

La lectura de DORA: la IA amplifica, no es un atajo

El informe de DORA de 2025 sobre desarrollo asistido por IA llega a un encuadre que reconcilia bien ambos experimentos: la IA amplifica las características que tu sistema de entrega ya tiene. Donde hay una base sólida, lotes pequeños, pruebas confiables y feedback rápido, la IA acelera. Donde hay cuellos de botella, aumenta la presión sobre ellos y expone el problema más rápido.

Por eso la misma herramienta produce resultados opuestos en dos equipos de la misma empresa. La variable no es el modelo, es la plataforma a su alrededor.

Cómo medir sin engañarse

El error más común es medir actividad: líneas aceptadas, sugerencias usadas, commits por día. Son métricas que la IA infla por construcción, y que nada dicen sobre valor entregado.

El framework SPACE existe precisamente para esto. Propone cinco dimensiones (satisfacción y bienestar, performance, actividad, comunicación y colaboración, eficiencia y flujo) y sostiene que la productividad no se reduce a una sola métrica. Combinado con las métricas de entrega de DORA (lead time, frecuencia de despliegue, tasa de fallo en cambios, tiempo de restauración), puedes ver si la IA está acortando el camino a producción o solo generando más código para revisar.

Una prueba honesta y barata: toma dos equipos comparables, cambia la adopción de IA en uno de ellos y observa lead time y tasa de fallo en cambios durante un trimestre. Si ninguno se movió, la ganancia que celebras es percepción.

Qué significa esto para tu equipo

Tres conclusiones que sostienen decisiones:

1. No esperes ganancias uniformes. Dirige la IA primero a código nuevo, scaffolding, pruebas, migraciones repetitivas y exploración de código desconocido. Mantén expectativas bajas en código central y maduro.
2. No midas por sensación. Instrumenta lead time y estabilidad antes de escalar la adopción, o no podrás distinguir ganancia real de entusiasmo.
3. Trátalo como inversión en plataforma. Si las pruebas son lentas y frágiles y el review es el cuello de botella, la IA empeora la cola. Resolver eso viene primero, y decide si la IA se paga.

La pregunta útil no es "¿funciona la IA?". Es "¿dónde, en nuestro flujo, se paga, y cómo lo sabremos?".