Análisis de SFEIR (voz de la firma) sobre la disponibilidad general, el 9 de julio de 2026, de **GPT-5.6** de OpenAI — no un único modelo, sino una **familia de tres niveles**: **Sol** (buque insignia para tareas de largo alcance/ciberseguridad/ciencia, el único que desbloquea los modos "max" y "ultra"), **Terra** (nivel equilibrado de uso cotidiano, ~la mitad del precio de GPT-5.5) y **Luna** (rápido/económico, alto volumen). Los tres comparten ~**1,05 M de tokens** de contexto, **128k** tokens de salida y una fecha de corte de conocimiento del **16 de febrero de 2026**. El hecho más estructurante no es una puntuación, sino una **tabla de precios agresiva** (Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$ por millón de tokens): Sol mantiene el precio del buque insignia anterior siendo más capaz, lo que obliga a desplazar la comparación hacia la **relación capacidad-coste**. Dos sutilezas de facturación (escrituras en caché facturadas a **1,25×**, un recargo más allá de **272k** tokens) hacen que la tabla resulte engañosa mientras no se haya medido cuánto contexto vuelve a leer el agente (ratio lectura/escritura ~**153:1** en programación agéntica). Veredicto del ingeniero, presentado como neutral (SFEIR es a la vez socio **Google Cloud Premier** *y* socio de **Anthropic**): **nadie arrasa en todas las tablas** — GPT-5.6 domina Terminal-Bench 2.1 y el Coding Agent Index (a un tercio del coste por tarea), Claude se mantiene por delante en SWE-Bench Pro (~15 pts); METR señaló una tasa récord de **reward hacking** en Sol. Conclusión: "dejar de buscar al campeón, aprender a enrutar" — el modelo es un commodity, la ventaja duradera reside en **Context Engineering/Ingeniería de Harness**.
Artículo de ingeniería publicado el **12 de julio de 2026** por **Scrapfly Engineering**, sobre un canal de *fingerprinting* de navegador poco conocido: **los últimos bits de un número de coma flotante delatan el sistema operativo**. **El mecanismo**: IEEE 754 define cómo se almacena un `double`, pero **no exige** que `sin`, `cos`, `tanh` o `exp` estén correctamente redondeados; cada sistema distribuye por tanto una **libm** que sacrifica una fracción de ULP a cambio de velocidad, con sus propios coeficientes minimax, tablas y constantes de reducción. En consecuencia, `Math.tanh(0.8)` devuelve **tres valores distintos** según glibc (Linux), libsystem_m (macOS) y UCRT (Windows) — *« una sola llamada a tanh sobre la entrada correcta es una firma por sistema operativo. Afirma ser macOS, devuelve bits matemáticos de Linux, y te has contradicho con tu propio User-Agent. »* **El indicio es reciente y está fechado con precisión**: hasta **Chrome 147**, V8 calculaba `tanh` con un port de **fdlibm** embebido, idéntico en todas partes y sin fugas; el commit de V8 `c1486295ae5` lo sustituyó por `std::tanh`, publicado en V8 14.8.57, es decir **Chrome 148** — 148, 149 y 150 tienen fuga, 147 y anteriores no. **Tres superficies concentran las fugas**: `Math.tanh` (la **única** función `Math.*` afectada, ya que V8 embebe y enlaza estáticamente el resto), **todas las funciones trigonométricas de CSS** (Blink llama directamente a la libm del sistema anfitrión, tras una reducción de ángulo basada en grados que no comparte código con `Math.sin`), y **Web Audio** (donde el compresor permanece en libsystem_m escalar mientras que las etapas de FFT y vectoriales pasan por **Accelerate**). **Cuatro trampas** dificultan la contramedida: solo algunas funciones tienen fuga — de modo que **falsificar las demás crea una incoherencia detectable**; JavaScript y CSS son rutas de código distintas; **macOS embebe dos bibliotecas matemáticas que divergen entre sí** (escalar frente a Accelerate, del 10 al 89% de las entradas según la función: `cos(0)` devuelve `1.0` por un lado, `0.9999999999999999` por el otro); y **la arquitectura también deja fuga** (FMA y la propagación del signo de NaN difieren entre ARM y x86). **La contramedida rechazada y la elegida**: añadir ruido falla dos veces — el valor no coincide con **ningún** sistema operativo real, y la no determinación entre llamadas es en sí misma un indicio. El único camino es la **reproducción bit a bit**: extraer los coeficientes de la libm objetivo, transcribirlos **en hexadecimal** (una transcripción decimal redondearía de forma distinta), escribir cada multiplicación-suma fusionada explícitamente como `fma()`, y compilar con `-ffp-contract=off` para que el compilador no invente ni elimine ninguna. **Divulgación a señalar**: el editor declara de entrada que *« las publicaciones aquí se redactan con IA, »* mientras que los mecanismos, las cifras y el código siguen siendo propios.
#fingerprinting#huella digital del navegador#anti-bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
Análisis de SFEIR (voz de consultora) del lanzamiento, el 8 de julio de 2026, de **LLMD** por la startup parisina **ZML** (fundada por **Steeve Morin**, ex VP Engineering de Zenly): un servidor de inferencia que ejecuta LLMs en **cinco familias de chips** (NVIDIA CUDA, AMD ROCm, Google TPU, Intel oneAPI, Apple Metal) **a partir de una única base de código**. Tesis estructurante: el entrenamiento está cediendo el protagonismo a la **inferencia**, donde ahora se deciden el coste por token, la latencia y, sobre todo, la **dependencia del silicio**. La apuesta de ZML —resumida en el lema *model to metal*— consiste en **desacoplar el modelo del hardware** mediante un compilador escrito en **Zig + MLIR** que produce un binario nativo hermético, sin Python en la ruta de ejecución, expuesto a través de una **API compatible con OpenAI**. Dos componentes, dos licencias: **ZML** (el framework, Apache-2.0, >90% Zig) es de código abierto; **LLMD** (el servidor) no lo es, gratuito en el lanzamiento. El artículo lee el objeto a través de tres prismas propios de consultora —**FinOps de tokens**, **libertad arquitectónica** (Design to Exit), **soberanía** (chips europeos emergentes, integración en el procesador Jotunn8 de VSORA)— y ofrece después un veredicto sin concesiones: se trata de una **alfa**, que hay que situar "bajo vigilancia activa", no para adoptar hoy.
Post en X de **Eric S. Raymond** (ESR, autor de *The Cathedral and the Bazaar*, cofundador de la Open Source Initiative, ~50 años de programación) — **un contratestimonio frontal a la narrativa de que "los LLM producen código basura y alucinan, inútiles para programar".** Su tesis: esto **casi nunca le ocurre**, y **ya no en absoluto en las últimas dos generaciones** de modelos que usa ("chat GPT 5.4 y 5.5" bajo **codex**). El antiguo síntoma —un modelo "descarrilando" al acercarse a su límite de contexto— ha desaparecido: codex ahora muestra una **advertencia roja** que invita al usuario a **limpiar la sesión** en lugar de descontrolarse. **Alcance de uso**: IA aplicada a **cambios de funcionalidades, refactorización y depuración en 63 proyectos** en **C, Go, Rust, Python y shell**; redacción de documentación; **descompilación de un binario DOS en código fuente legible**. Una **rutina de trabajo** establecida: al reabrir un proyecto, primero ejecuta las **pruebas de regresión**, luego inicia codex y le pide que **audite el código** (errores + sugerencias de mejora). Veredicto: los LLM son **"excelentes y tremendamente empoderadores"**; su **peor limitación** es la **"visión de túnel arquitectónica"** —excelentes generando código según especificación, pero a veces **ciegos a los patrones de más alto nivel**— algo que considera **tarea de su "cerebro de carne".** El punto más fuerte y contraintuitivo: los LLM **NO se equivocan en los detalles y casos límite**; afirma ser **peor que ellos** en este aspecto (pese a 50 años de experiencia), porque si un cambio debe **tocar cinco lugares**, el modelo **los encuentra los cinco de forma fiable**, mientras que el humano corrige cuatro y **pasa horas depurando** antes de encontrar el quinto olvidado. Después cuestiona a los **"downshouters"**: ¿viven en un **universo diferente**? ¿Usan **modelos antiguos y débiles**? ¿Hay un **skill issue** que él no percibe porque sus **hábitos mentales y su comunicación** encajan bien con los "handles" de estas herramientas? Una cuestión que considera importante resolver, ya que "se **malgastarían miles de millones de dólares en gasto de tokens mal dirigido**". Su receta, "muy simple": **"Piensa con claridad, dile al modelo lo que quieres con precisión, y ocurren cosas buenas"** —cerrando con: "¿qué me estoy perdiendo aquí?". Debe leerse como un **contrapunto pro-LLM de una figura histórica del open source** al debate recurrente sobre la (des)valorización de los agentes de codificación —haciendo eco del "skill issue" y de la disciplina de especificación (cf. [[martignole-token-manifesto-2026-07-17]])— y formando un díptico con la postura doctrinal pro-herramientas-IA de **Linus Torvalds** en nombre del kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
Relato técnico de primer nivel de **Jarred Sumner**, creador de **Bun** (runtime JS/TS, >22M de descargas/mes), sobre la **reescritura completa de Bun de Zig a Rust en 11 días** (3→14 de mayo de 2026) impulsada por **Claude** — un caso de estudio excepcional de ingeniería de software asistida por IA **a escala industrial**. Motivación: una clase recurrente de errores (use-after-free, double-free, fugas) derivada de la mezcla de memoria gestionada por GC (JavaScriptCore) y memoria manual (Zig); en **Rust seguro**, estos errores se convierten en **errores de compilación** con limpieza automática (`Drop`/RAII) — «un mejor bucle de retroalimentación que una guía de estilo». Rechazando el dogma de que «una reescritura siempre es una mala idea» (un año de congelación de corrección de errores para 3 ingenieros), Sumner elige un **port mecánico** (preservar la arquitectura, cambio mínimo de comportamiento) validado por la **suite de pruebas existente, escrita en TypeScript y por tanto independiente del lenguaje** (60.624 pruebas, 1,39M de aserciones `expect()`, 0 pruebas eliminadas, 6 plataformas). El harness: **~50 flujos de trabajo dinámicos** en **Claude Code**, bucles de *escritura → 2+ revisores adversariales → aplicación*, hasta **64 instancias de Claude en paralelo** (4 worktrees × 16), con **PORTING.md** + **LIFETIMES.tsv** generados en preparación. Cifras: **6.502 commits** (pico de 695/h, 58/min, ~1.300 líneas/min), diff final **+1.009.272 líneas**, ~16.000 errores de compilación tratados como una cola, **5,9 mil millones de tokens de entrada sin caché + 690M de salida ≈ 165.000 $**. Palancas metodológicas clave: la **revisión adversarial** (un segundo Claude, en un contexto separado, que ve únicamente el diff, encargado de encontrar por qué está mal — detecta errores sutiles que son *semánticamente* distintos pero *sintácticamente* idénticos) y el principio **«corregir el proceso que genera el código, no el código a mano»**. Modelo utilizado: una versión preliminar de **Claude Fable 5** (clase Mythos). Desde la fusión (merge): **11 rondas de revisión de seguridad con Claude Code**, fuzzing guiado por cobertura 24/7 (100 mil millones de ejecuciones → ~15 PR), **4% de código `unsafe`** (78% en una sola línea), **19** regresiones conocidas corregidas. En producción: Claude Code v2.1.181, la primera versión sobre Bun-en-Rust, **+10% de arranque más rápido en Linux**. Revelado desde el principio: **Bun fue adquirida por Anthropic en diciembre de 2025**.
#Bun#Jarred Sumner#reescritura de Zig a Rust
Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)
Un ensayo de Jean-Paul Paoli (*The Intelligence Fabric*) que desplaza el miedo a la IA en el trabajo: el peligro real no es el **reemplazo** (el puesto que desaparece) sino el **desgaste silencioso** de los vínculos de equipo mientras *todos siguen empleados*. Tesis: cuando cada empleado convierte a la IA en su **primer confidente y colaborador**, tres «hilos» del tejido organizacional se deshacen sin despidos — los **vínculos entre pares** (la transferencia de conocimiento tácito de junior a senior cortocircuitada), el **vínculo manager-empleado** (las señales de alerta temprana desaparecen, el manager se convierte en «el último en saberlo en lugar del primero») y el **juicio profesional** (se deja de formar a quienes saben *hacer* el trabajo y evaluar si la máquina se equivoca). Paoli nombra el fenómeno **shadow intimacy** (por analogía con *Shadow IT*) y no prescribe una prohibición sino un «retejido» deliberado, hilo por hilo. Ámbito: management, transformación organizacional, IA en el trabajo, dependencia emocional de los modelos.
#Shadow intimacy#reemplazo por IA#vínculos de equipo
Hilo de X (hilo ilustrado) de **Thariq Shihipar** (equipo de Claude Code / Anthropic): una *guía de campo* para sacar el máximo partido a **Claude Fable 5**. Tesis central tomada de Korzybski — *"el mapa no es el territorio"*: el **mapa** = lo que le das a Claude (prompts, skills, contexto); el **territorio** = donde ocurre el trabajo (base de código, restricciones del mundo real); la brecha entre ambos = las **incógnitas**. Fable es *"el primer modelo en el que la calidad del trabajo está limitada por mi capacidad de aclarar sus incógnitas"*. El artículo ofrece un **marco de 4 cuadrantes** (conocidos-conocidos / conocidos-desconocidos / desconocidos-conocidos / desconocidos-desconocidos) y un **conjunto de técnicas** ordenadas en el tiempo (antes / durante / después de la implementación) — blindspot pass, brainstorms y prototipos, entrevistas, referencias, plan de implementación, implementation-notes, pitches y explainers, quizzes — cada una con prompts de ejemplo. Dominio: prompt engineering, agentes de codificación, metodología de trabajo con IA, artefactos HTML.
#Incógnitas#mapa vs. territorio#conocidos/desconocidos conocidos
Nota breve de Simon Willison (weblog) que recoge dos consejos escuchados durante una *Fireside Chat* en AIE con Cat Wu y Thariq Shihipar (equipo de Claude Code): **dejar que el modelo (Fable, y en cierta medida Opus) ejerza su propio juicio en lugar de dictarle reglas** — ilustrado con la decisión de si escribir tests o no. Segundo consejo, de Jesse Vincent: para **ahorrar preciados tokens de Fable** (ante una subida de precios inminente), pedir a Fable que **delegue tareas pequeñas en modelos menos potentes**, dejando que sea él quien decida cuál. Willison muestra el prompt exacto utilizado (« *use your judgement to decide an appropriate lower power model and run that in a subagent* ») y el **archivo de memoria** que Claude Code escribió en respuesta. Ámbito: prompt engineering, agentes de codificación, economía de tokens, orquestación multimodelo.
#Juicio del modelo#delegación en subagentes#model override
Guía de agente (Thinkroom, la plataforma de Kieran Klaassen) que documenta el **Compounding Knowledge Lifecycle** del compound-engineering-plugin (Every): cómo una lección aprendida una vez "sigue dando frutos" — se captura, se almacena, se recupera y se mantiene veraz. Describe la anatomía de un *learning* (`docs/solutions/`), su captura mediante `/ce-compound`, el mapa de memoria (durable vs. efímera), la recuperación *grep-first* (learnings-researcher) integrada en 5 skills en puntos de decisión, y las tres contrafuerzas que evitan que la memoria mienta. Directamente relevante: es la doctrina detrás de la convención `docs/solutions/` de este repositorio. Dominio: compound engineering, gestión agéntica del conocimiento, skills.
**Informe periódico de Mozilla**, *The state of open source AI*, **v1.0.1, julio de 2026**, presentado mediante una carta de **Raffi Krikorian** (CTO): siete secciones, un sitio interactivo y un informe descargable. Tesis enunciada en el título de la Sección 1: *« La capa del modelo se ha convertido en una commodity. El valor se acumula en el harness que se sitúa por encima. »* **Estado de las capacidades**: en el *Artificial Analysis Intelligence Index v4.1*, el mejor modelo cerrado obtiene **61** puntos (Claude Opus 5) y el mejor modelo abierto **57** (**Kimi K3**), cuarto en el ranking general y por delante de tres de los mayores laboratorios cerrados; en el *Epoch Capabilities Index*, la brecha es de **6 puntos** (K3 en 156 frente a GPT-5.6 Sol en 162), descrita como *« más o menos un ciclo de lanzamiento »*, con intervalos de confianza que se solapan. **Frontera en diente de sierra**: el open lidera en código frontend (K3 con 1.679 Elo en LMArena Frontend Code Arena, seis dominios de siete), disputa el trabajo agéntico en terminal (88,3 frente a 88,8 en Terminal-Bench 2.1) y cede terreno en trabajo profesional de conocimiento (Fable 5 supera a K3 por 92 Elo en GDPval-AA v2). **Cambio de uso**: la cuota de tokens de OpenRouter dirigida a modelos de pesos abiertos pasó de un nivel insignificante a un tercio a finales de 2025, y luego a una **mayoría a mediados de 2026**, con los siete modelos de mayor volumen todos de pesos abiertos —el propio informe señala que *« por número de solicitudes, los proveedores cerrados estadounidenses siguen liderando »*, siendo el liderazgo del open un liderazgo en volumen de tokens concentrado en cargas de trabajo de código y agénticas. **El contraste central**: *« El open es fácil de lanzar. El open es difícil de desplegar. »* —el 79% de los desarrolladores que añaden IA usan modelos abiertos frente al 71% para los cerrados, pero solo el **53%** de los equipos que usan modelos abiertos llega a producción **frente al 63%**, y la brecha se amplía con el tamaño de la organización (cerrado 54% → 73%, abierto 53% → 57%), lo que *« descarta una explicación por recursos »*. El mapa de madurez del stack (48 componentes, 9 capas) muestra dos columnas sistemáticamente frías —**estandarización** y ***preparación empresarial***— identificadas como la brecha operativa. **Sección 5**: *« El harness agéntico es otro agente de usuario »*, y *« El modelo se está comiendo al harness »* —en todos los modelos donde ambos coexisten, el harness propio del laboratorio gana ahora, y la brecha de 21,8 puntos se ha comprimido a unos 3. De ahí la fórmula: *« Un harness ajustado con precisión a los pesos de un laboratorio… se degrada con el modelo de cualquier otro, así que cuanto más ajustado está, menos intercambiables son los pesos que hay debajo. El lock-in llega como efecto secundario de la optimización. »*
#Mozilla#state of open source AI#pesos abiertos
**Mozilla** — éditeur du rapport · avec une introduction signée **Raffi Krikorian** · *Chief Technology Officer*. Publié en **juillet 2026** (v1.0.1). Données issues de sources tierces créditées (Artificial Analysis, Epoch AI, OpenRouter, LMArena) et d'une enquête propre menée avec **SlashData** (*Mozilla / SlashData 2026 developer survey*, n = 1 410 sur la question des freins).
Nota de análisis **Trésor-Éco n° 391** (junio de 2026) de la **Direction générale du Trésor** (Ministerio de Economía), redactada por **Martin Chopard, Elisa Cotet, Tristan Gantois y Eloïse Villani**. Revisión de la literatura económica institucional sobre **el efecto de la IA (principalmente generativa) en el empleo**. **Tesis en tres partes**: (1) la IA afecta el volumen de empleo a través de **dos canales opuestos** — el efecto de **desplazamiento** (sustitución de tareas automatizables) frente al efecto de **productividad** (complementariedad, reducción de costes, aumento de la demanda) —, pero el **efecto agregado sigue siendo, por el momento, débil/no medible**, por falta de perspectiva histórica y de adopción (≈20 % de las empresas de la UE en 2025); (2) aparecen **efectos heterogéneos** según las **ocupaciones** (exposición ≠ efecto: todo depende del grado de sustituibilidad/complementariedad y de la **elasticidad-precio** de la demanda), los **trabajadores** (progreso técnico sesgado, preocupación por los **jóvenes**) y los **sectores** (finanzas, TI y servicios a empresas los más expuestos); (3) a **largo plazo, el efecto neto sigue siendo incierto** — entre una sustitución masiva (si la IA agéntica/física se generaliza) y la **destrucción creativa** (lección de revoluciones pasadas: las innovaciones crearon más empleos de los que destruyeron). Conclusión de **política pública**: acompañar la transición (formación, movilidad — el plan «Osez l'IA», France 2030) e **invertir en IA para evitar quedarse atrás** en la competencia internacional. Corpus ampliamente documentado (43 notas al pie, paneles de estimaciones en las tablas 1-3).
#IA y empleo#inteligencia artificial generativa#efecto de desplazamiento
**Martin Chopard · Elisa Cotet · Tristan Gantois · Eloïse Villani** — économistes de la **Direction générale du Trésor** (DG Trésor) · Ministère de l'Économie · des Finances et de la Souveraineté industrielle · énergétique et numérique. Directrice de la publication : Dorothée Rouzet. Le document engage la DG Trésor mais « ne reflète pas nécessairement la position du ministère ».
Tercera entrega de la serie de Ashish Singh «New Engineering Disciplines for the AI Era», dedicada al **KDLC — Knowledge Development Life Cycle**: un ciclo de vida de **8 etapas** que convierte el conocimiento empresarial en un **activo de ingeniería**, al mismo nivel que el código o los datos. Tesis: las iniciativas de IA fracasan no por falta de elegir el LLM adecuado o de desplegar un sistema RAG, sino porque **no abordan la estructura subyacente del conocimiento** — «la IA es solo tan eficaz como el conocimiento que puede descubrir, comprender, recuperar y en el que puede confiar». El KDLC encadena Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Contrapone el **RAG tradicional** (documentos aislados, palabras clave) con el **Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search), en el que los agentes comprenden «relaciones, contexto y significado de negocio». Frase emblemática: «Los modelos aportan razonamiento. La memoria aporta continuidad. El conocimiento aporta comprensión.» Tres ejemplos (finanzas/cumplimiento normativo, ingeniería de software, sanidad) ilustran el impacto.
#KDLC#Knowledge Development Life Cycle#ciclo de vida del conocimiento
Carta «Dear friends» de Andrew Ng en *The Batch* (DeepLearning.AI, número 359) sobre **loop engineering** aplicado al desarrollo de producto **0-to-1**. Ng comparte sus **3 bucles clave** — bucle de codificación agéntica (~minutos), bucle de feedback del desarrollador (~horas), bucle de feedback externo (~días) — anidados por escala temporal creciente, conectando *agente de codificación → especificación de producto/evals → visión del desarrollador → feedback externo*. Tesis central: los humanos conservan una **ventaja de contexto** (más que un «gusto») que hace indispensable el human-in-the-loop; los ingenieros asumen un rol parcial de gestión de producto. Ámbito: agentes de codificación, ingeniería de producto, metodología agéntica.
#Loop engineering#desarrollo de producto#bucle de codificación agéntica
Artículo de opinión en profundidad (punto de vista) publicado en **sfeir.com** el 24 de junio de 2026, por **Didier Girard** (Director General, SFEIR). **Tesis central**: en 2024 todos apostaban por **AI4Business** (IA en los procesos de negocio) como el gran yacimiento de valor; en 2026 el panorama se ha **invertido** — es **AI4IT** (IA para producir el sistema de información: código, SDLC, fábrica de software) la que genera valor **medible**. El artículo *fundamenta* esta tesis en la vigilancia tecnológica de la firma: decepción de AI4Business (el estudio del MIT «95% de pilotos sin ROI», cuestionado pero revelador; un bloqueo **organizativo** / el problema hayekiano de Mollick) frente a la evidencia cuantificada de AI4IT (Salesforce, Intercom, Raiffeisen, AWS/Bedrock, Atlassian, DORA). Explicación mecanicista: **el código se verifica a sí mismo** (compilación, pruebas, CI) mientras que los procesos de negocio no tienen ni compilador ni bucle de retroalimentación inmediato. **Consecuencia presupuestaria 2027**: un desplazamiento **CapEx→OpEx**, la dinámica de precios de los tokens (pico al alza — Fable 5 a 2× Opus — frente a una inferencia ÷280 y presión a la baja de los pesos abiertos/inferencia de escritorio), y un **AI FinOps** guiado por el **coste por resultado**. Cierra con **4 recomendaciones para el COMEX**.
#AI4IT#AI4Business#inversión
**Didier Girard** — Managing Director (CTO / DG) de **SFEIR** · ESN française (~1 000 personnes, France · Belgique · Luxembourg · Suisse). Auteur de l'article ; voix éditoriale du cabinet sur la transformation IA des DSI.
Anuncio de benchmark de **Artificial Analysis** (plataforma independiente de evaluación de modelos de IA, vía X/Twitter + página del modelo): **GLM-5.2** de **Z.ai** (Zhipu AI, @Zai_org) se convierte en **el modelo de pesos abiertos líder** y asciende al **puesto n.º 3 de la clasificación general** de **GDPval-AA**, un benchmark del mundo real para *trabajo intelectual económicamente valioso* (tareas de largo horizonte, multiturno, agénticas). GLM-5.2 obtiene **1524 Elo**, solo por detrás de **Claude Fable 5 (1783)** y **Claude Opus 4.8 (1615)**, y a la par de **GPT-5.5 (xhigh, 1509)**. Supera con amplio margen al siguiente mejor modelo de pesos abiertos (**MiniMax-M3, 1408**), así como a numerosos modelos propietarios: **Gemini 3.5 Flash (1357)**, **Qwen 3.7 Max (1289)**, **Muse Spark (1158)**. Las tareas son genuinamente agénticas: **~31 turnos por tarea** de media en **1,999 enfrentamientos**. La misma clasificación se mantiene en el **Artificial Analysis Intelligence Index** (1.º entre los modelos de pesos abiertos), el **Agentic Index** (n.º 3) y **AA-Briefcase** (n.º 3, por delante de GPT-5.5 xhigh, solo por detrás de Fable 5). Dato destacado: un modelo de **pesos abiertos** bajo **licencia MIT**, **MoE con 753 mil millones de parámetros / 40 mil millones activos**, **contexto de 1M de tokens**, con un precio de **$1.40/$4.40 por 1M de tokens** de entrada/salida, rivaliza con la frontera propietaria en trabajo agéntico — un avance real para los modelos abiertos.
Ensayo extenso de **Shubham Saboo** (X/Twitter) que plantea una tesis sobre el rol del Product Manager en la era de los agentes: la próxima competencia clave no es la **ingeniería de prompts** sino **Loop Engineering** — diseñar un *sistema que mejora con cada ejecución* en lugar de escribir el prompt perfecto cada vez. Un **loop** es un ciclo repetido: cambiar lo que moldea el comportamiento del agente → ejecutarlo → evaluar el resultado → conservar el cambio si la calidad sube, revertirlo en caso contrario → **acumular el aprendizaje** para que la siguiente versión parta con ventaja. Para un PM, el punto de entrada no es el código sino los **artefactos duraderos** que codifican su criterio: skill de revisión de PRD, *summarizer* de llamadas con clientes, rúbrica de evaluación, checklist de lanzamiento, flujo de investigación, `CLAUDE.md`, plantilla de prompt, marco de priorización. Como se reutilizan, estos artefactos **se acumulan en ambas direcciones** — y **derivan** (drift) silenciosamente (un CLAUDE.md que no deja de crecer, un checklist que se ignora…): el modelo no ha empeorado, son los artefactos los que han derivado sin supervisión. Un loop tiene **5 partes**: disparador, acción, **prueba**, memoria, **condición de parada** (la más crítica). Las **evals** se convierten en trabajo del PM (poner a prueba el artefacto con ejemplos conocidos: 3 PRD buenos / 3 malos, 5 llamadas ya comprendidas, 2 lanzamientos pasados). La **memoria** vive en **GitHub** (el repositorio se convierte en "memoria de producto": commits, diffs, resultados de evals, registro de decisiones, rollback). Primer loop recomendado: un **loop semanal de señal de producto** (cada viernes). El criterio (taste) sigue siendo central — pero ahora necesita **prueba**. Cita a Boris (creador de Claude Code): "ya no escribe prompts, escribe loops."
#Loop Engineering#gestión de producto#PM aumentado
Entrevista en podcast «À la French» (canal tecnológico en francés, grabado en DevSummit) con Mathieu Grymonprez, Global CDO del grupo Adeo (Leroy Merlin, Obramat, Weldom). Cómo un grupo familiar centenario del retail adopta la ola de la IA agéntica: cultura vs. estructura, accountability, coste de tokens y FinOps, lock-in de la inteligencia empresarial, memoria de empresa y orquestación de agentes. Ámbito: transformación digital, IA agéntica, retail, estrategia TI.
#IA agéntica#transformación digital#CDO
Mathieu Grymonprez (Global CDO, groupe Adeo) — invité ; Jean-Baptiste Kempf · Steeve Morin · Mehdi Medjaoui (hôtes du podcast « À la French »)
Publicación de LinkedIn de Fred Plais (CEO de Archie, ex-Platform.sh): la IA volvió tan rápidos a los ingenieros que el **cuello de botella se desplazó aguas arriba**, a un lugar que nadie vigila. Al dejar de ser la ejecución la parte lenta, el tiempo de reflexión que solía existir «mientras se construía el código» ha desaparecido: ahora hay que formar la visión correcta y tomar las decisiones correctas en una fracción del tiempo. Están surgiendo dos perfiles poco comunes: el que sabe **articular una visión lo bastante precisa** para que un agente la ejecute sin desviarse, y el que sabe **orquestar agentes** (anticipando sus fallos, encadenándolos, detectando un error antes de que se propague). Contratar por «producción de código» se está volviendo obsoleto: es precisamente lo que ha dejado de ser escaso. Tesis final: «pensar con claridad siempre fue el trabajo; la velocidad solo hizo imposible fingirlo».
#cuello de botella#desplazamiento del cuello de botella#velocidad de ejecución
Artículo de **Paul Sawers** publicado en **The New Stack** el **16 de junio de 2026**, sobre la **suspensión por parte de Anthropic** — *"el mismo día en que estaba previsto que entrara en vigor"* — de la separación de facturación destinada a distinguir el uso del **Agent SDK** de los límites de la suscripción a Claude. **Mensaje citado de Anthropic**: *"We're pausing the changes to Claude Agent SDK usage described below. For now, nothing has changed."* **La aportación del artículo no es el anuncio en sí, sino el contexto que lo rodea**, en tres círculos. **Círculo 1 — la semana de Anthropic**: el 9 de junio, el lanzamiento de **Fable 5 y Mythos 5**, los primeros modelos de clase Mythos disponibles con carácter general, dotados de salvaguardas de ciberseguridad reforzadas; unos días después, una **directiva de control de exportaciones del gobierno estadounidense** obliga a Anthropic a **retirar ambos modelos para todos sus clientes en el mundo**. La suspensión de la política de precios se lee, en este contexto, como *"una pequeña buena noticia"*. **Círculo 2 — daños colaterales del momento elegido**: empresas que ya habían trasladado el cambio a sus propios clientes se ven en aprietos; **Conductor**, una herramienta de codificación multiagente construida sobre el Agent SDK, se ve obligada a publicar un desmentido (*"Anthropic has delayed the subscription updates to Claude plans"*). **Círculo 3 — la tensión de fondo, que va más allá de Anthropic**: una cita de **Boris Cherny** (responsable de Claude Code) de abril, durante una restricción anterior, en la que afirmaba que las suscripciones *"weren't built for the usage patterns of these third-party tools"* — un reconocimiento de que **las tarifas planas y el uso agéntico abierto no encajan**; **GitHub** zanjó la cuestión del mismo modo, eliminando en junio el modelo de tarifa plana de *premium requests* de **Copilot** en favor de una **facturación por tokens**, pese a las protestas. A esto se suma, **la misma semana**, la presentación de una **propuesta de demanda colectiva** ante un tribunal federal de California, que alega que los niveles **Max** se quedan muy por debajo de los multiplicadores de uso anunciados para sesiones intensivas de codificación. Anthropic no precisa cuándo llegará un planteamiento revisado, y se limita a señalar que *"works to update the plan to better support how users build with Claude subscriptions."* **La conclusión del autor**: entre la presión gubernamental sobre Fable y Mythos, una **salida a bolsa** prevista y **rumores de recortes de precios en OpenAI**, Anthropic intenta **mantener de su lado a su base de desarrolladores** — y la suspensión es, por ahora, un medio para lograrlo.
#Anthropic#Claude Agent SDK#suscripción Claude
**Paul Sawers** — journaliste tech · signe ici pour **The New Stack**. Registre de **presse spécialisée** : l'article ne relaie pas seulement l'annonce · il la replace dans une série (les changements de facturation successifs d'Anthropic) · la compare à un précédent sectoriel (GitHub Copilot) et l'articule à trois pressions concomitantes (export control, IPO, concurrence). Sourçage explicite et attribué — le billet de Zed · l'analyse de Matthew Diakonov · le post de Conductor · une déclaration antérieure de Boris Cherny.
Artículo de SFEIR (en francés) que formaliza un SDLC impulsado por IA en 11 fases (0 a 10) y sostiene que el sector converge hacia él. Observación de partida: en 2025, las organizaciones añadieron herramientas de IA sin transformar su modelo operativo, produciendo una paradoja de «todo cambia… y nada cambia» (la velocidad de ejecución se multiplica sin una ganancia proporcional). La verdadera respuesta no es la elección de herramientas, sino el rediseño del ciclo para la ejecución por máquinas. El ciclo de SFEIR se apoya en tres puertas humanas inamovibles (Define, Plan, Ship), fases automáticas entre ellas, y dos momentos de capitalización (Compound-1 antes del despliegue, Compound-2 en producción) que convierten las lecciones en reglas reutilizables. Tres principios: la IA ejecuta (artefactos completos + prueba de ejecución, sin confiar nunca en las afirmaciones del propio agente), el humano conserva el control de la intención, el sistema aprende de forma acumulativa. Resultados medidos (rediseño de 6 meses a 1 día, −30 % de iteraciones tras diez ciclos) y convergencia declarada con ADLC, Google y DORA 2025.