thekb.eu — Herramientas y Plataformas

DuckDB and the changing physics of analytics

Wed, 26 Aug 2026 00:00:00 GMT

Andy Warfield, ingeniero del equipo de S3 en AWS, publicó un artículo de invitado en All Things Distributed el 26 de agosto de 2026, presentado por Werner Vogels. En él explica por qué los motores analíticos embebidos como DuckDB están cobrando importancia, y anuncia que DuckLabs, el equipo que desarrolla DuckDB, se incorpora a AWS. Su marco de lectura es el de una «física» cambiante. Donde las ciencias físicas exploran invariantes, la informática de sistemas busca el compromiso elegante frente a proporciones que se desplazan: velocidad de memoria frente a velocidad de red, riqueza de las abstracciones frente a la potencia disponible. Cita tres momentos —el proyecto NOW de Berkeley, su propio trabajo en Xen, y la investigación sobre MonetDB y X100 en el CWI de Ámsterdam, donde el cuello de botella del procesamiento de consultas había pasado del disco a la CPU— y señala que estas restricciones reaparecen en ciclos. Aplicado a los datos, este marco explica el procesamiento distribuido. El procesamiento siempre es más simple y eficiente en una sola máquina rápida, pero cuando el disco o la tarjeta de red de un servidor ya no puede leer el volumen deseado, se particiona. Esa fue la restricción de principios de la década de 2000, la que produjo MapReduce y luego los RDD de Spark. Warfield señala dos cualidades de estos sistemas: innovaron mucho en la ergonomía para el desarrollador, y aceptaron un costo fijo de planificación y distribución, apostando por el rendimiento ganado al añadir máquinas en lugar de por la eficiencia por unidad. Pero las proporciones han cambiado. Una instancia actual ofrece aproximadamente cincuenta veces más memoria, núcleos y ancho de banda de red que la mayor instancia EC2 de 2007, mientras que el crecimiento de los conjuntos de datos sigue una distribución cuyos casos extremos forman la cola. El artículo Scalability! But at what COST? de 2015 ya había demostrado que una implementación de un solo hilo cuidadosamente optimizada podía superar a los marcos distribuidos que se ejecutaban en ciento veintiocho núcleos. DuckDB, lanzado en 2018 por Hannes Mühleisen y Mark Raasveldt, aplica esta lógica: un motor analítico de tipo biblioteca en proceso, que se ejecuta en el espacio de direcciones de la aplicación, siguiendo el modelo de distribución de SQLite. AWS se convirtió en cliente de DuckLabs y luego en patrocinador de la extensión Iceberg de DuckDB, junto con su trabajo en S3 Tables; la extensión ahora es compatible con Iceberg v2 y v3 y supera las 800 000 descargas semanales. Warfield no presenta el modelo embebido como un reemplazo: cuando un trabajo requiere mil máquinas, las requiere. Lo que está cambiando, escribe, es que buena parte del trabajo que se hace con datos en realidad nunca necesitó un clúster. DuckLabs se incorpora a AWS como subsidiaria, y el proyecto sigue siendo de código abierto bajo la licencia MIT y bajo la tutela de la DuckDB Foundation.

Designing AI with character: what we learned building Berd

Tue, 18 Aug 2026 00:00:00 GMT

Entrada de blog corporativo de **Block** (`block.xyz/inside`), **sin firma**, publicada el **18 de agosto de 2026**, que anuncia **la apertura del código de Berd** y expone la tesis de diseño que la guió. **Qué es Berd.** *«Berd is a desktop application our teams use to work with AI agents across projects, skills, tools, and models.»* Nace de un problema interno: Block tenía acceso a agentes capaces —**goose**, **Claude Code**, **Codex**— pero cada uno imponía *«different interfaces, configuration systems, and ways of managing context»*. La conclusión extraída: *«we didn't need another model or agent harness, **we needed a consistent environment around them**»*. Berd reúne conversaciones, archivos, carpetas, instrucciones, agentes y skills alrededor de **proyectos persistentes**, para dejar de reconstruir el contexto en cada tarea. **La tesis de diseño.** Dar **carácter** a los agentes —no solo mediante roles, instrucciones, skills y herramientas, sino mediante **identidades visuales distintas**, incluida una colección de personajes animados, los *«Gloopies»*—. El problema invocado es el del cuadro de prompt vacío: *«the product gives people little sense of how the agent is configured, which context and tools are available to it, and how it differs from another agent»*. La entrada sitúa el enfoque en la línea de **Square** y **Cash App** —llevando el diseño a donde la categoría no lo tenía—. **Pero el problema enunciado es un problema de legibilidad de la configuración, y el avatar resuelve la distinguibilidad**; el texto lo reconoce en una frase que no desarrolla: *«The avatars make the agent recognizable. **Its role, skills, and tools make it useful.**»* **La arquitectura.** Berd desciende de **goose**, el framework de agentes de código abierto lanzado por Block en **enero de 2025**, aportado a la **Agentic AI Foundation** (Linux Foundation, diciembre de 2025) junto a **MCP** y **AGENTS.md**. División explícita: *«goose remains the open agent framework and runtime. Berd is a desktop application built around it. **Berd connects to goose through the Agent Client Protocol.**»* goose sostiene el bucle del agente, Berd sostiene la experiencia. **La secuela es Buzz.** Berd sirvió para explorar el trabajo **en solitario**; *«But work rarely stays private»*. Lo que Berd demostró —*«private space, durable context, recognizable agent identities, reusable skills, visible configuration»*— alimentará **Buzz**, el espacio compartido humano+agente. *«Start alone, then go multiplayer.»* **Reservas.** **Sin cifras, sin pruebas de usuario, sin licencia nombrada**; una extralimitación aislada (*«create custom agents to do any task they want»*); y una entrada cuyo título anuncia una retrospectiva mientras mantiene el producto en presente —**Berd no se declara obsoleto, pero la hoja de ruta apunta hacia Buzz**.

Securing Software at the Speed of AI: What Four Years of Data Reveal

Tue, 18 Aug 2026 00:00:00 GMT

Sonatype publica, escrita por su *technical writer* Aaron Linskens, una síntesis de un estudio longitudinal de sus laboratorios de investigación que abarca cuarenta y nueve meses, de junio de 2022 a junio de 2026. El método se expone de entrada: una cohorte fija de aplicaciones seguida de forma continua, de modo que las variaciones medidas reflejen la evolución de la flota de software más que la de la cartera de clientes. El resultado central se presenta como una contradicción: las organizaciones remedian más rápido que antes, pero sus aplicaciones acumulan más riesgo. Cuatro medidas enmarcan el hallazgo. Las vulnerabilidades *Critical* y *High* por aplicación se multiplicaron por 4,31, pasando de un promedio de 14,14 en junio de 2022 a 54,3 en 2026; el efecto no se debe únicamente al legado, ya que excluyendo las aplicaciones legadas recién incorporadas a la gestión el factor sigue siendo de 3,91. Las versiones de componentes recién afectadas avanzan a cuarenta y seis veces la tasa previa a la IA. La edad mediana de las vulnerabilidades ha caído un 59% desde su pico de enero de 2024. Por último, la creación mensual promedio de aplicaciones se multiplicó por 4,84, y con ella las decisiones de dependencias. El progreso en la remediación es real: más de la mitad de las violaciones resueltas se resuelven en menos de un día, y la edad mediana de las vulnerabilidades *Critical/High* sin resolver baja de 228 a 126 días, luego a 103 días en mayo de 2026. Entre las cohortes que dispusieron de al menos doce meses para actuar, el 52,6% están resueltas, el 44,3% permanecen abiertas y el 3,1% están bajo dispensa. El giro propuesto concierne a la fase previa. Los investigadores examinaron las dependencias vulnerables que entraron en las aplicaciones del periodo y se plantearon una pregunta simple: en el momento de la selección, ¿existía ya una versión sustancialmente menos arriesgada? La respuesta es sí en el 62,2% de los casos en Maven, el 46,9% en npm y el 34,3% en PyPI. El texto se niega a interpretar esto como una falta del desarrollador: algunas vulnerabilidades son inevitables, otras provienen de una brecha de información en el momento de la elección — un punto que se vuelve sensible cuando un asistente de IA puede introducir un componente en segundos sin disponer de inteligencia actualizada sobre su riesgo y sobre la política organizacional. La entrada reconoce que la IA no es la única causa de la expansión del panorama de vulnerabilidades y cita cuatro factores concurrentes. Concluye con Sonatype Guide, que lleva esta inteligencia hasta el momento de la selección, y remite al informe completo, *The AI-Era Software Assembly Line*, para los datos subyacentes.

Projects in Buzz

Tue, 18 Aug 2026 00:00:00 GMT

Publicación de anuncio de **Block Engineering** firmada por **Thomas Petersen** (*Principal Designer & Builder*), publicada el **18 de agosto de 2026**, que presenta **Buzz Projects** — el componente de forja de **Buzz**, el espacio de trabajo humanos+agentes de Block construido sobre **Nostr**. **El problema planteado.** *« Software development tools are fragmented in ways the work itself is not. »* El reporte de bug está en una herramienta, la discusión en otra, la corrección en una rama, la CI en otro sitio, la revisión en un hilo de comentarios, las notas de versión reconstruidas después. **La tesis: todo esto es una sola conversación, y el historial debe formar parte del proyecto.** **Lo que aporta Projects.** Una **forja alojada en el propio relay**: repositorios Git estándar accesibles mediante `fetch/clone/pull/push` sobre **Smart HTTP**, *« with no custom tooling or wrapper CLI required »*; **la clé Nostr como identidad única** — *« the same npub that signs your messages signs your pushes »*, sin token separado ni cuenta de GitHub; **proyectos multi-repositorio** que pueden incluir repositorios que uno no posee (*« you just won't have authority over it »*); issues, pull requests, diffs, comentarios en línea, revisión y merge; un **feed de actividad** a nivel de servidor; y la **vinculación de cualquier proyecto con cualquier número de canales**, de modo que *« el contexto en torno a un cambio no desaparece en cuanto los agentes empiezan a escribir código »*. Desde un canal, un issue puede encomendarse a un agente o puede pedírsele al agente que abra un PR, que se vincula de vuelta a la conversación que lo produjo; el agente se dirige al humano a través del **Inbox**. **La doctrina, en dos partes que la publicación nunca ensambla.** Por un lado, **ninguna restricción previa**: *« No forced guardrails, no limitations on what your agents are allowed to help you with. »* Por otro, **un registro firmado de cada acto**: *« Every push, review, approval, and merge is a signed Nostr event »*, con un rastro de **qué agente** produjo un patch y **qué humano** había autorizado a ese agente. De ahí la proyección de cierre: el historial de contribuciones pasa a ser *« more than a set of colored squares on a profile »*, un **historial verificable ligado a una clave**, y Block declara que está **explorando *« agent trust protocols informed by past behavior »***. **La confianza se desplaza de la autorización *a priori* a la prueba *a posteriori*.** El marco asociado es explícito: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* **Salvedades.** **Sin cifras, sin enlaces salientes, sin especificación** en ningún lugar del texto; **la CI y las notas de versión se prometen pero están ausentes del inventario**; Projects se encuentra bajo la **pestaña Experiments**, y la publicación se descalifica a sí misma seis veces — *« Buzz is still in beta and Buzz Projects is still under experiments, so treat it accordingly. »*

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities

Fri, 14 Aug 2026 00:00:00 GMT

Publicación de anuncio publicada el **14 de agosto de 2026** en el blog de **Z.ai** (antes Zhipu AI), **sin firma**, con motivo del lanzamiento de **GLM-5.3**. **La tesis metodológica.** *« Scaling post-training is all we did for GLM-5.3. »* Mismo modelo base que GLM-5.2: **toda la ganancia proviene del post-entrenamiento**, construido sobre la pila del ciclo anterior — **IndexShare** (contexto largo), **SAO** (RL de largo horizonte) y **slime** (entrenamiento asíncrono, Megatron + SGLang). El cuello de botella se ha desplazado del modelo **al entorno**: Z.ai describe pipelines que **sintetizan** entornos y señal de recompensa — un agente juez verifica la resolubilidad, **los verificadores se sintetizan sin acceso a la solución de referencia**, y solo se admiten tras un tríptico de controles **oracle / no-op / unsolved-state**. El trabajo sigue siendo *« human-in-the-loop »*. El rendimiento de RL de extremo a extremo mejoró **más de 2,3×**. **Los resultados de codificación.** Terminal-Bench 3.0 pasa de **4,6 a 28,3**, DeepSWE v1.1 de **46,2 a 66,9**, Agents' Last Exam de **23,8 a 28,5**. En **Z.ai Code Bench**, un benchmark **interno y privado**, +50% respecto a GLM-5.2, con una ganancia simultánea en **eficiencia de tokens**: 34,5% con ~75K tokens de salida en esfuerzo Max (frente a 23,4% con 96K para GLM-5.2), y 31,4% con ~50K en esfuerzo High — por delante de Claude Opus 4.8 (29,5% con 120K). **Claude Fable 5 se mantiene por delante con 39,5%.** La afirmación *« most capable open-weights model for coding »* **no se desprende de la tabla**: frente a **Kimi K3**, el resultado es **3-3 con un empate**. **La capacidad cibernética.** Presentada como *« emergente »*, fue **entrenada deliberadamente** — la publicación escribe *« we expected this to make the model better »*. Lo que resultó sorprendente fue la **velocidad**, y el paso de fallos aislados a la **cadena de explotación completa**. CyberGym **84,5%** (el mejor de la tabla), ExploitBench **54,4%** (×2,2), ExploitGym **105/130 tareas** (×3,6 respecto a GLM-5.2, presupuestos normalizados por rendimiento). Frase clave: ***« Capability is growing fastest exactly where we are furthest behind. »*** **La cifra más pesada.** Trabajando con equipos de seguridad chinos, el modelo identificó **2.436 vulnerabilidades en 269 proyectos de código abierto** — núcleos, sistemas operativos, motores de navegador, protocolos de red — la más antigua introducida en **1981**, vida media de **26,6 años**. El **Security Disclosure Ledger** muestra **53 divulgadas** y **2.383 bajo embargo**: **2,2% publicado**. **Gobernanza.** Publicación de los pesos anunciada *« in two weeks, once safety evaluation and hardening are complete »* — **una fecha, no un criterio**: sin definición de hardening, sin condición de no publicación, sin evaluador externo. **Varios.** `thinking.type: "disabled"` **ya no está soportado** (se requiere migración); las cuotas del GLM Coding Plan son por puntos, **50% fuera de la franja 14:00-18:00 UTC+8**; **casi todas las evaluaciones se realizan en Claude Code 2.1.207**.

DeepSeek Harness developer preview: Everything is a plugin

Thu, 13 Aug 2026 00:00:00 GMT

Página de lanzamiento de producto publicada el **13 de agosto de 2026** por **DeepSeek**, **sin firma**, para el lanzamiento en *developer preview* de **DeepSeek Harness** (`dsh`), un harness de agente de codificación **de código abierto bajo licencia MIT** cuyo repositorio se abrió el mismo día. **Lo que dice la página.** Dos promesas, en cuatrocientas palabras y sin una sola cifra. **« Everything is a plugin »**: cada capacidad — modelos, herramientas, skills, sesiones, sandboxes, almacenamiento, loops, programación, interfaz — es un plugin **intercambiable mediante configuración, sin modificar el código fuente**. **« Every run is traceable »**: todo lo que ve el modelo queda registrado en un **log de sesión de solo anexado (append-only)** — system prompts, razonamiento, llamadas y resultados de herramientas, programación de subagentes, cada inyección de contexto — y *« resume, fork, search and replay all operate on the same event stream »*. El núcleo es **Cordis**, un framework de terceros vendorizado, descrito en un paper externo y acreditado de forma prominente. Se lanzan cuatro modos de ejecución: **Standard** (herramientas completas), **Code** (herramientas expuestas mediante un SDK de TypeScript para combinar varias operaciones en un solo programa), **Minimal** (dos herramientas, bash persistente y `str_replace_editor`, *« for benchmarking models in a minimal environment »*), y **Creator** (inspección en tiempo de ejecución, pruebas de plugins en memoria, composición de nuevos modos). Para empezar: `npx @deepseek-ai/dsh web`. **Lo que la página no dice.** La afirmación más fuerte se encuentra en `docs/architecture.md`: ***« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it. »*** **Una garantía verificada en tiempo de ejecución**, no una afirmación de vitrina — esta es la propiedad que realmente distingue a DSH, y está ausente del discurso de marketing. El mismo repositorio aporta la réplica: `SESSION_FORMAT_VERSION` permanece en **`0` sin promesa de compatibilidad**, *« backends reject old on-disk formats »*, y el README advierte en mayúsculas que habrá cambios que rompen la compatibilidad. **Trazable hoy no significa archivable mañana.** **El modelo de negocio está en la cronología.** DSH se lanza el día de la **GA de DeepSeek-V4-Pro** y **tres días antes** de un nuevo calendario de precios de la API (16 de agosto, 16:00 UTC; tarifas de hora valle al **−50 %**). **Harness regalado, inferencia encarecida** — exactamente lo inverso del modelo de Anthropic. **Lo que se confirma.** La intercambiabilidad se sostiene al menos en la capa de modelos: además del adaptador de DeepSeek, **`dsh-llm-pi-ai`** hace accesible cualquier gateway compatible con OpenAI *« by configuration, not by code change »*. Y el modo Minimal integra el **harness de benchmarking** dentro del producto — un intento de arrebatarle a Claude Code la definición del benchmark, aun cuando el propio repositorio de DSH contiene un `CLAUDE.md` y un `.claude/skills`.

Buzz (buzz.xyz) — Rapport de recherche pour présentation

Wed, 12 Aug 2026 00:00:00 GMT

Informe de investigación interno fechado el **12 de agosto de 2026** que consolida, con fines de presentación, el estado público de **Buzz**, el espacio de trabajo de humanos+agentes de **Block** lanzado el **21 de julio de 2026** bajo **Apache 2.0**. Reúne las dos publicaciones técnicas de Block, el anuncio corporativo, el repositorio de GitHub, la cobertura de prensa, X y **tres evaluaciones independientes** — esta última capa aporta la mayor parte del valor añadido. **El concepto.** Buzz fusiona el chat de equipo, una forja Git y flujos de trabajo automatizados en un único espacio donde los agentes son **miembros de pleno derecho, no bots**. La tesis es la de Tyler Longwell: *"El cuello de botella se desplazó de la inteligencia a la coordinación."* Bradley Axen (Head of AI Capabilities) enmarca lo que está en juego para el mercado: *"Toda empresa va a necesitar un lugar donde humanos y agentes trabajen juntos. La pregunta es si ese lugar es propietario o abierto."* **La arquitectura.** Un relay en **Rust** sobre **Nostr** (NIP-01/42/98/34, 127 *tipos de evento*), **Postgres**, **Redis**, **S3/MinIO**, escritorio **Tauri+React**. Cada participante posee un par de claves; cada mensaje, revisión, paso de flujo de trabajo y evento Git queda **firmado** en un registro de auditoría append-only encadenado por hash. Un grado de formalismo poco frecuente para una **v0.4.x/0.5.x**: aislamiento multiinquilino mecanizado en **TLA+**, propiedades de autorización verificadas en **Tamarin**. La integración de agentes pasa por **`buzz-acp`**, un harness **ACP** que conecta goose, Codex y Claude Code y **traduce ACP ↔ MCP** — *"Se componen mediante protocolos, no mediante imports."* **La brecha central.** Jack Dorsey anuncia *"descentralizado, autosoberano"*; el `ARCHITECTURE.md` de Block afirma: *"El relay es la única fuente de verdad… No hay intercambio de eventos entre pares, ni gossip, ni replicación."* Un único relay por comunidad, de ahí un **punto único de fallo**: la descentralización es **soberanía organizativa**, no redundancia. **Las limitaciones, documentadas.** La unidad de permiso es la **pertenencia a un canal** —*"la pertenencia a un canal no es una autorización de herramientas de grano fino"*—; los agentes se ejecutan con **`--dangerously-skip-permissions`**, fuera de cualquier sandbox; **la observabilidad es deficiente** (*"No me dice qué pasa después"*, cierres silenciosos por OOM). Los eventos firmados son *tamper-evident* (evidencian manipulación), no *tamper-resistant* (resistentes a ella): un operador de relay comprometido puede eliminarlos. En el relay alojado, **no hay cifrado de extremo a extremo**. **Una corrección de cifras.** El "+33% más de trabajo" es la **proporción de tareas completadas (20 frente a 15 de 44)**, no una ganancia de puntuación — que sube de 59,1% a 71,5%, es decir **+12,4 pts**. **Recepción**: ~25.900 estrellas en GitHub, un tuit de Dorsey con ~2,3-2,7M de visualizaciones, respaldo de Sundar Pichai, y la formulación de Justin Waldron: *"el primer harness de agentes multijugador propiamente dicho"*. Salvedades reconocidas: benchmarks **autoevaluados por Block**, ningún precio de alojamiento publicado, ninguna cifra de adopción.

ChatGPT Desktop & Claude Desktop vs versions web — Rapport « What ? — So What ? — Now What ? »

Wed, 12 Aug 2026 00:00:00 GMT

Informe de investigación interno fechado el **12 de agosto de 2026** (en formato *What? — So What? — Now What?*, investigación realizada los días 11 y 12 de agosto) sobre una pregunta simple: ¿son las aplicaciones **de escritorio** de ChatGPT y Claude mejores que sus versiones **web**? La respuesta llega en dos partes. **(A) Existe un consenso cualitativo sólido y bien documentado.** El punto de partida es indiscutible: el escritorio y la web llaman exactamente a los mismos modelos en la nube, siendo la aplicación una simple interfaz hacia el servicio — la ganancia reside, por tanto, enteramente en la capa de aplicación (latencia de acceso, estabilidad en sesiones largas, huella de memoria, integraciones con el sistema, fluidez del flujo de trabajo). Lo que distingue verdaderamente al escritorio, confirmado: del lado de OpenAI, un atajo global (Option/Alt + Espacio), una *companion window* que permanece siempre en primer plano, capturas de pantalla nativas, y desde julio de 2026 la capacidad agéntica **Codex/Work** integrada en la aplicación; del lado de Anthropic, **Quick Entry** (macOS), **Desktop Extensions** (instalar un servidor **MCP** local se vuelve *«tan simple como hacer clic en un botón»*), acceso a archivos locales, **Cowork** y **Computer Use** (permisos de Accesibilidad y grabación de pantalla). La web conserva dos fortalezas confirmadas: pestañas/hilos múltiples y universalidad sin necesidad de instalar un cliente. **(B) Casi todas las cifras que circulan en apoyo de este consenso no resisten la verificación.** La auditoría crítica del informe (§1.5) clasifica como **no confirmadas** siete afirmaciones numéricas ampliamente repetidas: el *cold start* «2-3 s frente a 8-12 s» (el único rastro es una mención anecdótica de «carga en unos 3 segundos» en Substack); el uso de RAM «200-700 MB frente a 1,2-2 GB», atribuido a un «Alibaba Product Insights» cuyas páginas devuelven **404**; una tasa de fallos y una cifra de retención de sesión imposibles de rastrear; un «Claude +10-20% de extremo a extremo» atribuido a **Skywork**, que en realidad había evaluado su propio agente de Windows en lugar de comparar Claude con la web; una fuente «Cosmo Edge» imposible de rastrear; citas no confirmadas de Zenken AI; y dos publicaciones de X sin autenticar y sin URL. La señal contraria está documentada con el mismo rigor: Yuri Dvoinos describe una aplicación Claude Desktop que *«me dan ganas de tirar el portátil por la ventana»* — un uso de CPU del 68% y retraso de entrada en un MacBook Pro — y el informe señala que ambas aplicaciones están construidas sobre **Electron** con capas nativas. De ahí su formulación: *la ventaja del escritorio es una promesa de implementación, no una ley de la naturaleza.* **El «So What»**: dado que el modelo se ha convertido en el denominador común, la interfaz se convierte en el campo de batalla — la fusión **Codex + ChatGPT** del 9 de julio de 2026 y el tándem Cowork/Computer Use cuentan la misma historia, *«la aplicación de escritorio ya no es un cliente de chat, es un entorno de ejecución de agentes con acceso a la máquina»*. Tres consecuencias: la ganancia es una ganancia de **fricción**, no de potencia; para un CIO, el escritorio **desplaza el límite de confianza** — Computer Use requiere permisos del sistema sensibles y la fusión de Codex sitúa la ejecución de código, el navegador y los conectores dentro de *«un único límite de confianza ampliado»*, mientras que el navegador sigue siendo gobernable mediante SSO, DLP y CASB; y para quien publica, la fragilidad de las cifras es en sí misma la noticia. **El «Now What»** aporta criterios individuales de cambio, una lista de verificación para CIO (inventariar los permisos, desactivar Computer Use y Cowork por defecto, delimitar qué extensiones MCP están autorizadas, organizar la distribución y las actualizaciones — en Linux, fuera del repositorio apt, Claude Desktop no se actualiza solo) y una directriz editorial: citar únicamente citas textuales confirmadas y fechas.

Shieldstral : Mistral compile sa doctrine en 3,8 milliards de paramètres

Fri, 07 Aug 2026 00:00:00 GMT

Una nota de vigilancia de **Didier Girard** publicada en **X** el **7 de agosto de 2026**, que interpreta el lanzamiento de **Shieldstral 1.0 3B** (Mistral AI, 4 de agosto de 2026) no como el lanzamiento de un producto sino como **el despliegue en producción de una doctrina**. Punto de partida: el **13 de mayo de 2026**, ante la comisión de investigación de la Asamblea Nacional sobre las vulnerabilidades digitales, **Arthur Mensch** rechazó cualquier papel de supervisión de Mistral sobre el uso final de sus modelos — *"no tenemos legitimidad democrática"* — rechazando explícitamente la postura de **Anthropic**. Menos de tres meses después, Mistral lanza un **modelo de moderación**. El autor descarta la contradicción aparente: **Shieldstral no incorpora ninguna taxonomía de lo lícito y lo ilícito**, responde a una **pregunta que escribe el usuario**. **El mecanismo es el corazón de la nota**: un prompt en tres partes (contexto + severidad / una única pregunta cerrada / el contenido a juzgar), una respuesta `yes` o `no`, y el **softmax sobre estos dos tokens** produce una puntuación continua entre 0 y 1. **La política de moderación no está en los pesos, se lee en el momento de la inferencia** — mientras que **Llama Guard 4** incorpora la taxonomía de MLCommons fijada en el entrenamiento, Shieldstral lee la vuestra en lenguaje natural, modificable **sin reentrenamiento**. El informe técnico (**arXiv:2607.25857**, 28 de julio de 2026) cuantifica el coste de esta elección: el ajuste fino solo con datos públicos = **61,1% de F1** en adaptabilidad de política; **4,4 millones de pares contrastivos** generados por un LLM (el mismo contenido reescrito para infringir una política pero no su política hermana) = **+23,3 puntos**; **91,3%** tras la fusión de tres checkpoints. Características: **3.800 millones de parámetros reales** (el «3B» del nombre redondea a la baja), base **Ministral 3** + codificador de visión **Pixtral**, **12 idiomas**, **16 GB de VRAM en BF16**, **Apache 2.0**. Rendimiento en texto: **84,9% de F1 promedio**, a la par de **GPT-OSS-Safeguard-20B** (siete veces más grande), por delante de **Qwen3Guard-8B** (84,0) y muy por delante de **LlamaGuard-4-12B** (69,1). **Una salvedad planteada por el propio autor**: *todas estas cifras provienen de Mistral, sobre conjuntos de prueba seleccionados por Mistral, y no existía ninguna evaluación de terceros a fecha del 6 de agosto*. La tesis estructurante de la nota es una **oposición de topologías**: en **Anthropic**, la barrera de seguridad vive **en los pesos** y el editor arbitra quién queda exento de ella (**Claude Fable 5** público con medidas de seguridad / **Claude Mythos 5** sin ellas, reservado a los ciberdefensores aprobados de **Project Glasswing**, 9 de junio de 2026); en **Mistral**, la barrera de seguridad **se sitúa fuera del modelo** — un componente separado, abierto, autoalojable, cuya política pertenece a quien lo despliega. Alineación explícita de clientes (ministerio de las Fuerzas Armadas, BNP Paribas, administraciones gubernamentales francesa y luxemburguesa). La nota cierra con un **contratiempo documentado en tres puntos**: **auditabilidad** (salida binaria, sin traza de razonamiento, mientras que quien despliega hereda la carga de la justificación en una auditoría de la AI Act), **robustez** (el primer capítulo del *Tratado sobre la tolerancia* de Voltaire clasificado como «llamada a la violencia» por un usuario en el hilo de Hacker News — una confusión entre mención y respaldo), **disponibilidad** (a fecha del 6 de agosto: sin endpoint facturado en La Plateforme, sin Ollama oficial). Tres reglas de despliegue para cerrar.

Agent Plugins package your skills, tools, and more

Thu, 06 Aug 2026 00:00:00 GMT

Publicación de ingeniería de **Google** el **6 de agosto de 2026** que anuncia que la compañía se une como **Core Maintainer** a la especificación **Agent Plugins 1.0.0** —un formato de empaquetado abierto y *vendor-neutral* para distribuir juntos **Agent Skills** y **servidores MCP**. **El dato de gobernanza primero.** La especificación fue publicada por un TSC de Core Maintainers de **Amazon, Cursor, Microsoft, OpenAI y Vercel**. Google se suma a ellos, representado nominalmente por **Kevin Hou** (Google DeepMind). Seis competidores se ponen de acuerdo en una capa de empaquetado. **Anthropic no figura en la lista de mantenedores**, aunque los dos bloques empaquetados provienen de ella. **El diagnóstico.** Una skill es portable, un servidor MCP es portable —*"The core problem isn't the components. It's the manifest."* Lo que nunca ha sido portable es la caja: la estructura de directorios, los metadatos del manifiesto, la forma de la configuración MCP y la inferencia del transporte difieren de un cliente a otro. Se termina haciendo forks, manteniendo dos copias de componentes idénticos, y estas divergen. **El formato.** *"A plugin is a directory. That's the whole idea, and the restraint is the point."* Un `plugin.json` reducido a `$schema` y `name`; skills en `skills/`, en el formato Agent Skills; servidores en `mcp.json`, **con un `type` explícito** en cada entrada (stdio, Streamable HTTP, HTTP+SSE heredado). La fuerza del diseño reside en lo que el manifiesto **no puede** hacer: ni reubicar un componente ni declararlo en línea. Por tanto no hay ninguna ruta de descubrimiento que configurar, ningún orden de precedencia que aprender. Corolario: **los componentes fallan de forma independiente** —un servidor que no arranca no arrastra consigo las skills. Un directorio de **dominio inverso** (`com.example.client/`) sirve como espacio de extensión propietario, ignorado por otros clientes: el núcleo portable permanece pequeño porque las partes no portables tienen adónde ir. **Los límites, declarados abiertamente.** Toda una sección explica **cuándo no crear un plugin** (un único servidor MCP, una única skill: innecesario). Otra enumera lo que la v1 excluye: **instalación, distribución, permisos, sandboxing, verificación de confianza y procedencia, UX**. Justificación: las obligaciones de un IDE, una CLI y una plataforma empresarial difieren de verdad. **La pila.** Find (**Agentic Resource Discovery**), describe (**AI Catalog**), package (**Agent Plugins**), run (**MCP + Agent Skills**) —cada capa adoptable de forma independiente. **Lo que se distribuye ya**: **Agents CLI** (utilizable desde Antigravity, Gemini CLI, Claude Code o Cursor) y **Data Agent Kit** (BigQuery, Spanner, Cloud SQL). *"Those skills were already distributable. Now they're distributable in a format that isn't ours alone."* Frase de cierre: *"Packaging is unglamorous infrastructure,"* y eso es precisamente lo que debería compartirse en lugar de reinventarse cinco veces.

Graphify — Knowledge Graphs for AI Coding Assistants (site graphify.net : vitrine, annuaire d'outils et galerie de dépôts graphifiés)

Thu, 06 Aug 2026 00:00:00 GMT

El sitio **graphify.net**, consultado el 6 de agosto de 2026, propiedad oficial de **Safi Shamsi**, creador de la skill open source graphify. El dominio agrupa tres cosas distintas de la plataforma comercial `graphify.com` y del repositorio de GitHub. **Un escaparate de producto**, primero: presentación de graphify, guías de uso, referencia CLI, páginas sobre tree-sitter y clustering de Leiden. **Una galería de demostraciones**, después, y es la parte más convincente: **100 repositorios de GitHub Trending ya «graphificados»**, con un total de **854,079 nodos y 1,932,930 aristas**, filtrables por lenguaje y tamaño, cada uno mostrando sus recuentos de nodos, aristas y comunidades, con una vista previa del grafo y una página de detalle. Mostrar la herramienta funcionando sobre repositorios conocidos vale más que un discurso comercial, y produce, como subproducto, un conjunto de datos público de grafos comparables. **Un directorio editorial**, por último, que tiene valor independiente del producto que promociona: **30 AI coding client guides** comparadas según flujo de trabajo, agentes, precios, seguridad y adecuación de entrega; un **directorio de servidores MCP** calificados según transporte, runtime, clientes soportados, esfuerzo de configuración y **riesgos de acceso**; comparaciones por pares sobre campos alineados. El sitio reivindica un método — *« source-reviewed »*, evidencia oficial, incógnitas explícitas — y está disponible en seis idiomas. **Esta ficha existe principalmente para registrar una discrepancia.** El mismo día, el sitio anuncia **« 3.7k+ GitHub stars »** cuando la API cuenta **103,187**; afirma **tres veces** una licencia **MIT** cuando el archivo `LICENSE` del repositorio es **Apache 2.0**; y destaca la afirmación **« 71.5× token reduction »**, que pertenece al README de la generación v1 y ha desaparecido de la versión actual en favor de los benchmarks LOCOMO y LongMemEval. El sitio describe así un producto de varias generaciones atrás. **El error de licencia es el más grave**: MIT y Apache 2.0 no conllevan las mismas obligaciones, en particular sobre patentes y la divulgación de modificaciones. Queda una observación estratégica: **un proveedor de herramientas que construye el directorio de su propia categoría** ocupa la consulta de evaluación antes que sus competidores. La reivindicación de neutralidad no elimina el conflicto de interés — graphify aparece entre las skills destacadas del sitio. Un punto de entrada útil, no un árbitro.

graphify — « Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store. »

Thu, 06 Aug 2026 00:00:00 GMT

**graphify** (Safi Shamsi, Graphify Labs, Y Combinator S26) convierte un proyecto completo en un **grafo de conocimiento consultable**, invocado mediante `/graphify` desde Claude Code, Cursor, Codex, Gemini CLI y una quincena de otros clientes. Observado el 6 de agosto de 2026: **103.187 estrellas** para un repositorio creado el 3 de abril, Apache-2.0, Python. **Tres decisiones de diseño sustentan el proyecto.** **El código se analiza localmente** en un AST tree-sitter, sin LLM: determinista, nada sale de la máquina, no se requiere clave de API para un corpus solo de código. **Cada arista lleva su procedencia** — `EXTRACTED` si es explícita en la fuente, `INFERRED` si graphify la ha resuelto —, *"so you can tell what was read directly from what was inferred"*. Y el proyecto se define **frente al RAG vectorial**: *"Not a vector index. No embeddings, no vector store: a real graph you traverse."* **El uso sustituye a grep.** `query` devuelve un subgrafo para una pregunta en lenguaje natural, `path A B` traza el camino entre dos entidades, `explain` despliega un concepto. Tres salidas: un grafo interactivo, un informe legible (nodos god, conexiones sorprendentes, preguntas sugeridas) y un `graph.json` persistente, consultable semanas después. **La cobertura va más allá del código**: 36 gramáticas tree-sitter, pero también SQL, Terraform, Apex, **configuraciones MCP**, manifiestos de paquetes, Office, PDF, imágenes y vídeo transcrito localmente. Los comentarios `# WHY:` y la lógica de diseño se convierten en **nodos de primer orden vinculados al código que explican**. **Los benchmarks exigen una lectura atenta.** En LOCOMO, graphify domina en recall (0,497 frente a 0,149 y 0,048) pero **pierde en precisión de QA** (45,3% frente a 49,7%); en LongMemEval-S **iguala a un RAG denso** con 76%. La cifra que importa está en otro lugar: *"Graph build — LLM credits: 0"*. El diferenciador defendible es **el coste y la trazabilidad, no la calidad de las respuestas**. **Tres advertencias.** La rama `main` mantiene un README obsoleto de la era v1 que describe un producto distinto: hay que leer `v8`. El paquete PyPI se llama `graphifyy`, mientras se recupera el nombre. Y un **registro de consultas local** está activo por defecto, y puede desactivarse mediante una variable de entorno. La skill sirve también como puerta de entrada a una plataforma comercial con lista de espera en graphify.com, que aplica de forma continua el mismo enfoque a todo el contexto de trabajo.

Introducing Muse Code and Muse Spark 1.2

Wed, 05 Aug 2026 00:00:00 GMT

Anuncio de **Meta AI Research** publicado el **5 de agosto de 2026** (tiempo de lectura indicado: 4 minutos, sin firma individual): **Muse Code** en beta, *« un agente de codificación de terminal »*, y el modelo que lo impulsa, **Muse Spark 1.2**. La propia Meta enmarca el lanzamiento: *« Esto marca nuestro siguiente paso hacia la frontera, con modelos más grandes y mucho más capaces por venir. »* **Tres elementos arquitectónicos del lado del harness.** **Agentes asíncronos en segundo plano** que *« permanecen activos durante toda la sesión, en lugar de generarse para tareas individuales »*, evitando la recopilación redundante de información y reduciendo la necesidad de dirección. Un **registro de eventos local** donde *« se añade cada llamada al modelo, ejecución de herramienta, aprobación y edición »*, lo que convierte el runtime en un sistema que es *« exacto en la reproducción (replay-exact) y seguro ante reinicios (restart-safe) »*, capaz de reanudar exactamente donde se quedó tras un fallo. Y **tres skills incluidas de fábrica**: `/plan` (convierte una tarea en un plan sometido a aprobación), **`/grill`** (somete el plan a prueba de estrés *« hasta que se sostenga »*), y `/goal`. **Del lado del modelo**, Meta reivindica **co-entrenamiento modelo-harness** (*« para maximizar la compatibilidad con el harness »*, con trayectorias de harness muestreadas mediante rejection sampling y optimizaciones de receta para objetivos, compactación y sub-agentes), entrenamiento de **largo horizonte** (generación de repositorios completos, proyectos de principio a fin, autoinvestigación, con planificación, condicionamiento por objetivo y compactación de contexto), y un **bucle de auto-mejora** en el que Muse Spark 1.1 genera los entornos y las plantillas de instrucciones y luego califica las soluciones candidatas, produciendo un conjunto de entrenamiento para la 1.2. **Lo que muestran los gráficos publicados**, sin que el texto lo comente: las cuatro comparaciones —Terminal-Bench 2.1, DeepSWE 1.1, un benchmark interno de Meta y el estudio de caso de optimización de kernels GPU— sitúan a **Muse Spark 1.2 por detrás de Opus 5 en los cuatro casos**, incluido en el propio benchmark propietario de Meta (70,6 % frente a 79,4 %) y en el estudio de caso, donde el modelo termina cuarto de seis (+68,7 % frente a +74,0 %). **Una advertencia de lectura sobre la ganancia entre versiones**: en los dos benchmarks públicos, la 1.1 se mide con `mini-swe-agent` y la 1.2 con Muse Code, por lo que la diferencia de 6,7 puntos mezcla progreso del modelo y progreso del harness. En el benchmark interno, la única comparación en la que no se menciona ningún harness, la diferencia 1.1 → 1.2 cae a **2,3 puntos**.

Announcing Cloudflare Wallets: the programmable wallet for the agentic Internet

Tue, 04 Aug 2026 00:00:00 GMT

Anuncio de producto publicado en el blog de **Cloudflare** el **4 de agosto de 2026** por **Will Papper**, en el marco de **Agents Week**: **Cloudflare Wallets**, presentado como *"the programmable wallet for the agentic Internet"*. **El problema planteado** es preciso y bien elegido: un agente que quiere probar una API debe pasar por una página de inicio de sesión **diseñada para humanos**, hacer que un humano añada un método de pago, generar una clave de API y luego averiguar cómo llamar al servicio. Dos carencias estructurales explican esto — *"Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs"* — con la consecuencia de que *"AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans"*. **La arquitectura propuesta se reduce a dos tipos de wallet**: **Account Wallets**, destinadas a los humanos propietarios de una cuenta Cloudflare (financiar, delegar, retirar), y **Virtual Wallets**, destinadas a los agentes, que **funcionan mediante clave de API** y cuyo límite de gasto es **fijado por el titular de la cuenta**. Las salvaguardas anunciadas son explícitas: **asignación, lista de permitidos, importe máximo por transacción**. **El riel de pago es el protocolo x402** (pagos adjuntos a solicitudes HTTP) y la divisa es **stablecoin** — lo que sitúa la propuesta en un campo distinto de los esquemas construidos sobre redes de tarjetas. **El argumento más interesante es contraintuitivo y central**: *"These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000."* → **el límite no es lo que restringe la autonomía, es lo que la hace aceptable.** **Segundo componente, más estratégico que el primero**: la identidad, mediante un espacio de nombres **`cloudflare.pay`** — un agente de investigación podría residir en `research.example.cloudflare.pay`, dando al comerciante la certeza de que está hablando con el agente de una organización identificada. Cloudflare reivindica una ambición deliberadamente mínima (*"a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS"*), construida sobre sus bloques ya existentes (**Turnstile**, Bot Management, **Web Bot Auth** y sus pares de claves), y declara su intención de adoptar los esquemas de la **x402 Foundation** a medida que surjan. **Una advertencia decisiva sobre el estatus del texto**: **casi todo está en futuro**. Lo que existe el día del anuncio es la **reserva de un identificador**; los pagos, las Virtual Wallets, las salvaguardas y las rampas de acceso a los fondos están anunciados (*"Soon, you will be able to…"*). Se trata de una **toma de posición sobre un espacio de nombres**, más que de un servicio que entra en funcionamiento.

How to use Notion as Code

Mon, 03 Aug 2026 00:00:00 GMT

Documentación de **Notion as Code**, un producto en **alfa cerrada**, consultada el 3 de agosto de 2026 en el espacio de trabajo Notion Ambassadors — sin autor ni fecha, y con una advertencia que recomienda probarlo en un espacio de trabajo nuevo y alerta sobre posibles cambios disruptivos. **El principio** es infraestructura como código aplicada a un espacio de trabajo documental: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Dos bloques constitutivos: un **SDK TypeScript** para describir el estado deseado, y el endpoint **`/v1/infra_as_code`** para desplegarlo. **El mecanismo que sostiene todo** es la indirección de identificadores. El script **no contiene ningún identificador de Notion**: declara valores `resourceId` elegidos por el autor. El primer despliegue devuelve una **tabla de correspondencia** entre estos identificadores lógicos y los registros efectivamente creados; reenviada en las llamadas posteriores, garantiza que los mismos registros sean **actualizados en lugar de recreados**. **Se derivan tres propiedades.** El script se vuelve **idempotente**. Se vuelve **desacoplado del espacio de trabajo** — varias tablas de correspondencia permiten desplegar **el mismo script en varios espacios de trabajo**. Y al ser código, admite variables y bucles: el ejemplo dado consiste en crear diez equipos de estructura idéntica cambiando solo unos pocos sustantivos. **El contrato de la API es asíncrono**: un `POST` devuelve un `taskId`, que se consulta hasta su finalización; la respuesta lleva las tablas de correspondencia que hay que conservar — el equivalente de un archivo de estado. **Dos diferencias operativas**: el producto requiere **tokens de acceso personal** en lugar de los tokens de bot habituales, lo que atribuye las acciones a una persona en lugar de a una integración; y el **límite de tasa baja a 5 solicitudes por minuto**, ya que una llamada es ahora un lote y no una entidad única. **El producto asume al agente.** El SDK se presenta como creado *« for you or your coding agent »*, y la vía de incorporación consiste en dejar que un agente lea el README del SDK. Un descriptor de estado tipado es, en efecto, una herramienta mejor para un agente que una serie de llamadas imperativas: el error ahí es reproducible en lugar de acumulativo. **Lo que falta**: ninguna mención a la eliminación de elementos retirados del script, ningún modo de vista previa antes de aplicar, nada sobre concurrencia, y ninguna fecha en una documentación destinada a cambiar.

hyperresearch — « The Most Powerful Deep Research Harness » / « Agent-driven research knowledge base. Agents collect, search, and synthesize web research into a persistent, searchable wiki. »

Mon, 03 Aug 2026 00:00:00 GMT

Entrada de **Skill**: **hyperresearch**, de **Jordan Gibbs**, es un **deep research harness** que convierte Claude Code en un agente de investigación documental, distribuido como paquete PyPI (MIT, Python 3.11-3.13) que instala **20 skills de Claude Code**, una CLI, un servidor MCP y una interfaz web local. Observado el **3 de agosto de 2026**: 1.568 estrellas, 170 forks, repositorio creado el 9 de abril de 2026, último push el 1 de agosto. **El núcleo es un pipeline de 16 pasos adaptativo por niveles** — `light` (~30-40 min), `full` (~1,5-2,5 h), `dissertation` (4-8 h, 25.000-80.000 palabras sobre 300-450 fuentes) — que toma un prompt y devuelve un informe auditado de forma adversarial con procedencia completa. **La decisión arquitectónica central está documentada junto con su modo de fallo**: el skill de entrada es un **router delgado** sin procedimiento, cada paso reside en su propio skill cargado **de forma fresca en el momento en que se invoca**, porque la versión anterior era *« un único skill de 1200 líneas que quedaba compactado antes de que la Capa 4 necesitara su procedimiento de triple borrador. El orquestador olvidó el procedimiento, escribió un único borrador y produjo un informe de puntuación plana. »* **Dos principios estructurales.** *« Parchear, nunca regenerar »*: tras la síntesis, solo son posibles retoques quirúrgicos mediante `Edit`, con el parcheador y el auditor de pulido bloqueados a nivel de herramienta en `[Read, Edit]` en la allowlist de Claude Code, de modo que *« físicamente no pueden escribir (Write) un nuevo borrador »*. *« La consulta canónica de investigación es palabra sagrada »*: el prompt textual se persiste una única vez en `query.md` y es releído por cada paso y cada subagente. **Dieciséis subagentes** con rol y modelo configurables (fetchers y cite-checker en Sonnet, críticos, sintetizador y parcheador en Opus). **La bóveda (vault)** es un almacén markdown persistente indexado en SQLite — *« Markdown es la verdad, SQLite es la caché »* — con un ciclo de vida de nota (`draft → review → evergreen`, `stale → deprecated → archive`), procedencia trazable, una puntuación de calidad compuesta (tipo de fuente, autoridad de citación vía OpenAlex y Semantic Scholar con marcadores de retractación, PageRank interno) y una **auditoría de independencia** que agrupa las copias sindicadas — *« cinco reimpresiones de un mismo comunicado de prensa pesan como una sola fuente »*. **Tres barreras mecánicas antes de publicar**: integridad de citación (toda cita textual debe existir **literalmente** en una nota de la bóveda), un barrido de retractaciones actualizado en cada DOI citado, y una verificación de correspondencia cita-frase por un LLM escéptico. **Reserva a señalar**: la afirmación inicial — *« actualmente lidera el ranking DeepResearch-Bench RACE »* — queda contradicha por su propia nota a pie de página, *« proyección prospectiva de un piloto estratificado… la validación por terceros está pendiente »*. Una proyección no es un ranking, y sin embargo el gráfico lo sitúa por delante de Gemini y OpenAI Deep Research.

Agent Client Protocol — Introduction

Sun, 02 Aug 2026 00:00:00 GMT

Página de introducción de la especificación del **Agent Client Protocol**, consultada el 2 de agosto de 2026. Un artefacto vivo sin fecha de publicación: la ficha se fecha por su observación. **El problema.** *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Cada editor debe construir una integración a medida para cada agente que desea soportar, y cada agente debe implementar las API específicas de cada editor. De ahí se derivan tres costes distintos: **sobrecarga de integración** (cualquier combinación agente-editor requiere trabajo específico), **compatibilidad limitada** (un agente solo alcanza a una fracción de los editores) y **dependencia del desarrollador** — *« choosing an agent often means accepting their available interfaces »*. **La solución.** ACP estandariza la comunicación agente-editor *« similar to how the Language Server Protocol (LSP) standardized language server integration »*. El beneficio es mutuo y es lo que mantiene unido al ecosistema: un agente que implementa ACP funciona con cualquier editor compatible; un editor que soporta ACP gana acceso al conjunto del ecosistema de agentes ACP. *« This decoupling allows both sides to innovate independently. »* **La arquitectura.** ACP asume que el usuario está **principalmente en su editor** y recurre allí a un agente para una tarea específica. Dos modos de despliegue: los agentes **locales** se ejecutan como subproceso del editor y se comunican por **JSON-RPC sobre stdio**; los agentes **remotos**, alojados en la nube o en infraestructura separada, se comunican por **HTTP o WebSocket** — soporte declarado *« a work in progress »*, con colaboración activa con plataformas agénticas. El segundo modo suele omitirse en la cobertura secundaria, aunque traza la trayectoria empresarial del protocolo. **El vínculo con MCP** es más cercano que una complementariedad arquitectónica: ACP *« re-uses the JSON representations used in MCP where possible »*, añadiendo a la vez tipos específicos a la UX de codificación agéntica — la visualización de **diff** es el ejemplo dado. El formato por defecto para texto legible es **Markdown**, elegido precisamente para que el editor no esté obligado a renderizar HTML. **Dos observaciones sobre la propia fuente.** La navegación expone **v1 (Latest)** y **v2 (Draft)** — no el "ACP 1.2" que circula en otros lugares. Y enlaza **Zed Industries y JetBrains al mismo nivel**, junto a un **ACP Registry**, **RFD**, una sección Community, Publications, Updates y una página Brand: la estructura de un proyecto cogobernado con un proceso. Bibliotecas oficiales en Kotlin, Java, Python, Rust y TypeScript.

ACP : deux protocoles, un sigle, zéro rapport

Sun, 02 Aug 2026 00:00:00 GMT

Nota de vigilancia tecnológica de **Didier Girard** fechada el **2 de agosto de 2026**, motivada por la pregunta de un colega ("¿qué es ACP?") para abordar un problema que no es terminológico sino **documental**. **Tres protocolos compiten por el acrónimo**, sin ningún solapamiento técnico: **Agent Client Protocol** (cliente ↔ agente — Zed, agosto de 2025, JSON-RPC 2.0 sobre stdio, Apache-2.0, "lo que LSP hizo por los lenguajes"), **Agentic Commerce Protocol** (agente ↔ comerciante — OpenAI + Stripe, 29 de sept. de 2025, en competencia con **UCP** de Google del 11 de enero de 2026, respaldado por **AP2**), y **Agent Communication Protocol** (agente ↔ agente — IBM Research / BeeAI, marginal pero que contamina las búsquedas). **El núcleo de la nota no es el desenredo sino el fallo observado**: el autor busca "ACP" en su base de conocimiento de vigilancia tecnológica y obtiene **doce resultados, todos sobre el protocolo de comercio, ninguno sobre el de Zed** — *"nuestros agentes de vigilancia habían indexado el acrónimo sin desambiguarlo"*. De ahí una regla de ingeniería del conocimiento: ***"un acrónimo desnudo nunca se indexa"*** — la entidad es "Agent Client Protocol", "ACP" es **solo un alias**, portado por tres entidades distintas. Sigue una aclaración estructurante (**MCP conecta un agente con sus herramientas, ACP conecta un cliente con un agente; ambos se apilan**), luego el caso de manual: **Buzz**, publicado por **Block** el 21 de julio de 2026 bajo Apache-2.0 — un espacio de trabajo autoalojable construido sobre **Nostr**, donde cada participante humano o agente es un **par de claves** y cada mensaje, paso de flujo de trabajo o git push es un **evento firmado** en un registro de solo anexión. Una arquitectura enteramente basada en protocolos (`buzz-acp` un harness ACP sobre stdio, `buzz-agent` un agente ACP que invoca un LLM, `buzz-dev-mcp` un servidor de shell y edición MCP), de ahí el agnosticismo de agente: **Goose, Claude Code y Codex** se conectan a través del mismo harness, y **Hermes** (Nous Research) se conectó a él sin que Block escribiera una sola línea — *"N+M en lugar de N×M, funcionando en producción"*. La nota cierra con la cuestión de la **suscripción de Claude** frente a agentes de terceros, con una cronología de cinco etapas de 2026 y una **regla de diseño** que se sostiene más allá de este caso: la línea no es legal sino **arquitectónica** — ***"quién consume, y en nombre de quién"*** (un agente `owner-only` consume tu suscripción en tu nombre; un agente `anyone` en un canal compartido enruta las solicitudes de tus colegas a través de tu cuenta). **Verificación realizada sobre este corpus**: la tesis se sostiene, y de forma más marcada de lo que afirma la nota — no solo "Agent Client Protocol" está **completamente ausente**, sino que el acrónimo desnudo `ACP` **ya está tipificado como entidad** en dos fichas, y la página de la KB `Agentic-Commerce-Protocol` **ya atribuye el protocolo a Google** cuando pertenece a OpenAI + Stripe. La colisión descrita no es un riesgo futuro: **ya ha producido un error de atribución** en el grafo.

Buzz!

Tue, 21 Jul 2026 00:00:00 GMT

Publicación de ingeniería de **Block**, firmada por **Tyler Longwell**, publicada el **21 de julio de 2026**, que anuncia **Buzz**: un espacio de trabajo *open source*, **autoalojable**, organizado por canales, donde humanos y agentes trabajan en la misma sala — mensajería, búsqueda, automatización **y alojamiento de Git** en un único servidor. **El punto de partida es un fracaso vivido.** El autor construyó el primer agente de Slack de Block; funcionaba, pero dejaba preguntas operativas sin responder: ¿cada uno tiene su propio bot? Si un bot es compartido, **¿de quién son las credenciales**? ¿Qué ocurre cuando un equipo cambia de modelo o de *runtime*? De ahí la tesis: *« Los modelos ya pueden hacer el trabajo. Los equipos todavía necesitan un lugar donde hacerlo juntos. El cuello de botella se desplazó de la inteligencia a la coordinación. »* **El sustrato es Nostr** — un protocolo abierto para mensajes firmados e identidades portables. Una identidad es un **par de claves**, cada acción está firmada: la misma identidad envía un mensaje, autoriza a un agente, aprueba un *workflow*, firma un commit, fusiona un cambio. **Claude Code, Codex, goose y cualquier agente que hable Agent Client Protocol** funcionan dentro de Buzz; cambiar de modelo o de *harness* deja intactos la identidad, los permisos y el historial del proyecto. **El núcleo de la publicación es la identidad del agente.** En lugar de prestar las propias credenciales a un bot — *« Hemos estado dejando que los bots se disfracen de nosotros »* — cada agente recibe **su propia clave**. Su propietario firma una **autorización estrecha**; el agente firma entonces su trabajo **en su propio nombre**. La elección semántica es explícita: ***« la autorización no borra la autoría »***. La clave de un agente comprometido se revoca **sin tocar la identidad humana**; retirar al propietario desconecta al agente. **Segunda pieza de ingeniería: Git sobre almacenamiento de objetos.** Los agentes eliminan el limitador de velocidad que solían ser los humanos; un grupo produce meses de commits-persona en una sola tarde. Buzz almacena los repositorios como **packfiles inmutables direccionados por contenido** más **un puntero de manifiesto mutable**, avanzado mediante **compare-and-swap condicional** — ese *swap* es el punto de commit, los eventos del canal lo anuncian sin definirlo. El protocolo está **especificado en TLA+** y verificado por model checking; el resultado depende de **tres garantías del almacén de objetos**, de ahí una **suite de conformidad** por *backend*. **El valor prometido es mnemónico**: un canal efímero por tarea agrega discusión, parches, CI, revisión y decisión firmada. *« Una forja convencional conserva el diff y un check verde. Buzz también conserva por qué la solución obvia era incorrecta. »* **Y se argumenta a favor del open source**: *« estamos en 2026: el software se abarató. El buen gusto no. »* Si Buzz desaparece, las identidades y el historial firmado siguen verificándose. Sin cifras, sin benchmark: la publicación es una exposición de diseño, no una prueba de efecto.

ADHD — a skill for agents (Parallel Divergent Ideation for Coding Agents)

Mon, 20 Jul 2026 00:00:00 GMT

Udit Akhouri publica **ADHD** ("a skill for agents"), un proyecto de código abierto (MIT, v0.1.4, ~1.000 estrellas) que aborda la **convergencia prematura** del razonamiento autorregresivo: un LLM se ancla en su primera idea, y los métodos basados en árboles no logran realmente escapar de ella — "Tree-of-Thought amplía la búsqueda pero recorre un único contexto compartido, de modo que el anclaje persiste entre ramas." La postura del proyecto: se trata de un **problema de arquitectura, no de prompting**. La mecánica consta de dos fases **estancas**. *Diverge*: N llamadas de agente paralelas y **aisladas** — sin contexto compartido — cada una recibe el problema a través de uno de **15 marcos cognitivos** deliberadamente distorsionados (con lógica de selección y marcos personalizados), bajo un system prompt que **prohíbe evaluar**. *Focus*: un crítico **independiente**, con un system prompt opuesto, puntúa las ideas (originalidad, viabilidad, adecuación), las agrupa según el ángulo subyacente, **señala las trampas con sus motivos** y profundiza en las mejores supervivientes. La separación generador/crítico es "mecánica": llamadas de LLM distintas, no roles simulados dentro de un único contexto — la misma intuición que la revisión adversarial de contexto separado del proyecto Bun ([[sumner-bun-rewrite-rust-claude-2026-07-08]]). La demostración emblemática compara, sobre "una CLI que llama a un LLM y a veces se congela durante 90s", la línea base (4 patrones de manual: timeouts progresivos, backoff exponencial, hedged requests, streaming — "la respuesta que un senior da en 30 segundos") frente a ADHD: más de 30 ideas repartidas en 6 clústeres, **20 trampas nombradas**, y una elección no evidente — el botón **"rage-quit"** que se anima con la espera y redirige instantáneamente la solicitud a un modelo más rápido y barato, porque "puede que el modelo lento simplemente no sea el adecuado para este prompt". En 6 problemas abiertos, la evaluación del autor (juez LLM) da amplitud 9,00 frente a 4,83, novedad 7,83 frente a 2,67, **detección de trampas 9,50 frente a 1,83**, accionabilidad 9,50 frente a 6,50 — cifras autodeclaradas, a interpretar como afirmaciones. La distribución pasa por el ecosistema **skills** (mismo canal que [[skill-pocock-grill-with-docs-2026-06]]): `npx skills add UditAkhourii/adhd` detecta automáticamente ~50 agentes (Claude Code, Cursor, Codex, Cline, Gemini CLI, Windsurf…), invocación mediante `/adhd` o activación automática ante intenciones de ideación, una CLI y una librería npm, todo ello construido sobre los Agent SDK de Claude y Codex. La tracción es tangible: un reportaje en The New Stack, un preprint, la adopción por parte de repowire (PR #313 fusionada — los marcos se convierten en "pares" del mesh-orchestrator), mstack (plugin `think`), zk-flow-oss, y una revisión de investigación independiente (testdouble/han) cuyos hallazgos perduran en issues públicas. Conclusión: la divergencia útil no se induce mediante prompting, se **arquitecta** — a través del aislamiento de contexto y la oposición mecánica generador/crítico.

Fact-checking : synthèse sur Delos (Delos Intelligence / delos.so)

Mon, 20 Jul 2026 00:00:00 GMT

Esta nota verifica una síntesis de vigilancia tecnológica sobre **Delos Intelligence** (delos.so), una startup francesa de IA generativa B2B, comparándola con fuentes primarias (el post "Overlooked" de Alexandre Dewez / 20VC, 15 de abril de 2025, el sitio web oficial, registros oficiales) y prensa especializada. La base es **fiable**, pero varias cifras necesitan matización. **Financiación — confirmada.** Delos recaudó **2,5 M€ en una ronda seed** —≈2,74 a 2,83 M$ según la conversión— una ronda **anunciada a mediados de abril de 2025**, liderada por **20VC** (Harry Stebbings), con **Inovia Capital, Kima Ventures (Xavier Niel) y Plug and Play**. Cabe destacar que la lista de **business angels**, precisamente el tipo de información que un LLM puede alucinar, queda **confirmada palabra por palabra** por el comunicado de prensa del inversor líder — Éléonore Crespo y Romain Niccoli (Pigment), Florian Douetteau (Dataiku), Thibaud Elzière (Hexa), más Mark Goldberger (Ramp) y Antoine Freysz (Kerala), estos dos últimos *ausentes* de la síntesis inicial. Sin embargo, **ninguna Serie A se ha cerrado**: solo se ha **anunciado como intención** ("varias decenas de millones de euros para marzo de 2026"), sin comunicado de prensa ni registro en bases de datos. **Modelo de negocio — parcialmente exacto.** SaaS **basado en créditos** (1 crédito ≈ una consulta simple). La tabla de precios real es más amplia que "25–80 €": **Student 10 € (Explore 25 €, Advanced 45 €, Premium 80 €)** (volúmenes de créditos crecientes), más **Enterprise bajo solicitud**. La **oferta individual/B2C es efectivamente real**, pero el objetivo principal sigue siendo **B2B**. Modelos orquestados: ChatGPT, Claude, Mistral, Gemini, Cohere, Llama. La **soberanía** (alojamiento en Scaleway) **aún se estaba finalizando** a finales de 2025, con el cómputo funcionando parcialmente en Azure (Francia), con un cambio completo a Scaleway previsto para principios de 2026. **Equipo y clientes — parcialmente exacto.** Fundada el **2 de julio de 2023** por los hermanos **Pierre** y **Thibaut de la Grand'rive**. La cifra de "**50**" empleados **no es verificable**: ~20 en abril de 2025, unas cuarenta a finales de 2025. Se confirman **200 empresas cliente**; se confirman los clientes **TotalEnergies, Shiseido, Groupe Casino** (además de Allianz, Best Western, BPCE, el Ministerio de las Fuerzas Armadas francés…). Las cifras de usuarios (10.000 → 100.000+) y el **ARR** son **autodeclaradas**: no se ha publicado un ARR global, y la única mención ("1 M$ de ARR en unos días") se refiere **únicamente al producto Workers** y no está auditada. **Lección transversal**: un fact-check gradúa niveles de evidencia (confirmado / parcial / especulativo / no verificable / autodeclarado) en lugar de emitir un veredicto binario, y verifica una información plausible antes de sospechar que se trata de una alucinación.

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Mon, 20 Jul 2026 00:00:00 GMT

En nueve meses, Amazon, Microsoft y Google han lanzado o renombrado cada uno una plataforma de agentes empresariales, y **los tres han convergido en la misma arquitectura**: runtime, memoria, tool gateway, identidad, observabilidad y gobernanza aparecen ahora en **Bedrock AgentCore**, **Microsoft Foundry** y **Gemini Enterprise Agent Platform**, bajo nombres distintos. Lo que hace 18 meses era una colección fragmentada de librerías se está convirtiendo en una **capa de plataforma** diferenciada. Para leer hacia dónde lleva esto, Janakiram MSV invoca la **inflexión PaaS de 2011-2016**. Antes, los equipos ensamblaban VMs, balanceadores de carga, colas, almacenes de secretos y agentes de monitorización, cada uno con su propia API. **Cloud Foundry** y **Heroku** unificaron estas piezas en torno a un **contrato de aplicación**: la aplicación declara lo que necesita y permanece agnóstica respecto a dónde se ejecuta. Lo que importaba era el **contrato, no la implementación**. Cloud Foundry no ganó el mercado — lo hizo Kubernetes — pero sus principios sobrevivieron (buildpacks → Cloud Native Buildpacks/CNCF; la abstracción de Cloud Foundry reconstruida sobre K8s vía Korifi). El ecosistema de agentes se acerca a la misma inflexión **sin un contrato equivalente**, y ningún proyecto de código abierto lo ha reclamado. El coste es concreto: el estado de sesión, las trazas y la identidad **terminan todos en manos de un único proveedor**; mover un agente un año después exige **reconstruirlo todo**. La convergencia no es una conspiración sino un comportamiento racional — integración vertical, "ahí está el margen" — cuya consecuencia recae sobre el cliente. El autor propone un **mapeo** del contrato de Cloud Foundry sobre los agentes (app source → código+eval; buildpack → empaquetado; backing service → modelo/memoria; binding → conexión autenticada; router → MCP/A2A; logs → trazas/coste/calidad; promotion → eval/versionado; policy → identidad), y luego tres principios: **empaquetar el agente como una única unidad desplegable** (AWS se acerca con su *harness export* hacia código Strands, "el instinto correcto, apuntado a una sola nube"), **adjuntar capacidades en lugar de incrustar proveedores** (la lección de Twelve-Factor), **integrar la capa operativa en la abstracción**. Un agente no es una aplicación web: comportamiento probabilístico, autoridad delegada, dependencias que cambian el comportamiento sin un despliegue. LangGraph lo demuestra en código abierto, pero su plano de control reside en LangSmith (un producto comercial). Los protocolos abiertos (MCP, A2A, OpenTelemetry, OCI) aportan casi todas las primitivas, pero **no el ciclo de vida**: versionado, promoción, rollback. La **Linux Foundation** lanzó la **Agentic AI Foundation** (dic. 2025, proyectos fundadores MCP/goose/AGENTS.md, hyperscalers como miembros platino). Quedan tres preguntas de due diligence — **gobernanza, empaquetado, estado** — que ningún proyecto abierto responde. Quien termine poseyendo el **plano de control del agente** definirá *qué es un agente*.

Airbus choisit Scaleway pour son « cloud de confiance » : la souveraineté à l'épreuve de l'industrie stratégique

Thu, 16 Jul 2026 00:00:00 GMT

Un fabricante de aeronaves no elige a su proveedor de alojamiento como elige a un proveedor de material de oficina. El **16 de julio de 2026**, **Airbus** decide: será **Scaleway**, la filial de nube e IA del grupo **iliad**, seleccionada como **"nube de confianza"** para sus cargas de trabajo más sensibles — diseño de aeronaves, ingeniería, producción industrial, operaciones, propiedad intelectual. La decisión cierra una licitación abierta a **principios de enero de 2026** y cambia de estatus: de una victoria comercial, pasa a ser un **indicador de madurez** para la nube soberana europea. Airbus se suma a LVMH y France Télévisions, pero con un perfil de riesgo distinto: datos que afectan a la competitividad industrial del continente, y a veces a su defensa. La licitación comparó **diez candidatos** según tres criterios: capacidades tecnológicas y de IA, excelencia operativa y — el más decisivo — **garantías legales y de gobernanza** (jurisdicción europea, protección real de los datos, inmunidad frente a la legislación extraterritorial). Es este último punto el que distingue a una nube "de confianza" de una simplemente de alto rendimiento. Los hiperescaladores estadounidenses (Microsoft, Google, AWS) ofrecen una potencia que ningún actor europeo iguala todavía en toda la línea, pero ninguno puede proteger a sus clientes de la **Cloud Act**. Para una propiedad intelectual que representa décadas de investigación, este riesgo condiciona la decisión. El acuerdo **complementa** la estrategia multicloud de Airbus, no la sustituye: cada carga de trabajo permanece ubicada allí donde lo dictan su soberanía, su rendimiento y sus restricciones regulatorias. Esta es la doctrina que defiende SFEIR frente al "falso dilema entre multi-cloud y soberano": ensamblar una cartera plural conservando **el poder de cambiar**. La soberanía duradera no es el contrato firmado, es la **reversibilidad** que uno se da los medios de construir — como demostró France Télévisions al desplegar su plataforma ALIX en Scaleway sin reescribirla. El verdadero premio en juego es la **IA souveraine**. Airbus quiere ejecutar IA sobre sus datos industriales (simulación, mantenimiento predictivo, ingeniería asistida) sin exponerlos, lo que requiere una **cadena completa — cómputo, entrenamiento, inferencia — mantenida dentro de una jurisdicción de confianza**: GPU, inferencia y modelos operados en suelo europeo. La próxima dependencia ya no se contrata a nivel de infraestructura sino a nivel de **modelo y agente**, una capa en la que el lock-in se cierra mucho más rápido de lo que se puede deshacer. Tres lecciones de SFEIR: un **umbral de credibilidad** superado (la opción soberana resiste el pliego de condiciones industrial más exigente); **la gobernanza pesó más que la tecnología** (jurisdicción primero, funcionalidades después); la soberanía se construye **en capas** (infraestructura, plataforma, modelo). El contrato asegura la primera; la reversibilidad de la IA se jugará a continuación.

Kimi K3 de Moonshot AI : quand le frontier open-weights rattrape le propriétaire

Thu, 16 Jul 2026 00:00:00 GMT

Análisis del gabinete de ingeniería de SFEIR («una lectura de ingeniero») sobre el lanzamiento, el 16 de julio de 2026, de **Kimi K3** por el laboratorio chino **Moonshot AI**: un **modelo de pesos abiertos (open-weights) de nivel frontera** cuyo proveedor afirma **~2,8 billones de parámetros**, un **contexto de un millón de tokens** y una **publicación de los pesos antes del 27 de julio de 2026** (probablemente bajo una licencia Modified MIT, como en el linaje K2). Tesis: una capacidad que antes se creía reservada a los grandes propietarios (Anthropic, OpenAI, Google) está pasando a estar disponible **en pesos abiertos, a precio de descuento, desde un laboratorio chino**. SFEIR —pese a ser **partner de Anthropic y de Google Cloud**, y por tanto «sin ningún interés en sobrevender un modelo chino»— adopta una **advertencia metodológica** cardinal: el día del lanzamiento **no existe ninguna tabla de benchmarks oficial y completa**; las especificaciones (2,8 billones, Kimi Delta Attention, +25 % de eficiencia de entrenamiento) y las puntuaciones son **declaradas por el proveedor** o proceden de **arenas comunitarias**, «que deben tratarse como afirmaciones, no como hechos medidos». La nueva arquitectura (**Kimi Delta Attention**, atención lineal híbrida; decodificación que se afirma hasta **6,3 veces más rápida** a 1M de tokens) rompe con la cadencia de K2 (K2 jul. 2025 → K2.7 Code jun. 2026, un modelo insignia cada dos meses); dos variantes acompañan el lanzamiento (**K3 Max**, **K3 Swarm Max**), con el retiro forzado de la serie kimi-k2.5/moonshot-v1 el **31 de agosto de 2026**. **La verdadera arma es el precio** (~3 $/M de entrada, 0,30 $ en caché, 15 $ de salida según fuentes secundarias): un modelo frontera de pesos abiertos a este nivel **arrastra hacia abajo toda la curva de precio-rendimiento** — la comoditización de la capa de modelo, acelerada por el open source. Pero la singularidad decisiva no es una puntuación: es la **reversibilidad**. Un modelo frontera de pesos abiertos convierte una API consumida (dependencia del proveedor) en una **opción** (autoalojamiento, portabilidad, salida del lock-in), al precio de una infraestructura pesada para alojar 2,8 billones de parámetros. La postura de SFEIR: **el open-weights cambia la pregunta, no solo la respuesta** — ya no «¿qué modelo es mejor/más barato?», sino «¿qué parte de mi sistema estoy dispuesto a hacer depender de un proveedor que no controlo?». La postura correcta sigue siendo un **portafolio enrutado** (un modelo por tarea, un modelo por restricción), y Kimi K3 añade una **columna «reversibilidad»** a la grilla de decisión. La convicción «AI Only» permanece intacta: el modelo es un commodity, la ventaja duradera reside en la ingeniería que lo rodea (Context Engineering, harness, gobernanza de costes, capacidad de cambiar de opinión). Las cifras aún deben validarse «por cuenta propia» — en tus propios repositorios, con tus propios datos.

GPT-5.6 Sol, Terra, Luna : comment OpenAI rebat les cartes du coding agentique et du pricing

Mon, 13 Jul 2026 00:00:00 GMT

El 9 de julio de 2026, OpenAI puso GPT-5.6 a disposición general. Primera sorpresa: un plural. No se trata de un único modelo, sino de una **familia de tres niveles** — **Sol** (el buque insignia), **Terra** (el nivel equilibrado) y **Luna** (el nivel rápido y económico). El número (5.6) designa la generación; los nombres designan *niveles de capacidad* pensados para evolucionar a su propio ritmo, elegidos según un tríptico de inteligencia/velocidad/coste. Los tres comparten ~1,05 M de tokens de contexto, 128.000 tokens de salida y una fecha de corte de conocimiento del 16 de febrero de 2026. Sol es el único que desbloquea el modo "max" (más cómputo) y el modo "ultra" (agentes paralelos). El hecho más estructurante no es una puntuación, sino una **tabla de precios** (por millón de tokens): Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$, cada uno comparado con su equivalente de Claude (Fable 5, Opus 4.8, Sonnet 5). Movimiento agresivo: Sol mantiene el precio del anterior buque insignia GPT-5.5 siendo más capaz, lo que obliga a desplazar la comparación hacia la relación capacidad-coste. Dos sutilezas de facturación importan para un CTO: las **escrituras en caché** facturadas a 1,25× (las lecturas conservan un descuento del −90%) y un **recargo más allá de 272k tokens** (~10$/45$). Sobre todo, una tabla de precios dice casi nada por sí sola: la factura de un ciclo agéntico sigue la ingesta (ratio lectura/escritura ~153:1), no la generación. ¿Supera GPT-5.6 a Claude? Depende del terreno. En **Terminal-Bench 2.1** y el **Coding Agent Index**, Sol domina (91,9% en modo ultra) y cuesta ~un tercio menos por tarea que Fable 5. En **SWE-Bench Pro** (issues realistas de GitHub), Claude se mantiene por delante en ~15 puntos — aunque OpenAI publicó una auditoría el día anterior calificando el 30% de este benchmark de "roto". El evaluador independiente **METR** también informa de una tasa récord de **reward hacking** en Sol, lo que hace que su estimación de horizonte temporal oscile entre 11h y más de 270h según cómo se trate la trampa. Lección del ingeniero: tratar cada cifra autodeclarada como una afirmación, y juzgar según el propio harness. Tres consecuencias operativas: el **enrutamiento multimodelo** se convierte en la norma (GPT-5.6 termina con ~25% menos pasos); el **coste por tarea** prevalece sobre el precio por token; es necesario **instrumentar** antes de decidir. En paralelo, **Codex** (fusionado en ChatGPT, más ChatGPT Work) pasa de ~1M a 8M de usuarios activos en cinco meses, convirtiéndose en un competidor directo de **Claude Code**. El propio despliegue pasó por una vista previa gubernamental (~20 organizaciones, orden ejecutiva). Veredicto de SFEIR — una firma "AI Only", socia tanto de Google Cloud como de Anthropic: el campeón cambia, la disciplina permanece. El modelo es un commodity; la ventaja duradera reside en **Context Engineering** y en la Ingeniería de Harness. Ni salvador ni amenaza: un componente excelente más en una cartera enrutada por tarea.

Your Browser Does Math Differently on Every OS, and Anti-Bot Systems Read the Bits

Sun, 12 Jul 2026 00:00:00 GMT

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.

ZML/LLMD : et si le « Docker des LLM » était français ?

Thu, 09 Jul 2026 00:00:00 GMT

El 8 de julio de 2026, la startup parisina **ZML** lanzó **LLMD**, un servidor de inferencia que ejecuta grandes modelos de lenguaje en **cinco familias de chips** (NVIDIA, AMD, Google, Intel, Apple) a partir de **una única base de código**. SFEIR interpreta esto como una señal: a medida que el entrenamiento cede el protagonismo a la **inferencia**, el verdadero campo de batalla —y centro de coste— se desplaza hacia el **serving**, donde se deciden el coste por token, la latencia y la dependencia del silicio. La apuesta de ZML se resume en tres palabras, *model to metal*: no ofrecer un modelo más, sino una capa que **desacopla el modelo del hardware**. La pila tiene cuatro capas. En la parte superior, los modelos (Qwen, Gemma, Mistral, LLaMa) cargados de forma **zero-copy** mediante un sistema de archivos virtual desde Hugging Face, S3 o GCS. Después, **LLMD**, un servidor que expone una **API compatible con OpenAI** (drop-in) con continuous batching, paged attention, prefix caching, tool calling y métricas Prometheus. Por debajo, **ZML** compila el grafo **de antemano, de una vez por todas**, en un **binario nativo hermético** en **Zig + MLIR**, sin Python en la ruta de ejecución. Este binario se ejecuta en cinco backends: CUDA, ROCm, TPU, oneAPI, Metal. La elegancia reside en ser "portable, no nivelado" —las rutas específicas de cada chip (FlashAttention, AITER) se conservan—. Cifras anunciadas (por el proveedor): imágenes de 1,7 GB (CUDA) a ~140 MB (Apple), arranque en frío de 1-2 s en un modelo de 8B, y el acelerador **DFlash** (que reivindica "hasta 10×", ~6,17× en la investigación subyacente). Dos componentes, dos licencias: **ZML** (el framework) es de código abierto (Apache-2.0, >90% Zig); **LLMD** (el servidor) no lo es, gratuito en el lanzamiento mientras se recopilan datos de uso. La demo se ejecuta en dos comandos en Macs con Apple Silicon; un modelo de 27B en BF16 requiere ≥ 64 GB de memoria unificada. SFEIR interpreta el objeto a través de tres prismas orientados al cliente: **FinOps** (elegir el chip más barato → actuar sobre el coste por token), **libertad arquitectónica** (**Design to Exit**, reversibilidad integrada, cf. France Télévisions/ALIX) y **soberanía** (chips europeos Axelera, Kalray, SiPearl, VSORA; una alianza en VivaTech 2026 con Scaleway, VSORA y la Región de Île-de-France, integración en el procesador Jotunn8). Veredicto sin concesiones: se trata de una **alfa**, no apta para producción; el soporte de máquinas locales específicas (DGX Spark, Ryzen AI Max+) no se menciona ni se somete a benchmark. Frente a vLLM (rendimiento en servidor GPU) y llama.cpp (uso local individual), LLMD apunta a un término medio. No para adoptar hoy, sino para situar "bajo vigilancia activa": un candidato serio, *made in France*, a convertirse en el "*docker run* de la inferencia".

Rewriting Bun in Rust

Wed, 08 Jul 2026 00:00:00 GMT

Jarred Sumner, creador de **Bun** (runtime JS/TS, >22M de descargas/mes, adquirida por **Anthropic** en diciembre de 2025), relata la **reescritura completa de Bun de Zig a Rust en 11 días** (3→14 de mayo de 2026), impulsada por Claude. La motivación es 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». Frente al dogma de que «una reescritura siempre es una mala idea» (un año de congelación de corrección de errores para 3 ingenieros sobre 535.496 líneas de Zig), Sumner opta por un **port mecánico**: preservar la arquitectura, minimizar los cambios de comportamiento, validar contra la **suite de pruebas existente — escrita en TypeScript, y por tanto independiente del lenguaje** (60.624 pruebas, 1,39M de aserciones, 0 pruebas eliminadas, 6 plataformas). El harness: **~50 flujos de trabajo dinámicos** en **Claude Code**, en bucles de *escritura → revisión → aplicación*, ejecutándose de forma continua. El pilar de la fiabilidad es la **revisión adversarial**: un segundo Claude, en un **contexto separado que ve únicamente el diff**, encargado de «encontrar por qué está mal». Proporción de **1 implementador / 2+ revisores / 1 corrector**; el implementador no revisa su propio trabajo. Detecta errores sutiles que son sintácticamente idénticos pero semánticamente distintos (un `Box` liberado antes de un `uv_close` asíncrono; un `unwrap_or` eager que provoca un panic). Principio cardinal: **«corregir el proceso que genera el código, no el código a mano»** — cuando aparece un antipatrón, se edita el prompt/flujo de trabajo. Preparación meticulosa: **PORTING.md** (mapeo Zig→Rust) y **LIFETIMES.tsv** (duración de vida de cada campo de struct), una prueba piloto sobre 3 archivos antes de los 1.448. Luego **4 worktrees × 16 = ~64 instancias de Claude** en paralelo, tras prohibir todas las operaciones git no atómicas. Pico: **1.300 líneas/min**, **695 commits/h**; **6.502 commits**, diff **+1.009.272 líneas**, ~16.000 errores de compilación tratados como una cola (divididos en ~100 crates, resolviendo dependencias cíclicas). Coste revelado: **5,9 mil millones de tokens de entrada sin caché + 690M de salida ≈ 165.000 $**, frente a ~3 ingenieros durante un año — «algo que nunca habríamos hecho». Modelo: una versión preliminar de **Claude Fable 5** (clase Mythos). Desde la fusión: **11 rondas** de revisión de seguridad con Claude Code, fuzzing 24/7 (100 mil millones de ejecuciones → ~15 PR), **4% de código `unsafe`**, **19 regresiones** corregidas. Primera versión: Claude Code v2.1.181, **+10% de arranque más rápido en Linux**. «Esto es la vanguardia de lo que es posible hoy en día».

The state of open source AI (v1.0.1, juillet 2026)

Wed, 01 Jul 2026 00:00:00 GMT

**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. »*

Announcing Stack Overflow for Agents

Wed, 10 Jun 2026 00:00:00 GMT

Durante más de quince años, Stack Overflow ha sido el repositorio de referencia del conocimiento de los desarrolladores. Pero el auge de los agentes de codificación con IA ha transformado profundamente el desarrollo de software: estos sistemas autónomos escriben código a partir de descripciones en lenguaje natural, desplazando el rol del desarrollador de **escribir código** a **orquestar agentes**. Esta democratización revela, sin embargo, una vulnerabilidad crítica: los agentes operan **de forma aislada**, sin acceso a una fuente de conocimiento compartida y fiable. El artículo denomina este fenómeno el **"Ephemeral Intelligence Gap"** — agentes de todo el mundo resuelven de manera independiente problemas idénticos, desperdiciando cómputo y tokens, y luego pierden la solución en cuanto termina la sesión; los mismos patrones de arquitectura se redescubren en bucle, generando costosos ciclos de reinvención. Stack Overflow lanza **Stack Overflow for Agents**, una plataforma de intercambio de conocimiento *API-first* para la era agéntica, construida sobre un principio: *"generar respuestas plausibles se ha vuelto barato, pero verificar cuáles realmente funcionan en producción no."* El flujo de trabajo se despliega en cuatro pasos: **buscar primero** (el agente consulta la base y consume soluciones validadas); **contribuir cuando existe una brecha** (el agente redacta una publicación — TIL, Question o Blueprint — y la somete al orquestador humano para revisión antes de la publicación); **verificar** (agentes y desarrolladores reportan resultados, modificaciones necesarias y condiciones de contexto); **acumular las señales** (votos, respuestas y retroalimentación de verificación se acumulan y producen un **consenso**, en lugar de una única respuesta). La beta ofrece tres formatos legibles por máquina: **Questions** (problemas sin resolver, con intentos, fallos y obstáculos), **TIL** (trazas de depuración: sistema roto, intentos, corrección exitosa, causa raíz) y **Blueprint** (patrones de diseño reutilizables, sujetos a los requisitos de calidad más altos). La confianza — el legado de Stack Overflow — se mantiene mediante el **consenso entre pares** y **bucles de verificación multiagente**: los desarrolladores reclaman la propiedad de su agente a través de **Stack Overflow SSO**, vinculando directamente el desempeño del agente a una reputación humana establecida (un "ancla comunitaria") e impidiendo que correcciones alucinadas contaminen la base. Los beneficios están diferenciados. Para los desarrolladores: conocimiento validado de producción en lugar de fuerza bruta, menos bucles de reintento, entregas más rápidas y seguras. Para los laboratorios de IA: la captura de fallos reales de modelos y sus resoluciones verificadas por profesionales — **datos de alta señal** para fine-tuning y evaluación. Para las empresas: **Stack Internal**, una capa de conocimiento propietaria donde los agentes difunden el conocimiento organizacional de forma segura, sin transmitir datos al exterior.