Desarrollador de software júnior

Endpoints CRUD, formularios, integraciones estándar, pruebas de patrones conocidos.

Encontrar por qué algo se rompió cuando la causa no está donde está el síntoma.

Leer código plausible con el cuidado suficiente para cazar lo que está equivocado con aplomo.

Hacer las preguntas que revelan qué habría que construir de verdad.

Elegir una estructura y unos compromisos que sigan en pie dentro de dos años.

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.

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.

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.