Un junior con IA no se convierte automáticamente en arquitecto
14 octubre 2026
La asistencia de inteligencia artificial elimina la barrera de escribir código, no la de saber qué código debería escribirse. Un perfil junior con un buen asistente produce mucho más volumen que antes, y sigue sin poder evaluar si la estructura que está generando aguantará tres años, si el modelo de datos soporta el caso que aparecerá el trimestre próximo o si esa integración se romperá cuando cambie el otro sistema.
Eso no es un demérito. Es la definición de la experiencia: haber visto suficientes consecuencias como para anticiparlas.
McKinsey lo midió con precisión en su encuesta global de 2025: el factor que más correlaciona con impacto en EBIT es haber rediseñado de forma fundamental los flujos de trabajo, y solo el 21% de las organizaciones que adoptaron IA generativa lo había hecho. Las empresas de alto rendimiento tienen alrededor de tres veces más probabilidad de haberlo acometido.
Es, con diferencia, la conclusión más accionable de todo el ciclo.
Qué se aprende haciendo y qué no
El criterio técnico no se adquiere leyendo, sino observando el resultado de decisiones propias a lo largo del tiempo. Se aprende que una abstracción prematura complica más de lo que ahorra porque uno la construyó y la sufrió. Se aprende dónde poner una frontera entre módulos porque una vez se puso mal y costó seis meses.
Aquí aparece el riesgo real de este momento: si el asistente toma esas decisiones, el ciclo de aprendizaje se interrumpe. El profesional obtiene el resultado sin haber hecho el razonamiento, y el razonamiento era el aprendizaje.
El estudio de METR de 2025 apunta a un fenómeno relacionado. En un ensayo con desarrolladores experimentados sobre tareas reales, los participantes tardaron un 19% más usando IA, mientras creían haber ido un 20% más rápido. La propia METR revisó después ese diseño por posibles sesgos y una cohorte mayor arrojó una diferencia menor, así que la magnitud está en discusión. Lo que se sostiene es el desacoplamiento entre percepción y realidad: si los profesionales con experiencia se equivocan al juzgar su propio rendimiento, quienes carecen de referencias previas tienen aún menos criterio para detectarlo.
Lo que sí cambia, y es mucho
Sería un error leer esto como que nada ha cambiado. Ha cambiado bastante:
La curva de entrada es más corta. Un junior es productivo antes, porque la sintaxis y las tareas mecánicas dejan de ser el obstáculo.
El acceso a dominios nuevos es más rápido. Explorar una tecnología desconocida cuesta horas en lugar de semanas.
El trabajo tedioso desaparece. Menos tiempo en configuración, plantillas y transformaciones repetitivas; más tiempo disponible para pensar.
La pregunta es más barata. Consultar cómo funciona algo ya no implica interrumpir a un compañero, lo que reduce la fricción del aprendizaje autónomo.
El potencial es real. Lo que hace falta es una estructura que convierta ese potencial en criterio en lugar de en volumen.
El obstáculo real nQué distingue realmente a un perfil senior o es técnico
Capacidad | Junior con asistencia | Perfil senior |
|---|---|---|
Producir código | Alta | Alta |
Elegir entre alternativas | Limitada: acepta la primera que funciona | Compara coste de cambio futuro |
Anticipar consecuencias | Baja: falta experiencia acumulada | Reconoce patrones vividos |
Decir que algo no debe construirse | Poco frecuente | Es parte del trabajo |
Decidir fronteras entre sistemas | No | Sí |
La cuarta fila es la más valiosa y la menos visible en cualquier métrica. Un profesional con criterio dedica una parte importante de su tiempo a evitar trabajo: descartar funcionalidades que añaden complejidad sin valor, señalar que una regla ya existe, proponer una solución de una décima parte del tamaño.
Ese trabajo no aparece en ningún indicador de productividad, y es donde se concentra buena parte del valor de la experiencia.
Cómo formar criterio en este contexto
Cuatro prácticas que funcionan y no requieren estructura adicional:
Exigir la explicación, no el resultado. Antes de fusionar, que la persona explique por qué está así y qué alternativa descartó. Es la regla que desarrollamos en el código que nadie entiende es deuda [enlace interno].
Hacer visibles las consecuencias. Cuando algo falla en producción, revisar qué decisión lo causó y cuándo se tomó. El bucle entre decisión y consecuencia es donde se forma el criterio, y suele estar roto porque quien decide no está cuando se paga.
Revisar decisiones, no líneas. Una sesión sobre por qué se eligió esta estructura vale más que veinte comentarios sobre estilo.
Rotar por el mantenimiento. Quien mantiene lo que otros construyeron aprende en semanas lo que de otro modo tardaría años en ver.
La consecuencia para las empresas
Hay una tentación presupuestaria evidente: si los perfiles junior producen más, se puede reducir la proporción de perfiles senior. A corto plazo el volumen entregado lo confirma; a medio plazo aparecen los síntomas conocidos —cambios que tardan cada vez más, módulos que nadie quiere tocar, estimaciones poco fiables.
La consecuencia práctica es la contraria: cuando el volumen de código crece, el criterio escasea más. La proporción de revisión y diseño debería subir, no bajar.
Para muchas empresas medianas eso no significa contratar una plantilla senior completa. Significa asegurar criterio continuado sobre las decisiones que importan, que es el papel de un CTO externo o comité técnico asesor [enlace interno]: alguien que revisa arquitectura, acompaña al equipo y participa en las decisiones difíciles sin necesidad de estar a tiempo completo.
La pregunta para el próximo comité
Si la organización está entregando más que nunca, conviene hacer una comprobación sencilla: ¿cuántas decisiones de arquitectura se han tomado explícitamente este trimestre, y quién las tomó?
Si la respuesta es que se han tomado muchas y nadie las recuerda, no se están tomando: se están aceptando. Y aceptar decisiones de arquitectura es exactamente lo que se paga tres años después.
Preguntas frecuentes
¿La IA convierte a un desarrollador junior en senior?
No. Elimina la barrera de escribir código, no la de saber qué código debería escribirse. La experiencia técnica consiste en anticipar consecuencias a partir de decisiones propias observadas a lo largo del tiempo, y eso no se adquiere obteniendo el resultado sin haber hecho el razonamiento.
¿Qué distingue a un perfil técnico senior de uno junior con asistencia de IA?
La capacidad de comparar alternativas según su coste de cambio futuro, de anticipar consecuencias por patrones vividos, de decidir fronteras entre sistemas y, sobre todo, de argumentar que algo no debe construirse. Producir código ya no es un factor diferencial.
¿Qué riesgo tiene para la formación técnica el uso intensivo de asistentes?
Que se interrumpa el ciclo de aprendizaje: si el asistente toma las decisiones de diseño, el profesional obtiene el resultado sin haber hecho el razonamiento que constituía el aprendizaje. El bucle entre decisión y consecuencia es donde se forma el criterio.
¿Cómo se forma criterio técnico en un equipo que usa IA?
Con cuatro prácticas: exigir la explicación de por qué el código está así y qué alternativa se descartó, revisar qué decisión causó cada fallo en producción, dedicar las sesiones de revisión a decisiones en lugar de a estilo, y rotar a las personas por el mantenimiento de lo que otros construyeron.
¿Conviene reducir la proporción de perfiles senior si los juniors producen más?
No. Cuando crece el volumen de código, el criterio escasea más, no menos: la proporción de revisión y diseño debería aumentar. A corto plazo el volumen entregado sugiere lo contrario, pero a medio plazo aparecen cambios cada vez más lentos y módulos que nadie quiere tocar.
¿Qué alternativa existe si no se puede contratar una plantilla senior completa?
Asegurar criterio continuado sobre las decisiones que importan mediante un CTO externo o un comité técnico asesor: revisión de arquitectura, acompañamiento al equipo y participación en las decisiones difíciles, sin necesidad de dedicación a tiempo completo.
¿Quién toma las decisiones de arquitectura en tu equipo? Nuestro CTO externo aporta criterio senior uno o dos días por semana: revisión de arquitectura, supervisión del equipo y las decisiones que no conviene improvisar. Hablemos → |
Español 