Los devs ya no pueden trabajar sin IA — y eso asusta más de lo que parece
En febrero de 2026, un laboratorio de investigación quiso repetir un estudio. No pudo.
No fue un problema de presupuesto, ni de metodología defectuosa, ni de falta de interés. El problema fue más extraño que cualquiera de esos: los desarrolladores que necesitaban para el estudio se negaron a participar. La razón, según confesaron los propios investigadores, fue que no querían trabajar sin IA, ni siquiera por un número limitado de tareas, ni siquiera en un entorno controlado de investigación, ni siquiera a cambio de que les pagaran por hacerlo.
El laboratorio es METR — Model Evaluation and Threat Research — uno de los nombres más respetados en investigación independiente sobre capacidades de IA. Y lo que terminaron publicando no fue el estudio que planeaban. Fue algo más inquietante: una confesión metodológica sobre por qué ya no podían medir lo que se proponían medir.
Esta es la historia de cómo un experimento fallido terminó revelando más sobre la dependencia tecnológica de la industria del software que cualquier estudio exitoso podría haberlo hecho.
El estudio original: la sorpresa de 2025
Para entender por qué el fracaso de 2026 importa, hay que volver al estudio original de METR, publicado en julio de 2025.
La metodología era simple y rigurosa. Reclutaron 16 desarrolladores experimentados de proyectos open source. Les pidieron que predefinieran tareas reales en las que iban a trabajar, y luego asignaron aleatoriamente cada tarea a una condición: "IA permitida" o "IA no permitida". Midieron cuánto tiempo tomaba completar cada tarea bajo cada condición.
El resultado sorprendió incluso a los propios investigadores: cuando los desarrolladores usaban herramientas de IA, tardaban un 19% más que sin ellas. La IA los hacía más lentos, no más rápidos.
Lo más inquietante no fue el resultado en sí. Fue la brecha de percepción. Antes de empezar, los desarrolladores predijeron que la IA reduciría su tiempo en un 24%. Después de completar las tareas, creían que la IA los había acelerado en un 20%. La realidad medida fue exactamente la opuesta. No es un error de redondeo — es una brecha documentada entre cómo se siente usar las herramientas de IA y lo que realmente hacen.
¿Por qué pasaba esto? El código se generaba más rápido, sí. Pero después los desarrolladores invertían tiempo extra encontrando y corrigiendo errores, dirigiendo a la IA hacia el resultado correcto, y esperando a que completara las tareas. La velocidad de generación no se traducía en velocidad de entrega.
El intento de repetir el estudio: el momento en que todo cambió
METR quería actualizar esa investigación en 2026, para medir cómo habían avanzado tanto los modelos de IA como la pericia de los desarrolladores trabajando con ellos. Diseñaron el mismo experimento. Fueron a reclutar participantes.
No pudieron completarlo.
A lo largo de 2025 hubo un incremento sostenido en el uso de herramientas agénticas entre desarrolladores open source — herramientas como Claude Code y Codex. Esa adopción más amplia tuvo dos efectos directos sobre el estudio de METR: reclutar y retener desarrolladores se volvió más difícil, y una proporción creciente de desarrolladores dijo que no querría hacer el 50% de su trabajo sin IA — incluso cuando el estudio pagaba $50 por hora por trabajar en tareas de su propia elección.
El propio equipo de METR lo explicó con precisión técnica en su blog: el estudio estaba sistemáticamente perdiendo a los desarrolladores con las expectativas más optimistas sobre el valor de la IA. Es decir, los desarrolladores más dependientes de la IA eran exactamente los que se negaban a participar — porque participar significaba trabajar sin ella, aunque fuera parcialmente.
Eso introduce lo que los estadísticos llaman un sesgo de selección severo. La muestra que sí logró reclutarse ya no representaba a la población real de desarrolladores. METR concluyó que los datos estaban demasiado comprometidos como para producir resultados confiables, y decidieron rediseñar completamente su metodología.
La encuesta de reemplazo: 2x de valor percibido (y por qué no es confiable)
Sin poder completar el experimento controlado, METR publicó en mayo de 2026 una encuesta diferente: permitió que empleados técnicos autoreportaran sus propias ganancias de productividad con IA.
El resultado, sin sorpresa: los desarrolladores percibieron que la IA los hacía dos veces más valiosos para sus organizaciones.
Pero hay una razón estructural para desconfiar de ese número, y los propios investigadores de METR la señalaron primero. Cuando ya tienes evidencia controlada de que la IA ralentiza a los desarrolladores en tareas complejas, un autoreporte de "2x de valor" es difícil de aceptar sin escrutinio. Ambos datos pueden ser parcialmente correctos al mismo tiempo: la IA puede hacer el trabajo más placentero, puede sentirse más rápida, y puede representar una inversión en aprender habilidades que serán valiosas con sistemas futuros más capaces — sin que necesariamente acelere la entrega real de las tareas de hoy.
La brecha entre percepción y realidad no desapareció entre 2025 y 2026. Simplemente cambió de forma: de "creo que soy más rápido" a "creo que soy más valioso".
La segunda capa: lo que la IA le está haciendo al aprendizaje
Mientras METR luchaba con su experimento, otro estudio publicado en enero de 2026 en arXiv añadió una dimensión que nadie había medido con tanta claridad.
El paper, titulado "How AI Impacts Skill Formation", fue escrito por Judy Hanwen Shen y Alex Tamkin — este último, investigador de Anthropic, la propia empresa que construye Claude. El diseño experimental era directo: pusieron a desarrolladores a aprender una librería nueva de programación asíncrona, algunos con ayuda de IA y otros sin ella.
Los que usaron IA completaron las tareas más rápido. Pero cuando los evaluaron después sobre el material que supuestamente habían aprendido, su comprensión real era medible y consistentemente peor.
Completaron el trabajo sin aprender cómo funcionaba.
Esto conecta directamente con la dificultad de METR para reclutar participantes: si una proporción creciente de developers nunca practica trabajar sin asistencia, no solo se vuelve más lenta cuando la IA no está disponible — puede estar perdiendo, de manera silenciosa y acumulativa, la comprensión profunda que antes se formaba al resolver problemas por cuenta propia.
El telemetría que contradice ambos lados: el hallazgo de Faros
Hay un tercer dato que complica aún más el panorama, y viene de una fuente con una metodología distinta: telemetría real, no encuestas ni experimentos controlados de laboratorio.
Faros AI analizó dos años de datos de telemetría de 22.000 desarrolladores. Su conclusión no coincide exactamente ni con el pesimismo de METR ni con el optimismo de los autoreportes: los desarrolladores están completando muchas más tareas con IA, pero las organizaciones no están entregando más rápido.
Es un hallazgo incómodo porque no encaja en ninguna narrativa simple. No es que la IA ralentice a cada developer individual en cada tarea — el volumen de tareas completadas sí sube. Pero ese aumento de actividad individual no se está traduciendo en un aumento equivalente de velocidad de entrega a nivel organizacional. Algo se pierde en la transición entre "el developer hizo más cosas" y "el producto llegó más rápido al mercado".
Esa desconexión es coherente con lo que ya vimos en la historia del tokenmaxxing de Amazon: el volumen de actividad de IA no es lo mismo que el valor de negocio que esa actividad produce.
El contexto que lo conecta todo: 2026, el año del ajuste de cuentas
Esta historia no ocurre en el vacío. Encaja con un patrón más amplio que se hizo visible durante el mismo período.
La misma semana en que TechCrunch reportó la dificultad de METR para reclutar participantes, el Financial Times reportó que Amazon había cerrado su leaderboard interno de tokens, KiroRank, después de que empleados lo manipularan corriendo tareas sin valor a través de agentes de IA — una práctica bautizada como tokenmaxxing. Salesforce proyecta $300 millones en gasto de tokens de Anthropic este año, y su CEO Marc Benioff pidió una "capa intermediaria" que pudiera enrutar tokens de forma inteligente entre modelos frontier y modelos más baratos — un llamado que es, en sí mismo, una admisión implícita de que no todos los tokens producen valor.
El patrón es consistente: medir la adopción de IA por volumen de uso, en lugar de por calidad de output, produce los incentivos equivocados. Eso es exactamente lo que pasó con KiroRank. Y es, en una forma diferente, lo que está pasando con la dependencia de los developers: el volumen de uso de IA está subiendo de manera sostenida, pero la relación entre ese volumen y el valor real producido sigue siendo, en el mejor de los casos, ambigua.
El programador y autor James Shore lo formuló de manera contundente en un post que se volvió viral: generar código más rápido sin reducir los costos de mantenimiento futuro es una trampa. Escribes código que no entiendes completamente, y ese código se convierte en la deuda técnica de mañana.
La paradoja central: dependencia sin certeza de beneficio
Aquí está la tensión que define este momento en la industria, y que ningún estudio individual ha logrado resolver:
Los desarrolladores son cada vez más dependientes de las herramientas de IA — tan dependientes que se niegan a trabajar sin ellas incluso en condiciones de investigación remuneradas. Al mismo tiempo, la evidencia sobre si esa dependencia realmente acelera el trabajo es, en el mejor de los casos, mixta, y en el peor de los casos, contraria a la percepción que tienen los propios desarrolladores sobre su productividad.
Eso no significa que la IA no aporte valor. Los desarrolladores que usan IA pueden estar disfrutando más su trabajo, aprendiendo herramientas que serán críticas con sistemas futuros, o completando tareas que de otra manera no habrían abordado. Pero la promesa implícita detrás de la adopción masiva — "esto te hace más rápido y mejor" — no tiene el respaldo empírico sólido que la narrativa de la industria sugiere.
Y hay un riesgo estructural adicional que merece nombrarse sin rodeos: si una generación entera de developers nunca desarrolla la capacidad de trabajar productivamente sin asistencia de IA, esa generación queda expuesta a un riesgo que antes no existía. ¿Qué pasa cuando el modelo tiene una caída? ¿Cuándo el presupuesto de tokens se agota a mitad de un sprint crítico, como le pasó a Uber? ¿Cuándo una tarea requiere razonamiento profundo que la IA actual todavía no maneja bien?
Lo que esto significa para tu carrera y tu equipo hoy
Si eres developer, founder, o lideras un equipo técnico, esta historia tiene implicaciones prácticas concretas, más allá del debate académico.
Para developers individuales: Vale la pena hacer el ejercicio deliberado, aunque sea ocasionalmente, de resolver problemas sin asistencia de IA. No por nostalgia, sino porque el estudio de Shen y Tamkin sugiere que la comprensión profunda se forma específicamente en el proceso que la IA tiende a saltarse. Mantener ese músculo activo no es ineficiencia — es gestión de riesgo profesional.
Para tech leads: Si vas a medir el impacto de la IA en tu equipo, no te fíes solo de las métricas de actividad (tareas completadas, líneas generadas, sesiones de agente) ni solo de las encuestas de percepción. El hallazgo de Faros — más actividad sin más velocidad de entrega organizacional — sugiere que necesitas instrumentar la cadena completa, desde el commit individual hasta el deployment en producción, para saber si la inversión en IA realmente se traduce en negocio.
Para founders construyendo productos con IA: La narrativa de "la IA simplemente hace todo más rápido" no está sustentada con la solidez que el marketing del sector sugiere. Construir tu estrategia de producto o de equipo sobre esa suposición sin validarla con tus propios datos es un riesgo, no una certeza.
Lo que un experimento fallido nos enseñó sin querer
METR se propuso medir si la IA había mejorado la productividad de los developers entre 2025 y 2026. No pudo hacerlo. Y esa imposibilidad terminó siendo el hallazgo más interesante de todos.
No pudieron encontrar suficientes developers dispuestos a trabajar sin IA, ni siquiera por dinero, ni siquiera por ciencia. Eso no es evidencia de que la IA funcione. Es evidencia de que la dependencia ya es estructural, independientemente de si el beneficio medible la justifica.
La pregunta que queda abierta no es si deberías usar IA para programar. Es si tu relación con esa herramienta es una elección informada o un hábito que ya no puedes evaluar objetivamente porque nunca pruebas la alternativa.
METR lo intentó. No encontró suficientes voluntarios para responder esa pregunta sobre sí mismos. Quizás vale la pena que tú sí lo intentes.
¿Cuándo fue la última vez que resolviste un problema de programación complejo sin ninguna asistencia de IA? Cuéntalo en los comentarios — la respuesta de la comunidad a esta pregunta es, probablemente, más reveladora que cualquier estudio.
Comentarios