Hace unos meses recibí una llamada que, en retrospectiva, anticipaba exactamente lo que la industria está empezando a discutir en foros académicos y técnicos. Un amigo —CTO de una startup en etapa de crecimiento— me pidió orientación. Su pregunta fue sencilla: "¿Conoces buenos cursos para que mis devs juniors aprendan a programar mejor?"
La historia detrás de esa pregunta no lo era tanto.
El desastre del vibe coding
Su equipo había adoptado con entusiasmo asistentes de programación con IA. Los desarrolladores junior producían código a una velocidad que parecía imposible hace dos años. Features salían en días, no en semanas. Las métricas de productividad se disparaban. Todo parecía ir bien.
Hasta que no lo estuvo.
El código, generado a ritmo industrial, contenía errores sutiles de arquitectura, dependencias circulares, lógica de negocio inconsistente y soluciones que funcionaban en los tests aislados pero fallaban en producción. Los juniors no podían explicar por qué habían tomado ciertas decisiones —porque en muchos casos no las habían tomado ellos—. La IA decidía, ellos aceptaban.
Mi amigo me describió algo que ahora reconozco como un patrón: los juniors estaban produciendo código que no podían mantener, explicar ni corregir. El vibe coding —dejarse llevar por la fluidez de la generación automática— había creado una ilusión de progreso.
Mi consejo fue directo: no necesitas cursos. Necesitas contratar un ingeniero senior que limpie el desastre y ponga orden en esa base de código.
No porque los juniors fueran malos, sino porque el entorno en el que estaban trabajando les impedía aprender. Estaban en modo "pasajero" cuando necesitaban estar en modo "piloto".
El artículo que confirma lo que ya sospechaba
Hace poco leí "Redefining the Software Engineering Profession for AI" de Mark Russinovich y Scott Hanselman, publicado en Communications of the ACM (Volumen 69, Número 4, febrero de 2026). El artículo articula con precisión académica lo que mi amigo vivió en carne propia.
La tesis central es contundente: la IA generativa ha fracturado la economía de la ingeniería de software, creando una estructura de incentivos perversa donde tiene sentido contratar seniors y automatizar juniors. Pero si las organizaciones dejan de contratar desarrolladores en etapas tempranas de su carrera (Desarrolladores Jr), la cadena de talento colapsa. No habrá próxima generación de ingenieros experimentados.
Los autores presentan datos que refuerzan esta preocupación. Tras el lanzamiento de GPT-4, el empleo de personas de 22 a 25 años en trabajos altamente expuestos a la IA —como desarrollo de software— cayó aproximadamente un 13%, mientras que los roles senior crecieron. Un estudio de Harvard titulado "Generative AI as Seniority-Biased Technological Change" confirma que la IA ya está generando una forma de cambio tecnológico sesgado hacia la seniority.
El problema del "becario de IA"
Lo que más me resonó del artículo es lo que Russinovich y Hanselman llaman el "becario de ingeniería basado en agentes": la IA puede producir código que parece correcto pero que contiene errores que solo un ingeniero experimentado puede detectar.
Describen ejemplos concretos donde agentes de IA insertan sleep para ocultar condiciones de carrera, implementan algoritmos ineficientes, duplican código, dejan código de depuración y usan atajos que funcionan en tests específicos pero no generalizan. El agente incluso afirma haber tenido éxito cuando el código tiene errores importantes.
Esto es exactamente lo que le pasó al equipo de mi amigo.
Un junior frente a un agente que dice "¡listo, problema resuelto!" después de parchear un bug con un sleep de 200 milisegundos, no tiene el contexto para cuestionar esa solución. No sabe lo que es una condición de carrera. No entiende por qué ese parche es una bomba de tiempo. Acepta el resultado porque parece funcionar.
Como escriben los autores: "Solo un ingeniero familiarizado con protocolos de sincronización, primitivas de concurrencia y la arquitectura del código puede tener la confianza para señalar los errores del agente y guiarlo en la dirección correcta."
La deuda cognitiva del vibe coding
El artículo también referencia una investigación del MIT de inicios de 2025 que observó "deuda cognitiva" en adultos que usaron ChatGPT para redactar ensayos: menor actividad cerebral y menor retención en comparación con quienes trabajaron sin ayuda.
Esto conecta con algo que he visto repetidamente: cuando los juniors usan la IA como muleta en lugar de como herramienta, no desarrollan intuición. No construyen el juicio que necesitan para evaluar el trabajo de la IA. Como dice Ethan Mollick, citado en el artículo:
"Cada vez que delegamos trabajo a un 'mago', perdemos una oportunidad de desarrollar nuestra propia experiencia; de construir el juicio que necesitamos para evaluar su trabajo."
Los juniors del equipo de mi amigo no estaban aprendiendo. Estaban siendo espectadores de una generación de código que no comprendían.
La solución: preceptoría, no prohibición
Aquí es donde el artículo va más allá del diagnóstico y propone algo valioso. No se trata de prohibir la IA a los juniors —eso sería absurdo e insostenible—. Se trata de diseñar deliberadamente sistemas donde su crecimiento sea un objetivo organizacional explícito.
Los autores proponen un programa de preceptoría donde ingenieros senior guíen a desarrolladores Jr en un ratio de 3 a 5 aprendices por mentor, con la IA funcionando como acelerador de aprendizaje, no como sustituto del mismo.
La idea de un "modo Jr" en los asistentes de programación —que priorice el acompañamiento socrático antes de generar código— es particularmente interesante. En lugar de dar la respuesta directamente, el asistente desafiaría al aprendiz, explicaría su proceso de razonamiento y evaluaría la comprensión con preguntas.
Esto transforma la dinámica completamente. En lugar de un junior que acepta código generado sin entenderlo, tendrías un junior que aprende mientras trabaja con la IA, guiado por un senior que externaliza su criterio como acto deliberado de enseñanza.
Mi conclusión: la llamada que todos deberíamos estar recibiendo
La llamada de mi amigo no fue un caso aislado. Es el canario en la mina de carbón.
Cada startup que reemplaza juniors con agentes de IA, cada empresa que congela contrataciones de nivel inicial porque "la IA ya hace eso", cada equipo que mide productividad en líneas de código generadas sin evaluar si alguien las entiende —todos están acelerando hacia el mismo muro.
El artículo de Russinovich y Hanselman lo dice con claridad: el futuro de la ingeniería de software no estará definido por cuánto código genere la IA, sino por qué tan bien los humanos aprenden, razonan y evolucionan junto a ella.
Mi consejo para mi amigo, dicho meses antes de leer este artículo, era más simple pero apuntaba en la misma dirección: deja de buscar cursos y empieza a invertir en personas que puedan enseñar, no solo producir.
Porque al final, el código que no entiendes no es tuyo. Y el equipo que no puede mantener su propio software no es un equipo de ingeniería. Es una audiencia esperando el próximo truco del mago.
Referencia:
Russinovich, M., & Hanselman, S. (2026). Redefining the Software Engineering Profession for AI. Communications of the ACM, 69(4), 41–44. https://doi.org/10.1145/3779312
No hay comentarios.:
Publicar un comentario