Cómo pueden los desarrolladores conservar su empleo (2)
Personas conocidas del sector del software han hecho que la advertencia sobre el agotamiento de la cantera de talento llegue a todo el mundo. Estar de acuerdo resulta cómodo. Por eso, la segunda parte de esta serie se toma en serio la postura contraria.
Arquitectura de software
Aquí tienes los enlaces a los artículos de esta serie:
- Parte 1: A qué apuestan las empresas con la IA
- Parte 2: Qué dicen los optimistas y qué pienso yo
- Parte 3: Mis recomendaciones para ti como desarrollador y para ti como líder
Por lo visto no soy el único que ve el problema: el músculo de programar de las personas se debilitará cuanto menos lo usen. La «cantera de RR. HH.» dejará de convertir a juniors en seniors si las empresas se aferran a la idea de no contratar más juniors.
Hace dos años, Charity Majors, cofundadora y CTO de honeycomb.io, señaló la misma trampa en su ensayo en el blog de Stack Overflow. Así que podría limitarme a sentirme reivindicado y disfrutarlo, ¿no? Pero eso sería demasiado fácil.
El argumento de los optimistas
Simon Willison sostiene que entregar peor código con agentes es una elección, y que la refactorización es una tarea ideal para los agentes.
Simon no es un cualquiera: es cocreador del framework web Django. También acuñó el término prompt injection. Defiende la programación agéntica, pero con mirada crítica.
Como yo, Simon traza una línea clara entre dos cosas: el vibe coding, en el que ya no compruebas el código, y el desarrollo responsable asistido por IA. (Por desgracia, mucha gente usa ahora el nombre «vibe coding» también para lo segundo, lo que diluye el término.)
Charlie Graham, fundador, es aún más optimista y va todavía más lejos: la deuda que el modelo de hoy pasa por alto la encuentra el siguiente, así que solo dura unos meses.
La deuda técnica solía ser algo que se acumulaba y superaba rápidamente la capacidad de las personas para refactorizar. Simon y Charlie dicen que la IA ha cambiado esto. Si tienen razón, la crisis que yo predigo sencillamente no llegará.
Hasta dónde tienen razón los optimistas
La duplicación, las funciones demasiado largas, las pruebas que faltan y los nombres incoherentes son problemas locales. Los modelos pueden corregirlos bien hoy en día y cada vez lo hacen mejor. Concedo este punto: mi hipótesis original era demasiado amplia.
Los modelos son buenos en tareas como estas:
1. Unificar código duplicado. Un modelo detecta la misma lógica de validación, ligeramente variada, en cinco controladores y la extrae a una función compartida. Puedes comprobar el cambio archivo por archivo, porque el comportamiento debe seguir siendo el mismo y las pruebas existentes lo demuestran.
2. Dividir funciones demasiado largas. Un método de 300 líneas se divide en pasos con nombre, como comprobar la entrada, calcular y guardar. Para ello, el modelo solo necesita entender esta función y quienes la llaman directamente, no todo el sistema.
3. Añadir las pruebas que faltan. Para una función existente, un modelo escribe pruebas unitarias que cubren el caso normal, los valores límite y los casos de error. Eso funciona bien, porque el comportamiento esperado se puede leer en el propio código, y ejecutar las pruebas muestra enseguida si son correctas.
4. Hacer coherentes los nombres y el estilo. Cuando la misma cosa se llama «customer» en un sitio, «client» en otro y «user» en un tercero, un modelo la renombra de forma coherente en todo el proyecto. Es un trabajo pesado y tedioso en muchos archivos, pero no requiere ninguna decisión de diseño, y los errores aparecen enseguida en el compilador o en el linter.
Lo que tienen en común los cuatro ejemplos: la información necesaria está en el código, y el resultado se puede comprobar automáticamente.
Mi argumento tiene más que ver con la arquitectura: estructuras fundamentales que requieren mucha experiencia, visión de conjunto y criterio, a veces incluso gusto. Eso no se puede deducir de un único punto local del código.
Charlie Graham admite que la mayor parte de la deuda técnica no tiene que ver con la arquitectura:
But most technical debt is not architecture. It is imperfect implementation around an unproven idea. The slightly wrong abstraction. The feature built before anyone knew if users wanted it. The elegant system designed for a scale that never arrived.
Pero supone que los modelos también podrían resolver esto, ya en 2027.
No estoy de acuerdo. Una arquitectura rota no es un archivo desordenado. Es una decisión equivocada. La información que necesitas para corregirla (los próximos requisitos, las restricciones reales, los principios de diseño y evolución) sencillamente no está en el código. Así que una persona con experiencia tiene que decírselo a la IA, o esta no puede saberlo.
Mi hipótesis, ahora revisada
Los optimistas me obligaron a afinar mi hipótesis, y se lo agradezco. En un punto tienen razón: los modelos ya limpian hoy el código duplicado, las funciones demasiado largas y las pruebas que faltan, y cada vez lo hacen mejor. Quien espere la gran crisis aquí, esperará en vano.
Así que mi hipótesis dice ahora: Unos modelos mejores despejarán el desorden local. Pero, por ahora, no decidirán en qué debe convertirse el sistema. La razón es la información que falta. Qué requisitos llegarán el año que viene, qué restricciones son reales y cuáles simplemente se han ido acumulando con el tiempo, qué puede soportar el negocio durante una reconstrucción, etcétera: nada de eso está en el código.
Esa decisión necesita a alguien con criterio que entienda la arquitectura y domine las herramientas. El modelo lleva a cabo la reconstrucción. Una persona tiene que responder de hacia dónde se dirige.
La oferta que se reduce
Si eso es cierto, los ingenieros más valiosos de la próxima década son exactamente aquellos a los que las empresas acaban de dejar de formar. En la siguiente parte: quién gana, en qué podría equivocarme y a qué deberían prestar atención los desarrolladores y las empresas.