Tus developers mergean el doble de PRs con IA. Tu delivery no se movió.
La mayoría de las empresas cree que, si sus developers usan IA, el equipo entrega más. La realidad es que cada persona produce más código, pero la empresa no entrega más software. Y esa diferencia está empezando a definir decisiones de contratación que después cuestan caro.
La mayoría de las empresas cree que, si sus developers usan IA, el equipo entrega más. La realidad es que cada persona produce más código, pero la empresa no entrega más software. Y esa diferencia está empezando a definir decisiones de contratación que después cuestan caro.
¿La IA permite contratar menos developers en 2026?
Todavía no, al menos no a nivel equipo. El reporte de Faros AI (2025), con datos de más de 10.000 developers en 1.255 equipos, encontró que quienes adoptan mucho la IA mergean un 98% más de pull requests, pero no halló una correlación significativa entre esa adopción y mejoras de delivery a nivel empresa.
Un pull request (PR) es el paquete de cambios de código que un developer propone y que otro revisa antes de sumarlo al producto. Más PRs no es lo mismo que más producto funcionando en manos del cliente.
¿Qué dicen los datos 2025-2026 sobre productividad con IA?
Los números no se contradicen tanto como parece. Miden cosas distintas.
| Fuente (año) | Qué midió | Resultado |
|---|---|---|
| Faros AI (2025) | 10.000+ developers, 1.255 equipos | +21% tareas completadas, +98% PRs mergeados, +91% tiempo de revisión |
| METR (2025) | 16 developers senior, 246 tareas reales | 19% más lentos con IA, aunque creían ir 20% más rápido |
| DORA / Google Cloud (2025) | ~5.000 profesionales | 90% de adopción; sube el throughput y también la inestabilidad |
| Stack Overflow (2025) | Encuesta global de developers | 84% usa IA; 46% desconfía de la precisión de lo que genera |
| CoderPad (2026) | 650+ developers y líderes de hiring | 54% perdería 10% o más de productividad sin IA |
Throughput es el volumen de cambios que un equipo logra poner en producción. DORA lo resume con una idea que conviene tatuarse: la IA amplifica lo que ya existe. Un equipo ordenado acelera. Un equipo desordenado produce desorden más rápido.
¿Por qué la productividad individual no llega al delivery?
Porque el cuello de botella se movió. Antes el límite era cuánto código podía escribir una persona. Hoy el límite es cuánto código puede revisar, probar e integrar el equipo.
Faros lo muestra con claridad: con alta adopción de IA, el tamaño promedio de cada PR crece 154%, el tiempo de revisión sube 91% y los bugs por developer aumentan 9%. Se escribe más, pero alguien tiene que leer todo eso, y ese alguien suele ser el senior más caro del equipo.
A eso se suma el problema del código “casi correcto”. Según Stack Overflow (2025), el 66% de los developers dice que lidia con soluciones de IA “casi correctas”: parecen bien, pero fallan en un detalle. Encontrar ese detalle lleva tiempo que no aparece en ningún dashboard de productividad.
¿Por qué la percepción de velocidad es un riesgo para planificar?
El dato más incómodo es el de METR (2025). Los developers pronosticaron que la IA los haría 24% más rápidos. Al terminar, estimaron que habían ido 20% más rápido. La medición mostró que fueron 19% más lentos.
METR aclaró en febrero de 2026 que sus estudios posteriores son menos concluyentes y que las herramientas mejoraron. Pero la brecha de percepción sigue siendo el punto: el developer siente que vuela, el manager lo reporta, y la planificación de headcount se arma sobre esa sensación.
Eso ya está pasando. Según Chief Executive (enero 2026), el 31% de las empresas usa IA para reducir headcount. Y un relevamiento de Orgvue (2025) sobre 1.163 ejecutivos encontró que el 55% de quienes despidieron gente por la IA reconoce que se equivocó.
¿Qué perfil conviene contratar en un equipo que ya usa IA?
Si el recurso escaso es el criterio, hay que contratar criterio. En los más de 500 procesos que gestionamos en LATAM, lo que vemos es que los perfiles que más rinden en equipos con IA comparten tres rasgos:
- Revisan mejor de lo que escriben. Detectan rápido qué parte del código generado no encaja con la arquitectura existente.
- Parten el trabajo en piezas chicas. Un PR chico se revisa en minutos; uno gigante generado de un tirón se revisa mal o no se revisa.
- Saben cuándo no usar la herramienta. En código legado o con reglas de negocio muy específicas, a veces escribir a mano es más rápido.
Esto cambia la entrevista. Evaluar a alguien solo por cuánto resuelve en 45 minutos premia justamente lo que la IA ya hace. Pedirle que revise un PR con errores sutiles dice mucho más sobre cómo va a rendir en tu equipo.
¿Cómo medir si la IA cambió de verdad la capacidad del equipo?
Medir PRs, líneas de código o tickets cerrados es medir actividad. Para saber si el equipo entrega más, conviene mirar indicadores de flujo completo:
- Lead time: cuánto tarda un cambio desde que se empieza hasta que llega a producción.
- Tiempo de revisión: cuántas horas espera un PR antes de que alguien lo apruebe.
- Change failure rate: qué porcentaje de los cambios desplegados genera un incidente o hay que revertir.
- Retrabajo: cuánto del código nuevo se reescribe en las semanas siguientes.
Y el momento importa. Lo que vemos en la práctica es que la foto real aparece alrededor del tercer mes, cuando se agota el entusiasmo inicial y la deuda de revisión empieza a pesar. Decidir headcount con datos de las primeras semanas es decidir con la parte más optimista de la curva.
La pregunta correcta no es cuánta gente sobra
La IA sí cambia la ecuación de un equipo de ingeniería. Lo que todavía no cambió es que el software lo entrega un sistema, no una suma de personas escribiendo rápido.
Las empresas que salgan bien paradas de esta etapa no van a ser las que recortaron primero. Van a ser las que entendieron dónde se trabó el flujo y contrataron para destrabarlo.
Connecting people
Connecting People conecta empresas de Latinoamérica con el mejor talento de la región, a través de reclutamiento y un modelo de partner operativo.
