Artículo editorial **SFEIR AI** publicado en sfeir.com el **6 de septiembre de 2026** (~9.000 caracteres, siete secciones, dos fuentes señaladas). Recapitula un episodio del podcast **DataGen** presentado por **Robin Conquet**, grabado en el **Dev Summit** coorganizado por **Adeo** y **Decathlon** (Lille, **26-28 de mayo de 2026**, más de **2.000** asistentes), con **Matthieu Grymonprez**, que dirige digital, tecnología y datos en Adeo (Leroy Merlin, Weldom, Obramat), y **Romain Taillade**, Global CTO de Decathlon. Tres conclusiones. **(A)** La platformización llevada a cabo durante cinco años para absorber el marketplace de Leroy Merlin (**60.000** referencias en tienda, varios millones en línea) y la expansión de Decathlon (**más de 50** países) no estaba orientada a la IA agéntica, pero constituye su base: *"la plataforma construyó los músculos, la era de la inteligencia construye el sistema nervioso."* **(B)** Tres frentes de trabajo nombrados — el **harness** de desarrollo, la **seguridad** por zonas en todo el sistema de información (actividad agéntica cero en el pago, el flujo de checkout y la cadena de suministro), y la **semántica de datos**, abordada por vertical y en la que Adeo reconoce estar en deuda. **(C)** Un precedente que el grupo pagó caro: el BI de autoservicio produjo más de **150.000 dashboards** antes del retorno a productos de datos certificados. La frase marco de Grymonprez sostiene todo el conjunto — *"un agente no tiene sentido común"*: aplica la definición tal cual se le da y acelera el desorden donde este falta. Continúa, con el mismo directivo, [[alafrench-grymonprez-adeo-ia-agentique-grands-groupes-2026-06-18]].
#IA agéntica#platformización#dominios de negocio expuestos vía API
SFEIR AI (voix éditoriale du cabinet) · article non signé individuellement. Restitue un entretien de Matthieu Grymonprez (Adeo) et Romain Taillade (Decathlon).
Post de ingeniería de **Spotify** publicado el **3 de septiembre de 2026** en engineering.atspotify.com (~1.600 palabras, nueve secciones, dos manifiestos YAML, cuatro ejemplos de línea de comandos), escrito por **Dimitri Mazmanov**, Principal Product Manager. Describe una configuración personal diseñada para sacar las tareas de E/S del contexto de **Claude Code**. La premisa planteada de entrada: *« Most of what an AI coding agent does for me isn't thinking. It's I/O »* — leer cinco archivos para responder a una pregunta sobre un único método, producir una prueba modelada sobre las otras veinte del directorio. **(A) Los modos.** **Portal by Spotify** expone *AiKA Modes*, agentes declarativos sobre un runtime efímero — instrucciones, modelo, temperatura, herramientas **MCP** — comparados con *« AWS Lambda, but for agents »*; dos modos públicos, `bulk-reader` y `code-writer`, se ejecutan aquí sobre **Gemini 2.5 Flash**. **(B) El enrutamiento.** Un plugin de Claude Code llamado `shunt` sustituye las reglas de `CLAUDE.md`, consideradas *« advisory, not enforced »*, por tres capas: hooks `PreToolUse` que bloquean cualquier lectura más allá de **350 líneas** (umbral ajustable mediante `SHUNT_MIN_LINES`), dos scripts bash que llaman a la CLI de Portal, dos skills que proporcionan la sintaxis de invocación. El corpus pasa al modelo secundario y **nunca entra en el contexto de Claude**. **(C) Mediciones y sus límites.** En un monorepo Java, cuatro escenarios, el ahorro medio declarado es de **~90%** en `bulk-read`; el autor señala que el escenario `code-write` es *« harder to measure »*, y enumera tres limitaciones — edición no delegable, razonamiento no delegable, **10 a 30 segundos** de latencia por llamada. Prolonga las cuestiones de presupuesto de [[gupta-token-budget-wars-marginal-token-utility-2026-05-28]] y la delegación examinada en [[willison-fable-judgement-delegation-subagents-2026-07-03]].
#Portal by Spotify#AiKA Modes#shunt
Dimitri Mazmanov (Principal Product Manager, Spotify) · sur le blog d'ingénierie engineering.atspotify.com.
Post de **Rachel Laycock**, CTO de **Thoughtworks**, publicado el **2 de septiembre de 2026** en *Rachel's Ramblings*, la sección de martinfowler.com que dirige, de aproximadamente **8.000 caracteres**. El texto es una **respuesta deliberada** a [[houck-dx-what-are-code-reviews-for-2026-08-05]], tras un desacuerdo público entre ambas autoras en un panel de **Code Remix** organizado por **Moderne**. Laycock acepta el diagnóstico cuantificado de Houck (+**106%** de líneas por diff en **Meta**, +**64%** de tamaño mediano de PR en el lado de DX) y la lista de funciones de la revisión que no consisten en detectar defectos, y a continuación desplaza la pregunta: *« ¿por qué esperamos hasta la revisión de código para hacer todo eso? »* (A) El principio rector es el acortamiento de los bucles de retroalimentación aprendido en Thoughtworks — si la retroalimentación tiene valor, no se elimina, se acerca a la decisión que informa. Cada función atribuida a la revisión se reasigna aguas arriba: exploración de alternativas antes de la implementación, transferencia de conocimiento mediante **pair programming**, propiedad colectiva mediante **mob programming** y sesiones de diseño en equipo, alineación arquitectónica mediante diseño compartido seguido de **fitness functions**, y automatización de todo lo determinista — *« De verdad que no deberíamos seguir discutiendo sobre espacios en blanco en 2026. »* (B) La revisión basada en excepciones sustituye a la revisión sistemática: un cambio arquitectónico fundamental, un límite de seguridad sensible, un radio de impacto amplio, un área poco conocida de un sistema crítico, o simplemente la falta de confianza declarada por un equipo. (1) Automatizar la revisión con un agente que imita al revisor humano se descarta por *« automatizar la ceremonia en lugar de cuestionar por qué existe la ceremonia »*. (2) La deuda cognitiva de Houck se reconoce como real, pero la PR obligatoria se considera una defensa débil: *« Necesitamos que los ingenieros entiendan los sistemas, no los diffs. »*
#revisión de código#revisión basada en excepciones#pull request
Rachel Laycock · CTO de Thoughtworks · sur *Rachel's Ramblings* (martinfowler.com).
Ensayo de **Dario Amodei**, CEO de **Anthropic**, publicado en darioamodei.com en **septiembre de 2026** (~2900 palabras, cuatro secciones), en su sitio personal y no en el de la empresa. En él anuncia una posición revisada: *"debemos ralentizar el ritmo al que mejoramos las capacidades de los modelos de IA."* Dos hechos lo llevaron a ello. **(1)** Desde el verano de 2026, la **autosuperación recursiva** — la IA construyendo la siguiente generación de IA — se ha ido imponiendo en toda la industria, Anthropic incluida. **(2)** El **incident Hugging Face**, que él abrevia "OAI-HF" y se niega a tratar como el fallo de un único actor: *"incumbe a toda empresa de IA de frontera actuar como si OAI-HF le hubiera pasado a ella."* Su previsión: en **6-12 meses**, un enjambre comparable pero más capaz podría tomar como rehén a internet con una botnet persistente, por **cientos de miles de millones de dólares** en daños. De ahí un plan de tres pasos de dificultad creciente. **(a)** **Evaluadores externos integrados** (del tipo **METR**) con acceso de nivel empleado — oficinas, credenciales, portátiles, el derecho a publicar sin control editorial de Anthropic; un compromiso asumido unilateralmente, sin equivalente en el resto de la industria. **(b)** **Coordinación entre democracias**: regulación específica, estándares comunes bajo una exención antitrust, y *checkpoints* que vinculan una capacidad X dada a certificaciones de alineamiento Y y Z. **(c)** **Coordinación global** con China, graduada en cuatro niveles desde el más factible (prohibir usos que habiliten el bioterrorismo) hasta el menos probable (una pausa general), con el límite a la velocidad de autosuperación comparado con los tratados **SALT**. Una condición vinculada al conjunto: preservar la ventaja estadounidense (chips, destilación, robo de pesos). Contrapunto en el corpus: [[zuckerberg-meta-future-is-for-everyone-superintelligence-2026-08-10]].
#marcar el ritmo de la frontera#ritmo de la frontera#autosuperación recursiva
Dario Amodei (CEO et cofondateur d'Anthropic) · sur son site personnel darioamodei.com.
Comunicación de producto de **Anthropic** publicada el **1 de septiembre de 2026** en anthropic.com (~4.000 palabras, seis secciones, 22 testimonios de socios con acceso anticipado). Anuncia **Claude Fable 5.1** (disponibilidad general) y **Claude Mythos 5.1** (acceso verificado): *el mismo modelo, pero con distintos niveles de salvaguardas*.
Artículo de **Chase Covington**, **Tomer Slaney** (socios, Nueva York) y **David Pralong** (socio senior, Charlotte), publicado por la *McKinsey Transformation Practice* en **septiembre de 2026** (día exacto no especificado, fechado el 1 por convención); 8 páginas, 2 figuras cuyo contenido no se reproduce en el texto. **(1)** Hallazgo: la transformation office (TO) es lenta en modernizar sus propias herramientas; en un turnaround que involucraba a **3.000** empleados, **más de 15** personas producían un informe de **300 páginas** cada cuatro semanas. **(2)** Tres pilares encomendados a agentes: *performance intelligence*, *single source of truth*, *conversation facilitation*. **(3)** Ganancias reportadas: **35 a 40%** del tiempo en tareas centrales, en ocasiones **70%**; un equipo central reducido de **diez a tres** personas. **(4)** Salvaguardas: errores en cascada entre agentes, falsas alertas, trazabilidad de cada paso. **(5)** Secuencia: reporting primero, automatización de acciones después, gestión del cambio dentro de la TO. Los autores presentan el texto como "a first look at the opportunity for TOs". Los casos no están nombrados, no se describe ningún método de medición, y dos de las herramientas citadas (**Wave**, **Lilli**) pertenecen a McKinsey. El texto da continuidad a [[sternfels-mckinsey-60000-people-20000-agents-officechai-2026-01-14]], donde McKinsey ya cuenta sus agentes entre su plantilla.
Artículo de **Ethan Mollick** publicado el **31 de agosto de 2026** en *One Useful Thing* (~2200 palabras). Parte de un incidente de seguridad para plantear una cuestión organizativa: ¿cuándo debe una IA pedir ayuda a un humano?
#agencia#agencia#agentes autónomos
Ethan Mollick — professeur à la Wharton School (University of Pennsylvania) · auteur du blog *One Useful Thing* sur Substack.
Entrada de **Jeremy Norman** en **HistoryofInformation.com** (cronología "Exploring the History of Information and Media"), fechada "circa **370 a. C.**" para el texto comentado, con el sitio actualizado por última vez el **27 de agosto de 2026** (~600 palabras, incluyendo un extracto extenso). Reproduce el pasaje de *Phèdre* de **Platon** (274c-275b) en el que **Socrate** relata el mito egipcio de **Theuth** y el rey **Thamus** sobre la invención de la escritura.
#Socrate#Platon#Phèdre
Jeremy Norman — historien et éditeur de HistoryofInformation.com ; notice de frise chronologique citant Platon (*Phèdre*, v. 370 av. J.-C.).
Ensayo publicado en **Gates Notes** el **26 de agosto de 2026** por **Bill Gates**, cofundador de **Microsoft** y presidente de la **Gates Foundation**, ~4.500 palabras, anunciado como el primero de una serie. El texto plantea una alternativa —la IA será el mayor igualador jamás inventado, o la peor fuente de injusticia— y una constatación: no existe ningún plan para entrar en este período. **(A) Tres riesgos**: la desaparición duradera de los empleos de nivel inicial e intermedio, tanto de oficina como manuales, en el plazo de una década en lugar de varias generaciones, porque esta vez la sustitución afecta a la **cognición**; la instrumentalización por parte de actores maliciosos (ciberataques, bioterrorismo, fraude, deepfakes), unida a una concentración del poder entre quienes ya lo poseen; el efecto de los compagnons IA en el desarrollo infantil y en el pensamiento crítico. **(B) Los beneficios**, ubicados en cinco ámbitos —investigación, salud, agricultura en países de renta baja (el impacto que el autor califica de más rápido), servicios públicos, educación— con una reserva que recae sobre el verbo: *"la palabra clave es 'puede'"*. **(C) Tres propuestas** abren la serie: construir un marco institucional nacional e internacional sin precedentes, inspirado en el régimen de inspección nuclear, la regulación de la aviación y los acuerdos sobre el ozono; reservar ciertas ocupaciones para los humanos, un ámbito denominado **Human Reserved**; **gravar los tokens de IA y los robots** para reequilibrar la fiscalidad entre trabajo y capital. Gates revela sus vínculos financieros con la industria y la transferencia de sus beneficios a la fundación. El texto prolonga los ensayos de directivos sobre el reparto del valor de la IA —[[nadella-frontier-ecosystem-human-token-capital-2026-06-12]], [[zuckerberg-meta-future-is-for-everyone-superintelligence-2026-08-10]]— centrándose en el poder público en lugar de en la empresa.
#IA y equidad#transición a la era de la IA#sustitución de la cognición
Bill Gates — cofondateur de Microsoft · président du conseil de la Gates Foundation. Blog personnel Gates Notes. Page non capturable par `curl | lynx` (403 Akamai) : extraction navigateur.
Artículo de invitado de **Andy Warfield**, ingeniero del equipo de **S3** en **AWS**, publicado el **26 de agosto de 2026** en *All Things Distributed*, el blog de **Werner Vogels**, quien lo presenta en unas líneas firmadas «--W»: **3554 palabras** según la página. El texto sirve de vehículo para el anuncio de que **DuckLabs**, el equipo detrás de **DuckDB**, se incorpora a **AWS**. (A) La tesis: la informática de sistemas consiste en buscar el compromiso elegante frente a una «física» cambiante —las proporciones entre velocidad de memoria, red y cómputo— y esa física ha cambiado. Warfield cuantifica la brecha: una **m1.xlarge** de 2007 ofrecía **15 GB de RAM**, **4 núcleos virtuales** y **~1 Gb/s** de red; una **m8g.48xlarge** actual ofrece aproximadamente **50×** más en cada uno de los tres aspectos. El crecimiento de los conjuntos de datos, por su parte, sigue una distribución cuya cola está formada por volúmenes muy grandes. (B) La consecuencia: el procesamiento distribuido —**MapReduce**, los **RDD** de **Spark**— se diseñó bajo las restricciones de E/S de principios de la década de 2000, y buena parte del trabajo que se le asignaba ya no necesita salir de la aplicación. De ahí el motor embebido, de tipo biblioteca en proceso, que se ejecuta en el espacio de direcciones de la aplicación, del que **DuckDB** es el ejemplo. Warfield ancla esto en el artículo *Scalability! But at what COST?* (2015) y en el epígrafe de **Paul Barham**: «Puedes tener una segunda computadora una vez que hayas demostrado que sabes usar la primera.» Formula una salvedad explícita: «Cuando un trabajo realmente necesita mil máquinas, necesita mil máquinas.» El corpus ya contiene [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] del mismo blog y [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] sobre analítica de autoservicio.
#DuckDB#DuckLabs#adquisición de AWS
Andy Warfield · ingénieur du service S3 chez AWS · en billet invité sur *All Things Distributed* ; introduction de Werner Vogels · CTO d'Amazon.
*Deepdive* de **Gergely Orosz**, **Jessica Salmon** e **Ivan Klaric** en *The Pragmatic Engineer*, publicado el **25 de agosto de 2026**, basado en entrevistas con el CTO de Ramp **Rahul Sengottuvelu**, el responsable de ingeniería **Hamid Dadkhah**, y **Zach Bruggeman**, ingeniero fundador de **Inspect**. Artículo de pago: la nota cubre la parte pública (secciones 1 a 3 y el inicio de la sección 4; la arquitectura detallada, los aspectos internos del sandbox y la colaboración permanecen tras el muro de pago).
#agente de codificación en segundo plano#agente de codificación en segundo plano#agente de codificación interno
Gergely Orosz · Jessica Salmon · Ivan Klaric — *The Pragmatic Engineer* (newsletter Substack de Gergely Orosz).
Ensayo de **Bill Staples**, CEO de **GitLab**, publicado el **24 de agosto de 2026** en el blog about.gitlab.com: una lectura anunciada de **31 minutos**, unos **39.000 caracteres**, presentado como la continuación de un memorando escrito al consejo de administración en enero de 2026 y publicado parcialmente en mayo bajo el título *GitLab Act 2*. El texto se presenta como una respuesta al playbook de SDLC nativo en IA de **Anthropic**, publicado tres días antes, del que toma prestada la frase de apertura —"Code is no longer the bottleneck"— para plantear la pregunta que lo articula: qué se vuelve escaso cuando el código se vuelve abundante. (A) El diagnóstico económico: la unidad útil no es el costo por línea sino el **costo por cambio aceptado**, que agrega generación, entorno, contexto, verificación, revisión, remediación y gobernanza; la IA colapsa únicamente el término de generación, lo que hace que los demás pesen proporcionalmente más — una organización diez veces más rápida generando "simplemente desplazará la cola". (B) La respuesta arquitectónica: cuatro capacidades —plataforma de agentes, ejecución a escala de máquina, contexto duradero, gobernanza— que forman una capa empresarial que sobrevive al modelo, "The model should be replaceable. The agent should belong to the customer." (1) Tres modos coexisten de forma duradera, desde el legado dirigido por humanos hasta el desarrollo autónomo, en contra de la idea de una curva de madurez única. (2) El pipeline de CI/CD se convierte en el lugar donde se ejecuta el bucle interno, en lugar de ser una puerta de control al final de la cadena. Las cifras citadas son las de Stripe, Spotify y Amplitude; GitLab produce una sola, sobre su propio control de fuente. El corpus ya contiene [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la fuente a la que este texto responde, y [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sobre la articulación SDLC/PDLC que Staples adopta como propia.
#abundancia de código#costo por cambio aceptado#teoría de las restricciones
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Guía extensa de **Anthropic** firmada por **Louis Claxton** (equipo Applied AI), publicada el **21 de agosto de 2026** en el blog de claude.com: una lectura estimada en **40 minutos**, de unos **64.000 caracteres**, presentada como una colección de *plays* extraídos del trabajo del equipo con sus clientes. (A) El diagnóstico: al dejar de ser el código el cuello de botella, este se desplaza hacia las etapas situadas a ambos lados de la construcción (planificación, revisión/pruebas, despliegue), los controles línea por línea dejan de sostenerse en cuanto el agente escribe la mayor parte del diff, y el coste de la gobernanza aumenta porque las excepciones siguen pasando por comités periódicos. (B) La respuesta: seis etapas (Plan, Design, Build, Test, Deploy, Maintain) organizadas como un **loop** en lugar de una cadena, cada una terminando en un **artefacto versionado** que la siguiente etapa lee — `intent.md`, `spec.md`, `plan.md`, el diff y sus pruebas, la PR y sus hallazgos, el registro del incidente. (1) El conocimiento institucional se convierte en archivos versionados: `CLAUDE.md`, skills, `REVIEW.md`, `bands.yaml`. (2) La gobernanza se divide en dos capas, con la skill situada como control consultivo y el hook como capa determinista detrás de ella. La separación de funciones se fija como invariante — el agente que escribe el código no puede aprobarlo — y la pieza se cierra con *"El loop sigue corriendo. El juicio humano permanece por encima de él."* El corpus ya cuenta con [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sobre la vertiente de seguridad del mismo ciclo, y con [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sobre el mismo desglose en seis etapas visto por un competidor.
#SDLC nativo de IA#ciclo de vida de desarrollo de software#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Guía firmada por **Michael Segner**, publicada el **20 de agosto de 2026** en el blog claude.com, categoría *Claude Code*: una lectura de **5 minutos** anunciada para aproximadamente **31.500 caracteres** de cuerpo del texto, ofrecida también en PDF. Material declarado: entrevistas con **más de una docena** de startups, quince nombradas — **Artemis Security**, **Cainex**, **Clay**, **ClickHouse**, **Cognition**, **Commure**, **Crosby**, **Emergent**, **Harvey**, **Heidi**, **Higgsfield**, **Omni**, **Parahelp**, **Translucent**, **Zingage**. (A) Cinco reglas operativas: *everyone ships*, *automate the tedium*, *trust, but verify*, *build for rebuilding*, *prototype, dogfood, productionize*, cada una cerrada con consejos de producto y reunidas en una checklist final. (B) Un cuerpo compuesto de citas atribuidas, cada regla ilustrada por directivos nombrados en lugar de una métrica agregada. Las cuatro cifras destacadas son las de las empresas entrevistadas: **+30%** más funcionalidades entregadas (ClickHouse), **de 2 a 3×** productividad de ingeniería (Omni), **100%** del triaje de bugs automatizado (Clay), **más de 6.000 PR por semana** (Artemis Security). Dos pasajes se apartan del registro testimonial: el bucle de autocorrección de **Cainex** sobre la codificación médica, descrito paso a paso, y el uso interno de **Claude Tag** en **Anthropic** como primer respondiente para las guardias de CI/CD. La pregunta planteada al inicio — *"what would it look like if an organization built their product development lifecycle with Claude Code from the ground up?"* — conecta con [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], publicado al día siguiente por el mismo editor, y prolonga [[cherny-wu-reflecting-year-claude-code-2026-07-17]].
#Claude Code#startups#everyone ships
Michael Segner · auteur du guide sur le blog claude.com (fonction non affichée par la page) ; entretiens avec les dirigeants de quinze entreprises nommées.
Entrada de blog corporativo de **Block** (`block.xyz/inside`), sin firma —el autor mostrado es **«Block»**—, publicada el **18 de agosto de 2026**, ~930 palabras, que anuncia **la apertura del código de Berd**, la aplicación de escritorio interna de Block para trabajar con agentes, y expone la tesis de diseño que la guió: dar carácter a los agentes *«no solo mediante roles, instrucciones, skills y herramientas, sino mediante identidades visuales distintivas»* —de ahí los personajes animados desarrollados internamente, los *«Gloopies»*—. La entrada parte de una constatación de fragmentación (*«The technology was powerful, but the experience around it was fragmented»*) y de un problema de interfaz precisamente nombrado: *«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»*. Dos aportaciones estructurantes. **(A) Una articulación en tres niveles**: **goose** sigue siendo el framework y el *runtime* que sostiene el bucle del agente; **Berd** es el cliente de escritorio (proyectos, contexto, sesiones, agentes, configuración); ambos se comunican mediante el **Agent Client Protocol**. **Buzz** se designa como la continuación, para cuando el trabajo en solitario se vuelve colaborativo (*«Start alone, then go multiplayer»*). **(B) Seis requisitos transmitidos a Buzz**, enunciados como conclusión: *«private space, durable context, recognizable agent identities, reusable skills, visible configuration, and clearer visibility into an agent's configured context, tools, and capabilities»* —una parrilla directamente reutilizable para evaluar un cliente de agentes—. El propio texto distingue identidad de capacidad: *«The avatars make the agent recognizable. Its role, skills, and tools make it useful.»* No se aportan cifras de uso ni se nombra ninguna licencia para la apertura del código.
#Berd#Block#código abierto
**Aucun auteur nommé** : le billet est signé **« Block »** — le champ *Author* de la page porte le nom de l'entreprise. Publié le **18 août 2026** sur `block.xyz/inside` · le blog **corporate** · et non sur `engineering.block.xyz`.
Entrada de blog de **Sonatype** por **Aaron Linskens** (*technical writer*), publicada el **18 de agosto de 2026**, ~1.300 palabras: relata un estudio de **Sonatype Research Labs** que abarca **49 meses** (junio de 2022 — junio de 2026) y una **cohorte fija** de aplicaciones empresariales, una elección metodológica presentada como una forma de aislar la evolución de la flota de aplicaciones más que la de la cartera de clientes. El resultado se presenta como una contradicción: la remediación es más rápida, pero el riesgo se acumula aún más. (A) **El stock aumenta** — vulnerabilidades *Critical* y *High* por aplicación **×4,31** (de **14,14** en junio de 2022 a **54,3** en 2026, aún **×3,91** excluyendo las aplicaciones legadas recién incorporadas a la gestión), versiones de componentes recién afectadas al **46×** de la tasa previa a la IA, creación mensual de aplicaciones **×4,84**. (B) **La remediación mejora** — más de la mitad de las violaciones resueltas se resuelven en menos de un día, la edad mediana de las vulnerabilidades *Critical/High* sin resolver baja de **228** a **126 días**, luego a **103** en mayo de 2026; entre las cohortes que dispusieron de doce meses, **52,6%** están resueltas, **44,3%** abiertas, **3,1%** bajo dispensa. (C) **La palanca propuesta es la selección de componentes**: en el momento en que se eligió una dependencia vulnerable, ya existía una versión sustancialmente menos arriesgada en **62,2%** de los casos en **Maven**, **46,9%** en **npm**, **34,3%** en **PyPI** — una brecha que el texto atribuye a un problema de información más que a una falta del desarrollador. La propia entrada afirma que la IA no es la única causa de la aceleración, y concluye con **Sonatype Guide**, que lleva esta inteligencia hasta el momento de la selección. En el plano de la cadena de suministro, prolonga lo que [[fiches/2026-08/staples-gitlab-when-code-is-abundant-2026-08-24]] plantea en términos económicos y [[fiches/2026-07/clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] en términos de ciclo seguro.
#cadena de suministro de software#cadena de suministro de software#Sonatype Research Labs
Aaron Linskens · *technical writer* chez Sonatype · sur le blog de l'éditeur ; les chiffres sont produits par Sonatype Research Labs · non par l'auteur.
Publicación de anuncio de producto de **Block Engineering** firmada por **Thomas Petersen** (*Principal Designer & Builder*), publicada el **18 de agosto de 2026**, ~1.800 palabras en trece secciones breves, que presenta **Buzz Projects** — una **forja de software alojada en su propio relay**: repositorios Git, ramas, pull requests, issues, revisión y merge, proyectos multi-repositorio, un feed de actividad, todo vinculado a canales de conversación. El planteamiento y la tesis de la publicación: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Tres aportaciones. **(A) Una doctrina de confianza fundada en la prueba *a posteriori* más que en la autorización *a priori***: por un lado *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, por otro *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; la sección se cierra con una dirección enunciada — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Interoperabilidad Git sin herramientas propietarias**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, con la clé Nostr sirviendo como identidad única — *« The same npub that signs your messages signs your pushes. »* **(C) Una distinción entre superficie de ejecución y presencia en la red**: *« 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. »* La publicación no aporta ninguna cifra y no contiene enlaces salientes; se califica a sí misma de preliminar seis veces (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), y Projects se encuentra bajo la pestaña **Experiments** de Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
Publicación en X de **Andrew Ng** del **14 de agosto de 2026** (16:29 UTC), que retoma la carta «Dear friends» de ***The Batch* #366** (DeepLearning.AI, misma fecha), ~900 palabras. Ng presenta **The AI Engineering Skills Map** y publica **cuatro habilidades** consideradas las más importantes. **(1) Construir y desplegar aplicaciones de IA** — se nombra la especificidad: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, de ahí el énfasis en los *evals* y los bucles de análisis de errores. **(2) Fundamentos de ingeniería de software**, porque *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — el desarrollador inexperto fracasa *« because they don't know what context to give their coding agent »*, de ahí el objetivo de *« steering coding agents using the precise language of software engineering »*. **(3) Uso de agentes de codificación**, en una formulación operativa: *« help the agent autonomously close loops by providing verifiers or evals »*, y *« knowing how much to intervene and how much to leave them alone »*. **(4) *Shaping the build***: *« Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec »*, junto con *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Una **nota terminológica** aporta la mayor parte del enfoque: Ng habla de **habilidades** en ingeniería de IA y **no del rol** "AI Engineer", con una analogía explícita — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* El conjunto se apoya en *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, de la cual **no se publica ningún resultado numérico**: Ng describe su proceso como *« informally… akin to running clustering »* y anuncia un mapa detallado en futuras publicaciones. Declara el interés en la penúltima frase: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
#AI Engineering Skills Map#mapa de habilidades#Andrew Ng
**Andrew Ng** — fondateur de **DeepLearning.AI** · general partner d'**AI Fund** · cofondateur de **Coursera** et de **Google Brain** · ancien chief scientist de Baidu. Texte signé · à la première personne · écrit *« with my team »* sans qu'aucun collaborateur soit nommé. Publié le **14 août 2026** sur X et dans ***The Batch* n°366** — même texte aux deux endroits ; préférer *The Batch* pour toute citation durable. Quatrième fiche Ng du corpus · après les lettres n°350 (24 avril) · n°352 (8 mai) et n°359 (26 juin).
Publicación de anuncio publicada en el **blog oficial de Z.ai** (antes Zhipu AI, laboratorio chino) el **14 de agosto de 2026**, **sin firma individual**, ~2.000 palabras más notas al pie. Anuncia **GLM-5.3**, sucesor de GLM-5.2, y se abre con una tesis metodológica: *« Scaling post-training is all we did for GLM-5.3. »* Mismo modelo base que GLM-5.2 — *« every gain comes from post-training »*. Tres anuncios. **(A) Un modelo de codificación de pesos abiertos**: +50% reivindicado en **Z.ai Code Bench**, un benchmark interno no publicado. **(B) Una capacidad cibernética presentada como "emergente"**, que el cuerpo del texto atribuye a una decisión de entrenamiento — *« As part of post-training, we introduced vulnerability discovery data and environments into the training mix. We expected this to make the model better at finding and reasoning about vulnerabilities »* — lo que resultó sorprendente fue la velocidad y el cambio de naturaleza: el modelo pasa de identificar fallos aislados a *« coherent plans for complete exploitation chains »*. Las ganancias crecen con la posición en la cadena de explotación: CyberGym 77,2 → **84,5%**, ExploitBench 24,4 → **54,4%** (×2,2), ExploitGym 29 → **105** tareas en 2h (×3,6), con una brecha frente a la frontera cerrada que sigue siendo amplia (181 y 247 tareas). Z.ai lo formula así: *« Capability is growing fastest exactly where we are furthest behind. »* La publicación también difunde un **Z.ai Security Disclosure Ledger**: **2.436 vulnerabilidades identificadas en 269 proyectos de código abierto** — núcleos, sistemas operativos, motores de navegador, infraestructura, aplicaciones web, protocolos de red — la más antigua introducida en **1981**, vida media antes del descubrimiento de **26,6 años**, de las cuales **53 divulgadas** y **2.383 bajo embargo**. **(C) Una publicación de los pesos** *« within two weeks of launch, once safety evaluation and hardening are complete »*. El aporte metodológico más reutilizable: la **síntesis de entornos y verificadores**, esta última producida sin acceso a la solución de referencia y admitida solo tras un tríptico de controles negativos — **oracle**, **no-op**, **unsolved-state**. Todas las evaluaciones agénticas se realizan **en Claude Code 2.1.207**.
#GLM-5.3#GLM-5.2#Z.ai
**Z.ai** (anciennement **Zhipu AI**) · laboratoire d'IA chinois · éditeur de la famille **GLM**. Billet **institutionnel et non signé** : aucun auteur nommé · aucun chercheur mis en avant · aucun lien vers un rapport technique ou une carte de modèle. Publié le **14 août 2026**. La page est une SPA React — le HTML servi est un `<div id="root">` vide · et le texte comme les scores ont dû être extraits du bundle `glm-5.3-BCnx8T5_.js` · où ils figurent en valeurs source.
Página de producto oficial de **DeepSeek**, publicada el **13 de agosto de 2026**, **sin firma**, ~450 palabras, que anuncia 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. Una tesis de tres palabras, repetida en el título y en la descripción del repositorio: *« Everything is a plugin »*, junto a una segunda promesa, *« Every run is traceable »*. La página enuncia la ecuación *« AGENT = MODEL + HARNESS »* y enumera las capacidades intercambiables — *« models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI »*. Se lanzan cuatro modos: **Standard** (agente de codificación completo), **Code** (herramientas expuestas mediante el *Code Mode SDK*, que permite al modelo componer operaciones de varios pasos dentro de un programa TypeScript), **Minimal** (*« two-tool coding agent with persistent bash and str_replace_editor »*, explícitamente *« for benchmarking models in a minimal environment »*), y **Creator** (inspección en tiempo de ejecución, pruebas de plugins en memoria). La sustancia técnica reside en el repositorio, no en la página: `docs/architecture.md` enuncia un invariante de registro — *« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it »* — y declara que *« there is no privileged core to patch »*. El núcleo técnico no pertenece a DeepSeek: DSH está construido sobre **Cordis** (el proyecto `cordiverse`, un tercero), **vendorizado** en `vendor/` con un manifiesto y un procedimiento de sincronización, y la página sitúa el *« Cordis paper »* al mismo nivel de navegación que "GitHub" y "Developer docs". Se lanzan dos adaptadores LLM — `dsh-llm-deepseek` y `dsh-llm-pi-ai`, un adaptador multiproveedor genérico. El repositorio advierte en mayúsculas: *« THERE WILL BE COMPATIBILITY-BREAKING CHANGES »*, y `CLAUDE.md` especifica que `SESSION_FORMAT_VERSION` permanece en `0` *« with no compatibility promise »*, con backends que rechazan los formatos antiguos en disco. Cronología: DSH se lanza el mismo día en que **DeepSeek-V4-Pro alcanza la GA**, tres días antes de que entre en vigor un nuevo calendario de precios de la API el **16 de agosto de 2026 a las 16:00 UTC**, con tarifas de hora punta/valle y un descuento de hora valle del **−50 %**.
#DeepSeek Harness#dsh#harness de agente
**DeepSeek** (DeepSeek AI, laboratoire chinois) · en tant qu'institution. Page produit **non signée** : aucun auteur · aucun ingénieur mis en avant · aucun billet de blog ni papier technique associé. Le « nous » n'apparaît qu'une fois · en dernière phrase — *« We look forward to exploring the limits of intelligence with developers worldwide »*. Publiée le **13 août 2026**. La page est rendue en JavaScript : `curl` sur l'URL renvoie **HTTP 202 avec un corps vide** · le texte n'existant qu'après exécution du bundle. Deux documents de politique sont liés en pied de page — *Safe Use Policy* et *Data Processing Statement*.