Los desarrolladores chinos compran acceso a tokens para trabajar, pero la afirmación sobre seguridad laboral no está probada

Según informes, desarrolladores chinos están comprando acceso a tokens para trabajar, aunque la afirmación viral de que deben pagar para proteger sus empleos sigue sin verificarse.

La acusación llegó a Zhihu el 15 de agosto de 2026. Describía a programadores que pagan mensualmente por el uso de IA para mantener su empleabilidad, una práctica presentada como pagar por trabajar. La página no identificaba a ningún desarrollador, empleador, contrato, política de reembolso ni amenaza documentada de despido.

Esa falta de evidencia importa. Una suscripción personal puede reflejar experimentación, comodidad o la negativa de un empleador a financiar la infraestructura necesaria. Solo la última situación respalda la versión más contundente de la afirmación.

Sin embargo, la controversia no surgió de la nada. Los desarrolladores utilizan más agentes de programación con IA, las empresas celebran el alto consumo y los costes informáticos se vuelven visibles a nivel individual. El conflicto ya no enfrenta simplemente a trabajadores y automatización. Enfrenta las expectativas de los empleadores con su responsabilidad.

Lo que realmente establece la afirmación viral sobre los tokens

La evidencia disponible respalda una controversia sobre costes laborales, no un caso verificado de desarrolladores que compran seguridad laboral.

La pregunta de Zhihu presenta una inquietante cadena causal. Los programadores necesitan IA para cumplir expectativas de producción cada vez mayores. Presuntamente, los empleadores se niegan a cubrir suficiente uso. Los trabajadores compran entonces capacidad adicional porque quedarse atrás amenaza su empleo.

La secuencia es plausible, pero la plausibilidad no equivale a verificación. La pregunta pública no aporta registros de nóminas, documentos de políticas internas, facturas ni testimonios vinculados a una empresa identificada. Tampoco establece si se ordenó a los trabajadores utilizar herramientas de pago.

Un informe del 18 de julio sobre presupuestos corporativos de tokens ofrece el contexto subyacente más claro. Describía cómo empresas tecnológicas chinas trataban el consumo de IA como un nuevo recurso laboral. Algunos empleadores asignaban acceso, mientras los ingenieros discutían asignaciones de tokens junto con el salario y otras prestaciones.

Un token es una pequeña unidad de texto procesada o generada por un modelo de IA. Los agentes de programación pueden consumir grandes cantidades porque inspeccionan repetidamente repositorios, generan cambios, ejecutan pruebas, leen errores y revisan su trabajo.

Esto significa que una sesión de programación con agentes no es una simple pregunta. Es una cadena de llamadas al modelo, que a menudo incluye archivos fuente extensos y razonamiento repetido. Por tanto, un trabajo más autónomo puede generar más uso, incluso cuando el cambio final en el código parece pequeño.

La distinción entre acceso financiado por la empresa y acceso pagado por el trabajador es fundamental. Una cuenta personal voluntaria se parece a que un empleado elija su teclado preferido. Un acceso obligatorio y no reembolsado se parece a que un empleador pida a un trabajador que proporcione infraestructura de producción.

También existe una categoría intermedia. Algunas empresas proporcionan un asistente aprobado, mientras los desarrolladores compran otro porque resuelve mejor sus tareas. Esa elección puede ser voluntaria al principio, pero luego resultar difícil de abandonar cuando los directivos incorporan la velocidad resultante a los plazos.

La afirmación viral comprime esos distintos acuerdos en una frase dramática. Eso hace que la pregunta sea útil como advertencia, pero poco fiable como prueba de una práctica laboral generalizada.

Aun así, es significativo que la acusación pareciera lo bastante creíble como para convertirse en un debate destacado. La reacción revela cuán rápido el acceso a la IA ha pasado de ser una experimentación opcional a una condición informal de competitividad profesional.

El acceso a tokens está convirtiéndose en parte del trabajo

La capacidad de programación con IA empieza a funcionar como infraestructura laboral, incluso cuando las políticas empresariales todavía la tratan como una preferencia personal de productividad.

JetBrains encuestó a más de 10.000 desarrolladores profesionales en enero de 2026. Su encuesta sobre IA para desarrolladores concluyó que el 90 por ciento utilizaba regularmente al menos una herramienta de IA para programar y realizar trabajo de desarrollo.

La misma investigación reveló que el 74 por ciento había adoptado una herramienta especializada para desarrolladores, en lugar de depender únicamente de un chatbot generalista. GitHub Copilot siguió siendo el producto especializado más utilizado. Claude Code y Cursor compartieron la siguiente posición en adopción en el lugar de trabajo.

Estas cifras no muestran quién pagó. Sí muestran que el desarrollo asistido por IA ya no es una práctica poco común limitada a los primeros adoptantes.

Una encuesta anterior de GitHub llegó a una conclusión similar a partir de una muestra diferente. Abarcó a 2.000 trabajadores de software empresarial en cuatro países. Más del 97 por ciento afirmó haber utilizado herramientas de programación con IA en el trabajo en algún momento, según los datos publicados sobre uso empresarial.

El apoyo de las empresas fue menos uniforme. Según el país, entre el 59 y el 88 por ciento afirmó que su empleador permitía o fomentaba activamente el uso de IA. Esto deja una brecha importante entre la adopción y el respaldo institucional.

Un empleador puede decir que el uso de IA está permitido sin proporcionar licencias, presupuestos de uso, controles de seguridad, formación ni estándares de evaluación. El permiso transfiere poco riesgo fuera del trabajador.

La presión se intensifica cuando los directivos revisan las expectativas tras ver resultados asistidos por IA. A un desarrollador que antes completaba una tarea en varios días ahora se le puede pedir que la termine antes. El nuevo plazo puede mantenerse incluso si se agota una asignación gratuita o deja de estar disponible el modelo preferido.

Esto crea un efecto trinquete. Las ganancias temporales se convierten en expectativas permanentes, mientras el coste de la herramienta sigue siendo variable. Los trabajadores se enfrentan entonces a una elección entre pagar personalmente, aceptar un rendimiento aparentemente menor o intentar ocultar la limitación.

La dinámica es especialmente intensa para candidatos a empleo, contratistas y empleados bajo evaluación de desempeño. Tienen menos margen para cuestionar un mandato de productividad y más motivos para tratar el gasto en herramientas como una medida defensiva.

El acceso a la IA también puede determinar qué tareas acepta un empleado. Un desarrollador con un agente de programación competente puede explorar una base de código desconocida, redactar pruebas y traducir entre lenguajes con mayor rapidez. Un colega con acceso limitado puede evitar el mismo trabajo, incluso cuando ambos poseen un criterio de ingeniería comparable.

Eso no significa que el desarrollador mejor financiado sea intrínsecamente más competente. Significa que la organización ha permitido que el poder adquisitivo influya en el rendimiento medido.

Las empresas ya reconocen este principio para entornos de nube, dispositivos de prueba, compiladores y sistemas de observabilidad. Rara vez esperan que los empleados financien bases de datos de producción porque utilizar mejor infraestructura los hace más competitivos.

Tratar la IA de manera distinta se vuelve más difícil a medida que los agentes se integran más en el desarrollo rutinario. Si se espera la herramienta, se monitoriza su uso o se refleja en los objetivos de entrega, el acceso es un insumo empresarial.

Este es el primer problema sectorial que expone la controversia. Las empresas están operacionalizando las expectativas de IA más rápido de lo que definen quién asume la factura, la cuenta, los datos y la responsabilidad resultante.

Por qué el gasto en tokens es una mala métrica de productividad

El consumo de tokens mide actividad computacional, no valor para el cliente, calidad de ingeniería ni trabajo completado.

El entusiasmo corporativo ayudó a convertir el consumo en un símbolo de estatus. Los ejecutivos promovían un uso intensivo como prueba de que los trabajadores adoptaban la IA. Según informes, algunas organizaciones realizaron campañas o competiciones internas en torno al consumo.

La lógica parece intuitiva. Si los agentes hacen más productivos a los trabajadores, entonces los empleados que ejecutan más agentes deberían generar más valor. Sin embargo, cada paso de ese argumento requiere evidencia que un panel de uso no puede proporcionar.

Un mayor consumo puede significar que un agente resolvió una tarea complicada. También puede significar que el prompt carecía de contexto, que el modelo eligió un camino deficiente o que el usuario corrigió repetidamente resultados débiles. Dos desarrolladores pueden llegar al mismo resultado con cantidades de procesamiento muy distintas.

El uso incluso puede aumentar cuando la productividad disminuye. Un agente puede generar archivos innecesarios, complicar en exceso un parche o explorar una solución irrelevante. Cada intento adicional suma actividad mientras crea más trabajo de revisión.

The Associated Press informó el 27 de julio que el entusiasmo corporativo en torno a los límites del tokenmaxxing estaba dando paso al escrutinio de costes. Las empresas estaban descubriendo que un mayor consumo de IA no producía automáticamente ganancias comparables.

Ese giro debilita la idea de que un empleado deba maximizar personalmente el uso. Si las propias empresas no pueden conectar de forma fiable el consumo con los retornos, los trabajadores no deberían tener que comprar actividad solo para demostrar compromiso.

La historia de la gestión de software ofrece una comparación útil. Las líneas de código parecían proporcionar en otro tiempo una métrica clara de productividad. Con el tiempo, los equipos reconocieron que más código puede representar duplicación, complejidad innecesaria o una carga de mantenimiento.

Los recuentos de tokens corren el riesgo de repetir ese error a mayor velocidad. Convierten un recurso intermedio en un objetivo de rendimiento.

La buena ingeniería suele reducir el trabajo futuro. Un desarrollador puede eliminar un sistema obsoleto, acotar un requisito o impedir que se construya una funcionalidad. Esas decisiones pueden generar un valor considerable mientras consumen poca capacidad de IA.

Mientras tanto, un agente puede generar un parche extenso en cuestión de minutos. El resultado aún requiere que una persona verifique el comportamiento, evalúe la seguridad, entienda las consecuencias arquitectónicas y decida si el cambio debe incorporarse al producto.

Por ello, los directivos necesitan métricas de resultados, no métricas de consumo. Las señales útiles incluyen el tiempo de ciclo, los defectos que llegan a producción, la carga de revisión, la fiabilidad, el impacto en los clientes y la mantenibilidad de los cambios completados.

Incluso estas señales requieren cautela. Una entrega más rápida puede ocultar pruebas aplazadas, mientras que menos defectos visibles pueden reflejar una detección más débil. Ninguna métrica individual debería decidir si un desarrollador utilizó la IA de forma eficaz.

El modelo financiado por los trabajadores empeora la medición. Los empleados que pagan de forma privada pueden utilizar cuentas que los empleadores no pueden gobernar ni auditar. Los directivos ven entonces los resultados sin ver los prompts, los modelos, la exposición de datos ni la ruta de procesamiento que hay detrás.

Eso puede recompensar precisamente el comportamiento que una organización de ingeniería madura debería desalentar. El colaborador aparentemente más rápido puede estar asumiendo el mayor riesgo de propiedad intelectual o seguridad.

Por tanto, el debate abarca más que los reembolsos. Trata sobre si las empresas gestionarán la IA como un sistema de producción controlado o como una ventaja personal invisible.

La promesa de productividad sigue teniendo un problema de verificación

La IA puede acelerar tareas de programación seleccionadas, pero la evidencia no justifica tratar el acceso de pago como una protección universal frente a un rendimiento insuficiente.

Los desarrolladores informan de beneficios significativos de los asistentes de programación. Los encuestados empresariales de GitHub asociaron las herramientas con una navegación más sencilla por las bases de código, la generación de pruebas, la adopción de lenguajes y más tiempo para el diseño de sistemas.

JetBrains también documentó una adopción amplia y una elevada satisfacción con varios productos. Los desarrolladores claramente perciben suficiente valor como para seguir utilizándolos.

Sin embargo, la velocidad percibida y la velocidad medida pueden divergir. Un estudio de 2025 de la organización de investigación METR examinó a 16 desarrolladores experimentados de código abierto que trabajaban en repositorios conocidos. Los participantes esperaban que la IA los hiciera más rápidos, pero el resultado medido fue en la dirección opuesta.

Un resumen del estudio de programación medido informó que los participantes creían que la IA había acelerado su trabajo en alrededor de un 20 por ciento. El experimento encontró, en cambio, que tardaron alrededor de un 20 por ciento más.

Los investigadores advirtieron contra la generalización del resultado a todos los desarrolladores o tareas. La muestra era pequeña, los participantes tenían experiencia y las herramientas siguen cambiando.

Esas limitaciones son importantes. También lo es la brecha entre la confianza y la medición.

Un empleado puede sentirse más rápido porque un agente produce código visible de inmediato. Las partes más lentas llegan después, al leer, probar, depurar y corregir supuestos. La recompensa psicológica se adelanta, mientras que el costo de verificación se distribuye a lo largo del flujo de trabajo.

Las distintas tareas también generan rendimientos diferentes. El código repetitivo, las pruebas aisladas, los ejemplos de API y los borradores de migración pueden encajar bien con un agente. Los requisitos ambiguos de producto, el comportamiento heredado, el código sensible para la seguridad y las decisiones arquitectónicas exigen más contexto y criterio.

La elección del modelo también importa. Un modelo más grande puede abordar razonamientos más complejos, pero puede consumir más recursos. Dirigir todas las tareas a la opción más capaz puede elevar los costos sin mejorar el trabajo rutinario.

Una organización que exige a los empleados pagar personalmente evita enfrentar estas distinciones. Permite que cada trabajador realice un experimento sin control y luego juzga el resultado visible.

Ese esquema también oculta los usos fallidos. Los trabajadores rara vez anuncian las horas dedicadas a corregir a un agente, especialmente cuando la dirección ya ha declarado que la IA es un requisito de productividad. Las historias de éxito ascienden, mientras que el tiempo desperdiciado permanece privado.

El resultado es un sesgo de selección. Los líderes ven demostraciones pulidas y tickets más rápidos, pero no siempre los intentos abandonados ni el mantenimiento posterior.

Un sistema de evaluación justo debe separar el acceso de la capacidad. No debería comparar a un desarrollador que usa agentes financiados por la empresa con otro limitado al acceso gratuito. Tampoco debería asumir que quien más gasta es el ingeniero más competente.

En su lugar, los empleadores pueden realizar evaluaciones controladas. Los equipos pueden identificar categorías de tareas, medir la entrega de extremo a extremo, rastrear el tiempo de revisión y examinar los resultados en materia de defectos. Pueden comparar flujos de trabajo sin convertir el consumo individual en una competencia.

Los desarrolladores necesitan margen para rechazar la IA cuando añade fricción. Una herramienta que ayuda en un repositorio puede fallar en otro debido al soporte de lenguaje, la calidad de la documentación, la cobertura de pruebas o el tamaño del contexto.

Calificar toda negativa como resistencia al cambio desalienta el criterio profesional. También puede empujar a los trabajadores a usar IA en entornos donde la confidencialidad o la fiabilidad deberían tener prioridad.

Por tanto, el argumento más sólido a favor de las herramientas de programación con IA es condicional. Son útiles cuando la tarea encaja, el modelo dispone de suficiente contexto, el desarrollador puede verificar el resultado y el proceso circundante captura la ganancia.

Nada de esto respalda la conclusión automática de que comprar más acceso hace que un empleo sea más seguro.

La IA pagada por los trabajadores crea brechas de seguridad y rendición de cuentas

Cuando los desarrolladores compran IA para el trabajo de forma independiente, el empleador puede ahorrar en contratación mientras acumula mayores riesgos legales, de seguridad y mantenimiento.

Las cuentas personales de IA quedan fuera de muchos controles corporativos. Pueden carecer de gestión centralizada de identidades, configuraciones aprobadas de retención, registro de uso y términos contractuales que regulen el código enviado.

Un desarrollador bajo presión por una fecha límite puede pegar trazas de pila, archivos fuente, esquemas de bases de datos, datos de clientes o documentación interna en un modelo. Incluso los trabajadores responsables pueden evaluar mal lo que revela un prompt cuando la organización no proporciona un flujo de trabajo aprobado.

El riesgo no se limita a que los datos salgan de la empresa. El código generado por IA puede introducir dependencias, copiar patrones inseguros, malinterpretar permisos o crear comportamientos cuyo origen los revisores tienen dificultades para rastrear.

Un estudio de GitLab de 2026, comunicado mediante sus hallazgos publicados sobre gobernanza de IA, encuestó a más de 1.500 desarrolladores. Encontró que el 79 por ciento creía que la entrega de software no se había acelerado tanto como la productividad individual de los desarrolladores.

El mismo informe indicó que el 85 por ciento consideraba la revisión y la validación como la principal limitación. También encontró que el 43 por ciento tenía dificultades para distinguir el código generado por IA del escrito por personas.

Estos resultados procedían de un estudio de un proveedor y deben leerse en ese contexto. Aun así, identifican un problema organizativo que las compras personales no pueden resolver.

La generación de código ocurre a nivel individual, pero la revisión, el despliegue, los incidentes y el mantenimiento ocurren entre equipos. Un trabajador puede ahorrar tiempo mientras traslada mayores costos a sus colegas.

Esta es la diferencia entre productividad local y productividad del sistema. La productividad local pregunta si una persona completó un borrador más rápido. La productividad del sistema pregunta si la organización entregó valor fiable con menos esfuerzo total.

Las herramientas no reembolsadas pueden distorsionar ambas. Los empleados pueden elegir productos según su asequibilidad personal en lugar de la seguridad, la integración o el soporte a largo plazo. Los equipos pueden terminar con varios agentes produciendo código mediante flujos de trabajo incompatibles.

La rendición de cuentas se vuelve entonces poco clara. Si una empresa espera el uso de IA pero no aprueba la herramienta, ¿quién responde por una filtración de datos? Si un gerente recompensa la velocidad pero ignora la procedencia, ¿quién responde por un defecto generado por IA?

En la mayoría de las culturas de ingeniería, el empleado sigue siendo responsable del código enviado. Ese principio tiene sentido, pero se vuelve injusto cuando la dirección presiona simultáneamente a los trabajadores para adoptar herramientas sin proporcionar tiempo para la verificación.

Los empleadores no deberían resolver esto prohibiendo todas las herramientas personales mientras mantienen plazos ajustados a la IA. Eso conservaría la expectativa de productividad y eliminaría el medio del trabajador para cumplirla.

Una política viable necesita cuatro elementos conectados: acceso financiado, prácticas de datos aprobadas, orientación específica por tarea y tiempo realista de revisión. Eliminar cualquiera de ellos crea una laguna.

El acceso financiado evita que los ingresos personales determinen la capacidad laboral. Las prácticas aprobadas definen qué datos pueden entrar en un modelo. La orientación por tarea distingue las aplicaciones útiles de las de alto riesgo. El tiempo de revisión reconoce que el código generado no es código terminado.

Los equipos también necesitan registros duraderos. Los prompts, las decisiones, las pruebas y el contexto arquitectónico deberían seguir disponibles tras el final de una sesión individual. Una base de conocimiento de ingeniería con capacidad de búsqueda puede preservar el razonamiento sin convertir el volumen bruto de tokens en el registro del trabajo.

Este enfoque trata la IA como parte de la cadena de suministro de software. También hace que la contratación responda por los resultados, en vez de trasladar la incertidumbre a los empleados individuales.

La cuestión laboral es quién captura la ganancia

Si la IA eleva las expectativas de producción mientras los trabajadores financian la herramienta y absorben sus riesgos, los empleadores capturan el beneficio mientras los empleados asumen el costo.

Las empresas esperan habitualmente que los profesionales desarrollen sus habilidades. Los trabajadores compran libros, hacen cursos, experimentan con software y mantienen proyectos personales. No todos los gastos de carrera requieren reembolso.

Un insumo obligatorio de producción es diferente. La distinción depende del control, la necesidad y el beneficio.

Si un desarrollador compra libremente una herramienta para aprender o por comodidad personal, el gasto se parece al desarrollo profesional. Si un empleador exige la herramienta, establece objetivos dependientes de IA o penaliza a los empleados que no tienen acceso, el gasto se acerca más al equipamiento empresarial.

La presión informal complica la evaluación. Es posible que un gerente nunca emita una orden escrita. El equipo puede simplemente normalizar una producción más rápida hasta que los trabajadores concluyan que el acceso de pago es necesario.

Aquí es donde la expresión pagar para trabajar refleja una preocupación real, incluso sin una amenaza de despido verificada. La presión laboral suele operar mediante clasificaciones, plazos, renovación de contratos y calidad de las asignaciones, en lugar de órdenes explícitas.

Los trabajadores con mayores ingresos pueden comprar más capacidad, mantener varias suscripciones o experimentar con modelos adicionales. Los empleados junior y los contratistas pueden tener menos opciones, aunque enfrenten una mayor presión para demostrar rapidez.

La desigualdad resultante puede reproducirse a sí misma. Un mejor acceso produce resultados más visibles, los resultados visibles obtienen mejores asignaciones y las mejores asignaciones fortalecen la posición del empleado.

Los proveedores de IA se benefician de esta fragmentación porque la demanda pasa de la contratación centralizada a millones de compradores individuales. Los empleadores pueden retrasar decisiones difíciles sobre gobernanza mientras los trabajadores financian la adopción.

Sin embargo, la experimentación descentralizada tiene ventajas. Los desarrolladores pueden probar nuevos productos antes de que la contratación empresarial se ponga al día. Los equipos pequeños pueden descubrir flujos de trabajo útiles sin esperar un largo proceso de aprobación.

El problema comienza cuando los experimentos se convierten en expectativas. Una vez que la dirección depende de la producción resultante, la empresa debería formalizar el acceso y la responsabilidad.

La claridad colectiva importa porque la negociación individual es débil. Un desarrollador que se niega a financiar una herramienta puede parecer poco cooperativo, incluso cuando la objeción protege los datos de la empresa y establece un límite justo de costos.

Los equipos deberían indicar si el uso de IA es opcional, recomendado u obligatorio. Esas categorías necesitan un significado operativo.

El uso opcional significa que los estándares de rendimiento no presuponen el acceso. El uso recomendado significa que el empleador proporciona una vía aprobada, pero acepta la negativa basada en la tarea. El uso obligatorio significa que el empleador proporciona los recursos, la formación y el proceso de revisión necesarios.

La compensación también merece atención. Si la IA realmente permite que un empleado produzca trabajo más valioso, la discusión no debería terminar con cuotas más altas. Las organizaciones deben decidir cómo afectan las ganancias de productividad a la dotación de personal, la remuneración, la carga de trabajo y el desarrollo profesional.

De lo contrario, los empleados se encuentran con un acuerdo unilateral. Pagan para aumentar la producción, el empleador eleva las expectativas y el tiempo ahorrado desaparece en trabajo adicional.

Ese patrón puede perjudicar la adopción. Los desarrolladores que asocian la IA con vigilancia, gastos no compensados o inseguridad laboral la usarán a la defensiva. Pueden ocultar flujos de trabajo, exagerar los beneficios o evitar informar sobre fallos.

La confianza genera mejores datos. Cuando los trabajadores pueden hablar de dónde fallan los agentes sin amenazar sus evaluaciones de rendimiento, las empresas aprenden qué tareas merecen inversión.

Por lo tanto, la industria necesita un marco laboral junto a su marco técnico. La eficiencia de los tokens, el enrutamiento de modelos y la calidad del código importan, pero también importan la asignación de costos y el poder de negociación.

Qué observar tras la reacción contra los tokens

Tres señales mostrarán si la IA pagada por los trabajadores sigue siendo una norma informal o se convierte en infraestructura laboral con rendición de cuentas.

La primera señal es la política de contratación. Los empleadores deberían empezar a indicar qué herramientas de programación financian, qué límites de uso se aplican y cómo los empleados solicitan capacidad adicional.

Unas normas claras de reembolso reforzarían la idea de que la IA se ha convertido en un insumo empresarial estándar. El silencio continuado dejaría a los trabajadores absorbiendo costos mediante cuentas personales.

Observe cómo manejan las empresas la elección de modelos. Una asignación fija sin enrutamiento basado en tareas aún puede penalizar a las personas asignadas a repositorios complejos. El acceso justo requiere un proceso para las excepciones, no solo cuotas idénticas.

La segunda señal es la medición del rendimiento. Las empresas deberían alejarse del volumen de tokens, los recuentos de código generado y la velocidad bruta de los tickets.

Un cambio hacia métricas integrales indicaría un ciclo de adopción más maduro. Los resultados relevantes incluyen el tiempo de revisión, las tasas de defectos, el impacto de los incidentes, la mantenibilidad y el valor para el cliente.

La señal opuesta sería la proliferación de más clasificaciones vinculadas al consumo. Eso reforzaría la preocupación de que el uso de IA se esté convirtiendo en un sustituto del compromiso, en lugar de una herramienta evaluada por sus resultados.

La tercera señal es la cobertura de gobernanza. Los empleadores deberían conectar las cuentas aprobadas con controles de identidad, reglas de datos, trazabilidad y revisión de código.

El uso personal no desaparecerá. La cuestión relevante es si las empresas pueden ofrecer un flujo de trabajo respaldado que sea más seguro y útil que la cuenta privada de un empleado.

Una mejor gobernanza debilitaría la interpretación más severa de la controversia. Mostraría que los empleadores aceptan la responsabilidad por la tecnología que quieren que utilicen los trabajadores.

Un aumento de las disputas disciplinarias, el código filtrado o las cuentas personales ocultas apuntaría en la otra dirección. Sugeriría que las organizaciones impusieron expectativas moldeadas por la IA sin construir la estructura operativa necesaria.

La afirmación original de Zhihu debería seguir etiquetada como no verificada salvo que surjan pruebas identificables. No existe una base responsable para presentar discusiones anónimas como prueba de que los programadores, de forma generalizada, compran acceso a tokens para evitar el despido.

Sin embargo, desestimar la controversia también pasaría por alto el cambio más amplio. Las herramientas de programación con IA están muy extendidas, los costes de uso son visibles y el rendimiento individual se evalúa cada vez más frente a colegas asistidos por IA.

Los desarrolladores deberían plantear preguntas directas antes de pagar por capacidad relacionada con el trabajo. ¿La herramienta es opcional? ¿Pueden introducirse datos de la empresa? ¿Se reembolsará el gasto? ¿Los plazos presuponen su uso? ¿Quién asume la responsabilidad por los errores generados a través de ella?

Los líderes de ingeniería deberían responder esas preguntas antes de celebrar un mayor consumo. Si la IA es necesaria para el trabajo, la empresa debería financiarla y gobernarla. Si es opcional, los sistemas de rendimiento deben preservar esa elección.

La cuestión decisiva no es cuántas unidades de tokens puede consumir un programador. Es si las organizaciones pueden convertir la actividad de IA en valor fiable sin trasladar costes, riesgos e inseguridad a quienes realizan el trabajo.