Tokens o salario: ¿cómo medimos el coste del desarrollo de software?

Mi columna de esta semana en Invertia se titula «La próxima nómina será una factura de tokens» (pdf), y trata sobre una de esas transiciones que, como tantas otras en tecnología, tienden a malinterpretarse por completo en sus primeras fases: la evolución del desarrollo de software en la era de la inteligencia artificial generativa, y la manera en que el coste de programar empieza a desplazarse desde la nómina de los desarrolladores hacia la factura de tokens.

La idea parte de una predicción de Gartner que me pareció especialmente significativa: en 2028, el coste mensual de las herramientas de programación con inteligencia artificial podría superar el salario medio global de un desarrollador, algo que InfoWorld comentaba también en un artículo sobre cómo los costes de tokens en programación van camino de rivalizar con las nóminas humanas. La cuestión no es, como tantos titulares simplistas pretenden, que los programadores vayan a desaparecer, sino que el balance económico del desarrollo de software está cambiando de manera mucho más profunda: una parte creciente de lo que antes se contabilizaba como horas de trabajo humano pasa ahora a expresarse como consumo computacional, iteraciones, contexto, agentes y llamadas a modelos.

Llevo tiempo dándole vueltas a este tema, y de ahí que la columna conecte con varias entradas anteriores que he publicado sobre la transformación del papel del desarrollador. En «¿Despedidos o millonarios? La nueva fractura invisible entre desarrolladores» hablaba de esa división creciente entre quienes entienden la inteligencia artificial como una amenaza y quienes la convierten en una extensión de sus capacidades. En «El programador que dejó de programar: anatomía de una transformación» analizaba precisamente esa mutación del trabajo: menos teclear código y más diseñar, revisar, interpretar, decidir y asumir responsabilidad sobre sistemas que generan código. En «La nueva realidad de la programación y de la educación: inteligencia artificial, de trampa a requisito» planteaba la necesidad de dejar de tratar estas herramientas como una forma de hacer trampas y empezar a entenderlas como una competencia básica. Y en «Una factura de quinientos millones de dólares en tokens» abordaba ya el problema del coste oculto de esa supuesta magia, o de la estupidez que supone incentivar incondicionalmente el consumo de tokens.

El desplazamiento es interesante porque obliga a replantear la naturaleza misma de la productividad. Durante años, muchas empresas han medido la productividad del desarrollo de software con métricas tan cómodas como engañosas: líneas de código, historias cerradas, tickets resueltos o velocidad de entrega. Con la inteligencia artificial, esas métricas se vuelven todavía más peligrosas. Generar código es cada vez más barato, rápido y abundante. El problema es que generar más código no equivale necesariamente a generar más valor. De hecho, puede equivaler a generar más deuda técnica, más superficie de ataque, más dependencia de proveedores y más complejidad que alguien tendrá que entender, auditar y mantener.

Ahí está, en mi opinión, el cambio fundamental: el cuello de botella deja de estar en la escritura y pasa a estar en la validación. El desarrollador valioso ya no es simplemente quien sabe producir código correcto, sino quien sabe formular bien el problema, elegir qué debe automatizarse y qué no, limitar el contexto, evaluar el resultado, detectar errores plausibles y decidir cuándo una solución aparentemente brillante es en realidad una bomba de relojería. El código se abarata, el criterio se encarece.

Esa idea aparece también en otros trabajos recientes. La encuesta de Stack Overflow sobre inteligencia artificial muestra cómo los desarrolladores adoptan estas herramientas, pero también cómo mantienen reservas importantes sobre su precisión y fiabilidad. El informe DORA de Google Cloud insiste en que la productividad del software no puede entenderse simplemente como velocidad, sino como un equilibrio entre entrega, calidad, fiabilidad y cultura organizativa. McKinsey ha analizado el potencial de la inteligencia artificial generativa para aumentar la productividad de los desarrolladores, pero sus propios resultados apuntan a algo que conviene no olvidar: el impacto depende mucho del tipo de tarea, del contexto y de la capacidad de la organización para rediseñar procesos, no simplemente de enchufar una herramienta y esperar milagros.

También me pareció relevante un estudio de GitLab sobre organizaciones que generan código con inteligencia artificial más deprisa de lo que son capaces de controlarlo. Esa frase resume muy bien el riesgo: empresas encantadas con la velocidad de generación, pero incapaces de construir los mecanismos de revisión, seguridad, gobernanza y trazabilidad que esa velocidad exige. La inteligencia artificial puede convertir a un buen equipo en uno extraordinariamente productivo, pero también puede convertir a una organización mediocre en una fábrica de pasivos ocultos.

La comparación con los directivos me parece inevitable. Microsoft ha hablado del auge de los agentes y de cómo las organizaciones tendrán que rediseñar la relación entre personas y sistemas autónomos, mientras McKinsey ha señalado el papel de los mandos intermedios en la adopción de la inteligencia artificial generativa. En el fondo, desarrolladores y directivos se enfrentan a una evolución parecida: ambos pasan de hacer determinadas tareas directamente a dirigir sistemas que las hacen. La diferencia entre unos y otros no estará en quién usa más inteligencia artificial, sino en quién sabe gobernarla mejor.

Por eso me interesa tanto esta transición. No estamos ante una simple sustitución de humanos por máquinas, sino ante una redistribución de costes, responsabilidades y competencias. El que piense que basta con despedir desarrolladores y pagar tokens no ha entendido nada, y se va a llevar un suspenso como la copa de un pino… pero no se lo pondré yo, se lo pondrá la vida. Igual que pensar que basta con mantener a todos los desarrolladores haciendo exactamente lo mismo de siempre. La empresa que entienda esta transición aprenderá a gestionar los tokens como un recurso escaso, a medir valor en lugar de actividad, a formar a sus equipos para trabajar con agentes y a distinguir entre automatización sensata y entusiasmo irresponsable.

La programación no se acaba. Se vuelve más abstracta, más estratégica y, paradójicamente, más humana en aquello que realmente importa: criterio, responsabilidad, arquitectura, comprensión del problema y capacidad para decir que no. Lo que se acaba, probablemente, es una determinada idea del programador como simple productor de líneas de código. Y lo que empieza es una etapa bastante más interesante, en la que el verdadero diferencial no será quién genera más software, sino quién sabe qué software merece la pena generar.