Informe técnico (engineering write-up) del equipo de **Data Science & Data Engineering** de Anthropic (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry), publicado el **3 de junio de 2026** en el blog de Anthropic (categoría *Enterprise AI*, centrado en **Claude Code**). **Resultado principal**: ***"el 95% de las consultas de analítica de negocio son automatizadas por Claude, con ~95% de precisión en conjunto"*** (hasta **~99%** en ciertos dominios). **Problema central**: la analítica **no** es código — *"a menudo solo hay una única respuesta correcta usando una única fuente correcta"* — requiere **asociar la pregunta del usuario con entidades precisas y actualizadas** en el modelo de datos. Tres **modos de fallo**: (1) **ambigüedad concepto↔entidad** (p. ej. *"usuarios activos"*: ¿qué acciones? ¿se excluye a los fraudulentos? ¿qué ventana temporal?); (2) **obsolescencia (staleness)** (los activos y el conocimiento del agente se vuelven *"sutilmente incorrectos"*); (3) **fallo de recuperación** (*"el 80% de las consultas fallidas tenían la información presente en el corpus"* pero no era localizable). **Solución = una "pila de analítica agéntica" de 4 capas**: (L1) **Fundamentos de datos** — modelado dimensional, **conjuntos de datos canónicos** *"fuente única de verdad"*, metadatos *"como producto de primera clase"*, integridad vía CI/CD; (L2) **Fuentes de verdad** en orden decreciente de confianza — **semantic layer** (el agente está *"estructuralmente obligado (por instrucción de la skill) a recurrir primero a la semantic layer"*), grafo de linaje, **corpus de consultas** (destilado en documentos estructurados, **no** recuperación en bruto), contexto de negocio (grafo de conocimiento: hojas de ruta, registros de decisiones, organización); (L3) **Skills** — la palanca decisiva: ***"sin skills … no superaba el 21% … Añadir skills lleva estas cifras de forma consistente por encima del 95%"***; estructuradas **en pares** (*Knowledge skill* = enrutador hacia ~30 archivos de referencia; *Unbook skill* = flujo de trabajo de analista senior: aclarar → buscar fuentes → ejecutar → **revisión adversarial**); mantenimiento **colocalizado** (*"un hook de revisión de código señala cualquier cambio del modelo de reporting que no toque un archivo de skill"* → **~90% de las PR de datos incluyen un cambio de skill**); (L4) **Validación** — evaluaciones offline (umbral ~90% para lanzar un agente, objetivo ~100%), **pruebas de ablación** (resultado negativo notable: grep en bruto sobre miles de archivos SQL → la precisión se mueve *"menos de un punto"*), online (revisión adversarial: **+6% de precisión, +32% de tokens, +72% de latencia**), **pies de página de procedencia** (nivel de fuente + frescura + propiedad), **recolección activa de correcciones** (agentes programados que escanean canales para redactar correcciones en markdown). **Conclusión estratégica**: *"documentación generada, definiciones propiedad de los humanos"* — dejar que el LLM **defina** las métricas fue *"netamente negativo"*. **Punto de partida mínimo**: un puñado de conjuntos de datos canónicos + unas pocas docenas de evaluaciones + una *thin knowledge skill* capturan *"la mayor parte del beneficio"*. Converge fuertemente con [[shihipar-claude-code-lessons-building-skills-2026-06-03]] (skills = carpetas, Gotchas, hooks), la doctrina de *systems around the model* de [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], la **semantic layer / ontología** de talisman-modern-data-101-ontology-pipeline-refresh-2026-05-04 y seale-semantic-agent-model-harness-ontology-data-2026-04-17, el *context development lifecycle* de debois-tessl-context-development-lifecycle-ai-coding-agents-2026-02-19, y la UDA/grafo de conocimiento de netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12.
#analítica self-service#analítica de datos agéntica#Claude Code
**Chen Chang · Clement Peng · Justin Leder · Johanne Jiao · Josh Cherry** — équipe **Data Science & Data Engineering d'Anthropic**. Article publié le **3 juin 2026** sur le blog Anthropic (claude.com/blog) · catégorie *Enterprise AI* · ~5 min de lecture.
Entrada de blog de **Anthropic / claude.com** por **Thariq Shihipar** (Member of Technical Staff, equipo Claude Code), publicada el **3 de junio de 2026**, que destila la **experiencia interna** de Anthropic sobre el diseño y uso de las **Skills**. **Tesis de encuadre**: una Skill no es un simple archivo markdown sino una **carpeta** (instrucciones + scripts + recursos + configuración + hooks) que el agente **descubre y manipula**; *« You should think of the entire file system as a form of context engineering and progressive disclosure. »* El artículo aporta dos contribuciones estructurantes. **(A) Una taxonomía de 9 categorías de skills** observadas en Anthropic: (1) **Library/API Reference** (documentación de libs/CLIs internas con *gotchas* — p. ej. `billing-lib`, `internal-platform-cli`, `sandbox-proxy`); (2) **Product Verification** (pruebas/verificación mediante Playwright o tmux — `signup-flow-driver`, `checkout-verifier`, `tmux-cli-driver`); (3) **Data Fetching & Analysis** (acceso a stacks de datos/monitorización — `funnel-query`, `cohort-compare`, `grafana`, `datadog`); (4) **Business Process Automation** (flujos de trabajo repetitivos — `standup-post`, `weekly-recap`, `create-<ticket>-ticket`); (5) **Code Scaffolding** (boilerplate de frameworks — `new-migration`, `create-app`); (6) **Code Quality & Review** (`adversarial-review`, `code-style`, `testing-practices`); (7) **CI/CD & Deployment** (`babysit-pr`, `deploy-<service>`, `cherry-pick-prod`); (8) **Runbooks** (diagnósticos multi-herramienta — `<service>-debugging`, `oncall-runner`, `log-correlator`); (9) **Infrastructure Operations** (mantenimiento con salvaguardas — `<resource>-orphans`, `cost-investigation`). **(B) Un conjunto de buenas prácticas**: no repetir lo obvio (*« Claude already knows how to code and can read your codebase »* → apuntar a lo que **contradice el comportamiento por defecto**); pulir la **sección Gotchas** (*« the highest-signal content in any skill »*); **divulgación progresiva** a través del árbol de archivos (dirigir hacia archivos de referencia según la situación en lugar de cargar todo por adelantado); **descripciones escritas para el modelo** (*« the description field is not a summary, it's a description of when to trigger this skill »*); **flujos de configuración** (config en `config.json`, o en su defecto preguntar vía `AskUserQuestion`); **memoria persistente** (logs append-only / JSON mediante la variable `${CLAUDE_PLUGIN_DATA}`); **scripts auxiliares** (*« lets Claude spend its turns on composition… rather than reconstructing boilerplate »*); **hooks conditionnels** (habilitados solo durante la skill — p. ej. un hook de seguridad que bloquea comandos destructivos). **Distribución en Anthropic**: las skills se almacenan en `./.claude/skills`, se comparten de forma informal vía Slack en una carpeta sandbox, y luego se promueven mediante **PR** al **marketplace** interno una vez que ganan tracción; **medición de uso** mediante un **hook PreToolUse** que registra las invocaciones (revelando las skills populares frente a las infrautilizadas). Continuación directa de la fiche [[shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10]] (mismo autor) y complemento concreto a las fiches sobre Skills de Anthropic/Willison/Vincent y al *harness engineering*.
#skills#Claude Code#Anthropic
**Thariq Shihipar** (Member of Technical Staff chez Anthropic, équipe **Claude Code** ; @trq212 / @trq sur X, thariqs.github.io) · pour le blog **claude.com**. Même auteur que la fiche *Using Claude Code: The Unreasonable Effectiveness of HTML* (2026-05-10). Publié le **3 juin 2026**.
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**.
En vísperas de la salida a bolsa récord de SpaceX (valoración objetivo de entre 1,75 y 1,8 billones de dólares), The New York Times publica un análisis interactivo del historial de promesas públicas de Elon Musk. A partir de más de 600 compromisos fechados y cuantificados (declaraciones, publicaciones, llamadas con inversores), solo ~19% se cumplieron a tiempo, si es que se cumplieron. La tasa se deteriora con el tiempo: ~75% cumplidas en 2015, menos del 50% en 2020. Marte, el robotaxi y la autonomía total concentran la mayoría de los objetivos repetidos y aplazados. El artículo vincula este historial con el prospecto de SpaceX, que ahora apuesta por la IA (con xAI fusionada) y que reconoce por sí mismo que el calendario de sus grandes proyectos es indeterminable.
Guía del medio **Every** (every.to/guides) publicada el **2 de junio de 2026**, firmada conjuntamente por **Mike Taylor, Laura Entis y Claude**, que propone una **escala de madurez de 8 niveles para la adopción de IA**. **Tesis central**: la adopción de la IA **no es una carrera hacia la máxima sofisticación** — ***« un nivel más alto no es necesariamente mejor »*** ; hay que identificar el nivel que **se ajusta al propio flujo de trabajo y nivel de confianza**, y luego reevaluar regularmente si subir un escalón aporta **valor real**. ***« La mejor manera de encontrar valor en la IA es usarla de una forma que encaje con tu trabajo. »*** **Eje estructurante**: en cada nivel, *« delegas más de tu trabajo en la IA, y depositas más confianza en ella »* (delegación + confianza crecientes). **Los 8 niveles**: **(1) Chatbot** — interfaz conversacional sin contexto integrado (ChatGPT, Claude, Gemini); **(2) Copilot** — IA integrada en el espacio de trabajo con acceso al archivo actual (Cursor, Claude en Excel, Gemini en Docs); **(3) Agent** — sistema reactivo que ejecuta paso a paso solicitando aprobación (Cowork, Codex); **(4) Autopilot** — se describe el **resultado** y el agente ejecuta de forma autónoma, revisión únicamente del **resultado final** (Lovable, Codex, Claude Code; vinculado al *vibe coding*); **(5) Workflows** — ingenieros que construyen **harnesses** en torno a los agentes (planificación, revisión, verificaciones de confianza, salvaguardas; Compound engineering, Claude Workflows, Copilot AI Studio; paso del vibe coding puntual → **agentic engineering**); **(6) Assistant** — agentes **proactivos y siempre activos** que monitorizan un dominio y presentan información sin que se les solicite (OpenClaw, Hermes Agent, Claude Managed Agents; p. ej. `heartbeat.md` cada 30 minutos); **(7) Multi-agent** — gestión simultánea de **varios agentes de larga duración** con roles distintos (Claude Managed Agents, OpenClaw, Codex Goals; *« firmemente en el terreno de la ingeniería senior »*); **(8) Orchestrator** — un **gestor de agentes** dirige un equipo de subagentes (planificación, delegación, monitorización, consolidación; Gas Town, Paperclip, Symphony/OpenAI; *« altamente experimental »* — incluso los propios ingenieros de vanguardia ocupan este rol). **Puntos óptimos por rol**: los **trabajadores del conocimiento** suelen operar entre los niveles **1-4**, los **ingenieros** entre **5-8**. **Paralelismo canónico con la incorporación de un becario**: *« Espera invertir un esfuerzo similar con tus agentes antes de poder confiar en ellos… en el siguiente nivel de autonomía »* ; y la frase marcadora ***« No presumirías de tener ocho becarios trabajando toda la noche en un proyecto clave sin haber revisado su trabajo. »*** El nivel adecuado depende de **4 criterios**: calidad del resultado, coste, fiabilidad (confianza), riesgo en caso de fallo; y la **capacidad del modelo** desplaza progresivamente el nivel de autonomía "seguro". Un marco directamente utilizable para estructurar una **doctrina de adopción** en el ámbito de la consultoría. Convergencia con *los sistemas alrededor del modelo* (Dropbox/Okumura), la *harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines), y la doctrina del *agent manager* (BFM/Girard).
#adopción de IA#escala de madurez#ocho niveles
**Mike Taylor** · **Laura Entis** et **Claude** (co-auteurs déclarés) · pour **Every** (every.to) · rubrique *Guides*. Mike Taylor est un auteur connu sur les sujets prompt/AI (co-auteur de *Prompt Engineering for Generative AI*) ; Laura Entis est journaliste/éditrice. La co-signature explicite de **Claude** comme auteur fait partie du positionnement éditorial d'Every (entreprise AI-native). Publié le **2 juin 2026**.
Tribuna de opinión de **Olivier Rafal** (Director de Consultoría Estrategia, **WeNvision** — grupo **SFEIR**; exredactor jefe de *Le Monde Informatique*) publicada el **1 de junio de 2026** en **CIO-Online**, estructurada en torno a una **paradoja**: en la era de la IA, la ingeniería de software **lo cambia todo… y no cambia nada**. **Lo que cambia es el modelo operativo.** Los roles se redefinen: el **Product Owner** pasa de la descomposición del backlog a **generar contexto utilizable por la IA**; el **desarrollador** pasa de escribir código a **enmarcar, dirigir y revisar** la ejecución de los agentes; el **QA** adquiere la capacidad de definir de antemano la **prueba esperada**. La estructura de los equipos pasa de los *"double pizza teams"* (cadenas de traspaso de ~8 personas) a los ***"sandwich teams"***: un **binomio estrecho formado por un experto de negocio y un tech lead, ambos potenciados por IA**, con otras competencias en apoyo. Cifra interna de **Sfeir**: *"este binomio impulsa ahora aproximadamente el 80% de la cadena de producción"*, quedando el ~20% restante (arquitectura, gobernanza de datos, seguridad) centralizado. Cita pivote: ***"El problema no es un problema de herramientas, es un problema de modelo operativo."*** **Lo que no cambia es la disciplina del ciclo.** Las fases del **SDLC** (definir → construir → verificar → desplegar → mantener) permanecen idénticas y no negociables; la IA no elimina ninguna, las **intensifica**: ***"todo el margen que el ritmo humano solía absorber, aunque fuera de forma imperfecta, se convierte, a la velocidad de la IA, en defectos de nivel industrial"*** (una metáfora del deporte amateur frente al profesional). De ahí **tres *gates* inviolables** (control humano): **especificación, planificación, revisión de entrega**; validación **por prueba** (no por las propias afirmaciones de la IA); **capitalización sistemática** (cada ciclo alimenta al siguiente) → resultado medido: **−30% de iteraciones de corrección tras ~10 ciclos**. Principio: ***"cuanto más rápida la ejecución, más estricto debe ser el marco."*** Conceptos invocados: el **harness** (reglas agénticas adaptadas al contexto), el **vibe-coding** calificado de **insostenible en la empresa**. **Tercer pilar = gobernanza, FinOps y gestión orientada al valor**: costes de IA **variables y recurrentes** (~**10 €/hora** por rol potenciado), paso de la licencia a tarifa plana a la facturación por uso (un paralelismo con la nube de la década de 2010); el **FinOps** no busca recortar costes sino *"optimizar la eficiencia de las herramientas"* (coste en relación con el valor); alineación previa de las **métricas de negocio** (time-to-market, funcionalidades, rendimiento, ecodiseño). **Conclusión**: la aceleración hace que los fundamentos sean **no negociables**; el reto es **organizativo y cultural**, no tecnológico — sin asegurar la relación con el negocio y la disciplina colectiva, un SDLC potenciado por IA no hace más que **amplificar los problemas** (chocar contra el muro más rápido). Prolonga la doctrina de WeNvision de [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] y [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]]; converge con *los sistemas alrededor del modelo* dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28, la *harness engineering* osmani-agent-harness-engineering-2026-04-19, el Salesforce agéntico, y el debate sobre el *agent manager* (BFM/Girard, SFEIR).
#ingeniería de software#IA#todo cambia nada cambia
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (groupe **SFEIR**). Ancien **rédacteur en chef du *Monde Informatique*** · et auparavant consultant analyste du marché IT (~10 ans). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Publié le **1er juin 2026**.
Estudio de datos de Atlassian (Inside Atlassian) que mide el retorno real de un **SDLC nativo de IA** impulsado por **Rovo Dev**. En 3.400 repositorios de 2.500 clientes (un cuasi-experimento con emparejamiento por puntaje de propensión), los repositorios que adoptan la herramienta fusionan **19% más PR al mes**; hasta **37-51%** en repositorios de actividad baja/media y **59-87%** cuando **de 3 a 5 miembros** del equipo adoptan la herramienta. En cuanto a la eficiencia, los desarrolladores ahorran **2-3 h/semana** (≈10% de las 24 horas dedicadas a codificación y revisión), es decir, 20-30 horas/semana reinvertidas para un equipo de 10 personas. La tesis: resolver la «paradoja de la productividad» de Solow (1987) pasando de las **métricas de uso** (tokens) a las **métricas de impacto** (rendimiento, tiempo ahorrado, tasa de fallos, satisfacción). Recomendación: comenzar con un **equipo** (no un individuo) y medir 2-3 meses después.
Entrada de blog de **Pasquale Pillitteri** (ingeniero de software, Palermo) publicada el **29 de mayo de 2026** (versión FR), lectura de 18 minutos, sección *Claude Code & Anthropic*. **Tesis central**: *« Claude Opus 4.8 es el modelo de SEO más potente de 2026, pero casi todo el mundo lo usa mal »* — no es un problema de modelo sino un problema de **sistema**. La regla de oro: ***« la estrategia es una pizarra, la producción es una cadena de montaje »*** — el SEO debe **dividirse en dos fases distintas**, y mezclarlas es *« la forma más rápida de desperdiciar un modelo que cuesta cinco dólares por millón de tokens de entrada y veinticinco por los de salida »*. **Contexto del modelo**: Opus 4.8 se lanzó el **28 de mayo de 2026** (41 días después de Opus 4.7), contexto de **1M de tokens**, **GraphWalks Long-Context F1 a 1M: 40,3% → 68,1%**, **SWE-bench Verified 88,6%**, **USAMO 2026 96,7%** (+27,4 pts), **HLE con herramienta 57,9%**, precio sin cambios de **$5/$25** por millón de tokens, **Fast Mode 2,5× a $10/$50**, cuatro **niveles de esfuerzo** (Low, High, Extra, Max). **El antipatrón central** = *« la conversación gigante »* / **context drift**: mezclar estrategia, investigación de palabras clave, análisis competitivo y redacción en un único chat produce una *« amalgama de intenciones contradictorias »* → el modelo se desliza hacia **buenas prácticas genéricas** ("optimización holística", "enfoque estratégico") en lugar de contenido anclado en datos. **Fase 1 — Estrategia (pizarra, interfaz visual, puntual)**: dashboard / Google Sheet / lienzo de Claude.ai para decidir mientras se observan los datos juntos. **3 jugadas**: (a) **investigación de palabras clave clasificada** (tabla de volumen / dificultad 0-100 / intención / potencial de negocio / prioridad = volumen÷dificultad×peso de negocio); (b) **análisis competitivo visual** (matriz de cobertura de temas, huecos); (c) **hoja de ruta por fases** (quick wins M1-2 / medio plazo M3-6 / páginas pilar M7-12). El modo **Extra/Max** se justifica aquí (*« una decisión estratégica acertada vale más que mil páginas bien escritas sobre las palabras clave equivocadas »*). 3 artefactos cerrados guardados en Notion/Drive. **Fase 2 — Producción (cadena de montaje, Opus 4.8 + MCP)**: el modelo pasa de estratega a **máquina de ejecución**; cada decisión **anclada a datos en vivo** a través del **Model Context Protocol**. **Stack MCP mínimo**: **GSC MCP** (AminForou/mcp-gsc, 500+ estrellas), **Ahrefs MCP oficial** (98 estrellas), **GA4 MCP**; el repositorio `modelcontextprotocol/servers` = **86.440 estrellas**, **más de 10.000 servidores activos**, 97M de descargas del SDK al mes. Configuración ~35 min, actualización mensual ~20 min. **Bucle semanal**: un único prompt extrae datos en vivo, construye el brief (top 10 SERP + GSC + Ahrefs), deriva los H2/H3, redacta, verifica la densidad, sugiere títulos → **+45% de productividad**, borrador en **6-12 min** (referencia explícita al **content engineering de Ryan Law / Ahrefs**, 23 skills). Menciona los **Dynamic Workflows** de Anthropic (hasta 1.000 subagentes). **4 errores frecuentes**: (1) no verificar las cifras (comprobación puntual obligatoria, *trust & verify*); (2) sustituir por completo Semrush/Ahrefs (MCP es una **capa adicional**, no un sustituto); (3) ignorar el **desfase de contenido pago-orgánico** (caso de cliente de educación: **2.742 términos desperdiciados / 351 oportunidades** identificadas en 90 s); (4) usar Opus 4.8 donde **Haiku 4.5** basta (meta descripciones, texto alternativo). **Coste**: $1-3 por artículo de 2.500 palabras. **Sonnet 4.6** basta para la producción recurrente; Opus 4.8 se reserva para la estrategia. Artículo optimizado para SEO y autorreferencial (el autor escribe sobre SEO en un contenido diseñado a su vez para posicionar en "Opus 4.8 SEO"). Convergencia directa con **Ryan Law/Ahrefs** (citado), **sistemas alrededor del modelo** (Dropbox/Okumura), **skills-over-prompts** (Lattice), enrutamiento de modelos Haiku/Sonnet/Opus (Gupta token-to-outcome).
#Claude Opus 4.8#SEO con IA#flujo de trabajo en dos fases
**Pasquale Pillitteri** — Ingénieur informatique / développeur logiciel basé à **Palerme** (Italie) · certifié Innovation Manager UNI 11814:2021. Auteur d'un blog tech actif (rubrique *Claude Code & Anthropic*) · avec une newsletter hebdomadaire (~3,4k lecteurs). Article publié en version **FR** le **29 mai 2026** (lendemain de la sortie d'Opus 4.8).
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).
Ensayo fundamental de **Dan Shipper** (CEO de Every) publicado el **21 de mayo de 2026** en every.to, *"After Automation"* — una respuesta argumentada a la tesis del colapso del trabajo del conocimiento impulsado por la IA. **Tesis central**: el progreso de la IA crea **más trabajo para los humanos, no menos**. Mecánica cíclica (***"el ciclo de comoditización"***): (1) la IA comoditiza la competencia humana de ayer; (2) esa competencia abaratada se adopta ampliamente → abundancia; (3) la abundancia produce *homogeneidad* (el *"slop"*); (4) los humanos exigen diferenciación → demanda renovada de expertos; (5) los expertos usan la IA para abordar los problemas de hoy → vuelta al ciclo. **Cita canónica**: ***"hay más trabajo que hacer que nunca"***; ***"la IA comoditiza el residuo de la experiencia humana, creando demanda de lo diferente"***. **Marco conceptual central — Frame vs. Framer**: los benchmarks miden el desempeño ***"dentro de marcos"*** (encuadres específicos de problemas); una vez saturados, *cambiar el marco reinicia el contador* — los modelos **escalan dentro de los marcos, pero no reemplazan a quienes los definen**. Fórmula central: ***"el marco no es quien lo define"***. Incluso en la AGI, los humanos deben **especificar objetivos e interpretar resultados** — *"el problema del marco se regenera un nivel más arriba"*. **El "Human Sandwich"**: el humano define el marco → la IA ejecuta → el humano evalúa y extiende. **Dos modos de trabajar con agentes**: (a) ***agent employees*** — delegación asíncrona (compañero de trabajo / integrado — Claudie, Andy, Viktor, Fin); (b) ***colaboración humano-IA*** síncrona (Claude Code y equivalentes). **Datos de Every**: el 95% de los correos del CEO son procesados por IA; **Fin (Intercom) resuelve el 65% de las conversaciones de soporte**. **La paradoja de Zenón de la IA**: la IA cierra continuamente la distancia, pero los humanos siguen siendo "la tortuga por delante" porque están ***"vivos en un momento específico"*** — *"deseos en curso, preocupaciones en curso"* — mientras los modelos operan sobre datos de entrenamiento históricos. **Benchmarks detallados**: **GPT-5.5 = 62/100 en la reescritura de código Senior Engineer** (frente a un humano en 80-90); **GDPval**: 40-49% del nivel humano experto, **pero con un extenso encuadre humano**. **OpenClaw: 44.469 PR** en mayo de 2026 (frente a los 5.200 de Kubernetes en 2022) — prueba de que el trabajo agéntico crea *"más trabajo"*, no *"menos trabajo humano"*. **Implicaciones para la AGI**: incluso en la AGI, el **framer humano** sigue estando estructuralmente por delante — abordando problemas *"actuales, situados"* mientras el modelo opera sobre *"datos de entrenamiento históricos"*. **Conclusión anti-punto de inflexión**: esto no es un evento de punto de inflexión, es ***un patrón persistente*** que define el futuro del trabajo. **Relevancia mayor**: una contranarrativa explícita al *baño de sangre de cuello blanco de Amodei* / *subclase permanente de Sun* / *Anthropic Economic Index* — Shipper, **CEO de una empresa que convive a diario con agentes**, ofrece el marco teórico que concilia las dos observaciones empíricas (la IA hace más + los humanos siguen siendo indispensables). Fuerte convergencia con **Ng "No AI jobpocalypse"** (2026-05-08), **Mollick × roon ASI / FDE** (2026-05-10), **Tatsyi/Raiffeisen "AI made engineers different"** (2026-05-05), **Curran/Intercom 3× R&D** (2026-04-16) — todos describen a los humanos como *redistribuidos hacia el encuadre* en lugar de *reemplazados*. Tensión productiva con **Sun NYT permanent underclass** (2026-04-30), **Wallace-Wells AI populism** (2026-05-08), **Osmani Cognitive Surrender** (2026-05-05 — el framer humano debe permanecer activo). Para aprovechar en COMEX / DG / consejos directivos: vocabulario estratégico para 2026 — *"frame vs framer"* se convierte en la grilla canónica para la gobernanza de la IA.
#Dan Shipper#Every#after automation
**Dan Shipper** — CEO et co-fondateur de **Every** (média / studio AI-native, créateur de la newsletter *Every*, propriétaire du framework et plugin *Compound Engineering* — cf. fiche `shipper-klaassen-compound-engineering-every-agents-2025-12-11.md`). Profil rare : **opérateur-théoricien** · dirige une organisation entièrement augmentée par l'IA (95 % emails CEO automatisés, agents Claudie/Andy/Viktor en production, Fin pour le support) tout en publiant régulièrement des essais conceptuels sur every.to. Voix éditoriale anglo-saxonne de référence dans le corpus 2025-2026 sur les **modes de travail humain-IA**. Article publié sur **every.to/p/after-automation** le **21 mai 2026**.
Artículo de ingeniería publicado en el blog de **Uber** Engineering por seis ingenieros (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) el **21 de mayo de 2026**, que expone la **doctrina de identidad y control de acceso de agentes de IA** desplegada en producción en Uber para varios miles de agentes internos. **Tesis central**: los modelos de identidad existentes (humanos + cargas de trabajo) no logran describir la **agencia** — *"un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar"* — y pierden la **procedencia** a lo largo de los saltos de un flujo de trabajo agéntico. **Dos problemas operativos identificados**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delegación es el modo por defecto, los flujos de trabajo son composicionales (agentes que llaman a agentes que llaman a herramientas), el comportamiento es dinámico (los planes evolucionan según resultados intermedios); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"El contexto de ejecución (usuario de origen, agentes intermedios) se pierde a través de los saltos entre agentes."* **Arquitectura propuesta** como extensión de la Zero Trust Architecture de Uber: **Agent Registry** (fuente de verdad para las asignaciones agente↔carga de trabajo) + **AI Agent Mesh** (plano de datos entre agentes) + **STS (Security Token Service)** (emisión de JWT de alcance breve) + **MCP Gateway** (punto de aplicación de políticas para la invocación de herramientas) + **AI Gateway** (mediación de las llamadas a LLM externos con barreras de seguridad) + **SPIRE** (proveedor de credenciales de carga de trabajo). **Mecánica criptográfica**: las cargas de trabajo obtienen de SPIRE **SVID (SPIFFE Verifiable IDs)** firmados criptográficamente → el SDK solicita un JWT al STS mediante la identidad de la carga de trabajo → el STS verifica la autorización del agente contra el Agent Registry → se emite un token de vida corta (TTL del orden de minutos) para un **destino específico de un único salto** (claim `Audience` dirigido). **Doctrina central**: ***"Tokens de un único salto y de vida corta. Cada JWT emitido por el STS está pensado para un único salto, con un claim Audience específico y un tiempo de vida corto, del orden de minutos."*** **Preservación de la cadena de actores**: un ejemplo multisalto con el ingeniero de guardia `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; el JWT final transporta una **cadena de actores** verificable `[user1, oncall-agent, investigation-agent]`, lo que permite decisiones de acceso a nivel de herramienta basadas en el **historial completo de la solicitud**. **Estandarización**: un **Standardized A2A (Agent-to-Agent) Client** que automatiza los intercambios con el STS y la propagación de la cadena de actores — *"la ruta segura es también la ruta más fácil para que los desarrolladores implementen llamadas A2A"* — con una migración por fases de los agentes heredados. **Métricas de producción**: ***"la latencia P99 de la API STS Token Exchange se mantiene sistemáticamente por debajo de 40 milisegundos,"*** miles de agentes internos incorporados, un panel de observabilidad en tiempo real que traza las sesiones multiagente. **Visión a largo plazo — marco de tres capas**: (1) Identity & Trust Foundation (identidad de agente verificable + cadenas de delegación), (2) Dynamic Access Control (permisos basados en contexto + human-in-the-loop), (3) Unified Enforcement Plane (política centralizada y observable). **Alineación con estándares**: el grupo de trabajo IETF **WIMSE** + el draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, fundamentado conceptualmente en **OAuth 2.0 Token Exchange (RFC 8693)** y **SPIFFE/SPIRE** (graduado por la CNCF). La primera publicación de referencia de un hyperscaler ajeno a los laboratorios de IA (logística/movilidad) que industrializa la seguridad de los agentes a nivel de infraestructura, cerrando la brecha doctrinal entre los frameworks de skills/harness (Vincent, Lattice, PROJ-AI) y las cuestiones de identidad de nivel empresarial.
#Uber Engineering#identidad de agentes de IA#crisis de identidad de agentes
**Matt Mathew** (Sr Staff Engineer) · **Prasad Borole** (Staff Software Engineer) · **Meng Huang** (Engineering Manager) · **Sergey Burykin** (Sr Software Engineer) · **Gaurav Goel** (Software Engineer II) · **Bayard Walsh** (Software Engineer I). Tous chez **Uber** · équipe Security/Identity infrastructure responsable du déploiement de l'architecture d'identité agentique en production. Composition d'équipe représentative : un Engineering Manager · un Staff senior cadre · un Staff IC architecte · deux SWE séniors/intermédiaires · un SWE I — pattern classique d'une équipe Uber qui livre une plateforme transverse mission-critical.
Artículo pivote de **Ivan Chepurin & Travis Turner** (Evil Martians Chronicles, **19 de mayo de 2026**) — ***« AI-assisted engineers are burning out, is this fine? »*** — **diagnóstico estructurado del burnout entre desarrolladores asistidos por IA** y un **kit de intervención de 5 ejes**. **Tesis pivote**: la productividad acelerada por IA oculta un **coste oculto — el agotamiento del desarrollador**. *« Higher productivity doesn't translate to sustainable work practices or job satisfaction. »* Epígrafe de Shunryu Suzuki sobre la agitación mental. **TL;DR — 3 remedios esenciales**: (1) restaurar el disfrute del proceso, (2) reconstruir el logro / la propiedad / el orgullo, (3) eliminar la presión de la maximización continua de la productividad. **Marco narrativo central — Ben vs Alice**: Ben (codificación tradicional) = 4 h de trabajo estable, carga cognitiva distribuida, satisfacción al terminar; Alice (asistida por IA) = 2 h de trabajo de alta intensidad cognitiva, cambio continuo de tareas, **sin satisfacción** + llena el tiempo liberado con más tareas → **escalada exponencial de la carga** a pesar de la producción acelerada. **Fórmula canónica**: ***« We compensate for a lack of satisfaction with work quantity. »*** **Disrupción estructural del ciclo del oficio**: (planificación → elaboración → resultado) comprimido en (planificación → resultado), supresión de la fase meditativa de elaboración reemplazada por una **revisión de código cognitivamente exigente**. Convergencia directa con el **estudio HBR 2026** (citado): *« cognitive exhaustion from intensive oversight of AI agents is both real and significant »* + **investigación UC Berkeley 2026**: los trabajadores llenan las pausas naturales con tareas de IA. **Cambio de carrera silencioso** — concepto pivote: los desarrolladores contratados para programar ahora hacen **un trabajo diferente sin una transición de carrera consciente**. 4 vías posibles: (1) encontrar disfrute en la nueva estructura (priorizada), (2) ignorar la IA, (3) trabajar sin disfrute (insostenible), (4) cambiar de carrera. **5 factores diarios de burnout identificados**: (1) ***Perder el contexto*** — el agente porta la comprensión del proyecto externamente, desplazamiento de la deuda cognitiva del código a las personas, pérdida de la intuición del sistema; (2) ***Sin tiempo para el pensamiento pasivo*** — *« The model fills the silence before your own thinking has a chance to connect dots »* (duchas, paseos eliminados como momentos de resolución inconsciente de problemas); (3) ***Falsas expectativas*** — la velocidad inicial = línea base irrealista, las desaceleraciones posteriores vividas como fracaso; (4) ***Cuellos de botella de revisión*** — *« the more code is generated, the more code needs to be reviewed »*, carga cognitiva desproporcionada sobre los seniors, difusión de la responsabilidad; (5) ***Posibilidades infinitas*** — la baja fricción de prompting fomenta pivotes constantes, ausencia de delimitación natural. **Kit de 5 intervenciones**: (a) **Reconocer tus logros** (win-log, demos de equipo, seguimiento de horas); (b) **Repensar el flujo de trabajo con IA** (planificación > revisión, **3-4 iteraciones máximo**, sin cambio paralelo de tareas, separar las tareas intensivas en IA con pausas, descomponer); (c) **Seguir ejerciendo tu oficio** (horas de oficio protegidas sin IA, *modo « ask » > modo generación*, agentes desactivados en proyectos personales); (d) **Disciplina + equilibrio vida-trabajo** (horarios fijos, pausas reales, intenciones diarias, detenerse al terminar); (e) **Encontrar nuevas áreas de interés** (investigación de usuarios, habilidades blandas, analítica, ajuste fino de agentes + barreras de seguridad, optimización de rendimiento). **Conclusión**: *« AI can be helpful. Problems appear only if you misuse it. »* La evolución del sector = inevitable; el bienestar individual = controlable. Convergencia mayor con **Osmani Cognitive Surrender** (2026-05-05), **Frizzo "Year With Claude Code"** (2026-05-05 — *« writing muscle atrophy »*, *« deep flow rare »*), **Bedard BCG/HBR Brain Fry** (2026-03-05 — 1.488 empleados, pico de 3 herramientas, +39% errores, +39% intención de irse). Relevancia mayor para **CTO / VP Engineering / RR.HH. IT** que gestionan la retención de ingenieros aumentados por IA en 2026.
#Ivan Chepurin#Travis Turner#Evil Martians
**Ivan Chepurin** & **Travis Turner** — auteurs Evil Martians (cabinet de conseil ingénierie indépendant, Berkeley/global, ~150 ingénieurs, spécialiste Ruby on Rails / React / produits SaaS depuis 2010 ; éditeurs du blog *Evil Martians Chronicles* — référence dans la communauté Rails et JS). Article publié dans la catégorie **AI / Developer Community** sur evilmartians.com le **19 mai 2026**. Profil Evil Martians : voix éditoriale **opérateur-praticien** · articles longs ancrés dans le terrain produit · registre **soin du craft + lucidité business** · public habituellement développeurs / CTO / fondateurs early-stage.
Informe interno de desmontaje técnico sobre el lanzamiento de código abierto **`xai-org/x-algorithm`** (15 de mayo de 2026) — el algoritmo del **feed For You** de **X (antes Twitter)** en 2026, con cuatro líneas de recomendaciones de crecimiento adaptadas a la audiencia (personal/fundador, marca/empresa, marco generalizado, entregable de consultoría/cliente). **Tesis central**: ***« La famosa tabla de pesos de 2023 —las respuestas cuentan más que los me gusta por un gran multiplicador— describe un sistema que ya no existe en esa forma. »*** El algoritmo de 2026 es un **transformer (Phoenix, derivado de Grok-1)** que aprende pesos a partir del historial de interacción de cada usuario, evaluado frente a una **superficie multiacción de 19 dimensiones**, filtrado por un servicio offline de comprensión de contenido (**Grox**). **La forma de la puntuación importa ahora mucho más que las cifras — y las cifras en sí no están en el lanzamiento público**. **Arquitectura de 4 componentes**: (1) **Home Mixer** (Rust, orquestador en tiempo de solicitud, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, almacén en memoria alimentado por Kafka con publicaciones recientes, búsquedas de sub-milisegundo para candidatos in-network); (3) **Phoenix** (ML en JAX, recuperación two-tower + transformer de ranking, ~derivado de Grok-1); (4) **Grox** (offline, clasificadores de spam/seguridad/PTOS/banger + embedder multimodal v5). **Las 19 acciones predichas por Phoenix** (cambio clave respecto a 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (visualización de calidad de video condicionada por duración mínima), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continua). **Puntuación final** = `Σ (weight × P(action))` modificada por **3 multiplicadores estructurales**: (a) **OON_WEIGHT_FACTOR < 1** (penalización por fuera de red), (b) **decaimiento de diversidad de autor** `(1-floor) × decay_factor^position + floor` (atenuación exponencial de publicaciones repetidas del mismo autor dentro de un mismo render), (c) **umbral de duración de video** (vqv solo contribuye si `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Advertencia clave**: **ningún valor numérico de peso** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) está en el lanzamiento — todo es `crate::params::*`, gestionado por un servicio interno de feature-switch de X para pruebas A/B. ***« Cualquiera que diga que 'las respuestas valen N,N× más que los me gusta en 2026' está inventando una cifra que no se puede derivar del lanzamiento OSS. »*** **Diferencias clave frente a 2023**: (1) eliminación de todas las características diseñadas manualmente (*« Hemos eliminado cada una de las características diseñadas manualmente y la mayoría de las heurísticas del sistema »*); (2) un único modelo que predice 19 acciones frente a múltiples modelos de una sola acción; (3) Grox separa la comprensión de contenido del ranking; (4) nuevas señales de primer nivel (dwell continuo, vqv condicionado, follow_author, 3 variantes de share); (5) recuperación OON two-tower (frente a SimClusters+heurísticas) con embeddings multimodales de texto+imagen+video-ASR. **Tres capas de alcance** (marco generalizado): Elegibilidad (binaria, Grox+filtros) → Recuperación (probabilística, ANN two-tower) → Ranking (continuo, suma ponderada + multiplicadores). **Dos leyes del crecimiento mecánico**: (1) La red interna (in-network) es multiplicativa, la externa (OON) es aditiva; (2) La función del modelo es predecirte, no recompensarte. **Límite deliberado de honestidad**: el checkpoint de Phoenix publicado = versión mini (2 capas, 4 cabezas, 256 dimensiones, corpus de 537K publicaciones deportivas), no el modelo de producción; las integraciones Thrift están simuladas (`panic!("Not implemented")` en `candidate_features.rs`); las listas de brand-safety, los mapeos de ID de temas, las penalizaciones por idioma y las reglas de mezcla de anuncios están ausentes del lanzamiento público.
#algoritmo de X 2026#xai-org/x-algorithm#For You feed
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
Primera encíclica social del **Papa Léon XIV** (Robert Francis Prevost), fechada el **15 de mayo de 2026** (Roma, junto a San Pedro, 2º año del Pontificado), publicada con motivo del **135º aniversario de *Rerum Novarum*** (Léon XIII, 15 de mayo de 1891) y presentada explícitamente como una **continuación de la Doctrina Social de la Iglesia en la era de la IA**. Subtítulo canónico: *"sobre la protección de la persona humana en la era de la inteligencia artificial"*. **245 párrafos**, estructurados como **Introducción + 5 capítulos + Conclusión**. **Tesis central** organizada en torno a dos **iconos bíblicos**: la **Torre de Babel** (Gn 11) — uniformidad tecnológica sin Dios, *"absolutización de lo humano"* — frente a la **reconstrucción de los muros de Jerusalén por Nehemías** (Neh 2-6) — responsabilidad compartida piedra a piedra, escucha, coordinación entre familias. *"La primera elección no es entre un 'sí' o un 'no' a la tecnología, sino entre construir Babel o reconstruir Jerusalén"* (n. 9). **Conceptos canónicos**: (1) **IA "cultivada" más que "construida"** — *"los desarrolladores no diseñan directamente cada detalle, sino que crean una arquitectura sobre la que se desarrolla la IA"* (n. 98), una notable formulación teológica que se hace eco del vocabulario reciente de la investigación en ML; (2) ***"Desarmar la IA"*** (n. 110) — *"sacarla de la lógica de la competencia armada, que hoy ya no es solo militar sino también económica y cognitiva"*, haciendo la IA *"habitable, devolviéndola a la pluralidad de las culturas humanas"*; (3) **Crítica radical del "alineamiento"** — *"No podemos contentarnos con invocar la moralización de la máquina, lo que se llama el 'alineamiento' de la IA con los valores humanos, sin tener el valor de añadir una condición adicional: la posibilidad de debatir el código ético que se ha de utilizar"* (n. 107). ***"Una IA más moral no sirve de nada si esa moralidad la decide un puñado de personas."*** (4) **Asimetría epistémica** y **nuevos monopolios de la IA** (n. 109) — *"en un mundo donde unos pocos actores concentran datos, recursos de computación y poder regulador"*; (5) **Trabajo invisible** de etiquetadores de datos/moderadores/extractores de tierras raras (n. 109, 173) — *"cuerpos marcados, mutilados, utilizados para que el flujo de cómputo no se detenga nunca"*; (6) **Colonialismo de datos** (n. 178) — *"no domina solo los cuerpos, sino que se apropia de los datos"*, *"nuevas tierras raras del poder"*; (7) **IA y guerra** (n. 197-200) — *"Ningún algoritmo capaz de hacer moralmente aceptable la guerra"* (n. 198), tres criterios: responsabilidad personal trazable, negativa a acortar el tiempo del juicio moral, protección de los civiles; (8) **Crítica del transhumanismo/posthumanismo** (n. 115-117) como *"un archipiélago de islas conceptuales unidas por el mismo océano de presupuestos: la centralidad de la técnica y el sueño de superar los límites de la condición humana"*; (9) **El trabajo en la transición** (n. 150-156) — *"contrariamente a los beneficios anunciados de la IA, los enfoques actuales de la tecnología pueden paradójicamente descualificar a los trabajadores, someterlos a una vigilancia automatizada"*, el acceso al trabajo como prioridad pública, anticipación de la transformación, fijación de criterios sociales para la innovación; (10) **Pregunta canónica extraída de Juan Pablo II** (Redemptor hominis 1979): ***"¿hace la IA que la vida humana en la tierra sea 'más humana' en todos los sentidos? ¿La hace más 'digna del hombre'?"*** (n. 129); (11) **El auténtico "más que humano"**: no el transhumanismo, sino la gracia — *"logramos ser plenamente humanos cuando somos más que humanos, cuando dejamos que Dios nos lleve más allá de nosotros mismos"* (n. 128, citando a Francisco, *Evangelii gaudium*); (12) **Desarmar las palabras** (n. 214) — *"Desarmemos las palabras y ayudaremos a desarmar la Tierra"*. **Destinatarios**: *"A todos los fieles católicos, a todos los cristianos, a todos los hombres y mujeres de buena voluntad"* (n. 16) — un registro **universal** en línea con *Pacem in terris* (Juan XXIII 1963), *Laudato si'* (Francisco 2015) y *Fratelli tutti* (Francisco 2020). **Llamamiento especial a los desarrolladores de IA** (n. 111): *"cada elección de diseño expresa una visión de la humanidad"*. Fuente **magisterial** clave citada: *Antiqua et nova* (Dicasterios para la Doctrina de la Fe + Cultura y Educación, 14 de enero de 2025) + *Quo vadis, humanitas ?* (Comisión Teológica Internacional, 9 de febrero de 2026). Un documento mayor del **Magisterio social de 2026**, en la encrucijada entre la Doctrina Social ↔ la ética de la IA ↔ la geopolítica de las grandes tecnológicas ↔ la crítica del trabajo de los microworkers/extracción de tierras raras. Convergencia implícita con **Mensch / Mistral** (soberanía energética de la IA), **Sun / NYT Permanent Underclass** (cf. desplazamiento del trabajo hacia el capital), **Wallace-Wells / NYT AI Populism** (cf. crítica de los oligarcas tecnológicos), **Mollick × roon** (cf. ASI y política interna). Primera encíclica de un Papa que aborda explícitamente la IA como un **tema central y estructurante**, y no como un tema más entre otros.
#Léon XIV#Robert Francis Prevost#encíclica social
**Léon XIV** (de naissance Robert Francis Prevost) · 267e Pape de l'Église catholique · élu le **8 mai 2025** · premier pape américain de l'histoire (né à Chicago, USA, 1955 ; double nationalité américano-péruvienne). Augustinien (ancien Prieur général de l'Ordre de Saint-Augustin 2001-2013) · ancien évêque de Chiclayo (Pérou) puis Préfet du Dicastère pour les Évêques (2023-2025). *Magnifica Humanitas* est sa **première encyclique sociale** · signée *« Donné à Rome · près de Saint-Pierre · le 15 mai de l'année 2026 · la deuxième de mon Pontificat »* — date choisie pour **coïncider avec le 135e anniversaire de *Rerum Novarum*** (15 mai 1891) de Léon XIII · dont il a explicitement repris le nom de pontificat en référence à la tradition sociale lancée par son prédécesseur du XIXe siècle. La référence augustinienne est centrale dans le document (citations massives des *Confessions*, du *De civitate Dei* — *« deux amours ont fait deux cités »*, des *Enarrationes in Psalmos*, des *Sermones*). Trace de paternité collective : multiples références à *Antiqua et nova* (note conjointe DDF + DCE, 14 janvier 2025) et *Quo vadis · humanitas ?* (CTI, 9 février 2026) · suggérant un travail conjoint entre la Secrétairerie d'État · le Dicastère pour la Doctrine de la Foi · le Dicastère pour la Culture et l'Éducation · et le Dicastère pour le Service du Développement humain intégral.
Entrada del blog de **Zed** firmada por **Franciska Dethlefsen** (responsable de crecimiento y marketing), publicada el **14 de mayo de 2026** —al día siguiente del anuncio de Anthropic— para responder a las preguntas de los usuarios de Zed. **Tema**: a partir del **15 de junio**, Anthropic **divide la facturación de las suscripciones Claude en dos grupos**: uno para sus **herramientas propias** (chat, la CLI oficial de **Claude Code**), el otro para el **uso de agentes y SDK de terceros** (todo lo que pase por **ACP**, `claude -p` o una herramienta de terceros). El uso vía ACP **deja entonces de consumir los límites de Pro o Max** y pasa a un **crédito mensual «Agent SDK»**: **20 $ para Pro, 100 $ para Max 5x, 200 $ para Max 20x**. Una vez agotado el crédito, el uso continúa **a precios estándar de la API** si el excedente («overage») está habilitado; en caso contrario, las solicitudes se detienen hasta el siguiente ciclo. **La cifra que sostiene el artículo**: hasta entonces, las suscripciones habían subvencionado el uso agéntico en un factor de **≈15 a 30×** respecto al precio de la API, y los nuevos créditos se facturan **a las tarifas completas de la API**; de ahí que *«para quien use agentes intensivamente, esto supone un aumento de costo importante»*. **Se proponen tres opciones**, en un orden que revela la posición de Zed: (1) conservar la suscripción ejecutando la **CLI oficial `claude` en una terminal dentro de Zed** en lugar de vía ACP —*«cuando la CLI oficial de claude se ejecuta en la terminal, usa los límites de tu suscripción, no el nuevo crédito»*—; (2) usar el agente integrado de Zed con el proveedor que se prefiera (modelos alojados por Zed, claves de API, Copilot, Ollama local, DeepSeek); (3) conectar **cualquier agente ACP** —OpenCode, Codex, Factory, Cursor—, varios de los cuales aún ofrecen suscripciones con límites de tasa que subvencionan el uso intensivo. **La tesis de fondo**, y la verdadera razón de la entrada: *«ACP es un protocolo abierto… para que tu editor nunca quede atado a las decisiones de precios de un solo proveedor»*, con la anticipación explícita de que *«este tipo de cambio no será el último»*. **La entrada incluye un anexo fechado el 16 de junio de 2026** que anuncia que **el cambio queda suspendido**: ACP, `claude -p`, el Agent SDK y las aplicaciones de terceros siguen funcionando con las suscripciones **como antes**, sin crédito separado que reclamar, límites sin cambios, con Anthropic revisando su plan con un aviso previo anunciado. **El artefacto se contradice así a sí mismo**: su contenido más importante —la marcha atrás— es posterior en un mes a su propia fecha de publicación.
#Zed#Anthropic#suscripción Claude
**Franciska Dethlefsen** — head of growth and marketing chez **Zed Industries**. Le rôle est déterminant pour lire le texte : ce n'est pas un billet d'ingénierie mais une **communication de crise produit** · écrite le lendemain d'une annonce d'un fournisseur dont Zed dépend · à destination d'utilisateurs inquiets. La signature growth/marketing explique la structure (problème → options → réassurance) et le fait que l'argument protocolaire arrive en conclusion plutôt qu'en tête.
Continuous Delivery como base innegociable del desarrollo asistido por IA — Dave Farley, en su canal *Modern Software Engineering*, sostiene que sin CD la IA no es un acelerador sino una trampa (teoría de las restricciones y paradoja de Jevons aplicadas al código generado, ATDD/BDD como salvaguarda, pipeline de despliegue como árbitro de calidad).
#Continuous Delivery#IA generativa en el SDLC#ATDD (Acceptance Test-Driven Development)
Dave Farley (Modern Software Engineering — YouTube channel)
Testimonio de **Arthur Mensch** (cofundador y CEO de **Mistral AI**) acompañado de **Audry Herblin-Stoupe** (directora de asuntos públicos) ante la **commission d'enquête vulnérabilités numériques** de la Asamblea Nacional (presidida por Philippe Latombe, ausente — sesión presidida por el ponente). Testimonio bajo juramento, ~1h15, mayo de 2026. Tesis central de Mensch: ***"la nube es inteligencia artificial"*** — sin distinción entre servicios digitales e IA, la IA es la unidad atómica de la cadena de valor de la nube, desde los semiconductores (ASML) hasta el despliegue empresarial. **Mistral en 2026**: 1.000 empleados, valoración de 12.000 millones de euros, objetivo de **1.000 millones de euros de ingresos a finales de 2026**, 1.000 millones de euros invertidos en I+D durante el año, 30% de los ingresos en Francia / 70% fuera de Francia / ~75% en Europa, clientes: DINUM, Caisse des dépôts, France Travail, MACGM, Stellantis, TotalEnergies, BNP Paribas, ministère des Armées, Luxemburgo (administración central). **Marco conceptual de Mensch**: la IA es un **recurso natural** — *"transformamos electricidad en inteligencia, en generación de tokens."* Economía: 1 GW de centro de datos = **50.000 millones de dólares de inversión en 5 años**, genera **20.000 millones de dólares en tokens/año** ≈ 50% de margen bruto. A lo largo de la cadena electrón→token, **~10% del valor está en el electrón**, el 90% en otros eslabones (chips, software, servicios). **Tesis macro alarmista**: si Europa importa el 10% de su nómina en IA no europea, eso equivale a **un déficit comercial adicional de 1 billón de euros**; se necesitan 20 billones de euros de inversión en infraestructura para abastecer a Europa (40 GW en Francia / 400 GW en Europa). **Estrategia de soberanía**: ***"no pensar la soberanía como aislacionismo sino como palanca."*** **Presión temporal**: *"no tenemos tiempo"* — una ventana de **2 años** antes de que los recursos energéticos europeos sean monopolizados por los hiperescaladores estadounidenses, que despliegan **1 billón de dólares al año**. **Cinco diagnósticos operativos**: (1) Carga regulatoria = 5 personas dedicadas a cumplimiento normativo en Mistral, 27 regulaciones no sincronizadas, emprendedores que se marchan a EE. UU.; (2) Mercado fragmentado = ~60 operadoras de telecomunicaciones europeas frente a 3 en EE. UU.; (3) Contratación pública infrautilizada como palanca estratégica (50% del PIB de la UE); (4) Energía: 9 GW de excedente francés en riesgo de ser monopolizados por actores estadounidenses en 2 años; (5) La destilación = una técnica de reducción de costes, **no** una forma de ponerse al día tecnológicamente. **Doctrina de defensa**: Mistral trabaja con el ministère des Armées, rechazando explícitamente cualquier "supervisión" del uso final ("no tenemos legitimidad democrática"), un posicionamiento *anti-Anthropic-Mythos*. **Ciberseguridad**: reconoce las capacidades ofensivas de los modelos ("está aumentando de forma lineal y predecible, para todos al mismo tiempo"), se opone al *marketing del miedo* de un competidor estadounidense (implícitamente Anthropic). **Campus IA**: participación muy minoritaria, proveedor potencial (Mistral + hiperescaladores), 35.000 millones de euros MGX/Abu Dabi + Nvidia, 100 hectáreas en Saint-Arnoult, 1,4–1,6 GW (= Flamanville), energía nuclear francesa = huella de carbono reducida. **Anotación**: equipos de doctorandos (ya no microworkers), Madagascar para robótica con garantías salariales. **Modelo de negocio**: sin burbuja por el lado de la demanda, **cuello de botella de oferta** (chips, memoria, helio, electrones). **Conclusión de advertencia**: *"si no lo hacemos lo bastante rápido, nos convertiremos en un Estado vasallo."*
#Arthur Mensch#Mistral AI#Audry Herblin-Stoupe
**Arthur Mensch** (cofondateur et directeur général de **Mistral AI**) accompagné d'**Audry Herblin-Stoupe** (directrice des affaires publiques et de la communication, Mistral AI). Mensch a cofondé Mistral AI le 28 avril 2023 avec **Guillaume Lample** et **Timothée Lacroix** — tous les trois précédemment dans les *« gros acteurs américains »* (Google DeepMind / Meta FAIR). Audition tenue devant la **commission d'enquête de l'Assemblée nationale sur les vulnérabilités numériques** · présidée par **Philippe Latombe** (député MoDem, Vendée — absent ce jour). Séance présidée par la **rapporteur** (non nommée dans le transcript) · avec interventions du président lui-même (revenu en cours) · du député **Arnaud Saint-Martin** (LFI/Saint-Arnoult — sa circonscription accueille Campus IA) · et de la rapporteur sur les questions économiques.
Lanzamiento de **AI/works™**, una **plataforma de desarrollo agéntico** presentada por **Thoughtworks** como *"the new standard for building and running industrial-grade systems in the AI era."* El argumento central es **económico**: *"the old model made you pay millions to build, run, then pay again to rebuild — AI/works™ ends that routine."* La plataforma cubre **todo el SDLC** en torno a un concepto central, la ***Super Spec*** (una especificación dinámica y unificada que abarca arquitectura, flujos de trabajo, seguridad, datos y UX), con **seis capacidades**: Reverse Engineering (legado → especificaciones as-is), Dynamic Spec Development (requisitos en bruto → Super Spec), Spec to Code (coordinated agents que generan código verificable), Developer Experience (golden paths gobernados), Control Plane (orquestación de agentes con transparencia de costes, guardrails activos, trazabilidad de extremo a extremo), Runtime Ops (monitorización continua que detecta cambios, actualiza la Super Spec y regenera el código afectado). Metodología **3-3-3**: 3 días para alinear el concepto de producto, 3 semanas para el prototipo (deseabilidad/viabilidad/factibilidad), 3 meses para el MVP en producción. Reconocimiento de **Constellation Research**: *"changing the economics of enterprise software delivery"* mediante un enfoque *"spec-driven, lifecycle"*. Eslogan de apertura: ***"We are doing it again for the AI era"*** — que invoca la herencia de Thoughtworks en XP/CI-CD/microservicios. Posicionamiento anti-hype: *"stands on an engineering foundation rather than enthusiasm"*, *"no consultant crowds"*, *"finance can open the bill without switching on emergency lighting."* Socios destacados: AWS, GCP, Azure, Databricks, Snowflake + Claude, OpenAI, DeepSeek, Gemini, Grok + NVIDIA, Groq, Stripe, Spotify, CAST, Cyn DX, Mechanical Orchard.
#Thoughtworks#AI/works#marca registrada AI works
**Thoughtworks** (auteur collectif corporate, page produit/marketing). Aucun individu cité sur la page. Contexte des figures Thoughtworks pertinentes en arrière-plan : **Martin Fowler** (chief scientist emeritus, *Refactoring*, *Patterns of Enterprise Application Architecture*) · **Rebecca Parsons** (CTO emeritus) · **Birgitta Böckeler** (Distinguished Engineer, *Harness Engineering for Coding Agents*, fiche 2026-04-02) · **Matt Kamelman** (*Service-as-Software*, fiche 2025-12-03) · **Sam Newman** (*Building Microservices*).