Página **About** del sitio web **tokeneconomics.com**, que presenta a la **Tokenomics Foundation** — un proyecto de la **Linux Foundation** anunciado el **3 de junio de 2026**, operado en **estrecha colaboración con la FinOps Foundation**. **Misión declarada**: *"establish open industry standards, benchmarks, and best practices for the economics of AI infrastructure"* — vinculando la **producción, el consumo y la monetización** de tokens al **valor de negocio**. **Definición marco de tokenomics**: *"Tokenomics is not just about the cost of tokens, it's about the entire layer of AI that they drive from production, to consumption to monetization"* — es decir, **toda la capa económica de la IA**, desde el coste de infraestructura hasta la selección de modelo y la optimización de valor. **Tesis de fase**: la adopción temprana de la IA priorizó la **capacidad**; la fase actual se desplaza hacia la **eficiencia y el valor**, lo que exige una gestión de costes sistemática y **visibilidad**. **5 principios fundacionales**: (1) ***"Efficiency is a design choice. AI cost is shaped by architecture, not just usage"***; (2) ***"Bigger is not always better. The best AI system is not always the one using the most expensive model"*** (right-tool / enrutamiento); (3) ***"Visibility comes before optimisation. Teams cannot manage what they cannot see"***; (4) ***"Value matters more than volume. More tokens, more calls, and more automation do not automatically mean better outcomes"***; (5) ***"Open knowledge benefits everyone"*** (estándares compartidos, aprendizaje comunitario, transparencia). **Gobernanza**: un **Governing Board** (dirección sectorial + despliegue de fondos) y un **Technical Committee** (especificaciones abiertas + benchmarks). **Entregables**: extensión de la **FOCUS specification** (FinOps), especificaciones abiertas, benchmarks, marcos y métricas compartidos. **Público objetivo**: CAIO, CTO, CIO, CFO, ingenieros, equipos de producto, profesionales de FinOps, investigadores, startups, empresas, sector público. **Objetivo declarado**: llevar a las organizaciones *"from experimental AI adoption to sustainable AI operations"* extendiendo la disciplina del **gasto tecnológico variable** a la era del token. **Relevancia para esta veille**: institucionalización/estandarización del **FinOps agéntico** a nivel de fundación sectorial — converge directamente con las fichas [[finops-foundation-finops-for-ai-overview-2026-02-17]], [[finout-finops-ai-agents-four-step-allocation-framework-2026-04-27]], orq-ai-finops-ai-agents-cost-per-outcome-hosseini-2026-04-15, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (capa de asignación, token-to-outcome) y con el desplazamiento **token → outcome** (Salesforce/Tallapragada, Sierra/Greenwald). Los 5 principios se corresponden exactamente con las palancas ya registradas: arquitectura > uso, **enrutamiento Haiku/Sonnet/Opus**, observabilidad antes de optimización, valor ≠ volumen.
#Tokenomics Foundation#tokenomics#economía de tokens
**Tokenomics Foundation** (entité collective, projet de **The Linux Foundation**, en partenariat avec la **FinOps Foundation**). Page institutionnelle *About* — **aucun auteur individuel nommé**. Annonce datée du **3 juin 2026**.
Publicación del **blog Dropbox Tech** (sección *culture*), publicada el **28 de mayo de 2026** por **Kazuaki Okumura** (Dropbox, rol no especificado en el artículo), que recapitula una charla en la conferencia **DX Annual 2026** (productividad de desarrollo). **Tesis central**: la productividad de ingeniería debe ir más allá de la *generación de código*. *« Acelerar la generación de código simplemente desplazó algunos cuellos de botella aguas abajo »* — la IA ha aumentado masivamente el rendimiento de código, pero *« cuanto más rápido se mueve el código, más presión ejerce sobre las colas de revisión, los sistemas de CI, los flujos de validación, la coordinación de releases y las operaciones de producción »*. El verdadero desafío ya no es escribir código más rápido, sino permitir que todo el SDLC **absorba, valide y despliegue de forma segura** un volumen mucho mayor. **De copiloto a agente**: la primera ola (explicación de código, snippets, preguntas y respuestas) operaba *« como copilotos junto al ingeniero »*; el agente, en cambio, *« puede tomar una tarea acotada, inspeccionar la base de código, editar archivos, ejecutar pruebas, iterar sobre fallos y devolver un artefacto para revisión humana »* — con el ingeniero permaneciendo *« responsable de la intención, la arquitectura, la calidad y las decisiones de release »* (más trabajo en paralelo, más opciones, delegación de la ejecución repetitiva). **Nova** = la plataforma **interna** de agente de codificación de Dropbox: describir una tarea en lenguaje natural, ejecución en un entorno controlado con contexto de la base de código. Dato canónico: ***« el valor de Nova proviene menos del propio modelo que de los sistemas que lo rodean »*** (contexto de la base de código, prácticas internas, ejecución segura, integración en el flujo de trabajo, revisión humana); Nova representa hoy **aproximadamente 1 de cada 12 PR en Dropbox** (adopción creciente), y se extiende más allá de las funcionalidades a **migraciones, corrección de tests inestables (flaky), investigación de errores, actualizaciones de dependencias** (trabajo de alto desgaste). **Medir la velocidad del producto, no la producción de código**: el *rendimiento de PR*, una señal útil cuando la velocidad de codificación era la limitación, *« ya no era suficiente »*. Un modelo de medición en **4 etapas**: ***Fuel*** (¿se están usando las herramientas de IA?) → ***Adoption*** (cómo están cambiando los flujos de trabajo en los equipos) → ***Output*** (¿la IA contribuye al trabajo de producción?) → ***Impact*** (*« mejorar la velocidad del producto y reducir el tiempo que se tarda en pasar de la idea al valor para el cliente »*). Señales de calidad monitorizadas: **tiempo de resolución de revisión de código, tasa de éxito de pruebas en la primera ejecución, tasa de defectos, tasa de retrabajo**. *« La calidad y la confianza importan tanto como la velocidad »* — el núcleo del cambio: *« pasar de métricas de actividad local hacia resultados de sistema más amplios »*. **Los flujos de trabajo también deben evolucionar**: esto no es *« solo un cambio de herramientas »* sino un cambio de **modelo operativo** — el rol del ingeniero se desplaza hacia *« definir la intención, mapear los problemas, revisar los cambios generados y tomar decisiones arquitectónicas y de calidad de mayor contexto »*. La **capacitación** (enablement) es tan crucial como la propia herramienta (aprendizaje práctico, hackathons, workflow spotlights, bootcamps, ejemplos liderados por pares); la adopción avanza a ritmos variables según los equipos; *« el objetivo no es forzar cada flujo de trabajo a través de un agente »* — el objetivo es hacerlo *« útil, seguro, medible y repetible allí donde genera un apalancamiento significativo »*. **Lo que aprendimos**: ***« la IA no elimina los cuellos de botella en el desarrollo de software, pero sí los desplaza »*** (aguas abajo: revisión, validación, pruebas, release, operaciones de producción) → optimizar el antiguo cuello de botella ya no genera el mismo apalancamiento. *« La ventaja no vendrá del acceso a los mismos modelos fundacionales que todos pueden usar. Vendrá de los sistemas construidos alrededor de esos modelos: contexto, herramientas internas, controles de calidad y los flujos de trabajo que los conectan. »* La presión también se acumula **aguas arriba** (producto y diseño): especificaciones estructuradas, claridad de diseño, un planteamiento más preciso de los problemas. Cierre: ***« el futuro de la productividad de ingeniería no estará definido únicamente por quién tiene los mejores modelos. Estará definido por quién construye los mejores sistemas alrededor de ellos »***; *« el verdadero desafío ya no es solo generar más código, sino construir sistemas de ingeniería que puedan convertir de forma fiable la producción asistida por IA en experiencias valiosas para nuestros clientes »*. Convergencia directa con **Salesforce/Tallapragada** (Effective Output: medir el valor, no el volumen; sin compensación velocidad/calidad), **Gupta** (atribución de token a resultado, coste de un resultado completado), **DORA** (más allá del rendimiento), y el desplazamiento del KPI hacia el **resultado de sistema** (idea→valor para el cliente).
#productividad de ingeniería#productividad de ingeniería#más allá de la generación de código
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.
Hilo viral de X (**230.5K visualizaciones**, 28 de mayo de 2026, 1:51 AM) de **Jaya Gupta** (@JayaGup10, inversora — probablemente de Foundation Capital, autora del marco *Context Graphs*) titulado ***"Token Budget Wars"***. **Tesis central**: ***"La IA empresarial ha pasado de la adopción a la asignación"*** — la fase 1 de la IA empresarial demostró que los modelos funcionan; la fase 2 decidirá **cuánto vale ese trabajo**. La nueva moneda en la cúpula de la empresa es la **capacidad de cuantificar el ROI de la IA**: *"muéstrame el valor"*. Concepto canónico: ***utilidad marginal del token*** = *"el valor de negocio creado por cada dólar adicional de inferencia"* — el número que importa a escala, y que **la mayoría de las empresas no puede ver**. Cronología: **Claude se lanzó en noviembre de 2025**, después de que se cerraran los presupuestos anuales de 2026 → ya en el **primer trimestre**, empresas *"funcionando muy por encima de lo previsto"* → la inferencia deja de ser una partida de experimentación y se convierte en un **costo operativo recurrente**. Paso de la **experimentación (unos cientos de miles de dólares) a la infraestructura (siete cifras, más de 1 millón de dólares)**: a escala de infraestructura, **la varianza técnica produce oscilaciones materiales en el P&L — dos ejecuciones del mismo flujo de trabajo sobre la misma entrada pueden diferir entre 5 y 10 veces en costo de tokens** sin que nada se vea visiblemente roto, *"una cifra que el CFO tiene que explicarle al CEO"*. **La IA compite con la mano de obra**: 3 tipos de solicitudes presupuestarias (sustituir trabajo externalizado / sustituir trabajo interno / generar ingresos) → desplazamiento hacia el ***costo de un resultado completado*** (costo por ticket resuelto, siniestro procesado, contrato revisado, factura completada, contratación evitada, cliente retenido, dólar de ingreso movilizado). **El BPO es la referencia más fácil para comparar** (ya tiene precio por unidad completada); el trabajo interno es mucho más difícil (empleados multi-competencia, ganancias difusas, resistencia de RR. HH. a la reducción de plantilla). **Por qué es distinto del SaaS**: el SaaS aprendió a tratar el uso como indicador indirecto del valor; la IA rompe ese indicador — *"la señal y el ruido comparten la misma unidad"* (el token), *"el uso de SaaS te decía que el software había sido adoptado. El uso de IA te dice que el contador sigue corriendo. No te dice si tu empresa está funcionando de verdad."* **Tres causas de la invisibilidad de la utilidad marginal del token**: (1) ***colas de reintento*** — tokens por flujo de trabajo resuelto ≈ **T/p**; pasar de un 90% a un 70% de finalización aumenta el costo efectivo en ~**28%**, no un 20%, porque los fallos se acumulan; (2) ***inflación de contexto*** — el costo de inferencia ≈ **O(n²)** respecto a la longitud del contexto (atención), duplicar el contexto **cuadruplica** el costo de razonamiento (sobre-recuperación: 50 documentos cuando bastarían 5); (3) ***enrutamiento*** — por defecto se usa el modelo más potente (una clasificación básica ejecutada en un modelo de razonamiento complejo); a través de millones de llamadas, la diferencia entre enrutar tareas fáciles a un modelo pequeño y enviarlo todo al modelo de vanguardia = *"la diferencia entre una factura manejable y un problema de nivel de consejo de administración."* **División sectorial**: las empresas de **software** = un problema de **medición de productividad** (ya instrumentado: PR, commits, despliegues, incidentes, tiempo de ciclo, MTTR — sigue el rastro de los *"despidos por IA"*); las empresas **no-software** = un problema de **transformación** (trabajo operativo: siniestros, suscripción de pólizas, soporte, revisiones de cumplimiento, excepciones de cadena de suministro, disputas de pago — *correcto bajo auditoría, no solo correcto en promedio*). **La capa que falta = atribución de token a resultado**: una capa de conversión que vincula el gasto en inferencia → el trabajo realizado → el resultado de negocio, respondiendo a 3 preguntas (costo real incluyendo reintentos/correcciones; qué partes de la traza importaron frente al desperdicio; si el trabajo cambió el modelo operativo). ***La medición se convierte en memoria***: vincular un token a un resultado exige capturar **trazas de decisión** (lo que el agente vio, recuperó, invocó, ignoró, dónde reintentó, cuándo un humano lo anuló) — *"el razonamiento de una decisión es uno de los activos más perecederos de una empresa"* (vive en Slack, correos, llamadas de escalado, en la cabeza de las personas). Los agentes **crean** estas trazas; capturadas primero para justificar el gasto, se vuelven *"más valiosas que el informe de costos"* → un **grafo de contexto** (*"aunque estoy tan cansada de esa palabra estos días"*). **La capa de asignación es el premio**: quien posea la atribución de token a resultado toma las **decisiones de asignación** (qué flujos de trabajo merecen más cómputo, cuáles tienen un tope, cuáles pasan a modelos más baratos, cuáles siguen siendo humanos, cuáles sustituyen al BPO). Las empresas no harán esto por sí solas — lo **comprarán como una transformación** (manual del Fortune 500: exalumnos de McKinsey + Palantir y un CEO que impulsa desde arriba, al estilo de la transformación ERP/BI/digital, un *"programa"* con un patrocinador ejecutivo e infraestructura que se convierte en la **nueva fuente de verdad**). Enmarcado por **Charlie Munger**: *"muéstrame el incentivo y te mostraré el resultado."* Subtesis organizativa: el instinto ejecutivo de décadas de que *equipos grandes = trabajos/alcance/poder grandes* → una vez que la inteligencia se convierte en el **recurso escaso**, el nuevo indicador es *"cuánta de ella estás orquestando."* Relevancia directa para el **posicionamiento de Cost Optimization / FinOps agéntico**: confirma empíricamente las palancas (enrutamiento de modelos, caché de prompts, higiene de contexto, subagentes) y desplaza el KPI hacia el **costo por resultado completado**. Fuerte convergencia con el *cross-system labor* de Bain (foso de datos de ejecución, Cursor), el *No AI jobpocalypse* de Ng (precios anclados al salario del empleado sustituido), el ROI de DORA (costo por función), Mensch/Mistral (electrón→token), Ensarguet (economía del cómputo), *Context Graphs* de Foundation Capital (trazas de decisión, misma autora), *Token Burning* de Wescale, BFM/Girard (token = combustible de valor).
#Token Budget Wars#utilidad marginal del token#atribución de token a resultado
**Jaya Gupta** (@JayaGup10) — investisseuse / VC. Très probablement **Foundation Capital** (le thread s'auto-réfère au cadre ***Context Graphs*** — *« ahem, context graph, although I am so tired of that word these days »* — concept porté par Foundation Capital, cf. fiche `bain-100b-saas-opportunity` qui cite *Foundation Capital — Context Graphs trillion-dollar opportunity, 2025-12-22*). Thread publié sur X le **28 mai 2026 à 1h51** · **230 · 5K vues** · format essai long en un seul post. Une réponse notable de **@tuning_engines** (*« DevSecFinOps for the Agentic Era »*) : *« Tokens will basically have to be managed like headcount […] model hierarchies too »*.
Entrada oficial del blog **Salesforce News** (sección *Agentic Enterprise*, serie *"Pioneering the Agentic Shift Within Salesforce Engineering"*), publicada el **27 de mayo de 2026** (lectura de 6 minutos) por **Srinivas "Srini" Tallapragada**, *President and Chief Engineering and Customer Success Officer* en Salesforce. Continuación directa de una entrada anterior (*"How we got our engineers to use AI — without breaking everything"*) que relataba haber superado el **>90% de adopción**. **Tesis del giro**: Salesforce Engineering pasó de un mundo en el que la IA era un *copiloto* útil a otro en el que **las herramientas agénticas impulsan el propio ciclo de vida de desarrollo de software (SDLC)** — escribiendo código, revisando PRs, generando tests, actualizando documentación, gestionando despliegues, coordinando trabajo antes gestionado mediante traspasos humanos. **Decisión señal canónica**: estandarización a escala de la organización en **Claude Code** + ***"eliminamos todos los límites de tokens"*** — *"eliminar hasta el último resquicio de fricción entre nuestros ingenieros y las herramientas que los hacen más rápidos y más eficaces"*. **Resultado empírico mayor** (abril 2026 frente a abril 2025): elementos de trabajo completados por desarrollador **+50,8%**, PRs fusionadas por desarrollador **+79%**, y sobre todo la puntuación de **Effective Output** (una medida de ML del **valor real del código entregado**, no del volumen) **+151,3% interanual**. **Caso de uso emblemático**: migración de **33 endpoints de API** a una arquitectura cloud-native, estimada en **~231 persona-días** (7 por API) de forma tradicional, completada en **13 días — 18 veces más rápido** — mediante un **marco basado en reglas construido en Claude** (archivos markdown + implementaciones de referencia), con el feedback de las PRs realimentando continuamente el conjunto de reglas, **bucles LLM autónomos (build, fix, validate)** sin intervención manual, paralelizados en entornos aislados → **5 PRs**, la mayor de las cuales entregó **21 endpoints con 100% de cobertura de tests**. **Sin compromiso velocidad↔calidad**: a través de la plataforma **Engineering 360** (que centraliza datos de ingeniería de cientos de sistemas), **los incidentes totales caen un 5%** pese al aumento de PRs (*"la calidad no sufre por la velocidad. Se beneficia de ella"*), gracias a **barreras de seguridad y estándares de calidad estructuralmente integrados** en el flujo de trabajo agéntico (Trust como valor n.º 1). **Revisión del SDLC**: una vez adoptada la IA, los ingenieros **desmontan y reconstruyen** los flujos de trabajo (¿qué procesos eliminar? ¿qué traspasos ya son innecesarios? ¿dónde sigue un humano haciendo un trabajo que podría asumir un agente?). **Nuevo oficio de ingeniería**: las **skills de Claude Code** (capacidades empaquetadas y reutilizables que codifican el contexto del equipo, las convenciones de nomenclatura, los patrones) se convierten en un **artefacto de ingeniería** compartido y componible; **AI Expert Suite** + **Salesforce Foundation Plugins** = una biblioteca de skills institucionalizada y curada (benchmark interno: **mayor precisión y fiabilidad, coste innecesario reducido**); los **subagentes y equipos de agentes** paralelizan los flujos de trabajo (*"Describen el resultado, y un conjunto de agentes coordinados averigua los pasos"*). **Lo que sigue siendo difícil**: (1) la **gestión del contexto** en sesiones largas — la **calidad del archivo CLAUDE.md** varía mucho y pesa fuertemente en la calidad del resultado; (2) la **seguridad agéntica** = un modelo fundamentalmente distinto (agentes que *actúan*, no solo *sugieren* → mayor radio de impacto); (3) **roles en evolución** (¿cómo pasan los junior a senior si la IA absorbe el trabajo de nivel inicial? ¿papel del diseñador/PM? la unidad de ejecución = equipo scrum → experimentos con unidades de 1 o 3 personas). Conclusión: *"Cambió lo que era económicamente posible"*; la ambición declarada es **"el SDLC agéntico más automatizado del sector"**. Se cruza directamente con Gupta (*coste de un resultado completado*, utilidad marginal del token), Greenwald/Sierra (precios basados en resultados), DORA (ROI / coste por funcionalidad) y el debate BFM/Girard (el token como combustible de valor, no como coste a recortar).
#SDLC agéntico#sdlc agéntico#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
FinOps para agentes de IA: un marco de asignación en cuatro pasos para los costes de los asistentes de codificación (Claude Code, Cursor, Copilot) y por qué el etiquetado tradicional de la nube falla - Finout
#FinOps agéntico#asignación de costes#asistentes de codificación
FinOps para agentes de IA centrado en el "coste por resultado": por qué el FinOps tradicional falla frente al comportamiento en tiempo de ejecución, guardrails, observabilidad conductual y un ciclo de vida de 4 fases - Orq.ai
#FinOps agéntico#coste por resultado#comportamiento en tiempo de ejecución