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.
This article is also available in English with no paywall on my Medium page, «The scale is tipping: human hours vs. machine tokens»
Me parece fabuloso. Pero en el camino ya fueron despedidos miles de programadores. Me pregunto si los recolocarán en otra parte.
Como siempre digo, menos mal que aprendí a instalar paneles solares… eso van a tardar mucho los robots en sustituirme (¡y ni tanto! hahaha)
Creo que le otorgas un papel muy simplista al programador, como si fuéramos simples generadores de líneas aleatorias de instrucciones.
El Analista dice de qué partimos y qué quiere conseguir, lo de en medio es casi magia generada por el programador. Puede ser basura o no, puede funcionar, funcionar bien o funcionar óptimamente.
Y desde luego que el programador entiende perfectamente el problema, de lo contrario no sería muy diferente de un chimpancé aporreando un teclado.
El programador nunca ha sido un simple productor de líneas de código.
Cualquiera que haya programado sabe que diez programadores generarán diez códigos diferentes. El estilo de cada programador se plasma en el código casi tanto como si fuera un novelista. Todo el que haya modificado código de terceros sabe que muchas veces cuesta más corregir que rehacerlo todo de nuevo a tu propio estilo.
Así que no sólo estamos añadiendo carga de trabajo a ese nuevo súper-analizador de código, también le va a costar mucho más analizar código no generado por él mismo.
¿De dónde van a salir esos súper-analizadores si se corta la cadena por la base eliminando a los programadores?
Como de costumbre, destila usted un optimismo exagerado pero, como dice Benji, las listas del paro se seguirán llenando de programadores, y dentro de veinte años ya nadie sabrá qué demonios dice eso que escupe la IA-programadora. Quién sabe, quizás para entonces programen en un lenguaje inventado por ellas o, directamente, en código máquina. Y que levanten la mano los ingenieros de software que sean capaces de analizar un ERP programado así.
KBOOOUM…!!!
Solo hay un “pero”… y lo he comentado en diversas ocasiones. Llevamos un par de años leyendo noticias de “tal empresa a largado a 5.000 programadores”… “cual empresa a largado a 10.000…”, 25mil, 30mil… y en poco menos de dos meses, esas mismas empresas están recontratando a esa gente de la que se deshicieron… Los despidos despiertan titulares, las recontrataciones, apenas unas líneas.
Porque esta muy bien que una IA te ayude. No hay problema en ello. El problema, es cuando se plantea la “sustitución”. Y el añadido, el momento de mantener ese código hecho por IA, generalmente por juniors, los mismos que la han usado para crearlo y que no saben por dónde navegan. Eso a los seniors, los que “largan a la calle”, no les pasa…
Mi sensación, es que actualmente al usar los modelos de IA en cualquier tarea, tanto los gratuitos como los de pago, estamos quemando de forma despreocupada una enorme cantidad de dinero. Dinero que inversores y fondos aportan a paladas, en una carrera enloquecida entre ellos, esperando un retorno futuro. ¿Que pasará cuando el coste de desarrollo con ayuda de un modelo de IA se ajuste a lo real, p.e. cuando Antropic deba repercutir en el usuario el coste de desarrollo y de inferencia de claude?
Justo lo que iba a decir. Bien puede pasar que el kilo de carne sea más barato que el kilo de silicio, y toda esta discusión se esfume de golpe en la historia.
Pensé que no tendría por donde agarrarme, pero apareció una línea de «código» y me lancé a ella.
«El problema es que generar más código no equivale necesariamente a generar más valor.» (EDANS).
Le quitamos la palabra código y buscamos muchas otras que pueden ser equiparables, por ejemplo, absorber conocimientos (de forma racional y emocionalmente positiva), en vez de simplemente adsorberlos. Porque lo que se adsorbe en clase , ya se olvida una vez que se sale del aula o se acaba el examen (si está más adherido).
Por eso el trabajo del profe tiene tanto de establecer conexiones mentales, que nunca pueden estar bien aseguradas. Especialmente cuando el personal no sabe de la importancia que tiene distinguir una «b» de una «d». Y, aún más, si no sabe retroalimentar su trabajo diario. Como ocurre en muchos otros trabajos profesionales.
Y, por supuesto, le damos a la palabra valor su justo sentido humanista.
Creo que hay otra derivada interesante que quizá comentamos menos: no solo cambia el coste del desarrollo dentro de una empresa, también cambia la escala mínima necesaria para crear software competitivo.
Tendemos a analizar este tema pensando en grandes compañías, plantillas de programadores, nóminas, despidos, reorganizaciones y facturas de tokens. Todo eso es importante, claro. Pero la IA también está abriendo otro escenario: el de profesionales o microequipos que, con suficiente criterio, conocimiento del problema y capacidad de validación, pueden construir productos que antes habrían exigido una estructura mucho mayor.
En mi caso lo estoy viviendo con Live Aula, una plataforma para convertir documentación en cursos interactivos con IA. No es que la IA “programe sola”, ni mucho menos. El trabajo sigue estando en definir bien el producto, entender al cliente, decidir qué merece la pena automatizar, revisar lo generado, corregir, probar, simplificar, mantener y asumir la responsabilidad final. Pero la diferencia es que muchas tareas que antes bloqueaban durante semanas ahora pueden iterarse en horas o días.
Por eso me parece muy acertada la idea de que el código se abarata y el criterio se encarece. La cuestión no es solo si una empresa sustituirá salario por tokens, sino qué nuevos tipos de empresa o producto pueden surgir cuando una sola persona motivada puede operar con una capacidad técnica que antes estaba reservada a equipos completos.
Esa es, creo, una de las transformaciones más profundas: no simplemente producir más software más barato, sino reducir drásticamente el umbral de entrada para que más gente pueda convertir conocimiento experto en producto.
Lo próximo coste para el programador será el lector de mentes que ha sacado Meta, con este invento se consigue hacer código sin pisar teclas…
https://x.com/AIatMeta/status/2071566924803395741
COROLARIO: Me imagino a Enrique usando el casco y la IA negándose a transcribir al ordenador….
PS: Al menos Meta no te taladra el cerebro como los de Neuralink…
Mi predicción va en dirección contraria a la mencionada de Gartner porque lo que hace básicamente es mirar la tendencia reciente y extrapolarla unos años vista, sin tener en cuenta muchos factores que frenarán ese crecimiento, entre ellos (ni menciona) la opción de la gestión local de modelos abiertos.
Yo creo que a medio plazo las empresas correrán en local modelos abiertos gratuitos y suficientemente potentes para la mayoría del trabajo de sus desarrolladores: las mejoras que estamos viendo en modelos abiertos, técnicas de inferencia y hardware especializado me llevan a pensarlo. Y las ventajas son evidentes: menores costes (tras la inversión inicial) y privacidad total.
Además es lo más coherente con la idea de que el modelo no va a ser lo importante sino la arquitectura, el ecosistema y los bucles de retroalimentación, cuestiones mucho más específicas de cada implementación que casi nada tienen que ver los los tokens.
Y en cuanto a si harán falta programadores, lo que he dicho en anteriores ocasiones: las necesidades de aplicaciones y funcionalidades son infinitas, solamente el coste lo ha estado limitando: reduce el coste de desarrollo y aumentarán las necesidades y requisitos. A un nivel de abstracción mayor pero los desarrolladores seguirán haciendo falta para decidir qué, cómo y verificarlo todo.
Yo soy de los que llevan tiempo diciendo, que la IA será local o no será… Pero me temo, que de eso, ya se han dado cuenta, los vendors de IA, los fabricantes de hardware, etc… y por ello, como dije no hace mucho, la IA local, se va a ir al garete, con la acumulación de fabricación de RAM y SSD para los Bigs, y el inflado de precios para los de la calle.
Aquí la estrategia pasa porque no puedas hacer nada en local, y pases por la suscripción sí o sí. Si te corto las alas, tendrás que viajar conmigo… y en ello estamos. No hay mas que ver las tarifas de distribuidores de pc y como 16Gb/32Gb han triplicado su precio, así como los SSD. Yo ya he hecho acopio, a precios desorbitados, y veremos si pierdo pasta… o no.
Hace un par de meses mínimo que no vengo y venía pensando en encontrarme un artículo. Supongo que será el de mañana.
Supongo que Enrique tocará el tema porque marca un antes y un después histórico y aquí se puede ver si la decisión será correcta o no. Playstation sin juegos físicos.
Se habla de la burbuja inmobiliaria pero la del videojuego…