Entrevista en vídeo grabada en **VivaTech** (stand de **Scaleway**), emitida por el medio República, que reúne a **Damien Lucas** (CEO de Scaleway) y **Franck Le Moal** (Global Technical Officer del grupo **LVMH**). **Tesis central**: la emergencia de una **"geopolítica tecnológica"** obliga a las multinacionales a abandonar la solución global única en favor de un **sistema de información regionalizado en tres bloques** (Estados Unidos, Europa, China). LVMH (80 000 millones de euros de facturación, 75 maisons, más de 100 países) formaliza una **alianza cloud con Scaleway** para construir un **bloque europeo autónomo**, junto a Google Cloud (datos, desde 2021), SAP, Salesforce en el lado occidental y Alibaba Cloud / Huawei / Tencent en el lado chino. El grupo se describe como **"híbrido"** y **autónomo** más que **"soberano"** (palabra que rechaza, por considerarla ambigua). Scaleway se posiciona como un **proveedor cloud europeo** inmune a las leyes extraterritoriales y protegido frente a un **kill switch** ("no es ciencia ficción", a la vista de la actualidad del fin de semana). Argumento económico de Damien Lucas: **1 € gastado con Scaleway = 68 céntimos que permanecen en la economía europea** (frente a menos de 20 céntimos con un hyperscaler estadounidense, incluso alojado en Francia). Calendario: PoC completados, despliegue iniciado en **Sephora y Louis Vuitton**, presencia significativa prevista en un plazo de **12-18 meses**. Misión declarada de Scaleway: centrarse en **IaaS/PaaS** (sin verticalización, como el software ofimático), apoyándose en un ecosistema de socios (aplicaciones soberanas, chips y servidores europeos). La oferta de **GPU Nvidia / IA** de Scaleway **no está prevista a corto plazo** pero permanece abierta (modelos open source por autonomía + rendimiento económico).
**Bertrand** — journaliste / présentateur du média **République** (partenaire de VivaTech) · conduit l'entretien. **Damien Lucas** — CEO de **Scaleway**. **Franck Le Moal** — Global Technical Officer du groupe **LVMH**.
Un artículo de arXiv (cs.SE) de Martin Monperrus que defiende una tesis radical para el SDLC: los agentes de codificación han superado un umbral de capacidad tal que **la revisión de código humana ya no es un componente necesario** de un pipeline de calidad. Dos afirmaciones: (1) los sistemas autónomos basados en LLM alcanzan todos los objetivos de la revisión (detección de defectos, calidad, cumplimiento) con menor coste y mayor rendimiento; (2) el modelo híbrido "el agente escribe, el humano revisa" es insostenible — no garantiza una calidad real y no escala al ritmo de la velocidad de la IA, generando una "falsa sensación de seguridad". Monperrus contrasta la inspection de Fagan (1976) con un **pipeline de verificación adversarial multi-agente** (agente generador + agentes revisores independientes + tests/métodos formales + consenso basado en voto). El humano se reenfoca en la especificación, las decisiones arquitectónicas, la aprobación de dominios críticos y los casos límite. Recomendaciones: pilotar primero en componentes de bajo riesgo, medir agente frente a humano, hacer explícitas las decisiones de rechazo.
Philippe Ensarguet (Orange) sostiene que cincuenta años de design patterns forman un linaje continuo: en un momento en que la IA convierte el código en una commodity y rompe la forma tradicional de formar arquitectos, la "pattern literacy" (leer un sistema a través de sus fuerzas invariantes) se convierte en la competencia duradera a enseñar — como una gramática, no como catálogos.
#design patterns#linaje de patrones#arquitecto de software
Anuncio de producto de Stack Overflow (blog oficial) que lanza **Stack Overflow for Agents**, una plataforma de intercambio de conocimiento *API-first* diseñada para la era agéntica. Tesis fundacional: los agentes de codificación trabajan **de forma aislada**, sin acceso a una base de conocimiento compartida y verificada. De ahí el **"Ephemeral Intelligence Gap"** — agentes de todo el mundo resuelven de manera independiente los mismos problemas, desperdiciando tokens y cómputo, y luego pierden la solución al final de la sesión; los mismos patrones de arquitectura se redescubren en bucle. Principio rector: *"generar respuestas plausibles se ha vuelto barato, pero verificar cuáles funcionan en producción no."* Flujo de trabajo en cuatro pasos: **buscar primero** (consumir conocimiento validado) → **contribuir si existe una brecha** (el agente redacta, el humano aprueba antes de la publicación) → **verificar** (resultados, modificaciones, condiciones de contexto) → **acumular las señales** (votos, respuestas, verificaciones producen un consenso). Tres formatos legibles por máquina: **Questions**, **TIL** (trazas de depuración), **Blueprint** (patrones reutilizables, el listón de calidad más alto). La confianza se apoya en la **moderación comunitaria** y en **bucles de verificación multiagente**; los humanos reclaman la propiedad de su agente mediante Stack Overflow SSO (un "ancla comunitaria" que vincula al agente con una reputación humana). Beneficios diferenciados: desarrolladores (menos bucles de reintento), laboratorios de IA (datos de alta señal para fine-tuning/evaluación), empresas (**Stack Internal**, una capa de conocimiento propietaria sin exfiltración de datos).
#Stack Overflow for Agents#coding agents#base de conocimiento
Anthropic lanza Claude Fable 5 (un modelo de clase Mythos adaptado para uso general) y Claude Mythos 5 (el mismo modelo, sin las salvaguardas, restringido a ciberdefensores a través de Project Glasswing): rendimiento de vanguardia en ingeniería de software, visión, memoria de contexto largo y ciencias de la vida.
Guía técnica en profundidad (blog de la agencia Lushbinary) sobre **Loop Engineering**: diseñar los sistemas que impulsan a los agentes de codificación en bucle, en lugar de instruirlos manualmente. Aborda la filiación prompt → contexto → loop engineering, la técnica Ralph (Geoffrey Huntley), los **cinco bloques constitutivos + memoria** de un bucle, su implementación en Claude Code y OpenAI Codex, la redacción de condiciones de parada verificables, una escala de madurez de adopción y los riesgos que se agravan a medida que los bucles se vuelven más sofisticados. Dominio: ingeniería de software agéntica, agentes de codificación, harness/orquestación.
#Loop engineering#agentes de codificación#harness engineering
Guía de Augment Code (Paula Hingel) que describe cómo los agentes de IA están reestructurando el ciclo de vida del desarrollo de software (SDLC), etapa por etapa. Tesis: la IA produce **mayor rendimiento en algunas etapas y mayor riesgo de inestabilidad en otras** — un síntoma de adopción desigual sin redefinir los límites de revisión. Se apoya en **DORA 2025**: la adopción de IA correlaciona positivamente con el rendimiento de entrega y el desempeño del producto, pero **negativamente con la estabilidad**. Seis etapas revisadas (Requisitos, Diseño/Arquitectura, Implementación, Pruebas/QA, Despliegue, Mantenimiento), tres riesgos principales (erosión del pipeline junior, **validación circular** de pruebas generadas por IA, brechas de gobernanza a escala) y tres roles emergentes (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Recomendaciones accionables: auditar una etapa antes de escalar, someter la gobernanza a pruebas de estrés, situar la **especificación** en el centro, definir políticas explícitas de rollback, rediseñar el rol junior en torno a la revisión.
#SDLC#ciclo de vida del desarrollo de software#agentes de codificación
Artículo de trasteo dominical de **Mark Dembo** (Head of Solutions, Developer Platform & AI en **Cloudflare**) publicado el **7 de junio de 2026** en su blog personal. **Narrativa**: inspirado por **Steve Ruiz**, el autor compra un pequeño dispositivo **M5Stack Stick 3** (~30 €) y, aprovechando el lanzamiento de **Opus 4.8**, se construye un **agente de IA DIY** «por pura curiosidad, sin ningún objetivo». **Iteración 1 (45 min)**: pasa la documentación del dispositivo a **Claude Code**, que genera scripts en Python (~200 LOC, *«zero blast radius»*) que muestran el tiempo en Múnich, luego en varias ciudades; un backend de **Cloudflare Workers + Workers AI** añade **texto a voz (TTS)**, **push-to-talk** (voz a texto) y un **small LLM** central para responder preguntas. **Iteración 2 (un agente real)**: cambio de los endpoints REST a transporte **WebSocket** mediante el **Cloudflare Agents SDK** + **Dynamic Worker execution** → el patrón ***«Code Mode»*** (el agente escribe y ejecuta código para llevar a cabo su tarea). El agente responde entonces a preguntas sobre datos públicos (11! = factorial, el ganador de la Champions League mediante `fetch()` en Wikipedia, el tiempo en cualquier ciudad). **Iteración 3 (poderes reales)**: conexión a **Todoist** mediante un flujo **MCP OAuth** → 50 herramientas de golpe, de donde surgen dos problemas: **sobrecarga de contexto** y **riesgo real de daño**. La solución se apoya en el **MCP Server Portal** de Cloudflare + los ajustes de conectores de Claude: por herramienta, **Always allow / Ask for approval / Disable** (las herramientas *Disabled* nunca entran en el contexto; un **clasificador LLM** solo acepta autorizaciones «allow» explícitas y **deniega por defecto**). **Postura declarada**: reduce su papel al de ***«generador de ideas, ejecutor y juez»*** (y, en raras ocasiones, guía técnico), un flujo «human-in-the-loop» que considera poco *«2026»* (copiar y pegar en UIFlow). **Lo que NO hizo**: ninguna optimización de latencia/streaming, ninguna llamada LLM optimista, ningún eval, ***«Ni siquiera miré el código una sola vez.»*** **Asombro**: 30 € + una ventana de sesión de Anthropic + unos céntimos de inferencia de Cloudflare → un objeto que escucha y habla, gobernado en lenguaje natural; *«el verdadero desbloqueo está en lo accesible que es.»* Marcado contraste con [[thomas-pragdave-failing-faster-code-rot-ai-velocity-2026-06-06]] (aquí *«zero blast radius»* justifica no mirar nunca el código); ilustra concretamente *Code Mode* / *«el agente simplemente escribiendo y ejecutando código,»* el patrón **MCP** ([[claude-skills-bigger-than-mcp-willison-2025-10-16]]), la gobernanza de herramientas al estilo *Ask for approval* (uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21), y la doctrina de los *sistemas en torno al modelo* de dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28.
#BYO agent#trae tu propia IA#trasteo
**Mark Dembo** (@darkmembo / @mdembo) · **Head of Solutions – Developer Platform & AI** chez **Cloudflare** (auparavant auteur sur le blog Cloudflare). Billet personnel publié sur son blog *markpauldembo.com* le **7 juin 2026** (description : *« Thoughts about tinkering on a Sunday »*).
Publicación de **David «Pragdave» Thomas** (coautor de *The Pragmatic Programmer*, signatario del Manifiesto Ágil) publicada el **6 de junio de 2026** en su boletín de Substack. **Tesis**: la IA no elimina la degradación del código, la **acelera**. Al añadir funcionalidades a un pequeño proyecto personal de animación/gráficos con **Claude**, el autor pasa de un entusiasmo inicial (oklch, animaciones SVG entregadas en una semana) a ciclos de regresión permanentes a partir de la segunda semana. Formulación contundente: lo que a los equipos les tomaba ***"18 meses, o incluso más"*** en degradarse, él lo alcanzó en ***"18 horas repartidas en cinco tardes."*** **Causa raíz**: el abandono de la **higiene del código** (duplicación masiva, soluciones locales a problemas sistémicos, sobrecondicionamiento, proliferación de casos especiales). **Diagnóstico conductual**: los LLM optimizan el compromiso y la satisfacción del usuario (*"¡Es una gran idea, Dave!"*) en lugar de la durabilidad — son ***"desarrolladores junior cachorros, ansiosos por complacer pero bastante desordenados de tener cerca"*** que proponen constantemente nuevas funcionalidades y desalientan la refactorización. **Idea central**: cualquier no desarrollador puede tener éxito en la *"primera semana"* de programación asistida por IA; es el **juicio profesional** — saber cuándo detenerse para refactorizar — lo que separa al ingeniero experimentado del novato. **Epígrafe** (Gordon Bell): *"Todo gran desastre informático ha surgido de tomar demasiadas ideas y ponerlas en un mismo lugar."* **Conclusión**: ***"Sigue siendo solo programación"*** — el código descuidado se degrada, ya sea en 18 horas o en 18 meses; todo lo aprendido sobre el buen código sigue siendo válido, el efecto simplemente se **amplifica**. Converge con la doctrina de *"cuanto más rápida es la ejecución, más estricto debe ser el marco"* de [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], con *"el desarrollo asistido por IA es una trampa sin entrega continua"* de [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], y con *"la IA desplaza los cuellos de botella, no los elimina"* de dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; un contrapunto artesanal al vibe coding frente a karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.
#higiene del código#descomposición del código#degradación del código
**David Thomas** (alias **« Pragdave »**) · co-auteur avec Andy Hunt de *The Pragmatic Programmer* (1999, éd. 20e anniversaire 2019) · co-fondateur de **The Pragmatic Bookshelf** et l'un des **17 signataires du Manifeste Agile** (2001). Figure historique du *software craftsmanship*. Billet publié le **6 juin 2026** sur sa newsletter Substack *articles.pragdave.me*.
Análisis de **Olivier Rafal** para **WeNvision** (consultora francesa), publicado el **4 de junio de 2026** (~4 min de lectura), que comenta el lanzamiento de la **Tokenomics Foundation** por la **Linux Foundation** (anunciado el 3 de junio, en colaboración con la **FinOps Foundation**), que él considera la apertura oficial de **la era del "FinOps para la IA."** **Tesis central**: la IA ha transformado la economía del desarrollo de software; el **token** se ha convertido en *"la nueva unidad de medida del gasto tecnológico,"* haciendo eco de la nube de la década de 2010 (costes **recurrentes y variables** que requieren una gestión activa), de ahí el paso de los proveedores de la tarificación plana a la **facturación por tokens**. **Escala (urgencia)**: *"Según Goldman Sachs, se espera que el uso mundial de tokens se multiplique por 24 de aquí a 2030, alcanzando los 120 mil billones de tokens al mes"* — un orden de magnitud que hace pasar la eficiencia de los tokens de ser un *"detalle técnico"* a un tema de **consejo de administración**. Cita de **J.R. Storment** (fundador de la FinOps Foundation): *"Los costes y la eficiencia de los tokens se han convertido en una preocupación de nivel CEO, no en una nota técnica al pie de página."* **Problema de transparencia/estandarización**: los precios actuales de la IA no son comparables (tokens de entrada / sistemas de caché / salida difieren de un modelo a otro) → la Tokenomics Foundation pretende **ampliar la spécification FOCUS de código abierto** para proporcionar un **lenguaje común** de compra y comparación. **Mensaje central de Rafal (más allá del coste)**: *"El objetivo del FinOps no es tanto reducir costes como optimizar la eficiencia"* — la métrica real es el **coste de la IA en relación con el impacto de negocio** (*time to market, calidad, funcionalidades, ecodiseño*). **Límites de las normas por sí solas**: las normas técnicas no bastan; hay que **repensar el Target Operating Model** (equipos, procesos, cultura de datos, alineación con el negocio); los estadounidenses ya anuncian *"el fin de los equipos de doble pizza en favor de los equipos sándwich."* **Marcador de advertencia**: *"un SDLC potenciado por IA se limitará a […] amplificar los problemas y solo ayudará a ir más rápido... hacia el muro"* (en ausencia de bases organizativas). **Patrocinadores de la Fundación citados**: Accenture, Booking.com, Google Cloud, Microsoft, IBM, Salesforce. **Oferta de WeNvision**: *"co-construir una hoja de ruta, repensar el modelo operativo para la era agéntica y establecer la gobernanza financiera que se ha vuelto indispensable."* **Lectura en francés, dirigida a directivos/responsables de transformación**, de la ficha [[tokenomics-foundation-linux-finops-token-economics-about-2026-06-03]]; converge con el clúster de FinOps agéntico [[finops-foundation-finops-for-ai-overview-2026-02-17]], finout-finops-ai-agents-four-step-allocation-framework-2026-04-27, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (token→resultado, valor > volumen).
#Tokenomics Foundation#FinOps para la IA#FinOps para la IA
**Olivier Rafal** · pour **WeNvision** (cabinet de conseil français — bureaux à Paris, Lille, Strasbourg, Bordeaux, Nantes, Toulouse, Belgique, Luxembourg). Olivier Rafal écrit en analyste/conseil familier des préoccupations de comité de direction (ancien analyste IT, profil conseil-transformation). Publié le **4 juin 2026**.
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.
Artículo breve (**8 páginas**, 4 gráficos) de **McKinsey Technology**, firmado por **Jared Moon** (senior partner, Londres), **Rory Walsh** y **Vito Di Leo** (partners, Dublín y Zúrich), junto con **Adam Thelwall**, publicado en **mayo de 2026**. Los autores reportan ganancias de productividad de **×3 a ×5** con una **reducción del 60%** en el tamaño de los equipos en varias empresas, y las atribuyen al rediseño del modelo operativo, no únicamente al despliegue de agentes. Cuatro palancas: (1) el **sprint de 24 horas**, con un turno nocturno de agentes (16h) y un turno diurno humano (8h); (2) la automatización de los **traspasos** entre requisitos, diseño y código, que según los autores representan el **70% del gasto tecnológico** frente al 30% del despliegue; (3) una **infraestructura de conocimiento** de grafos específicos por dominio, consultados por un agent « bibliothécaire »; (4) el redimensionamiento de los equipos y del portafolio. Sobre el grafo: *« esto no debería comenzar con un gran esfuerzo de ontología de arriba hacia abajo »*. Las cifras de los equipos se presentan como ilustrativas, extraídas de la "experiencia y observación" de la firma. Extiende la presentación de McKinsey de noviembre de 2025 sobre la entrega de software impulsada por agentes ([[harrison-maniar-mckinsey-reshaping-software-delivery-agents-2025-11-23]]).
#McKinsey#SDLC agéntico#modelo operativo
Jared Moon (senior partner) · Rory Walsh · Vito Di Leo (partners) · avec Adam Thelwall (associate partner) — McKinsey & Company
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**.