De salarios a tokens: ¿Qué pasa cuando la computación se convierte en compensación?

¿Y si parte del salario de un desarrollador dejara de ser dinero… y pasara a ser tokens?

La idea suena futurista.

También suena eficiente. Incluso moderna.

En las últimas semanas, Jensen Huang ha planteado públicamente que los ingenieros podrían recibir presupuestos de tokens muy significativos como parte de su paquete total, llegando a sugerir cifras equivalentes a una fracción muy relevante de su salario.

La idea, tal y como se ha reportado tras GTC 2026 y en entrevistas posteriores, es sencilla: si el acceso a computación multiplica la productividad, ese acceso deja de ser un coste secundario y pasa a convertirse en parte del valor que recibe el trabajador.

A primera vista, la lógica parece impecable.

Si cada vez más trabajo de ingeniería depende de modelos, agentes, copilots y capacidad de inferencia, ¿por qué no tratar esa capacidad como parte de la compensación? Del mismo modo que durante años algunas empresas han competido con salario, bonus, equity o formación, ahora podrían competir también con acceso a computación.

Y, sin embargo, cuanto más lo pienso, más incómoda me resulta la idea.

No porque esté en contra de la IA. Al contrario: nosotros apostamos claramente por ella, la estamos incorporando en nuestro trabajo y vemos que muchos clientes están haciendo lo mismo. Pero precisamente por eso me interesa mirar más allá del titular. Porque aquí no hay solo una innovación en recruiting o una nueva perk para ingenieros. Aquí puede haber un cambio más profundo en cómo se define el valor del trabajo en ingeniería.

Mi tesis es bastante simple: pagar parcialmente a desarrolladores con tokens no es solo una idea nueva de compensación; es un cambio de modelo que mezcla coste operativo, capacidad productiva y valor del talento de una forma que todavía entendemos mal. Y eso importa porque, si normalizamos esa lógica demasiado pronto, podemos terminar rediseñando no solo cómo se remunera a los ingenieros, sino cómo se mide su aportación.

Para mí, hay tres capas que merece la pena explorar: la económica, la profesional y la organizativa. La primera tiene que ver con quién gana poder cuando el acceso a computación entra en la compensación. La segunda, con cómo cambia la forma de evaluar a los desarrolladores. Y la tercera, con la nueva palanca de control que aparece dentro de las empresas.

La capa económica: cuando el acceso a computación deja de ser solo un coste operativo

Lo primero que me parece importante aclarar es que los tokens no son dinero, ni equity, ni un bonus tradicional.

Son acceso a un recurso productivo. Y eso cambia bastante las reglas del juego.

El salario clásico tiene un significado relativamente claro: remunera tiempo, capacidad, responsabilidad, experiencia y mercado. La equity, al menos en teoría, alinea a la persona con la evolución futura de la empresa. Un bonus suele reconocer resultados concretos o incentivar un comportamiento. Pero los tokens no encajan del todo en ninguna de esas categorías. Lo que ofrecen no es valor directo, sino capacidad de producir más dentro de un entorno tecnológico concreto.

Eso, por sí solo, ya es interesante. Pero lo realmente importante es otra cosa: si conviertes ese acceso en parte del paquete de compensación, empiezas a mover una frontera que hasta ahora estaba bastante clara. Históricamente, la computación era un coste operativo de la empresa. El talento era otra cosa. Con esta lógica, ambos mundos empiezan a mezclarse.

Y cuando mezclas coste operativo y compensación, cambias también el terreno de juego económico.

¿Por qué? Porque el token no es una unidad neutral. Está ligado a precios definidos por proveedores, a infraestructuras controladas por terceros y a dinámicas de mercado que todavía son relativamente inestables. Huang no habla de esto en abstracto: lo vincula explícitamente a productividad, inversión masiva en computación y presupuestos crecientes de tokens como una ventaja competitiva para contratar y producir más.

Aquí es donde la idea deja de parecerme inocente.

Porque una cosa es reconocer que el acceso a IA tiene valor. Y otra muy distinta es empezar a construir alrededor de eso una nueva lógica de compensación. En el momento en que el mercado acepta que “estar bien pagado” incluye acceso a compute, estás ayudando a consolidar una economía donde el recurso escaso ya no es solo el talento, sino también la capacidad de consumir infraestructura.

Y eso favorece, de manera bastante obvia, a quien controla esa infraestructura.

No hace falta ponerse conspiranoico para ver la dirección del incentivo. Si los tokens se convierten en una parte reconocida del valor que recibe un ingeniero, entonces su consumo deja de ser un simple gasto interno y empieza a formar parte del lenguaje del mercado laboral. Lo que antes era una línea de coste en la empresa se transforma en parte del “valor percibido” del paquete retributivo. Desde un punto de vista económico, eso es un movimiento relevante.

Además, llega en un momento en el que la adopción de IA va claramente por delante de la claridad sobre sus efectos reales. MIT Sloan ha insistido recientemente en que las empresas deben entender mejor cuándo y cómo encaja la IA generativa frente a otras aproximaciones, y trabajos académicos recientes muestran que los beneficios de productividad existen, pero son heterogéneos y no siempre se traducen en cambios sostenibles o uniformes en la forma de trabajar.

Por eso me cuesta ver esta conversación solo como innovación. También puede leerse como una forma temprana de anclar la economía del token antes de que esté del todo estabilizada.

La capa profesional: cuando el valor del desarrollador empieza a medirse en consumo

La segunda capa es la que más me preocupa a medio plazo.

Si parte de tu capacidad de producir depende del acceso a tokens, entonces la discusión sobre rendimiento cambia. Ya no se trata solo de si resuelves problemas complejos, diseñas bien, entiendes sistemas, tomas buenas decisiones técnicas o colaboras mejor con otros.

Empieza a entrar otra variable: cuánta capacidad de computación puedes consumir y con qué eficiencia la conviertes en output.

Parece una diferencia pequeña, pero no lo es.

Porque en ese momento el trabajo empieza a traducirse en métricas como output por token, coste por funcionalidad, velocidad por presupuesto de inferencia o retorno por consumo de IA. Y en cuanto el lenguaje del rendimiento se desplaza hacia ahí, también lo hace el tipo de profesional que se premia.

No estoy diciendo que optimizar sea malo. Sería absurdo. Parte del trabajo de ingeniería siempre ha consistido en utilizar bien recursos escasos: memoria, CPU, ancho de banda, tiempo, atención, complejidad.

El problema es otro. El problema aparece cuando esa lógica se convierte en el marco principal para evaluar valor.

Ahí el rol empieza a desplazarse.

Poco a poco, el desarrollador deja de ser visto principalmente como alguien que entiende sistemas y toma decisiones bajo incertidumbre, y pasa a verse también como alguien que opera una capa de herramientas para maximizar throughput. Es una diferencia sutil, pero importante. Porque una cosa es usar IA como multiplicador. Otra es que tu valor empiece a definirse por lo eficientemente que conviertes tokens en entregables.

Y todo lo que puede medirse de esa manera tiende a compararse.

Y todo lo que puede compararse tiende a estandarizarse.

Y todo lo que se estandariza corre el riesgo de commoditizarse.

Esa, para mí, es la cadena peligrosa.

Además, aparece una distorsión bastante curiosa en el mercado de talento. Imagina dos ingenieros igual de buenos en dos empresas distintas. Uno trabaja en un contexto con acceso casi ilimitado a modelos, agentes y presupuestos generosos. El otro está en una organización mucho más conservadora, con límites estrictos, aprobaciones, fricción y una economía del token muy contenida.

¿Quién parecerá más productivo?

La respuesta obvia es: probablemente el primero.

Pero entonces la pregunta importante ya no es quién es mejor, sino qué estamos midiendo exactamente. Porque si el output visible depende en parte del contexto de compute disponible, entonces parte del rendimiento deja de ser una propiedad del profesional y pasa a ser una propiedad del entorno.

Esto no invalida el talento. Pero sí lo contamina.

Y ahí es donde la comparación entre desarrolladores se vuelve más confusa de lo que parece. Igual que en otros momentos hemos confundido seniority con familiaridad con cierto stack, o liderazgo con visibilidad, aquí podríamos empezar a confundir capacidad real con presupuesto operativo.

Esa es una mala base para construir mercado, carrera y evaluación.

La capa organizativa: cuando controlar tokens también significa controlar autonomía

La tercera capa es, probablemente, la más sutil.

Y quizá por eso sea la más importante.

Si los tokens pasan a formar parte de la capacidad real de producir, entonces quien controla los tokens controla más que una partida presupuestaria. Controla velocidad. Controla capacidad de exploración. Controla margen de prueba y error. Controla autonomía.

Es decir: aparece una nueva palanca de poder dentro de la organización.

Hasta ahora, si una empresa quería condicionar el trabajo de un equipo, lo hacía con prioridades, presupuesto, headcount, procesos, aprobaciones o incentivos. Todo eso sigue existiendo, por supuesto. Pero ahora se suma algo nuevo: el acceso granular a la capacidad de producir con IA.

No hace falta reducir salario para alterar la realidad del trabajo.

Basta con reducir acceso.

No hace falta decirle a un equipo que ralentice.

Basta con poner fricción computacional.

No hace falta redefinir formalmente el rol.

Basta con crear un entorno en el que experimentar, prototipar o iterar tenga un coste que alguien monitoriza de cerca.

Esto introduce una capa organizativa bastante potente, porque transforma la computación en un mecanismo de gobierno. Y si además esa computación se presenta como parte del paquete de valor que recibe el trabajador, el efecto es todavía más interesante: algo que antes era simplemente infraestructura pasa a vivirse también como un componente de estatus, productividad y capacidad individual.

Eso cambia comportamientos.

Cambia cómo se negocia internamente.

Cambia cómo se distribuye el poder entre equipos.

Y cambia, también, qué tipo de cultura acaba emergiendo alrededor de la IA. Una cultura de exploración amplia y aprendizaje, o una cultura de consumo vigilado y rendimiento medido al detalle.

A mí esa pregunta me parece mucho más importante que la anécdota de si el token entra o no en el paquete retributivo.

Porque, al final, lo que está en juego no es solo la compensación. Es el modelo operativo que viene detrás.

Lo que une las tres capas

Si juntas estas tres dimensiones, el patrón empieza a verse más claro.

En la capa económica, los tokens desplazan parte del lenguaje del valor desde el salario hacia el acceso a infraestructura.

En la capa profesional, el rendimiento empieza a asociarse más fácilmente con consumo eficiente de compute que con criterio, diseño o comprensión sistémica.

En la capa organizativa, el control sobre la capacidad de producir se vuelve una nueva herramienta de dirección y gobierno.

Vistas por separado, cada una de estas capas puede parecer razonable. Incluso útil. Pero juntas dibujan algo más ambicioso: un cambio en la forma de entender el trabajo de ingeniería en un entorno donde la IA no es solo una herramienta, sino una infraestructura mediadora entre la persona y su output.

Y ahí es donde creo que conviene frenar un poco.

No para rechazar la dirección. No para negar que la IA esté cambiando la profesión. No para defender una visión romántica del software.

Sino para evitar que una lógica instrumental termine definiendo demasiado pronto qué es lo valioso del trabajo técnico.

Nosotros estamos viendo, como muchos otros, que la IA ya está aportando valor real en determinados contextos. También estamos viendo que ese valor no es uniforme, que depende mucho del tipo de trabajo, del nivel de la persona, del contexto organizativo y de la calidad de las prácticas que rodean a la herramienta. La literatura sobre productividad con IA va en esa dirección: hay mejoras reales, pero muy heterogéneas, y los resultados dependen mucho del contexto, del tipo de tarea y de cómo se integra la herramienta en el trabajo.

Por eso creo que convertir el acceso a tokens en un elemento normalizado de compensación es, como mínimo, prematuro.

Entonces, ¿qué deberíamos hacer con esta idea?

No creo que la respuesta correcta sea descartarla con cinismo.

Tampoco comprarla sin más porque suena inevitable.

Creo que lo útil es usarla como señal.

Como una forma de observar hacia dónde se está moviendo la conversación sobre trabajo, valor y productividad en la era de la IA.

Porque la pregunta buena no es si los tokens tienen valor. Claro que lo tienen.

La pregunta buena es otra: qué tipo de valor queremos que representen.

¿Un multiplicador operativo? Perfecto.

¿Una capacidad que la empresa pone al servicio de mejores decisiones y más aprendizaje? También.

¿Un criterio para evaluar el worth de un desarrollador? Ahí ya tengo más dudas.

¿Una parte normalizada de la compensación que redefine qué significa estar bien pagado? Ahí creo que merece la pena ser especialmente prudentes.

Antes de asumir esta lógica como una evolución natural del mercado, quizá conviene preguntarnos algo bastante básico: qué estamos optimizando realmente cuando hablamos de talento en ingeniería.

Si la respuesta es solo velocidad, throughput y eficiencia de consumo, entonces probablemente los tokens encajan muy bien.

Si la respuesta incluye criterio, juicio técnico, capacidad de navegar ambigüedad, diseño de sistemas, colaboración y responsabilidad, entonces quizá conviene tener más cuidado con las métricas y las metáforas que elegimos.

Y por eso vuelvo al principio.

La idea de pagar a desarrolladores con tokens suena futurista.

Incluso suena inteligente.

Pero quizá la pregunta importante no es si podemos hacerlo.

Quizá la pregunta importante es qué empieza a pasar con el trabajo de ingeniería cuando decidimos que una parte creciente de su valor ya no se expresa en dinero, ni en autonomía, ni en confianza, sino en acceso medido a capacidad de computación.