Cómo pueden los desarrolladores conservar su empleo (1)
Las empresas creen que necesitan menos desarrolladores porque la IA hace el trabajo pesado. Me parece una visión miope, y deberíamos mirarlo más de cerca.
Arquitectura de software
La apuesta que hacen ahora las empresas
Las empresas han concluido que los agentes de programación hacen el trabajo pesado y que, por tanto, necesitan menos desarrolladores. Los recortes golpean con más fuerza a quienes están empezando su carrera:
Un estudio de Stanford concluye que los jóvenes en empleos expuestos a la IA se ven especialmente afectados, mientras que entre las personas con experiencia no se observa ese efecto:
We find no evidence of widespread, economy-wide job displacement. However, employment of young workers (ages 22–25) in AI-exposed occupations now stands 19% below where it would be had it kept pace with that of their less-exposed peers; experienced workers show no comparable gap.
Un estudio de Harvard con 65 millones de empleados apunta en la misma dirección: en los seis trimestres posteriores a la adopción de la IA por una empresa, su contratación de juniors (y no solo de desarrolladores) cayó entre un 9 y un 10 %, mientras que la de seniors se mantuvo estable.
(Algunos artículos muy conocidos en internet hablan incluso de una caída del 67 %, pero esa cifra parece imposible de respaldar, así que no los cito aquí.)
En mi opinión, el comportamiento de las empresas se basa en una falacia: ¿de dónde saldrán los futuros seniors si dejas de contratar juniors y de transmitirles la experiencia?
Lo que produce el vibe coding
Los desarrolladores con menos experiencia entregan ahora software que funciona sin entenderlo. El código se ejecuta, y precisamente por eso el problema sigue siendo invisible. Un análisis de GitClear de 623 millones de cambios de código muestra que, en comparación con la época anterior a la IA, la duplicación de código ha aumentado un 81 % y la reutilización ha caído un 70 %.
Según mi experiencia, la duplicación está lejos de ser el único problema. Supongamos que le digo a Claude Code que me gustaría una aplicación web basada en bun y le describo unas cuantas historias de usuario. Claude genera de verdad algo que hace lo que quiero.
Pero cuando miro el código, la lógica de dominio está mezclada sin ton ni son con el acceso a la base de datos, lo que dispara el esfuerzo de mantenimiento más adelante.
Y entonces llega lo mejor. Si ahora le pregunto a Claude Code si eso le parece bien, responde «en absoluto, deberíamos separar la tecnología de la lógica de dominio» y refactoriza en consecuencia.
Así que, si no hubiera preguntado, este código simplemente habría llegado a producción. Las personas sin experiencia en arquitectura producirán mal código con agentes de IA y no se darán cuenta.
Dos tipos de deuda, no uno
La deuda técnica vive en el código. La deuda de comprensión vive en el equipo: es la brecha entre cuánto código existe y cuánto de él entiende realmente alguien. El segundo tipo es más peligroso, porque ningún panel de control lo mide.
La «deuda de comprensión» (comprehension debt) es un término acuñado por Addy Osmani (antes Director, Google Cloud AI - Gemini, Vertex, Agents). En su artículo, Osmani describe qué ocurre cuando en un sistema existe cada vez más código, pero la parte de él que alguna persona sigue entendiendo de verdad no puede seguir ese ritmo.
Un estudio de Anthropic halló que los desarrolladores que delegaban en la IA mientras aprendían a programar obtenían puntuaciones mucho más bajas en pruebas de comprensión. Eso significaría que a los juniors les conviene resolver a mano unos cuantos problemas difíciles, porque así aprenderían más rápido. Los desarrolladores que usaron la IA como compañera de debate y para que les explicara cosas lo hicieron mejor que un grupo que delegó el trabajo por completo en la IA. Así que importa cómo usas la IA, no solo si la usas.
El día en que saldrá mal
Sobre todo con aplicaciones nuevas y bastante pequeñas, el vibe coding sin una comprensión más profunda no hace ningún daño. Puedes darle a un junior la siguiente receta y llegará bastante lejos con ella:
- Dile al agente de programación qué se necesita
- Deja que genere código hasta que todas las pruebas vuelvan a estar en verde
- Después pídele una revisión a fondo de lo que acaba de generar
- Si la revisión ha encontrado errores o inconvenientes, haz que el agente los corrija
- Repite los pasos 3 y 4 hasta que la revisión solo encuentre problemas calificados como «menores».
- Crea un pull request con los cambios y pásaselo a otra persona.
Eso funciona hasta que llega el primer requisito que contradice la arquitectura existente. En ese momento, alguien tiene que entender todo el sistema, a fin de cuentas, para decidir qué hacer. Puede que esa persona ya no esté en plantilla, porque era alguien con experiencia que entretanto ha dado el siguiente paso en su carrera.
¿Qué hace entonces una empresa así? Simplemente deja que tome las decisiones necesarias quien esté por allí, y la arquitectura empieza a deteriorarse.
La objeción que no pude descartar
Cuando busqué a personas que compartieran esta preocupación, encontré a muchas, incluso muy conocidas. Por ejemplo, Mark Russinovich, CTO, Deputy CISO y Technical Fellow de Microsoft Azure, y Scott Hanselman, VP y Member of Technical Staff en Microsoft/GitHub.
En su artículo para Communications of the ACM sostienen que la IA generativa ha resquebrajado la economía del desarrollo de software, de una forma que el sector todavía no ve del todo.
Pero también encontré a ingenieros serios que dicen que todo el problema se resolverá solo, y sus argumentos son, de hecho, mejores de lo que esperaba. En la siguiente parte de esta serie leerás por qué podrían tener razón. No te la pierdas.