La IA no está matando a los programadores. Está borrando la escalera junior

La IA no está matando a los programadores. Está borrando la escalera junior

La gente sigue preguntando si la IA va a barrer con los programadores en cinco años. Creo que esa pregunta ya va un paso por detrás. Lo más feo está pasando más abajo. No dejo de volver a una escena muy directa del mundo real: una pequeña empresa de software antes armaba una app empresarial rutinaria con una persona de producto, una diseñadora, un par de desarrolladores de interfaz, un desarrollador del lado del servidor y una persona de pruebas. Luego el dueño obligó a la gente senior a empezar a usar IA para las partes aburridas. Los modelos de base de datos salieron rápido. Las rutas CRUD salieron rápido. Las páginas con formularios salieron rápido. Incluso los esqueletos de pruebas salieron rápido. Una porción grande del trabajo junior simplemente desapareció.

Esa es la parte que demasiada gente todavía se niega a decir con claridad. La IA no está matando principalmente la idea de programar. Está atacando el viejo campo de entrenamiento: paneles de administración, herramientas internas, interfaces de programación de relleno, interfaces cargadas de formularios, andamiaje de pruebas, lógica de migraciones y todos esos tickets repetitivos que antes eran molestos pero útiles porque enseñaban cómo funcionan de verdad los sistemas reales. Cuando esa capa empieza a ser devorada por la IA, la profesión no desaparece de la noche a la mañana. La escalera sí.

El viejo camino para principiantes nunca fue glamoroso

Nadie entró al software soñando con construir páginas de configuración de cuenta u otro panel interno de aprobaciones.

Pero así fue como mucha gente aprendió.

Aprendió encargándose de:

  • tickets aburridos
  • arreglos repetitivos de bugs
  • pantallas básicas de alta, edición y borrado
  • reglas de validación
  • conexiones entre sistemas
  • paneles de administración
  • limpieza de tests
  • documentación que nadie quería tocar

Ese trabajo no era impresionante. Seguía siendo valioso.

Permitía que los principiantes cometieran errores en cosas manejables. Les daba repeticiones. Les enseñaba lo desordenado que es el software real una vez que sales de los tutoriales.

Por eso precisamente creo que este momento es tan peligroso. La IA está cayendo con más fuerza sobre la capa menos glamorosa, y esa capa era el sistema de aprendizaje, le gustara o no a la gente.

La economía se vuelve brutal muy rápido

La razón por la que esto se mueve tan deprisa no es que los modelos sean mágicos. Es que la aritmética es brutal.

Si un ingeniero senior puede sacar con una instrucción una primera pasada decente para:

  • un panel interno de operaciones
  • un lote de rutas del sistema
  • un formulario de permisos
  • un script de migración
  • andamiaje de pruebas unitarias

en el tiempo que antes le tomaba a un desarrollador junior acomodarse, hacer preguntas y construir a mano la primera versión, la dirección no ve un debate filosófico. Ve compresión de costos.

Por eso no compro la frase tranquilizadora de que “la IA todavía comete errores”. Claro que sí. Ese no es el umbral que importa. Si la persona senior puede corregir la salida de la IA más rápido de lo que puede acompañar a la persona junior durante el proceso, el puesto junior se vuelve mucho más difícil de defender.

Por eso los equipos pequeños de repente parecen todavía más pequeños

Creo que la gente no ve lo concreto que esto ya es.

Tomemos un proyecto muy normal: un cliente quiere una app web interna con formularios, roles de usuario, reportes e integraciones. Hace unos años, eso significaba entregar una parte de la implementación a juniors porque el trabajo era predecible y consumía tiempo.

Ahora la conversación cambia.

En vez de:

  • “que el junior haga los formularios”
  • “que el junior monte el esqueleto de las conexiones”
  • “que el junior se encargue de preparar los tests”

se vuelve:

  • “que el senior genere la primera pasada con IA”
  • “revisemos la seguridad y la lógica de negocio”
  • “saquémoslo antes con menos gente”

Eso no es teoría. Es un cambio de flujo de trabajo. Y una vez que un flujo de trabajo cambia así, la plantilla cambia con él.

La profesión sobrevive. El carril de entrada no

Esta es la distinción que me gustaría que más gente hiciera.

Seguirá habiendo ingenieros.

Seguirá habiendo bugs duros.

Seguirán existiendo integraciones feas, fallos de seguridad, incidentes en producción, problemas raros de rendimiento, compensaciones de arquitectura, bugs de permisos y reglas de negocio que ningún modelo entiende limpiamente con una sola instrucción.

Pero nada de eso protege el viejo carril de entrada.

Lo que antes era un campo de entrenamiento ahora parece, desde la silla de un gerente, exactamente el lugar donde la IA debería ahorrar dinero primero.

Por eso esto es mucho más duro que la pregunta “¿Van a desaparecer los programadores?”.

No, no de esa manera.

La versión más dura es esta: ¿las empresas seguirán pagando para que los humanos aprendan en trabajos que la IA ya resuelve suficientemente bien?

Esa respuesta se ve mucho peor.

“Simplemente aprende IA” no es una respuesta completa

También creo que mucho del consejo en este espacio es demasiado superficial.

Sí, los desarrolladores nuevos deberían aprender las herramientas.

Sí, negarse a usar IA es estúpido.

Pero “usa IA” no es un plan de carrera por sí solo.

Si lo único que haces es usar IA para ir más rápido exactamente en la capa que el mercado ya está intentando devaluar, no estás escapando del problema. Estás sentado dentro de él.

El valor más seguro se está moviendo hacia arriba:

  • descomponer mejor los requisitos
  • pensamiento sistémico
  • criterio de arquitectura
  • depurar tonterías generadas
  • saber cuándo un código solo parece correcto
  • entender cómo encajan de verdad la lógica de producto y la lógica de negocio

Ese es un listón distinto de “sabe escribir código”.

El riesgo a largo plazo es un colapso del pipeline

Esta es la parte en la que creo que las empresas están entrando dormidas.

Los ingenieros senior no aparecen de la nada. Normalmente salen de años haciendo trabajo más pequeño, más desordenado y repetitivo hasta que la biblioteca de patrones en su cabeza se vuelve lo bastante fuerte como para manejar cosas más difíciles.

Si las empresas vacían esa capa con demasiada agresividad porque el ahorro a corto plazo se ve increíble, quizá descubran más tarde que ahorraron dinero quemando el camino que antes producía a sus futuros seniors.

Ese tipo de error me parece muy creíble.

Encajaría perfectamente con el patrón:

  • celebrar la eficiencia ahora
  • ignorar el problema de formación
  • entrar en pánico después cuando el mercado esté lleno de gente que ha usado herramientas de IA pero nunca ha construido criterio profundo de verdad

Lo que yo le diría a un desarrollador nuevo ahora mismo

Si yo estuviera empezando hoy, dejaría de pensar que la meta es “ser alguien que escribe código”.

Eso es demasiado pequeño.

Apuntaría a convertirme en alguien que pueda:

  • entender el sistema completo
  • detectar dónde el código generado es débil
  • rastrear bugs a través de capas
  • razonar sobre permisos y estados de fallo
  • convertir pedidos vagos en una arquitectura viable
  • usar IA sin confiar en ella a ciegas

Porque el mercado va a pagar menos por salida de código en bruto de lo que pagaba antes. Va a pagar más por la persona que sabe si esa salida es segura, completa y digna de ponerse en producción.

Reflexión final

Así que no, no creo que la IA simplemente “mate a los programadores”.

Creo que primero hace algo más sucio.

Vacía por dentro el trabajo barato, repetitivo y amigable para principiantes que antes enseñaba a la gente a convertirse en programadora en primer lugar.

Por eso la pelea real aquí no es IA contra ingeniería de software.

Es IA contra la escalera junior.

Y si esa escalera colapsa, el daño no va a aparecer solo en los números de contratación de este año. Va a aparecer unos años más tarde, cuando todo el mundo de repente se dé cuenta de lo difícil que es encontrar gente con criterio real.