Desarrolladores junior con IA: el agente escribe el código y nadie aprende a revisarlo

Una prueba para esta semana: elige el último bug que cerró alguien junior de tu equipo y pídele que te explique, sin abrir el asistente, por qué fallaba. No qué cambió en el código, sino por qué fallaba. Si la respuesta es «el agente lo encontró», el bug está cerrado, pero esa persona no ha aprendido nada de él.

No es un reproche. Es lo razonable cuando el asistente propone el arreglo en treinta segundos y el sprint aprieta. El problema no está en el junior, sino en que el trabajo que lo formaba ha cambiado de manos sin que nadie lo decidiera.

La tesis de esta pieza es que la IA no hace innecesarios a los juniors: hace innecesario el ejercicio con el que un junior se convertía en senior. Y como las personas que dentro de cinco años revisarán y firmarán el código generado por agentes son los juniors de hoy, ese ejercicio hay que volver a ponerlo en el proceso, a propósito, en el sitio donde ahora está el trabajo.

Dos estudios que parecen contradecirse

El primero es uno de los experimentos de campo más amplios publicados sobre asistentes de código. Cui, Demirer, Jaffe, Musolff, Peng y Salz analizaron tres ensayos aleatorizados con GitHub Copilot en Microsoft, Accenture y una empresa del Fortune 100, con 4.867 desarrolladores en total. Quienes tenían el asistente completaron un 26% más de tareas. Y la ganancia no se repartía igual: los desarrolladores con menos antigüedad y en puestos más junior lo adoptaban más y mejoraban más; en los de más antigüedad y puestos senior, el efecto no era significativo.

El segundo es un experimento controlado que Anthropic publicó en enero de 2026, firmado por Judy Hanwen Shen y Alex Tamkin. 52 desarrolladores, en su mayoría junior y todos con más de un año de Python, tenían que aprender Trio, una librería de programación asíncrona que no conocían, e implementar dos funcionalidades. A la mitad se le dio un asistente de IA. Después, todos hicieron un test sobre los conceptos que acababan de usar. El grupo con IA sacó de media un 50%; el grupo sin IA, un 67%. La mayor diferencia apareció en las preguntas de depuración. Y el grupo con IA no terminó significativamente antes: unos dos minutos, dentro del margen de error.

Leídos juntos, no se contradicen. Miden cosas distintas. El primero mide lo que sale por la puerta esta semana. El segundo mide lo que se queda en la cabeza de quien lo hizo. Una empresa puede mejorar mucho en lo primero mientras empeora en lo segundo, y ningún panel de productividad se lo va a enseñar, porque esos paneles miden tareas cerradas, no criterio adquirido. Es la misma trampa que describíamos en el ROI de Copilot y Cursor: lo que se mide con facilidad no es lo que decide el resultado.

Lo que el junior hacía y ya no hace

Un junior no aprendía porque alguien le enseñara, sino porque hacía un tipo concreto de trabajo que le obligaba a entender. Ese trabajo es el que más se ha automatizado.

Las dos últimas filas ya las hemos tratado desde el lado de la calidad: los tests generados desde el código que no prueban nada y el review que sigue esperando a un autor. Aquí aparece la otra cara del mismo fenómeno. Cuando esas tareas se las queda el agente, no sólo se pierde un control de calidad: se pierde el sitio donde la gente aprendía a ejercerlo.

Cómo usaba la IA el grupo que sí aprendió

Lo más útil del estudio de Anthropic no es la media, sino lo que hay debajo. Los autores revisaron las grabaciones de cada sesión y encontraron seis formas distintas de usar el asistente. Tres se asociaban a notas bajas y tres a notas altas.

• Notas bajas: delegar todo el código desde el principio; empezar solo e ir cediendo cada vez más; y usar la IA para depurar a base de pegar errores hasta que algo funcione.
• Notas altas: generar el código y después esforzarse por entenderlo; pedir código y explicación a la vez; y usar la IA sólo para preguntas conceptuales, escribiendo el código uno mismo.

Los grupos son pequeños —entre dos y siete personas cada uno—, así que conviene leerlos como pistas, no como leyes. Pero la conclusión de los autores es clara: los patrones con esfuerzo cognitivo preservan el aprendizaje aunque haya IA de por medio. Lo que daña no es el asistente, es dejar de pensar mientras lo usas.

Un trabajo anterior, en otro contexto, apunta en la misma dirección. Bastani y otros dieron acceso a GPT-4 a casi mil estudiantes de secundaria en Turquía durante sus sesiones de práctica de matemáticas, con dos versiones: una que imitaba el chat estándar y otra con instrucciones diseñadas para proteger el aprendizaje. Mientras tenían acceso, las dos mejoraban las notas. Cuando se lo retiraron, los que habían usado el chat estándar sacaron un 17% menos que quienes nunca lo tuvieron; en los que usaron la versión con salvaguardas, ese efecto negativo se mitigó en gran parte. Publicado en PNAS en 2025, su conclusión es casi una instrucción para un CTO: las decisiones de diseño del despliegue deciden si se aprende.

Mover el aprendizaje a donde ahora está el trabajo

Con agentes, el trabajo de ingeniería no desaparece: se desplaza. Pasa de escribir código a decir qué tiene que hacer y a comprobar que lo hace. Es la idea de fondo de la especificación como el sitio donde se firma. Si el trabajo se ha movido ahí, el aprendizaje tiene que moverse con él. En la práctica, eso se traduce en tres cambios concretos.

1. El junior escribe la especificación y los criterios de aceptación

Antes de que el agente toque nada, el junior escribe qué debe hacer el cambio, qué casos límite existen y cómo se sabrá que funciona. Un senior la revisa en diez minutos. Es el borrador que antes era el código: obliga a descomponer el problema y a tomar las decisiones que el agente tomaría en silencio. Y tiene una ventaja que el código no tenía: los errores de razonamiento se ven antes de que exista una sola línea. Los criterios de aceptación, además, son los tests que el agente no puede escribir por su cuenta sin describir su propio código.

2. En el review, el autor explica su cambio sin el asistente

Una regla de equipo sencilla: quien abre el pull request es el autor, aunque lo haya escrito un agente, y tiene que poder explicar qué hace el cambio, qué pasa si falla la llamada externa y por qué se descartó la alternativa obvia. Sin abrir el chat. Si no puede, el cambio no está listo, aunque los tests pasen. Son cinco minutos por pull request y convierten el review en lo que era: el sitio donde un junior aprende de alguien con más criterio. También es la forma de detectar el patrón de «delegarlo todo» que el estudio asociaba a las peores notas.

3. Para aprender, el asistente explica en vez de resolver

Las herramientas ya lo permiten. Claude Code trae un estilo de salida llamado Learning: el asistente explica sus decisiones y, cuando llega a una parte con una decisión de diseño real, deja unas líneas marcadas con TODO(human) para que las escriba la persona, y espera. Se activa por usuario o se fija en la configuración del proyecto para todo el equipo. No hace falta usarlo siempre; tiene sentido en las primeras semanas con una tecnología nueva, en un módulo que el junior va a tener que mantener o al depurar un incidente. Con una advertencia que la propia documentación hace: es una instrucción que el modelo sigue, no un control que se garantice. Funciona si el equipo lo quiere usar, igual que las instrucciones compartidas.

Ninguno de los tres cambios frena la entrega de forma apreciable, y los tres refuerzan controles que el equipo necesitaría de todos modos. Es la diferencia entre formar como una actividad aparte, que siempre pierde contra el sprint, y formar dentro del flujo de trabajo, que es la única que sobrevive. Lo veíamos al hablar de por qué las transformaciones se rompen en el mes 6: lo que no está en el proceso no se sostiene.

La lección incómoda: el problema llega en tres años, no ahora

Hay una lectura cómoda de todo esto: si el agente hace el trabajo de junior, contratemos menos juniors. Los datos sugieren que algunas empresas ya lo están haciendo. Erik Brynjolfsson, Bharat Chandar y Ruyu Chen, de Stanford, analizaron las nóminas de millones de trabajadores registradas por ADP, la mayor empresa de gestión de nóminas de Estados Unidos. En septiembre de 2025, el empleo de los desarrolladores de software de 22 a 25 años había caído casi un 20% respecto a su máximo de finales de 2022, mientras el de los perfiles con más experiencia seguía estable o crecía. En el conjunto de ocupaciones más expuestas a la IA, la caída relativa del empleo de entrada era del 16%.

Dos matices honestos. Son datos de Estados Unidos, y los autores lo presentan como evidencia temprana compatible con un efecto de la IA, no como prueba de causalidad. Pero el razonamiento que nos interesa no depende de esa cifra. Todo el modelo de trabajo que defendemos con agentes —especificar, verificar y que una persona firme donde hay riesgo— necesita personas con criterio para firmar. Ese criterio no se compra hecho en el mercado de forma indefinida: alguien tiene que formarlo. Una empresa que deja de formar juniors hoy está decidiendo quién no va a firmar su código en 2030, y lo descubrirá cuando intente contratar seniors y compita con todas las demás que tomaron la misma decisión.

Por eso este no es un tema de recursos humanos, sino de arquitectura del equipo. Lo planteábamos desde la entrada en qué medir al contratar desarrolladores: si el agente resuelve la prueba técnica, lo que hay que evaluar es el criterio. Esta pieza es la continuación: una vez dentro, ese criterio se forma o se atrofia según cómo esté montado el trabajo. Y eso sí depende del CTO.

Preguntas frecuentes

¿Los desarrolladores junior aprenden menos si usan IA?

Depende de cómo la usen. En el experimento controlado que Anthropic publicó en enero de 2026, 52 desarrolladores, en su mayoría junior, aprendieron una librería nueva de Python con y sin asistente. El grupo con IA sacó un 50% en el test posterior y el grupo sin IA un 67%, y la mayor diferencia estuvo en las preguntas de depuración. Pero quienes usaron la IA para preguntar conceptos o pedir explicaciones, y no para delegar el código, conservaron el aprendizaje.

Si la IA hace más productivos a los juniors, ¿dónde está el problema?

En que productividad y aprendizaje se miden en sitios distintos. Los experimentos de campo con GitHub Copilot en Microsoft, Accenture y una empresa del Fortune 100 encontraron un 26% más de tareas completadas, con las mayores ganancias en los perfiles junior y recién incorporados. Eso mide lo que sale hoy. El test de comprensión mide si esa persona podrá revisar y firmar código dentro de unos años. Una empresa puede ganar en lo primero y perder en lo segundo sin enterarse.

¿Hay que prohibir el asistente de IA a los juniors?

No. En los datos de Anthropic, los patrones de uso que preservaron el aprendizaje usaban la IA: pedían explicaciones, hacían preguntas conceptuales o generaban código y después se esforzaban por entenderlo. En el estudio de Bastani y otros con casi mil estudiantes, un tutor con instrucciones pensadas para proteger el aprendizaje mitigó en gran parte el efecto negativo. El problema es el uso sin diseño, no la herramienta.

¿Qué es el estilo Learning de Claude Code?

Es uno de los estilos de salida que trae Claude Code. Con él, el asistente explica sus decisiones y, cuando llega a una parte con una decisión de diseño real, deja unas líneas marcadas con TODO(human) para que las escriba la persona, y espera. Se activa por usuario o se fija en la configuración del proyecto para todo el equipo. La propia documentación avisa de que es una instrucción que el modelo sigue, no un control que se garantice.

¿Cómo se comprueba en el review si el autor entiende su cambio?

Pidiéndole que lo explique sin el asistente delante: qué hace el cambio, qué casos cubre, qué ocurre si falla la llamada externa y por qué se descartó la alternativa obvia. Si no puede, el pull request no está listo, aunque los tests pasen. Es una pregunta de cinco minutos y es la que convierte el review en un momento de aprendizaje y no sólo en un filtro.

¿Están dejando las empresas de contratar desarrolladores junior por la IA?

Hay indicios en Estados Unidos. Brynjolfsson, Chandar y Chen, de Stanford, analizaron nóminas de ADP y encontraron que el empleo de los desarrolladores de 22 a 25 años había caído casi un 20% en septiembre de 2025 respecto a su máximo de finales de 2022, mientras el de los perfiles con más experiencia seguía estable o crecía. Los autores lo presentan como evidencia temprana compatible con un efecto de la IA, no como prueba de causalidad.

Fuentes

• Judy Hanwen Shen y Alex Tamkin (Anthropic), «How AI assistance impacts the formation of coding skills», 29 de enero de 2026, y el artículo completo, «How AI Impacts Skill Formation», arXiv:2601.20245.
• Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng y Tobias Salz, «The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers», versión de febrero de 2025.
• Hamsa Bastani, Osbert Bastani, Alp Sungu, Haosen Ge, Özge Kabakcı y Rei Mariman, «Generative AI without guardrails can harm learning: Evidence from high school mathematics», PNAS 122 (26), 2025 (texto completo en PubMed Central).
• Erik Brynjolfsson, Bharat Chandar y Ruyu Chen, «Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence», Stanford Digital Economy Lab, 13 de noviembre de 2025.
• Documentación de Claude Code, «Output styles».