Desarrollador de software júnior

Los desarrolladores de software de sistemas ocupan el 7.º puesto por empleo dentro del quintil de mayor exposición en el apéndice del artículo, y el desarrollo de software es una de las dos ocupaciones que los autores destacan como estudio de caso. Registros de nóminas del sector privado de EE. UU. de ADP que cubren a millones de trabajadores, de noviembre de 2022 a junio de 2026. La caída del 11% es para los de 22 a 25 años en los dos quintiles más expuestos a la IA; el mismo grupo de edad en los tres quintiles menos expuestos creció alrededor del 10%. Los trabajadores con experiencia no muestran una brecha comparable, y los autores afirman que no encuentran indicios de un desplazamiento generalizado en el conjunto de la economía. Los hallazgos son descriptivos, no causales, y están medidos a nivel de ocupación, no de tarea.

Cambio verificable en contratación, plantilla, horas o alcance del puesto. El mayor peso, pero la atribución causal sigue habiendo que argumentarla, no darla por supuesta.

Un censo por obligación legal: las mismas 20 preguntas a cada organismo declarante, cada una respondida con S o N, con el producto nombrado y las licencias indicadas por tramos. «Generar código con IA» tiene S en 31 de 45, y los productos nombrados no existían hace tres años. Una S es el empleador declarando que tiene la herramienta, no una medición de cuánto código escribe ni de cuánto se conserva, y un tramo de licencias no es un recuento de personas que escriben código con ella. La pregunta no distingue a un ingeniero con diez años de experiencia de uno con diez meses; este registro se asocia aquí porque escribir código rutinario —endpoints CRUD, formularios, integraciones estándar, pruebas de patrones conocidos— es precisamente esta tarea, no porque el inventario diga algo sobre desarrolladores júnior.

Una empresa lo ha puesto en producción. Puede mover la línea de base, ponderado por la escala y por cuánto se parece ese entorno al tuyo.

Un estándar de ingeniería que obliga a los equipos de software del Ministerio del Interior británico. Dice que los equipos deberían usar la IA donde ayude, que los resultados asistidos por IA deben ser revisados y aprobados por una persona antes de llegar a producción y deben ser trazables, y que los equipos seguirán respondiendo plenamente de todo el código y los resultados asistidos por IA porque las herramientas de IA no pueden sustituir el juicio, la comprensión, la propiedad ni la responsabilidad humanas sobre las decisiones, los diseños o los cambios hechos en los sistemas. El «must» tajante se aplica a la revisión humana; la frase sobre los diseños es una declaración de responsabilidad. Obliga a los ingenieros de un solo ministerio.

Un fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.

Un estudio universitario sobre modelos de lenguaje que redactan especificaciones de requisitos en un proyecto de una consultora de TI, evaluado por el analista experto de la empresa. Un subconjunto de historias de usuario quedó sin cubrir con todos los modelos porque el conocimiento de los analistas puede ser tácito y no estar escrito en los documentos de elicitación; el analista estimó un ahorro del 10% al 15% del tiempo de redacción, y los autores concluyen que los modelos pueden ayudar en la documentación inicial pero no pueden sustituir la intervención humana. Es un proyecto con un experto, y el puesto estudiado es el de analista de requisitos, no el de desarrollador.

Ensayo a pequeña escala en un entorno real. Nos dice que se están probando las condiciones de despliegue, no que se cumplan, así que un piloto nunca basta por sí solo; dos independientes sí.

Una gran empresa tecnológica, con datos declarados por ella misma y sin definir cómo se mide «generado» (autocompletado frente a funciones enteras). No dice nada sobre contratación; el paso de revisión se quedó con los ingenieros.

Una empresa lo ha puesto en producción. Puede mover la línea de base, ponderado por la escala y por cuánto se parece ese entorno al tuyo.

Ingenieros de Google describiendo sus propias herramientas internas. Google asignó al azar al 50% de todos sus desarrolladores a recibir en el IDE correcciones sugeridas por aprendizaje automático para compilaciones rotas y los comparó con el resto durante 11 semanas; después, alrededor del 34% de los usuarios que sufrían una compilación rota en un mes aplicaban esas correcciones, y la reparación de compilaciones con aprendizaje automático se activó para todos los desarrolladores de Google. El desarrollador previsualiza cada corrección y decide aceptarla o rechazarla. Son errores de compilación y de construcción del proyecto — el tipo que la entrada describe como bien entendido —, no fallos en tiempo de ejecución cuya causa está lejos del síntoma; Google vende herramientas de IA para desarrolladores.

Una empresa lo ha puesto en producción. Puede mover la línea de base, ponderado por la escala y por cuánto se parece ese entorno al tuyo.

Esta ocupación tiene la división más marcada entre entrada y sénior de todo el primer lote. Las tareas que hacían económicamente razonable crear puestos júnior son las que se están automatizando, mientras que las que definen el trabajo sénior no. El riesgo no es que programar deje de ser una carrera — es que se está quitando el primer peldaño de la escalera mientras la parte de arriba sigue intacta. En concreto: tienes que demostrar criterio, no producción, y tienes que hacerlo antes de que nadie lo espere de ti.

Tu posición es comparativamente fuerte, pero depende de que haya un suministro de gente que aprendió a juzgar por la vía lenta. Si el peldaño de entrada sigue roto, la restricción que llegará dentro de unos años no es la automatización — es que nadie construyó la experiencia necesaria para revisar lo que producen las herramientas. Conviene pensarlo como una cuestión de contratación y de mentoría ahora, no más tarde.

Quedarte y reforzarte

Construir criterio más rápido de lo que la escalera espera

Lo escaso es alguien capaz de decir si el código generado está bien. Puedes empezar a demostrarlo el primer día en vez de esperar dos años.

Rehacer el puesto

Especializarte donde la corrección sale cara

Pagos, seguridad, integridad de datos, infraestructura — los dominios donde una respuesta equivocada y segura de sí misma cuesta dinero de verdad mantienen a las personas firmemente dentro del circuito.

Movimiento lateral

Puestos que están entre la ingeniería y el problema

Ingeniería de soluciones, experiencia de desarrollador, producto técnico — trabajos donde el valor está en entender a la vez el sistema y lo que alguien necesita de él.

Cambio de sector

Aplicar el pensamiento de ingeniería fuera del software

Muchos sectores casi no tienen a nadie que entienda su dominio y además sepa construir. Esa combinación es escasa y no compite con la generación.

Sí, pero por una razón distinta a la de hace cinco años. Aprender a programar servía para poder producir código. Ahora el valor está en poder juzgarlo — y no puedes juzgar un código que no habrías sabido escribir. La formación sigue funcionando; lo que ha cambiado es que el mercado de empleo de entrada ya no te paga de forma fiable mientras adquieres el criterio. Cuenta con esa brecha de forma explícita en vez de suponer que el primer trabajo te enseñará.

La razón económica por la que existían esos puestos — producción barata sobre trabajo bien especificado — se está debilitando, y eso es un cambio estructural real y no un ciclo. Pero los equipos que dejan de contratar júnior del todo se crean un problema a sí mismos: dentro de unos años no tienen a nadie que haya aprendido a juzgar el resultado por la vía difícil. Cuenta con que el puesto se redefina en torno a la revisión y el criterio en vez de la producción, y con que haya menos por equipo que antes.

La señal para los desarrolladores de entrada no es la capacidad de los modelos, es cuánta gente recién titulada contrata tu empresa. Mira a cuántos júnior contrató este año frente a hace dos. Varias organizaciones que recortaron la entrada de júnior han dicho en público que eliminaron el camino que produce sénior — esa admisión es el hecho que conviene seguir.

Escribir código rutinario — la tarea marcada como en automatización, y la que llenaba los dos primeros años de un júnior. El diseño de sistemas y los requisitos no lo están, pero es a donde se llega después de esos dos años, y nada ha sustituido el camino.

Sí, y por una razón que ha cambiado: ahora aprendes a programar para poder revisar código, no para producirlo. Revisar bien un resultado fluido pero equivocado exige haber escrito tú mismo lo mismo, así que el aprendizaje sigue teniendo que ocurrir por la vía lenta aunque el mercado de ese resultado se haya encogido.