Un mes sin IA: la confesión de un developer arrepentido

Un developer dejó la IA por un mes: lo que recuperó (y lo que la data de 2026 confirma)

En septiembre de 2026, un developer con más de una década haciendo TDD publicó en su blog una confesión incómoda: llevaba meses sin escribir una sola línea de código. Todo lo delegaba a agentes de IA conectados a Jira, en worktrees paralelos, mientras él aprobaba PRs que no entendía. Un día, un colega le señaló en code review que un test que había escrito… no testeaba lo que su código cambiaba. Decidió dejarlo. Por un mes.

Su testimonio se titula One Month Without AI y lo publicó el 25 de septiembre en su blog personal. Lo que cuenta — la sensación de ir volviéndose perezoso, de perder el control sobre lo que el código realmente hace, de acabar siendo "un pastor de IAs" — no es una anécdota aislada. Tres estudios publicados en los últimos meses lo confirman con números.

La paradoja del 84% que usa pero solo el 29% que confía

La encuesta más reciente de Stack Overflow muestra que el 84% de los desarrolladores usa herramientas de IA, frente al 76% del año anterior. Casi la mitad lo hace a diario. Pero solo el 33% dice confiar en lo que producen — apenas un 3,1% lo hace plenamente. La cifra de confianza cayó del 40% al 29% interanual según el Temporal 2026 State of Development Report, realizado sobre 554 ingenieros en EE.UU. y Reino Unido.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

SD Times, en una encuesta informal a 103 desarrolladores a mediados de 2026, encontró una brecha aún más marcada: el 87% usaba o planeaba usar IA, pero solo el 31% confiaba en la precisión del código generado y apenas un 4% la calificaba como "alta confianza". La brecha entre adopción y confianza es el hallazgo más repetido del año: el developer no abandona la IA, pero ya no se fía de ella.

"Casi correcto pero no del todo": el problema exacto que él describe

El autor del blog lo cuenta con una frase que coincide con la queja más repetida del Stack Overflow Developer Survey 2025: el 45% de los desarrolladores señaló que las soluciones de IA son "casi correctas pero no del todo", y el 66% dijo dedicar más tiempo a arreglar ese código "casi bueno" del que habría dedicado a escribirlo desde cero.

Esa es exactamente la trampa que describe: PRs que parecen bien escritos, descripciones de siete párrafos impecables, código que "suena profesional" y por eso se aprueba sin cuestionar. La IA es tan buena comunicando que relaja al revisor. Uno deja de preguntar por qué y empieza a aceptar lo que nunca habría aceptado.

El embudo que se rompió: 180% más código, solo 30% más releases

Una investigación de la Wharton School y MIT — liderada por el profesor Leon Musolff con Mert Demirer y Liyuan Yang — siguió a más de 100.000 desarrolladores en GitHub entre 2022 y 2026, combinando registros públicos con datos de uso de Microsoft. Los resultados contradicen el discurso de la productividad multiplicada:

El autocompletado básico elevó la actividad de codificación un 40%.
Sumando agentes síncronos (que editan junto al developer), el alza acumulada llegó al 140%.
Con agentes asíncronos (autónomos a partir de un prompt), al 180%.

Pero el incremento en proyectos terminados fue solo del 50%, y en releases entregados, del 30%. La conclusión de Musolff es directa: "la restricción ya no es escribir código, sino revisarlo, integrarlo y distribuirlo". Es decir, lo que el developer del blog llama "dos días para revisar lo que la IA hizo en cinco minutos" no es percepción: es el nuevo cuello de botella documentado.

En paralelo, los investigadores analizaron las cuatro mayores tiendas de software del mundo y vieron que los lanzamientos mensuales en la App Store de Apple pasaron de unos 30.000 antes de la llegada de los agentes de IA a unos 100.000 hacia abril de 2026. Pero el uso total se mantuvo plano o cayó: se está produciendo mucho más software, pero los usuarios no lo están adoptando.

El estudio METR: creían ir 24% más rápido, iban 19% más lento

El caso más citado del año es un experimento controlado de METR (Model Evaluation and Transparency Research) con 16 developers senior de open source resolviendo 246 issues reales en sus propios repositorios. Los voluntarios pronosticaron que la IA los haría 24% más rápidos. Cuando la usaron, fueron 19% más lentos. Después de la prueba, aun habiendo vivido el retraso, estimaron que la IA los había hecho un 20% más rápidos.

La diferencia de 40 puntos entre percepción y realidad entre developers experimentados sobre código que conocían bien es lo que el Forbes Technology Council denominó "the AI validation gap": el bucle de retroalimentación se rompió. El developer ya no puede medir su propia velocidad real.

La erosión de habilidades que IBM confirma

El developer del blog también menciona algo más sutil: dejar de programar por meses le hizo sentir oxidado. La ironía es que la herramienta que prometía liberar tiempo le quitó la práctica que mantiene la habilidad. El estudio "Designing the Thinking Organization" del IBM Institute for Business Value, con 1.500 CHROs y 8.800 empleados en 28 países entre abril y junio de 2026, lo cuantifica:

El 46% de los ejecutivos sitúa la erosión de habilidades entre sus principales preocupaciones.
El 60% de los empleados dice verse directamente afectado.
Entre quienes lo temen, tres de cada cuatro reportan que la IA ya empezó a erosionar al menos algunas de sus capacidades; el pensamiento crítico aparece como la más citada.
Solo el 29% de los empleados prioriza el juicio propio al usar IA.

La pregunta incómoda que plantea Bustikiller — "¿cuánto de tu valor como engineer depende de no delegar lo importante?" — tiene respuesta en estos números: si el 60% de tu equipo nota erosión, el problema no es individual, es de diseño organizacional.

¿Qué significa esto para tu startup?

La historia de Bustikiller y los estudios que la respaldan no son una invitación a apagar la IA mañana. Son una advertencia sobre tres puntos ciegos que ya están costando dinero y talento:

El cuello de botella se movió. Si tu equipo genera 3x más PRs pero no entrega 3x más features, el problema no es generación, es revisión. El paper de Wharton muestra que una release del 30% sobre software AI-generated ya es un resultado excepcional. Presupuesta capacidad de revisión al mismo ritmo que capacidad de generación.
La métrica de productividad es la nueva fea. Si mides líneas de código, PRs abiertos o "sentimiento del equipo", estás midiendo la ilusión de velocidad que METR desmontó. Cambia a métricas de flujo: change failure rate, rework rate, time to restore.
La erosión de skills es un riesgo de hiring. Si dejas a un junior dos años pastoreando IAs, no consigues un senior: consigues un junior oxidado que cree ser senior. La rotación costará más que el ahorro en tokens.

Tres acciones que puedes tomar esta semana

Separa budget de generación y budget de revisión. Si tu CFO aprobó gasto en Cursor o Claude Code, negocia a la vez una línea equivalente en code review humano, pair programming y testing. Los papers de Wharton y Forbes coinciden: sin la segunda, la primera se evapora.
Mide "casi correcto pero no del todo". Empieza a trackear cuántos ciclos de revisión necesita cada PR AI-generated antes de mergear. Stack Overflow lo señala como la queja número uno; en tu equipo es una métrica accionable desde el próximo sprint.
Reserva un día a la semana sin IA. El autor del blog no volvió a TDD por nostalgia: volvió porque lo hacía más rápido en su propio código. Prueba con tu senior engineer durante un sprint y mide. El IBM Institute for Business Value reporta que el 80% de las empresas tiene roadmap de reskilling; pocas lo aplican al coding.

La IA no va a desaparecer. Pero la fantasía de que el "AI shepherd" es un rol profesionalizable sí debería desaparecer. Como escribe Bustikiller: "Lo que te consiguió ese trabajo fue tu experiencia como developer. Si apagas tu cerebro, no te vuelves más rápido: te vuelves reemplazable".