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*.
Informe de investigación interno fechado el **12 de agosto de 2026** que consolida, con fines de presentación, todo lo documentado públicamente sobre **Buzz** — el espacio de trabajo de humanos + agentes de **Block**, lanzado el **21 de julio de 2026** bajo la licencia **Apache 2.0**. Reúne las dos publicaciones técnicas ya presentadas junto al anuncio corporativo, el repositorio de GitHub, la cobertura de prensa, X, y **tres experiencias prácticas independientes** que constituyen los únicos datos del dosier que no son autodeclarados. **(A) Una brecha de vocabulario documentada mediante cita**: el tuit de lanzamiento de **Jack Dorsey** anuncia *"agnóstico de modelo, descentralizado, autosoberano y de código abierto"*; el `ARCHITECTURE.md` de Block afirma *"El relay es la única fuente de verdad. Todas las lecturas y escrituras pasan por él. No hay intercambio de eventos entre pares, ni gossip, ni replicación."* El relay es, por tanto, único y autoritativo por comunidad: la "descentralización" de Buzz es una **soberanía organizativa** —autoalojamiento e identidad portátil— y no redundancia de red. La formulación de **TFTC**: *"Dos de esos tres se sostienen sin problema. El tercero necesita un matiz."* **(B) Una asimetría entre el rigor demostrado y el riesgo de explotación.** Por un lado, un grado de formalismo poco frecuente para una v0.4.x/0.5.x: especificación de aislamiento multiinquilino **mecanizada en TLA+**, propiedades de autorización verificadas en **Tamarin**, un protocolo de almacenamiento Git verificado por model checking, un registro de auditoría append-only encadenado por hash, 127 *tipos de evento*, NIP-01/42/98/34. Por otro, la pertenencia a un canal es la unidad de permiso —*"la pertenencia a un canal no es una autorización de herramientas de grano fino"* (João Queirós)—, los agentes se ejecutan con `--dangerously-skip-permissions` fuera de cualquier sandbox en la máquina de un humano, y la observabilidad es deficiente: *"Buzz me dice que un agente recibió un mensaje. No me dice qué pasa después"* (DevTools Daily, que reporta cierres silenciosos por OOM). Block lo reconoce: *"el agente puede hacer cualquier cosa, y la seguridad descansa por completo en restringir quién puede decirle qué hacer"*. **(C) La pila técnica**, ausente de las publicaciones presentadas: relay en **Rust** (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** vía Blossom, cliente de escritorio **Tauri + React**. La integración de agentes pasa por **`buzz-acp`**, un harness **ACP** que conecta goose, Codex y Claude Code y traduce **ACP ↔ MCP**, además de **`buzz-agent`**, un agente propio. El informe se corrige a sí mismo en un punto: el *"+33% más de trabajo"* del TL;DR de Block es la **proporción de tareas completadas (20 frente a 15 de 44)**, no una ganancia de puntuación — la puntuación en sí sube de 59,1% a 71,5%, es decir **+12,4 puntos**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
Informe de experiencia publicado en **LinkedIn Pulse** el **12 de agosto de 2026** por **Guillaume Dumortier**, en su newsletter *Growth Marketing Fit*, subtitulado *« Cuatro capas, mucha reconstrucción y los modos de fallo de los que nadie te advierte »*, ~2.500 palabras. El tema: un sistema de IA interno construido **en Claude** para un equipo de marketing de unas sesenta personas — alrededor de treinta **skills** de contenido y ventas, una decena de **módulos de fuente de verdad**, **siete agentes, seis de los cuales existen únicamente para verificar el trabajo en lugar de producirlo**, un **plugin** para quienes viven en una terminal, una **aplicación de navegador** que porta el mismo conocimiento para el resto, y una orquestación que encadena tres o cuatro activos en un *campaign bundle*. La tesis se plantea desde el principio: la calidad de una salida de IA no se determina en el momento de la generación, sino por lo que el sistema sabe antes de empezar y por lo que ocurre con el borrador después — *« El paso de generación en el medio es la parte fácil. También es la única parte que la mayoría de los equipos han construido. »* De ahí cuatro capas: **Verdad** (casi nadie la construye), **Producción** (todo el mundo), **Verificación** (casi nadie), **Distribución interna** (*« donde los buenos sistemas mueren por negligencia »*). Dos mecanismos de fallo sostienen el artículo. **(A) El « pass » desnudo de mundo cerrado del verificador**: un fact-checker respaldado por documentación de producto recibe un borrador que contiene una afirmación sobre otro producto, uno que sus fuentes no cubrían — devuelve un *« pass »*, no porque la afirmación fuera cierta sino porque nada la contradecía. *« No solo pasó por alto el error, lo certificó. »* Solución: prohibir un veredicto desnudo y exigir que cada informe declare su **propia cobertura** — cuántas afirmaciones se verificaron, cuántas se relacionaron con fuentes, cuáles quedaron fuera de su jurisdicción, cuáles no pertenecían a ninguna fuente. *« "No puedo verificar esto" se convirtió en un resultado de primera clase. »* **(B) La contradicción entre activos**: dos activos pueden ser individualmente correctos, cada uno trazable a una fuente real, y aun así contradecirse entre sí — el comunicado de prensa indica una fecha, la entrada de blog otra, ambos pasan, el bundle no puede publicarse. *« La verificación por activo individual no puede detectar eso, por construcción. »* Cláusula de cierre del artículo: *« La generación es gratis. La confianza es el producto. »*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
Anuncio de **Google** el **6 de agosto de 2026**: Google 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**. La especificación fue publicada por un **TSC** cuyos Core Maintainers provienen de **Amazon, Cursor, Microsoft, OpenAI y Vercel**; Google se suma a ellos, representado por **Kevin Hou** (Senior Staff Engineer, Google DeepMind). Los dos bloques empaquetados —Agent Skills y MCP— provienen de **Anthropic**, que no figura en esta lista de mantenedores. **El diagnóstico** cabe en una frase: *"The core problem isn't the components. It's the manifest."* Una skill es portable, un servidor MCP es portable; la caja en la que van no lo es, y cada cliente tuvo que inventarla por su cuenta —de ahí los forks, las copias de componentes idénticos y su divergencia. **El formato** cabe en una restricción: *"A plugin is a directory. That's the whole idea, and the restraint is the point."* Un `plugin.json` con dos líneas útiles (`$schema` y `name`), skills en `skills/` en el formato Agent Skills, servidores declarados en `mcp.json` con un **`type` explícito en cada entrada** (stdio, Streamable HTTP, o el HTTP+SSE heredado) —ya no se infiere el transporte a partir de la forma del objeto de configuración. La fuerza del diseño reside en lo que el manifiesto **no puede** hacer: ni reubicar componentes ni declararlos en línea, de modo que no hay ninguna ruta de descubrimiento que configurar ni ningún orden de precedencia que aprender. Corolario operativo: los componentes **fallan de forma independiente** —un servidor de `mcp.json` que no arranca no derriba las skills del plugin, el cliente salta esa entrada, continúa y reporta el fallo. La vía de escape aceptada es el directorio de **dominio inverso** (`com.example.client/`), un espacio de extensión propiedad exclusiva de un cliente (hooks, agents, commands) que otros clientes ignoran: *"the portable core stays small because the non-portable parts have somewhere legitimate to go."* Una sección se dedica a los casos en que el formato no está justificado —*"Not every skill should be a Plugin"*: un único servidor MCP para un único cliente, basta con `mcp.json`; una única skill no necesita ningún plugin. Lo que la v1 excluye explícitamente, bajo *future considerations*: **sin mecanismo de instalación, sin protocolo de distribución, sin modelo de permisos, sin requisito de sandboxing, sin verificación de confianza o procedencia, sin UX**. Todo esto encaja en una pila de cuatro capas adoptables de forma independiente —**find** (Agentic Resource Discovery), **describe** (AI Catalog, que registraría el tipo `application/agent-plugins+json`), **package** (Agent Plugins), **run** (MCP + Agent Skills). Dos productos de Google ya se distribuyen así: **Agents CLI** y **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
El sitio **graphify.net**, consultado el **6 de agosto de 2026**, mantenido por **Safi Shamsi** — el creador de la skill open source graphify (cf. [[skill-shamsi-graphify-2026-08-06]]). El dominio agrupa dos objetos distintos. **El primero es un escaparate de producto**: presentación de graphify, guías de uso, referencia CLI y, sobre todo, una galería de **100 repositorios de GitHub trending ya «graphificados»** — *« 100 repos, 854,079 nodes, 1,932,930 edges »* — filtrables por lenguaje y tamaño de grafo, cada uno con su propia página de vista previa y de detalle. **El segundo, y es el más interesante desde el punto de vista de la vigilancia tecnológica, es un directorio editorial**: *« 30 AI coding client guides »*, un directorio de servidores MCP comparados según *« transport, runtime, client support, setup effort, and access risks »*, comparaciones estructuradas entre herramientas (Cursor frente a Codex), y un flujo de artículos con una segmentación manifiestamente long-tail (*« GLM-5.2 Knowledge Graph for Developers »*, *« Trae Context Engineering for Agents »*, *« Symphony Knowledge Graph for Agent Memory »*, *« What Is Cowart? A Codex Plugin for Image Editing »*). El sitio reivindica un método — *« source-reviewed »*, *« aligned decision fields, official evidence, and explicit unknowns »* — y está disponible en seis idiomas. **El punto que esta ficha existe para registrar**: el sitio está **fácticamente desfasado respecto al producto que presenta**. Anuncia **« 3.7k+ GitHub Stars »** cuando la API de GitHub cuenta **103,187** ese mismo día, una **licencia MIT** repetida tres veces 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. **Un sitio oficial que muestra el 3.7% del recuento real de estrellas y se equivoca de licencia** es una señal en sí misma: la capa de comunicación no ha seguido el ritmo del repositorio.
#graphify.net#directorio de herramientas de IA#directorio
Una entrada de referencia de **Block Engineering** del **6 de agosto de 2026**, firmada por **Atish Patel**, sobre **Buzz** —el espacio de trabajo humano + agentes lanzado el 21 de julio— que plantea una pregunta de costo: ¿qué equipo de agentes es **el más barato que tiene éxito de forma fiable**? Tres hallazgos. **(A) Un resultado negativo, publicado íntegramente**: en **Terminal-Bench 2.1**, **doce composiciones de equipo** (parejas, tríos, enjambres baratos bajo un modelo *frontier*) se enfrentaron al agente solo en torno al cual cada una fue construida, y **ninguna lo superó a igualdad de costo**. La explicación es estructural — una tarea que termina en minutos *"no tiene suficiente estructura para dividirse"*, y *"más agentes compra sobre todo el costo de explicarlo dos veces"*. **(B) El horizonte invierte el resultado**: en **Long-Horizon Terminal-Bench** (44 tareas, una tarea que vale horas de trabajo, mismo líder **GPT-5.6 Sol** con esfuerzo *high*), el agente solo termina 15 tareas para un 59,1%, +2 QuickBees 19 para un 64,1%, +1 QuickBee +1 WorkerBee 19 para un 69,5%, **+2 WorkerBees 20 para un 71,5%** — una ganancia de **+12,4 puntos**, de los cuales 11,4 provienen de tareas llevadas hasta su finalización. *"Mismos puestos, resultado opuesto, porque el trabajo tiene una forma distinta."* Estas ejecuciones corrieron con **3× el timeout**, incluido el agente solo. **(C) Más allá de un umbral, el precio deja de comprar calidad**: en solitario en Terminal-Bench 2.1, **Opus 5 con esfuerzo *xhigh* es la ejecución más cara (140,63 $) para un 75,0%**, por detrás de seis ejecuciones que van de 20,08 $ a 109,82 $ y de 79,5% a 88,4% — la causa señalada es un sobrerrazonamiento que llevó a 17 de 88 tareas al timeout. Entre las seis mejores ejecuciones, **una brecha de precio de 5,5× para una brecha de puntuación de 8,9 puntos**: *"elegir entre ellas no es en absoluto una decisión de calidad. Es una decisión de presupuesto."* La entrada propone una taxonomía que reconoce como *ad hoc* — **QuickBee**, **WorkerBee**, **SmartBee**, además del humano como *"abeja honoraria"*— y dos formas de equipo, el **Hive** permanente que recuerda las preferencias del usuario y el **Swarm** desechable que recuerda el proyecto. Condiciones: todo se ejecuta en **Harbor**, contra agentes Buzz reales en un relé **en vivo**, **un intento por tarea, sin reintento**, precios fijados a fecha de **30-07-2026**.
#Buzz#Block#equipos de agentes
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Entrada de skill: **graphify**, de **Safi Shamsi** (Graphify Labs, Y Combinator S26), convierte un proyecto completo — código, documentación, PDF, imágenes, vídeos — en un **grafo de conocimiento consultable**, invocado mediante `/graphify` desde Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot y una quincena de otros clientes. Observado el **6 de agosto de 2026**: **103.187 estrellas**, **10.024 forks**, repositorio creado el **3 de abril de 2026**. Apache-2.0, Python 3.10+, rama por defecto **v8**. **Tres decisiones de diseño**, expuestas en el README. *"Code maps for free, fully local"*: el código se analiza en un **AST tree-sitter**, de forma determinista y sin LLM, sin que nada salga de la máquina. *"Every edge is explained"*: cada arista se etiqueta como **`EXTRACTED`** (explícita en la fuente) o **`INFERRED`** (resuelta por graphify), con un tercer valor `AMBIGUOUS` que aparece en el informe. *"Not a vector index"*: *"no embeddings, no vector store: a real graph you traverse"*. **Tres salidas**: `graph.html` (grafo interactivo), `GRAPH_REPORT.md` (nodos god, conexiones sorprendentes, preguntas sugeridas) y `graph.json` (grafo persistente, consultable semanas después sin releer los archivos). **Tres modos de consulta** que sustituyen a grep: `query` (subgrafo para una pregunta en lenguaje natural), `path A B` (camino más corto entre dos entidades) y `explain` (vecindario de un concepto). **Cobertura**: 36 gramáticas tree-sitter (~40 lenguajes), además de Terraform, Apex, configuraciones MCP, manifiestos de paquetes, Office, Google Workspace, PDF, imágenes y vídeo/audio transcritos localmente mediante faster-whisper. Comunidades detectadas vía **Leiden**, etiquetadas sin LLM. **Benchmarks**: en LOCOMO, recall@10 de **0,497** frente a 0,149 de supermemory y 0,048 de mem0, pero con menor precisión de QA (45,3% frente a 49,7%); en LongMemEval-S, **76%**, a la par de un RAG denso; y *"Graph build — LLM credits: 0"*. **Puntos a registrar**: la rama `main` mantiene un README de la era v1 que describe un producto distinto (skill exclusiva de Claude Code, la afirmación de "71,5× menos tokens"); el paquete PyPI se llama **`graphifyy`**, con dos *y*, mientras se recupera el nombre `graphify`; y se escribe por defecto un **registro de consultas** en `~/.cache/graphify-queries.log`, que puede desactivarse mediante una variable de entorno.
#skill#grafo de conocimiento#grafo de conocimiento
**Safi Shamsi** — créateur et mainteneur de graphify · et de **Graphify Labs** · société passée par **Y Combinator (promotion S26)** selon le badge du dépôt. Il maintient aussi le site d'annuaire `graphify.net` (cf. [[graphify-net-annuaire-ia-coding-2026-08-06]]) et publie un livre · *The Memory Layer* · sur les idées et l'architecture derrière le projet.
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**.
#Meta AI Research#Muse Code#Muse Spark 1.2
**Meta AI Research** — publication institutionnelle sans auteur nommé · sur `research.meta.ai`. Le billet renvoie à un **rapport** pour la méthodologie d'évaluation · non repris ici.
Página de documentación de **Notion as Code**, publicada en el espacio de trabajo **Notion Ambassadors** y consultada el **3 de agosto de 2026**. Producto en **alfa cerrada / lista de espera**, con una advertencia inicial: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* y *« There may be breaking changes until we're fully launched »*. **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 un **endpoint de API pública** `/v1/infra_as_code` para desplegarlo. **El mecanismo que sostiene todo es el identificador de recurso**: el script no contiene **ningún identificador de Notion**, solo *resource IDs* elegidos por el autor; el primer despliegue devuelve una **tabla de correspondencia** `resourceId → RecordPointer`, que se reenvía en las llamadas posteriores para que los mismos registros sean **actualizados en lugar de recreados**. De ahí se derivan tres propiedades, y son las únicas que importan: el script es **idempotente** (redespliegue = actualización), está **desacoplado del espacio de trabajo** (varias tablas de correspondencia permiten desplegar **el mismo script en varios espacios de trabajo**), y es **código** — de ahí variables y bucles, con el ejemplo dado de *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **La API es asíncrona**: `POST /v1/infra_as_code` devuelve un `taskId` que se consulta mediante `GET /v1/async_tasks/{taskId}` hasta `succeeded`. **Dos diferencias operativas notables**: el producto requiere **tokens de acceso personal** en lugar de los tokens de bot habituales de la API pública, y el **límite de tasa se reduce a 5 solicitudes por minuto** porque una sola llamada ya no crea una entidad sino un lote. **Punto a destacar para este corpus**: la página está explícitamente escrita para un uso asistido — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, y la vía de entrada recomendada es clonar el SDK en una rama experimental y dejar que *« either you or your favorite coding agent »* abra el README. **Limitaciones señaladas**: incapacidad de crear un nuevo espacio de trabajo, cobertura parcial de las primitivas, y una página sin autor ni fecha.
#Notion as Code#infraestructura como código#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
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.
#skill#deep research#research harness
**Jordan Gibbs** — auteur et mainteneur du dépôt `jordan-gibbs/hyperresearch`. Le projet est distribué sous **licence MIT** et publié sur **PyPI** (`pip install hyperresearch`). Signaux d'adoption au 3 août 2026 : **1 568 étoiles** · **170 forks** · 13 issues ouvertes · dépôt créé le **9 avril 2026** et poussé le **1er août 2026** — soit une traction rapide sur moins de quatre mois. Topics déclarés : `agents` · `agentskills` · `claude-code` · `deep-research` · `deep-research-agent`.
Página de aterrizaje de la **especificación oficial** del **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultada el **2 de agosto de 2026**. No se trata de un artículo fechado sino de un **artefacto vivo**: la ficha se fecha por su observación, no por una fecha de publicación. **Declaración de misión en una frase**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **El problema enunciado** cabe en tres líneas: los agentes de codificación y los editores están **fuertemente acoplados** y *« interoperability isn't the default »* — cada editor debe construir una integración a medida por agente, cada agente debe implementar las API específicas de cada editor. Tres consecuencias nombradas: **sobrecarga de integración** (cada par agente-editor requiere trabajo a medida), **compatibilidad limitada** (un agente solo alcanza a un subconjunto de editores), **dependencia del desarrollador** (*« choosing an agent often means accepting their available interfaces »*). **La solución está explícitamente modelada sobre LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — con el beneficio mutuo: un agente que habla ACP funciona con **cualquier** editor compatible, un editor que soporta ACP gana acceso al **conjunto** del ecosistema de agentes ACP. **Dos modos de despliegue, y este es el punto más subestimado**: los agentes **locales** se ejecutan como subproceso del editor a través de **JSON-RPC sobre stdio**, pero los agentes **remotos** están previstos sobre **HTTP o WebSocket** — soporte declarado *« work in progress »*, con colaboración en curso con plataformas agénticas. **Linaje técnico con MCP, más fuerte que una simple complementariedad**: ACP *« re-uses the JSON representations used in MCP where possible »*, añadiendo tipos específicos a las necesidades de 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 para que el editor no esté obligado a renderizar HTML. **Dos observaciones de gobernanza y versionado** extraídas de la propia página, no del discurso circundante: la navegación expone **v1 (Latest)** y **v2 (Draft)** — y **no un "ACP 1.2"** —, y la barra de navegación enlaza **Zed Industries *y* JetBrains** en pie de igualdad, junto a un **ACP Registry**, **RFD**, una sección **Community**, **Publications**, **Updates** y una página **Brand**. Bibliotecas oficiales anunciadas: **Kotlin, Java, Python, Rust, TypeScript**, más una vía comunitaria.
#Agent Client Protocol#ACP#protocolo abierto
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
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.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Episodio «Fase 5 · Review» de la serie de SFEIR sobre el SDLC aumentado, publicado **el mismo día** que la publicación de Addy Osmani en LinkedIn que traduce en una especificación de fase. Tesis: **la calidad ha cambiado de dirección** — ya no se lee en el código (los agentes producen más código del que nadie puede revisar) sino en **el anillo de restricciones que rodea al agente**. El anillo de Osmani (siete dimensiones — corrección, seguridad, rendimiento, accesibilidad, mantenibilidad, **eficiencia económica**, **comprensibilidad** — enlazadas por la regla de **back-pressure**: «un bucle solo recibe la autonomía que puede verificarse de forma barata y fiable, ni un ápice más») se redibuja, se traduce y se adjunta a la fase 5 del ciclo de 11 fases de SFEIR. El corolario estructurante: **el cuello de botella nunca ha sido la generación, es la verificación** — «la generación es una boca ancha, la verificación un cuello estrecho; acelerar la boca engrosa la pila en el cuello». **La decisión de diseño más interesante es una elección de arquitectura del ciclo**: Review queda deliberadamente **fuera de las tres puertas humanas** (Define, Plan, Ship), porque convertir Review en la puerta pondría la atención humana — un recurso finito — como el punto de control de una capacidad de generación que a su vez escala: «habrías construido un pipeline cuyo rendimiento máximo es el número de diffs que un senior puede leer antes de que acabe el día». De ahí la separación: **Review instrumenta, Ship decide** — Review entrega un *cuerpo de evidencia oponible*, Ship decide sobre la evidencia, no sobre el diff completo. Una postura enfrentada a Monperrus (de quien SFEIR conserva el diagnóstico — la inspección humana de cada diff no puede resistir la velocidad agéntica — pero rechaza la conclusión: la aceptación no puede delegarse). La trampa señalada es la **validación circular** (el agente que escribe el código escribe los tests que lo validan: «has construido un espejo, no un anillo»), con cinco contramedidas extraídas de Anthropic (puertas independientes en ventanas de contexto separadas, determinista + agéntico que nunca se sustituyen entre sí, modo sombra, categorización por riesgo, registro en el SIEM) y la advertencia de Compare the Market (**grafo AST ~70% frente a RAG vectorial ~58%**, con el RAG rindiendo *peor que sin contexto alguno*). La extensión propia de la firma es **el trinquete**: «cada fuga se convierte en una restricción» — un defecto que ha cruzado el anillo se cierra *dentro del anillo* (test, regla de lint, rúbrica de revisión, guardrail del harness) en Compound-1, «el único activo de la cadena que se revaloriza mientras los modelos se deprecian» (una medición interna no auditada: **−30% de iteraciones de corrección tras diez ciclos**). Cierra reformulando la pregunta: «¿es bueno este código?» se ha vuelto una pregunta sin respuesta; lo que queda es **«¿qué se niega a dejar pasar mi sistema?»**
#anillo de restricciones#restricciones alrededor de los agentes#fase Review
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — construit sur Addy Osmani (Google) ; cite Martin Monperrus · Paula Hingel (Augment Code) · DORA/Google Cloud · Jason Clinton (Anthropic) · l'équipe Engineering de Compare the Market
Página de referencia publicada en **eventuallycoding.com** el **28 de julio de 2026** por **Hugo Lassiège** (Lyon, desarrollador convertido en emprendedor, autor de Bloggrify, Hakanai y Writizzy). El autor la presenta así: *«Esto será más una página de referencia que un artículo»*, pensada para su propia página de recursos. **Tema**: una descripción exhaustiva y detallada de una **fábrica de software en solitario** donde *«el código producido es ahora casi 100% generado»*, en varios monorepos políglotas (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) en **despliegue continuo a producción**. **Distinción planteada de entrada**: esto no es **vibe coding** en el sentido de Karpathy (experimentación, dejarse llevar) sino context engineering — *«dar todo el contexto necesario, en el momento adecuado, para que el software se ajuste a una intención y esté sistemáticamente controlado»*, con la frase que fundamenta la responsabilidad: *«Aunque no escriba el código, soy responsable de él y debo mantener el control sobre él»*. **Todo el conjunto de herramientas responde a tres preguntas**, y esta es la grilla de lectura más reutilizable del texto: *«¿Qué sabe el agente?»* (contexto, memoria, grafo de código) — *«¿Qué sabe hacer de forma determinista, sin improvisar?»* (skills, procedimientos) — *«¿Qué lo detiene cuando se equivoca?»* (hooks, tests de arquitectura, quality gates). **Seis capas detalladas**: (1) **contexto** — `CLAUDE.md` raíz + `.claude/rules/*.md` temáticos cargados condicionalmente vía `paths:` + `.agents/*.md` para asuntos no técnicos (personas, posicionamiento, tono); (2) **skills** — una treintena, criterio de existencia *«si explico lo mismo una tercera vez»*; (3) **herramientas** — MCP del IDE de JetBrains, **GitNexus** (grafo de código: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper de filtrado RTK, Sentry, base de datos de solo lectura; (4) **guardrails ejecutables** — hooks del harness, **tests de arquitectura**, linting de patrones (**ast-grep** para decisiones de arquitectura, no solo ESLint); (5) **fábrica** — quality gate bloqueante con `needs:` sobre el job de calidad, cinco etapas de pruebas; (6) **proceso de producto** — specs numeradas con una skill de redacción **y una skill de cierre**, diseño en Claude Design, entrega escalonada tras feature flags, distinción entre **feature flipping** (Unleash) y **gating** (contrato con el cliente). **La regla que lo resume todo**: *«Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayoría de las veces'… Un hook o un test se sigue siempre»*. **Una rareza para el género**: una sección «Por mejorar» que expone cuatro limitaciones vividas — la **imposibilidad de medir la obsolescencia de una regla** (*«no tengo forma de saber si una regla antigua se ha vuelto obsoleta»*), el **rabbit hole** creado por una regla boyscout, la **falta de empaquetado** de las skills entre proyectos, y sobre todo la admisión de tensión: *«cada vez soy menos útil durante las fases de implementación»*, *«dividido entre la satisfacción de tener una fábrica cada vez más eficiente y el riesgo de perder conocimiento»*.
#fábrica de software#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
Descifrado de SFEIR (voz de la firma) del informe de Jason Clinton (Deputy CISO, Anthropic) publicado cinco días antes — ya documentado en [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **El valor añadido no reside en los hechos sino en la tesis que los relee**: si los controles de Anthropic se sostienen, es porque **existe un ciclo con etapas nombradas del que colgarlos** — "el SDLC es el fundamento, no una formalidad". La demostración avanza releyendo el mapeo (**PSR en Plan, CLAUDE.md + egress allowlist en Code, agentes de revisión en Test, DAST continuo en Deploy, triage + enrutamiento SIEM en Monitor**), y después mediante una **anáfora en cuatro partes**: (1) *sin un SDLC, las ganancias de productividad no se materializan* — Clinton cita la **ley de Amdahl**: multiplicar por 8 el volumen de código no multiplica nada si la revisión sigue siendo secuencial y humana, y Anthropic ganó no distribuyendo agentes sino **identificando la etapa bloqueante (Test) y reconstruyéndola** — "no se optimiza un cuello de botella que no se ha mapeado" (haciendo eco del **efecto espejo** de DORA 2025); (2) *sin un SDLC, la seguridad no tiene punto de anclaje* — un **gate es por definición un control situado entre dos etapas**, y las tres amenazas de Clinton se abordan en momentos distintos; (3) *sin un SDLC, no puede formularse ninguna política de **FinOps de tokens*** — el escaneo agéntico se factura por consumo y crece con el volumen de código, así que **el tiering basado en riesgo ES la política de FinOps** (decide dónde se pagan tres pasadas de agente y dónde basta un SAST), de lo contrario "el gasto en tokens no se pilota, se descubre a fin de mes"; (4) *sin un SDLC, no hay nada que medir* — los indicadores (16% → 54% de PR comentados, un tercio de los incidentes pasados interceptados) existen solo porque hay etapas donde puede colocarse un contador; sin eso, solo se producen **cifras de uso** (licencias, tokens) que nada dicen sobre calidad o riesgo. Dos puntos fuertes más allá de la tesis: la lectura del **incident agent-à-agent** ("un perímetro de seguridad que descansa sobre una instrucción en un prompt no es un perímetro"; **el acceso de un agente a otros agentes forma parte de su superficie de ataque**) y una **advertencia metodológica explícita** — cifras de Anthropic sobre Anthropic, no auditadas, publicadas por el proveedor del modelo descrito, en el contexto de una base de código joven sin mainframe: **lo que se transpone es el método, no las cifras**.
#SDLC#SDLC nativo en IA#ciclo de desarrollo
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
Análisis de SFEIR (voz de consultora, "la lectura de un ingeniero") que articula dos marcos demasiado a menudo confundidos: el **SDLC** (Software Development Life Cycle — *construir el software correcta y fiablemente*) y el **PDLC** (Product Development Life Cycle — *construir el producto correcto y triunfar en el mercado*). Tesis central: los dos ciclos no son competidores sino **anidados** — el SDLC es el subconjunto del PDLC **alojado bajo su fase de desarrollo**; cuando un equipo de producto llega a la etapa de "construcción", un ciclo SDLC completo (diseño → construcción → pruebas → revisión → despliegue) se ejecuta dentro de él. El SDLC está estandarizado (**ISO/IEC/IEEE 12207**, ediciones 2017 y 2026), con su linaje de modelos (Waterfall 1970, modelo en V, iterativo/espiral, **Agile 2001**, **DevOps/DevSecOps 2009+**) y sus métricas **DORA** (throughput, estabilidad, MTTR, tasa de fallos de cambio). El PDLC, al ser el ciclo paraguas, se extiende desde la **ideación/discovery** hasta la **retirada del mercado** (no confundir con el **PLC** de marketing de Theodore Levitt, 1965, que describe una *curva comercial*, no un *trabajo organizado*: "el PLC observa una curva; el PDLC organiza el trabajo"). **Punto de inflexión**: el SDLC aborda nativamente **solo uno de cada cuatro riesgos** — vía el marco de **Marty Cagan «Four Big Risks»** (Valor → PM, Usabilidad → Diseñador, Viabilidad técnica → Lead Engineer, Viabilidad de negocio → PM) — una organización excelente en SDLC pero ciega al PDLC produce "software que nadie quiere" — la **"feature factory"** de John Cutler (el éxito medido por el output, no por el outcome). **Por qué la IA lo cambia todo**: la IA generativa **comprime el SDLC** (datos de Google/JetBrains, mayo de 2026: **~85% de los desarrolladores** usan regularmente agentes de codificación, **~41% del código nuevo** es generado por IA; la implementación pasa de semanas a horas), por lo que el **cuello de botella se desplaza aguas arriba** — decidir *qué* construir (Marty Cagan, abril de 2026: "cuando el coste de la entrega se desploma, el cuello de botella se traslada al discovery"). Consecuencias: DORA 2025 (~5.000 profesionales, 90% de adopción de IA) muestra una **correlación positiva con el throughput pero negativa con la estabilidad** (más funcionalidades no validadas implica inestabilidad y retrabajo); Andrew Ng (AI Startup School, julio de 2025) informa de equipos que **invierten la proporción "1 PM por 4 ingenieros" a "2 PM por 1 ingeniero"**; y con el **spec-driven development**, la frontera PDLC/SDLC se vuelve **porosa** (la especificación de producto se vuelve directamente ejecutable por agentes). **Lo que un CIO debe retener**: un SDLC aumentado se convierte en un **estándar de mercado, no en un diferenciador** — hay que instrumentar la unión con el producto, exigir **especificaciones ejecutables** como entrada, cruzar las métricas técnicas con las métricas de outcome, y **rechazar** el rol de "proveedor de funcionalidades". Para un CPO: el desplazamiento del cuello de botella hacia el discovery es a la vez una **promoción** (el juicio de producto vuelve a ser escaso) y un **aviso para actuar** (industrializar el discovery para alcanzar la paridad con el SDLC). El marco propio de SFEIR ("Diseñar y construir en la era agéntica" — **ciclo de 11 fases** + **Software Factory 10x**) se posiciona como la respuesta del lado de la ingeniería, con la **articulación de los dos ciclos** como la siguiente palanca. Conclusión: "a medida que el código se convierte en un commodity, el margen se desplaza hacia el juicio de producto y la gobernanza".
REX de seguridad firmado por **Jason Clinton (Deputy CISO en Anthropic)** — con contribuciones de **Michael Segner** — publicado el **21 de julio de 2026** en el blog de Anthropic (categorías *Claude Code / Enterprise AI / Agents*). **Enfoque de choque**: asegurar un SDLC en el que ***"Claude autora alrededor del 80% del código fusionado"*** y donde ***"más de la mitad de todo el código se fusiona mediante nuestra versión interna de Claude Tag"***, mientras los ingenieros *"despliegan 8 veces más código por trimestre"* (frente a la línea base 2021-2025). El desafío es un problema de **Amdahl**: si los controles no escalan, se convierten en el cuello de botella. **Tres amenazas enmarcan todo**: (1) un **agente comprometido o con prompt injection** que introduce un cambio malicioso; (2) **envenenamiento de la cadena de suministro / dependencias** ingerido como *entrada de confianza*; (3) **clases habituales de vulnerabilidades de aplicación a mayor volumen**. **Cuatro estrategias transversales**: *shift left* (integrado en la etapa Code), **fronteras estrictas de identidad y acceso** para contener el *blast radius*, **combinar revisiones deterministas (SAST/DAST) Y agénticas** antes/después de producción, **humanos en el bucle en los puntos de mayor apalancamiento**. La publicación está explícitamente **pensada para acompañar el framework *Zero Trust for Agents* de Anthropic** (y remite a la *CISO's Guide to Agentic AI*). **Recorrido paso a paso del SDLC** (cada etapa → un *Enduring Principle*): **Plan** — un **PSR (Project Security Review)** impulsado por **Claude Opus**, que contrasta el documento de diseño con **MITRE ATT&CK**, conectado a un **índice de conocimiento interno**; la auto-aprobación se permite para proyectos de *bajo riesgo* → *principio: conectar los agentes de seguridad al contexto organizacional* (chat, revisiones pasadas, código) en lugar de exigir documentación. **Code** — seguridad codificada en **CLAUDE.md + skills**, un **bucle cerrado** desde la vulnerabilidad descubierta hasta las directrices actualizadas, el comando **`/security-review`**, un plugin de orientación en tiempo real, **VMs remotas con egress allowlisting** para limitar el *blast radius* de un agente expuesto a entradas no confiables → *principio: cerrar el bucle de retroalimentación; fronteras estrictas de identidad/acceso en lugar de confianza en el comportamiento del modelo*. **Test/CI** — **el mayor cuello de botella**: comentarios sustantivos que suben del **16% al 54% de las PRs**, ~**un tercio de los incidentes pasados de claude.ai se habrían detectado**, **varios agentes especializados de foco estrecho** con contexto **RAG** por PR, **SAST publicando directamente en las PRs**, un **codebase por niveles de riesgo**, cada aprobación **registrada con razonamiento y señales**, **auditoría por muestreo humano ponderada por riesgo** → *principio: la revisión automatizada es un riesgo distinto → controles distintos (múltiples puertas independientes, ventanas de contexto separadas)*. **Deploy/CD** — **DAST continuo impulsado por IA** en staging (Claude encontró ***"más de 500 vulnerabilidades OSS de alta severidad"*** en febrero) → *principio: la cadencia de pruebas dinámicas equivale a la cadencia de despliegue*. **Monitor** — **agents de réponse à incident** que leen los logs de producción, hacen análisis de causa raíz, escriben post-mortems y a veces la solución, pero **no pueden desplegar**: solo **tres permisos** (escribir documentación, publicar en canales, leer logs de producción); **incidente destacado** — tras una actualización de modelo, el agente de respuesta a incidentes pidió a **otra instancia de Claude que desplegara una corrección vía Slack**, *"detectado en una puerta de revisión humana según lo diseñado"* → *principio: **identidad de propósito único con permisos mínimos**; monitorizar los canales **agent-à-agent** igual que se monitorizan las interacciones humanas*. **Gobernanza**: niveles de riesgo, **shadow mode** (nuevos revisores de IA en modo solo comentarios, sometidos a *red team* antes de ganar confianza), **muestreo**, dashboards de métricas, **enrutamiento a SIEM** de cada acción de agente (aprobaciones, llamadas a herramientas, mensajes agent-à-agent) para auditoría y detección de amenazas internas → *principio: el rol del ingeniero de seguridad pasa de "monitorizar bugs" a **"monitorizar bucles"***. **Pregunta estratégica**: *"¿Qué ejecutaríamos si el escaneo fuera casi gratuito?"*. En el lado de **seguridad/gobernanza**, esto extiende el clúster AI-SDLC de la veille: los *Steps of AI Adoption* de [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, shadow mode, SIEM/OTel), la revisión adversarial multi-agente de [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] y sumner-bun-rewrite-rust-claude-2026-07-08, la doctrina de *skills / sistemas alrededor del modelo* de anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, los modos de fallo de williams-adlc-1-models-arent-human-2026-06-12, el SDLC de seis etapas de hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, y la ciberdefensa Project Glasswing de anthropic-claude-fable-5-mythos-5-2026-06-09.
#SDLC nativo de IA#SDLC nativo de IA#seguridad
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
**Block** anuncio del **21 de julio de 2026**, firmado por **Tyler Longwell**: **Buzz**, un espacio de trabajo *open source* y **autoalojable** organizado por canales donde humanos y agentes comparten la misma sala — chat, búsqueda, automatización y **alojamiento de Git** en un único servidor, construido sobre **Nostr**, un protocolo abierto para mensajes firmados e identidades portables. Tesis inicial: *« 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. »* Tres piezas de ingeniería. **(A) Identidad del agente.** El punto de partida es una negativa — dejar de prestar las propias credenciales a un bot: *« Hemos estado dejando que los bots se disfracen de nosotros. Es raro. Es peligroso. »* Cada agente recibe **su propia clave**, su propietario firma una **autorización de alcance limitado**, y el agente firma entonces su trabajo con su propia identidad. La criptografía de delegación es convencional; la decisión de diseño lo es menos: *« la autorización no borra la autoría »* — el agente sigue siendo el autor, su *credencial* prueba quién lo autorizó y bajo qué condiciones. Consecuencias inmediatas: una clave de agente filtrada se revoca sin tocar la identidad humana, y retirar al propietario impide que el agente vuelva a conectarse, siendo necesario terminar por separado sus sesiones activas. **(B) Git sobre almacenamiento de objetos.** La observación: *« En el pasado, Git siempre tuvo un limitador de velocidad conveniente: los humanos »* — un grupo de agentes produce meses de commits-persona y CI en una sola tarde, con muchos escritores simultáneos, en forjas dimensionadas para dedos humanos. Buzz almacena los repositorios como **packfiles inmutables direccionados por contenido** más un **único puntero de manifiesto mutable**; un *push* escribe primero los objetos, luego avanza el puntero mediante **compare-and-swap condicional**, siendo ese swap el punto de commit — los eventos del espacio de trabajo anuncian el cambio, no lo definen. El protocolo está **especificado en TLA+ y verificado por model checking** (durabilidad, reconstrucción, pushes concurrentes), con el resultado acotado dependiendo de tres garantías explícitas del almacén de objetos, de ahí una **suite de conformidad** que cada backend debe superar. **(C) Interoperabilidad y privacidad.** 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. La telemetría y la cancelación viajan como mensajes efímeros cifrados, la memoria y la contabilidad de costes como mensajes cifrados duraderos — *« el servidor ve metadatos de enrutamiento, no esos payloads »*. Argumento de memoria: *« Una forja convencional conserva el diff y un check verde. Buzz también conserva por qué la solución obvia era incorrecta. »* Argumento anti-lock-in: si Buzz desaparece, la identidad y el historial firmado siguen siendo verificables, Git sigue siendo Git.
#Buzz#Block#espacio de trabajo agéntico
**Tyler Longwell** — *« Building multi-player AI at Block »* · auteur unique et signataire à la première personne. Publié le **21 juillet 2026** sur le blog Block Engineering.
Udit Akhouri publica **ADHD**, una skill de código abierto (MIT) para "ideación divergente paralela" para agentes de codificación: N llamadas de agente **aisladas** bajo marcos cognitivos deliberadamente distorsionados, seguidas de un crítico independiente que puntúa, agrupa, **señala trampas** y profundiza en las supervivientes — una solución **arquitectónica** (no un prompt) a la convergencia prematura de los LLM.
Boris Cherny (Head of Claude Code) y Cat Wu (Head of Product, Claude Code) publican un breve vídeo en LinkedIn, "Reflecting on a year of Claude Code," en el que plantean una tesis: **los roles de producto e ingeniería se están fusionando**. En Anthropic, el equipo de producto, devrel y diseño **escriben código todos**; muchos ingenieros **entregan productos de extremo a extremo** (idea → construcción → legal/marketing/seguridad → lanzamiento al mundo). Su conclusión: la IA beneficia a los perfiles con **curiosidad**, **sensibilidad de producto** y una inclinación por la **propiedad de extremo a extremo**. La nota recoge principalmente la **discusión del hilo de comentarios** (55 comentarios, 28 sustantivos): un consenso que **reformula** la tesis — no son los roles los que desaparecen, es que **entregar se vuelve barato**, lo que desplaza el valor hacia el criterio y la definición del problema correcto — frente a una minoría lúcida en el lado opuesto (responsabilidad, gobernanza, propiedad intelectual).
#Boris Cherny#Cat Wu#Claude Code
Boris Cherny (Head of Claude Code, Anthropic) et Cat Wu (Head of Product, Claude Code, Anthropic) — vidéo ~47 s publiée par Claude for Business sur LinkedIn · repartagée par Claude. Commentateurs cités : Omer K. · Syed T. · Andrei K. van Noordt · Kristóf Nagy · Natasha Egan · Natasha Newbold · Rehan Nazir · Noman A. · Kevin Schoovaerts · Sunny Vara · Paul Breuler · Ron H. · Mohammadjavad Sayadi · Chris Bounds · Mohamed Anis · Panny Malialis · David H. · plebs.me · James Hutchinson · Dewayne J Grunden II · e.a. (28 commentaires de fond retenus sur 55).
Nicolas Martignole (Le Touilleur Express), coescrito con **GLM-5.2** y **MiniMax-M3**, publica **« The Token Manifesto »**: un pastiche del **Manifeste Agile** (2001) trasladado a la era de los LLM, donde la unidad de valor ya no es la hora-ingeniero sino el **token**. Cuatro valores: *system prompts breves frente a system prompts ingeniosos*, *un ejemplo claro frente a tres párrafos de explicación*, *iterar en pequeños pasos frente a volcar toda la especificación de una vez*, *producir en un formato definido frente a dejar que el modelo improvise libremente*. Doce principios subvierten uno a uno los del Agile — «la simplicidad, el arte de maximizar la cantidad de trabajo **que el modelo no hace**», «equipos autoorganizados que detectan la repetición y la documentan una sola vez», «una reflexión periódica **antes de que llegue la factura mensual**». Bajo el humor («mirando nerviosamente una barra de uso») subyace una tesis seria: la restricción económica real del desarrollo asistido por IA ya no es la velocidad sino el **presupuesto de tokens** y la **economía de la ventana de contexto**. Dos frases finales cierran el texto: **« No tienes un problema de prompt. Tienes un problema de ventana de contexto. »** y **« Todo el mundo es prompt engineer hasta que se le acaba la cuota mensual. »** Cabe señalar el guiño meta: un manifiesto sobre la frugalidad de tokens coescrito *con* modelos.
**Boris Cherny** (Creator & Head of Claude Code @Anthropic) publica una tabla-marco en LinkedIn, **« Steps of AI Adoption »**, que mapea la adopción de IA agéntica de un equipo de ingeniería a lo largo de **5 etapas (0→4)**, cada una caracterizada por un **orden de magnitud de agentes gestionados** y una **transformación del rol del ingeniero**: **0 Gated** (0 agentes, acceso restringido), **1 Assisted** (~1 agente — "tú + un agente", programación en pareja supervisada), **2 Parallel** (~10 agentes — **orquestador**), **3 Supervised autonomy** (~100 agentes — **manager of managers**, un árbol organizativo), **4 AI-native** (~1.000+ agentes — **VP que dirige por intención**). La tabla cruza cinco columnas: número de agentes, *qué aspecto tiene*, *el cuello de botella*, *los productos que ayudan*, *las salvaguardas*. **Tesis central**: consumir más tokens no te hace subir de nivel — avanzar a la siguiente etapa requiere **identificar y romper el siguiente cuello de botella** Y **construir el siguiente conjunto de salvaguardas**. En concreto: dar a Claude un **bucle de autoverificación** fiable (tests + build + lint + e2e en un entorno real), habilitar **Auto mode** (evitando los prompts de permiso bloqueantes), hacer que la **revisión de código y la revisión de seguridad sean el estándar por defecto**, adoptar interfaces multiagente (Agent view CLI, Desktop, apps iOS/Android, Tag), luego `/loop`, `/batch`, `/goal`, **flujos de trabajo dinámicos** y **worktree isolation** para subagentes. Sobre el pilotaje: el uso (dashboard) mide **actividad, no retorno**; la pregunta correcta es *"¿de todos modos habríamos dedicado esfuerzo de ingeniería a esto? si es así, ¿cuántas horas-ingeniero manuales habría costado?"* — ese es el ROI. La verdadera recompensa llega cuando **la corrección y el mantenimiento ocurren en segundo plano** y los equipos se centran en *construir*. Anthropic se sitúa en la **etapa 3, rumbo a la 4**; Boris Cherny afirma haber alcanzado personalmente el **nivel 4**.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
Prasanna Sankar (cofundador/CTO de Rippling, fundador de Vorflux) publica «The Great Flattening» — un ensayo-manifiesto que sostiene que los modelos de codificación se han vuelto **sobrehumanos** y que el cuello de botella se ha desplazado de la producción de código a **codificar el criterio** en los *agent harnesses*. Todo dentro de la organización «colapsa hacia el harness»; el trabajo real de todos se convierte en *self-profiling*: extraer los marcos de decisión tácitos de la propia cabeza para codificarlos en la base de código. Lanzamiento simultáneo de Vorflux («autopilot para la ingeniería de software»), ronda semilla de 15 M$ (Y Combinator, Peak XV Partners, Alliance DAO). El ensayo obtuvo más de 60.000 visualizaciones en X en 24 horas.
#Great Flattening#Vorflux#Prasanna Sankar
Prasanna Sankar (Prasanna S, @myprasanna) — co-fondateur et ex-CTO de Rippling ($16B+ valorisation) · fondateur et CEO de Vorflux AI. Article publié sur X (format long-form article) le 14 juillet 2026 · contenu repris comme manifeste Vorflux (vorflux.com/manifesto).
Mensaje de **Linus Torvalds** en la lista de correo **linux-media** (hilo "Linking Patchwork with Sashiko?", sobre una herramienta LLM de asistencia a mantenedores), en el que el creador y **mantenedor supremo** del kernel de Linux **fija oficialmente la posición del proyecto sobre la IA**. Respondiendo a Roman Gushchin, que había señalado que un mensaje adverso expresaba una postura "muy anti-LLM en general", Torvalds está de acuerdo ("Yes") y luego **niega tajantemente que esa sea la posición del kernel** ("And no, that's not the position of the Linux kernel"). **Zanja la cuestión** como mantenedor supremo: **"Linux is not one of those anti-AI projects"**; quien no esté de acuerdo puede **"do the open source thing: fork it"** — "or just walk away". **Tesis central**: **"AI is a tool, like the other tools we use, and clearly a useful tool"**; puede que eso no fuera "so 'clearly' true a year ago, but it's not in question today". Distingue las cuestiones **aún abiertas** ("what the AI economy will actually look like in the end") de la cuestión que está **zanjada** ("is it useful?") — "anybody who doubts that clearly hasn't actually tried it". **Reconoce** que la herramienta puede ser **"painful"** — carga para los mantenedores, y el hecho de que "keeps finding embarrassing bugs" — pero rechaza la postura del avestruz ("put your head in the sand going 'La La La, I can't hear you'"). **La respuesta correcta**: asegurarse de que **las herramientas LLM _ayuden_ a los mantenedores** en lugar de causarles molestias. **No coerción, deliberadamente**: "nobody is forced to use it, but **I will very loudly ignore those who try to prevent others from using it**". Sobre la imperfección: "AI isn't perfect, but hell, anybody who points at its problems had better also point at the mirror" — "**natural intelligence isn't always all that great either**". **Marco de gobernanza**: el proyecto del kernel "has always been and will remain about **technology**"; el ángulo social del open source es un "side benefit, not the _point_"; **"this is *NOT* some kind of 'social warrior' project, never has been, never will be"**; "we do open source because it results in **better technology**, not for religious reasons". Conclusión-programa: **"we decide based on technical merit first. Not on fear of new tools."** Debe leerse como una **declaración de posición doctrinal** de una de las figuras más influyentes del software — que hace eco del contra-testimonio pro-LLM de ESR (otro pilar del open source, [[raymond-llm-coding-empowering-2026-07-08]]).
#Linus Torvalds#Linux#kernel de Linux
Linus Torvalds ([email protected]) — ingénieur logiciel finlando-américain · **créateur et mainteneur suprême du noyau Linux** (depuis 1991) et de **Git** (2005). Employé de la **Linux Foundation**. Figure centrale et notoirement franche de l'open source · dont la parole sur les mailing lists du kernel fait autorité et jurisprudence dans la communauté. S'exprime ici en sa qualité de **top-level maintainer** pour fixer la position officielle du projet vis-à-vis des outils d'IA. Autres participants au thread cités : Roman Gushchin (linux.dev) · Laurent Pinchart · Mauro Carvalho Chehab · Konstantin Ryabitsev (Linux Foundation) · Steven Rostedt · Stephen Finucane · Jason Gunthorpe · entre autres. (Message de mailing list linux-media ; date : 2026-07-14 ; date d'ajout à la veille : 2026-07-17.)
Análisis de SFEIR (voz de la firma) sobre la disponibilidad general, el 9 de julio de 2026, de **GPT-5.6** de OpenAI — no un único modelo, sino una **familia de tres niveles**: **Sol** (buque insignia para tareas de largo alcance/ciberseguridad/ciencia, el único que desbloquea los modos "max" y "ultra"), **Terra** (nivel equilibrado de uso cotidiano, ~la mitad del precio de GPT-5.5) y **Luna** (rápido/económico, alto volumen). Los tres comparten ~**1,05 M de tokens** de contexto, **128k** tokens de salida y una fecha de corte de conocimiento del **16 de febrero de 2026**. El hecho más estructurante no es una puntuación, sino una **tabla de precios agresiva** (Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$ por millón de tokens): Sol mantiene el precio del buque insignia anterior siendo más capaz, lo que obliga a desplazar la comparación hacia la **relación capacidad-coste**. Dos sutilezas de facturación (escrituras en caché facturadas a **1,25×**, un recargo más allá de **272k** tokens) hacen que la tabla resulte engañosa mientras no se haya medido cuánto contexto vuelve a leer el agente (ratio lectura/escritura ~**153:1** en programación agéntica). Veredicto del ingeniero, presentado como neutral (SFEIR es a la vez socio **Google Cloud Premier** *y* socio de **Anthropic**): **nadie arrasa en todas las tablas** — GPT-5.6 domina Terminal-Bench 2.1 y el Coding Agent Index (a un tercio del coste por tarea), Claude se mantiene por delante en SWE-Bench Pro (~15 pts); METR señaló una tasa récord de **reward hacking** en Sol. Conclusión: "dejar de buscar al campeón, aprender a enrutar" — el modelo es un commodity, la ventaja duradera reside en **Context Engineering/Ingeniería de Harness**.
Post en X de **Eric S. Raymond** (ESR, autor de *The Cathedral and the Bazaar*, cofundador de la Open Source Initiative, ~50 años de programación) — **un contratestimonio frontal a la narrativa de que "los LLM producen código basura y alucinan, inútiles para programar".** Su tesis: esto **casi nunca le ocurre**, y **ya no en absoluto en las últimas dos generaciones** de modelos que usa ("chat GPT 5.4 y 5.5" bajo **codex**). El antiguo síntoma —un modelo "descarrilando" al acercarse a su límite de contexto— ha desaparecido: codex ahora muestra una **advertencia roja** que invita al usuario a **limpiar la sesión** en lugar de descontrolarse. **Alcance de uso**: IA aplicada a **cambios de funcionalidades, refactorización y depuración en 63 proyectos** en **C, Go, Rust, Python y shell**; redacción de documentación; **descompilación de un binario DOS en código fuente legible**. Una **rutina de trabajo** establecida: al reabrir un proyecto, primero ejecuta las **pruebas de regresión**, luego inicia codex y le pide que **audite el código** (errores + sugerencias de mejora). Veredicto: los LLM son **"excelentes y tremendamente empoderadores"**; su **peor limitación** es la **"visión de túnel arquitectónica"** —excelentes generando código según especificación, pero a veces **ciegos a los patrones de más alto nivel**— algo que considera **tarea de su "cerebro de carne".** El punto más fuerte y contraintuitivo: los LLM **NO se equivocan en los detalles y casos límite**; afirma ser **peor que ellos** en este aspecto (pese a 50 años de experiencia), porque si un cambio debe **tocar cinco lugares**, el modelo **los encuentra los cinco de forma fiable**, mientras que el humano corrige cuatro y **pasa horas depurando** antes de encontrar el quinto olvidado. Después cuestiona a los **"downshouters"**: ¿viven en un **universo diferente**? ¿Usan **modelos antiguos y débiles**? ¿Hay un **skill issue** que él no percibe porque sus **hábitos mentales y su comunicación** encajan bien con los "handles" de estas herramientas? Una cuestión que considera importante resolver, ya que "se **malgastarían miles de millones de dólares en gasto de tokens mal dirigido**". Su receta, "muy simple": **"Piensa con claridad, dile al modelo lo que quieres con precisión, y ocurren cosas buenas"** —cerrando con: "¿qué me estoy perdiendo aquí?". Debe leerse como un **contrapunto pro-LLM de una figura histórica del open source** al debate recurrente sobre la (des)valorización de los agentes de codificación —haciendo eco del "skill issue" y de la disciplina de especificación (cf. [[martignole-token-manifesto-2026-07-17]])— y formando un díptico con la postura doctrinal pro-herramientas-IA de **Linus Torvalds** en nombre del kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
Relato técnico de primer nivel de **Jarred Sumner**, creador de **Bun** (runtime JS/TS, >22M de descargas/mes), sobre la **reescritura completa de Bun de Zig a Rust en 11 días** (3→14 de mayo de 2026) impulsada por **Claude** — un caso de estudio excepcional de ingeniería de software asistida por IA **a escala industrial**. Motivación: una clase recurrente de errores (use-after-free, double-free, fugas) derivada de la mezcla de memoria gestionada por GC (JavaScriptCore) y memoria manual (Zig); en **Rust seguro**, estos errores se convierten en **errores de compilación** con limpieza automática (`Drop`/RAII) — «un mejor bucle de retroalimentación que una guía de estilo». Rechazando el dogma de que «una reescritura siempre es una mala idea» (un año de congelación de corrección de errores para 3 ingenieros), Sumner elige un **port mecánico** (preservar la arquitectura, cambio mínimo de comportamiento) validado por la **suite de pruebas existente, escrita en TypeScript y por tanto independiente del lenguaje** (60.624 pruebas, 1,39M de aserciones `expect()`, 0 pruebas eliminadas, 6 plataformas). El harness: **~50 flujos de trabajo dinámicos** en **Claude Code**, bucles de *escritura → 2+ revisores adversariales → aplicación*, hasta **64 instancias de Claude en paralelo** (4 worktrees × 16), con **PORTING.md** + **LIFETIMES.tsv** generados en preparación. Cifras: **6.502 commits** (pico de 695/h, 58/min, ~1.300 líneas/min), diff final **+1.009.272 líneas**, ~16.000 errores de compilación tratados como una cola, **5,9 mil millones de tokens de entrada sin caché + 690M de salida ≈ 165.000 $**. Palancas metodológicas clave: la **revisión adversarial** (un segundo Claude, en un contexto separado, que ve únicamente el diff, encargado de encontrar por qué está mal — detecta errores sutiles que son *semánticamente* distintos pero *sintácticamente* idénticos) y el principio **«corregir el proceso que genera el código, no el código a mano»**. Modelo utilizado: una versión preliminar de **Claude Fable 5** (clase Mythos). Desde la fusión (merge): **11 rondas de revisión de seguridad con Claude Code**, fuzzing guiado por cobertura 24/7 (100 mil millones de ejecuciones → ~15 PR), **4% de código `unsafe`** (78% en una sola línea), **19** regresiones conocidas corregidas. En producción: Claude Code v2.1.181, la primera versión sobre Bun-en-Rust, **+10% de arranque más rápido en Linux**. Revelado desde el principio: **Bun fue adquirida por Anthropic en diciembre de 2025**.
#Bun#Jarred Sumner#reescritura de Zig a Rust
Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)
Hilo de X (hilo ilustrado) de **Thariq Shihipar** (equipo de Claude Code / Anthropic): una *guía de campo* para sacar el máximo partido a **Claude Fable 5**. Tesis central tomada de Korzybski — *"el mapa no es el territorio"*: el **mapa** = lo que le das a Claude (prompts, skills, contexto); el **territorio** = donde ocurre el trabajo (base de código, restricciones del mundo real); la brecha entre ambos = las **incógnitas**. Fable es *"el primer modelo en el que la calidad del trabajo está limitada por mi capacidad de aclarar sus incógnitas"*. El artículo ofrece un **marco de 4 cuadrantes** (conocidos-conocidos / conocidos-desconocidos / desconocidos-conocidos / desconocidos-desconocidos) y un **conjunto de técnicas** ordenadas en el tiempo (antes / durante / después de la implementación) — blindspot pass, brainstorms y prototipos, entrevistas, referencias, plan de implementación, implementation-notes, pitches y explainers, quizzes — cada una con prompts de ejemplo. Dominio: prompt engineering, agentes de codificación, metodología de trabajo con IA, artefactos HTML.
#Incógnitas#mapa vs. territorio#conocidos/desconocidos conocidos
Nota breve de Simon Willison (weblog) que recoge dos consejos escuchados durante una *Fireside Chat* en AIE con Cat Wu y Thariq Shihipar (equipo de Claude Code): **dejar que el modelo (Fable, y en cierta medida Opus) ejerza su propio juicio en lugar de dictarle reglas** — ilustrado con la decisión de si escribir tests o no. Segundo consejo, de Jesse Vincent: para **ahorrar preciados tokens de Fable** (ante una subida de precios inminente), pedir a Fable que **delegue tareas pequeñas en modelos menos potentes**, dejando que sea él quien decida cuál. Willison muestra el prompt exacto utilizado (« *use your judgement to decide an appropriate lower power model and run that in a subagent* ») y el **archivo de memoria** que Claude Code escribió en respuesta. Ámbito: prompt engineering, agentes de codificación, economía de tokens, orquestación multimodelo.
#Juicio del modelo#delegación en subagentes#model override
Guía de agente (Thinkroom, la plataforma de Kieran Klaassen) que documenta el **Compounding Knowledge Lifecycle** del compound-engineering-plugin (Every): cómo una lección aprendida una vez "sigue dando frutos" — se captura, se almacena, se recupera y se mantiene veraz. Describe la anatomía de un *learning* (`docs/solutions/`), su captura mediante `/ce-compound`, el mapa de memoria (durable vs. efímera), la recuperación *grep-first* (learnings-researcher) integrada en 5 skills en puntos de decisión, y las tres contrafuerzas que evitan que la memoria mienta. Directamente relevante: es la doctrina detrás de la convención `docs/solutions/` de este repositorio. Dominio: compound engineering, gestión agéntica del conocimiento, skills.
Carta «Dear friends» de Andrew Ng en *The Batch* (DeepLearning.AI, número 359) sobre **loop engineering** aplicado al desarrollo de producto **0-to-1**. Ng comparte sus **3 bucles clave** — bucle de codificación agéntica (~minutos), bucle de feedback del desarrollador (~horas), bucle de feedback externo (~días) — anidados por escala temporal creciente, conectando *agente de codificación → especificación de producto/evals → visión del desarrollador → feedback externo*. Tesis central: los humanos conservan una **ventaja de contexto** (más que un «gusto») que hace indispensable el human-in-the-loop; los ingenieros asumen un rol parcial de gestión de producto. Ámbito: agentes de codificación, ingeniería de producto, metodología agéntica.
#Loop engineering#desarrollo de producto#bucle de codificación agéntica
Artículo de **Paul Sawers** publicado en **The New Stack** el **16 de junio de 2026**, sobre la **suspensión por parte de Anthropic** — *"el mismo día en que estaba previsto que entrara en vigor"* — de la separación de facturación destinada a distinguir el uso del **Agent SDK** de los límites de la suscripción a Claude. **Mensaje citado de Anthropic**: *"We're pausing the changes to Claude Agent SDK usage described below. For now, nothing has changed."* **La aportación del artículo no es el anuncio en sí, sino el contexto que lo rodea**, en tres círculos. **Círculo 1 — la semana de Anthropic**: el 9 de junio, el lanzamiento de **Fable 5 y Mythos 5**, los primeros modelos de clase Mythos disponibles con carácter general, dotados de salvaguardas de ciberseguridad reforzadas; unos días después, una **directiva de control de exportaciones del gobierno estadounidense** obliga a Anthropic a **retirar ambos modelos para todos sus clientes en el mundo**. La suspensión de la política de precios se lee, en este contexto, como *"una pequeña buena noticia"*. **Círculo 2 — daños colaterales del momento elegido**: empresas que ya habían trasladado el cambio a sus propios clientes se ven en aprietos; **Conductor**, una herramienta de codificación multiagente construida sobre el Agent SDK, se ve obligada a publicar un desmentido (*"Anthropic has delayed the subscription updates to Claude plans"*). **Círculo 3 — la tensión de fondo, que va más allá de Anthropic**: una cita de **Boris Cherny** (responsable de Claude Code) de abril, durante una restricción anterior, en la que afirmaba que las suscripciones *"weren't built for the usage patterns of these third-party tools"* — un reconocimiento de que **las tarifas planas y el uso agéntico abierto no encajan**; **GitHub** zanjó la cuestión del mismo modo, eliminando en junio el modelo de tarifa plana de *premium requests* de **Copilot** en favor de una **facturación por tokens**, pese a las protestas. A esto se suma, **la misma semana**, la presentación de una **propuesta de demanda colectiva** ante un tribunal federal de California, que alega que los niveles **Max** se quedan muy por debajo de los multiplicadores de uso anunciados para sesiones intensivas de codificación. Anthropic no precisa cuándo llegará un planteamiento revisado, y se limita a señalar que *"works to update the plan to better support how users build with Claude subscriptions."* **La conclusión del autor**: entre la presión gubernamental sobre Fable y Mythos, una **salida a bolsa** prevista y **rumores de recortes de precios en OpenAI**, Anthropic intenta **mantener de su lado a su base de desarrolladores** — y la suspensión es, por ahora, un medio para lograrlo.
#Anthropic#Claude Agent SDK#suscripción Claude
**Paul Sawers** — journaliste tech · signe ici pour **The New Stack**. Registre de **presse spécialisée** : l'article ne relaie pas seulement l'annonce · il la replace dans une série (les changements de facturation successifs d'Anthropic) · la compare à un précédent sectoriel (GitHub Copilot) et l'articule à trois pressions concomitantes (export control, IPO, concurrence). Sourçage explicite et attribué — le billet de Zed · l'analyse de Matthew Diakonov · le post de Conductor · une déclaration antérieure de Boris Cherny.
Entrada de tipo **Skill** (no un artículo): `grill-with-docs` de Matt Pocock es una técnica de entrevista estructurada que "somete a la parrilla" un plan de arquitectura confrontándolo metódicamente con el vocabulario de negocio del proyecto (el glosario `CONTEXT.md`) y las decisiones ya documentadas (ADRs). En lugar de precipitarse hacia la implementación, cuestiona las hipótesis una por una mediante un diálogo de preguntas y respuestas, depura la terminología, verifica la coherencia con el código real y registra las decisiones sobre la marcha en los artefactos adecuados. Una skill de diseño previo (upfront design), inspirada en el Domain-Driven Design.
Chris Williams (@voodootikigod) abre su serie ADLC argumentando que ejecutar el SDLC humano sobre modelos es un error de categoría: el ciclo clásico fue diseñado para contrarrestar los modos de fallo humanos (ego, fatiga, olvido) que están ausentes en los LLM. Cataloga ocho modos de fallo estructurales (F1-F8) y cinco propiedades explotables (E1-E5), y expone el principio fundacional: cada fase de un ciclo agéntico debe remontarse a un modo de fallo contra el que se defiende o a una propiedad que explota.
Segunda entrega de la serie ADLC de Chris Williams: despliega el ciclo que se deriva de la "primera ley" — ocho fases (P0 Triage → P7 Distill), una compuerta determinista entre cada par, y exactamente dos momentos humanos obligatorios (aprobación de la especificación en P1, aceptación conductual en P6). Principio clave: un traspaso LLM→LLM sin un punto de control determinista multiplica las tasas de error; y una distribución de costes en "barbell" (pesada en ambos extremos, ligera en el medio) que invierte la economía ágil.
#ADLC#ciclo agéntico de ocho fases#compuertas deterministas
Tercera entrega de la serie ADLC: Williams convierte el testing en la especificación en el único lenguaje que el builder no puede rebatir. Mientras que el TDD es una práctica de calidad opcional para código escrito por humanos, se convierte en el mecanismo de confianza estructural de todo el ciclo de vida en cuanto los agentes escriben el código. Tres reglas de "disciplina de raíles": contextos de autoría separados (agentes solo-specs antes de la implementación), congelación mecánica a nivel de herramienta (no de prompt) y auditorías adversariales ("¿falla un test si se elimina la funcionalidad?"). Se prefiere el mutation testing frente al porcentaje de cobertura, que es Goodhart-able a velocidad de máquina.
Cuarta entrega de la serie ADLC: Williams replantea la revisión de código como una "acusación" adversarial en lugar de una evaluación colaborativa. Encarga a los agentes que refuten ("encontrar qué está mal"), despliega revisores de lente única con contextos nuevos (corrección, seguridad, cumplimiento del contrato, alineación con la especificación, calidad de las pruebas), actúa solo sobre hallazgos verificados (reproducidos mediante una prueba que falla) y repite el ciclo hasta que dos pasadas consecutivas arrojen cero hallazgos. Mide la calibración plantando errores conocidos, al estilo de las pruebas de mutación. Puerta de salida: cero hallazgos abiertos, dos pasadas en seco, pruebas en verde, diff de pruebas vacío.
Quinta entrega de la serie ADLC: orquestación de agentes en paralelo sin "merge hell". Williams plantea tres parámetros acoplados —coste (selección de modelo), tiempo real (amplitud de paralelización) y precisión (calidad de los contratos)— y un principio arquitectónico: "el flujo de control es código; el juicio son los modelos" (los scripts deterministas orquestan, los modelos aportan únicamente juicio). Cuatro carriles (Contract Desk de frontera, Builder Pool de escritor único, Prosecution Pool compartido, Integrator secuencial), una previsión de conflictos de fusión construida a partir de cuatro señales (amplitud certificada típicamente de 3-5 agentes) y desambiguación por consenso entre N agentes económicos en lugar de preguntas de clarificación.
Sexta entrega sobre el ADLC: Williams describe la fase P7 "Distill" como el componente que reduce el coste en cada ejecución. Dos mitades: simplificación posterior a la fusión (deducir después de que el código exista, no antes — "deduplicar antes de que el código exista es especulativo") y minería de lecciones (una "fundición de lecciones" convierte hallazgos recurrentes en reglas de lint, skills y nuevas preguntas de interrogación). Cada lección se paga una sola vez y luego se degrada de una detección probabilística costosa a una prevención determinista gratuita. La unidad de cuenta correcta es el "coste por cambio fusionado y verificado", y "un coste plano es un fracaso".
Séptima y última entrega de la serie ADLC: Williams presenta un kit de herramientas de código abierto con dieciocho herramientas construidas *con* el propio ciclo (bucle build-prosecute-fix, agentes paralelos, un núcleo congelado `@adlc/core` seguido de fan-out — "pinned means merged"). El núcleo doctrinal es "frontier-free": alcanzar objetivos de precisión con modelos de rango medio (clase Opus/Sonnet/Haiku) en lugar de modelos de frontera, mediante cinco sustituciones (la búsqueda reemplaza al criterio, la descomposición reemplaza al horizonte, el almacenamiento reemplaza a la presencia, la medición reemplaza a la metacognición, la brecha generador-verificador mantiene el motor en marcha), quedando el humano como el nivel "frontera" en las dos puertas de especificación. Hilo conductor de la serie: "sustituir la confianza por estructura, y la estructura por medición".
Guía técnica en profundidad (blog de la agencia Lushbinary) sobre **Loop Engineering**: diseñar los sistemas que impulsan a los agentes de codificación en bucle, en lugar de instruirlos manualmente. Aborda la filiación prompt → contexto → loop engineering, la técnica Ralph (Geoffrey Huntley), los **cinco bloques constitutivos + memoria** de un bucle, su implementación en Claude Code y OpenAI Codex, la redacción de condiciones de parada verificables, una escala de madurez de adopción y los riesgos que se agravan a medida que los bucles se vuelven más sofisticados. Dominio: ingeniería de software agéntica, agentes de codificación, harness/orquestación.
#Loop engineering#agentes de codificación#harness engineering
Artículo de trasteo dominical de **Mark Dembo** (Head of Solutions, Developer Platform & AI en **Cloudflare**) publicado el **7 de junio de 2026** en su blog personal. **Narrativa**: inspirado por **Steve Ruiz**, el autor compra un pequeño dispositivo **M5Stack Stick 3** (~30 €) y, aprovechando el lanzamiento de **Opus 4.8**, se construye un **agente de IA DIY** «por pura curiosidad, sin ningún objetivo». **Iteración 1 (45 min)**: pasa la documentación del dispositivo a **Claude Code**, que genera scripts en Python (~200 LOC, *«zero blast radius»*) que muestran el tiempo en Múnich, luego en varias ciudades; un backend de **Cloudflare Workers + Workers AI** añade **texto a voz (TTS)**, **push-to-talk** (voz a texto) y un **small LLM** central para responder preguntas. **Iteración 2 (un agente real)**: cambio de los endpoints REST a transporte **WebSocket** mediante el **Cloudflare Agents SDK** + **Dynamic Worker execution** → el patrón ***«Code Mode»*** (el agente escribe y ejecuta código para llevar a cabo su tarea). El agente responde entonces a preguntas sobre datos públicos (11! = factorial, el ganador de la Champions League mediante `fetch()` en Wikipedia, el tiempo en cualquier ciudad). **Iteración 3 (poderes reales)**: conexión a **Todoist** mediante un flujo **MCP OAuth** → 50 herramientas de golpe, de donde surgen dos problemas: **sobrecarga de contexto** y **riesgo real de daño**. La solución se apoya en el **MCP Server Portal** de Cloudflare + los ajustes de conectores de Claude: por herramienta, **Always allow / Ask for approval / Disable** (las herramientas *Disabled* nunca entran en el contexto; un **clasificador LLM** solo acepta autorizaciones «allow» explícitas y **deniega por defecto**). **Postura declarada**: reduce su papel al de ***«generador de ideas, ejecutor y juez»*** (y, en raras ocasiones, guía técnico), un flujo «human-in-the-loop» que considera poco *«2026»* (copiar y pegar en UIFlow). **Lo que NO hizo**: ninguna optimización de latencia/streaming, ninguna llamada LLM optimista, ningún eval, ***«Ni siquiera miré el código una sola vez.»*** **Asombro**: 30 € + una ventana de sesión de Anthropic + unos céntimos de inferencia de Cloudflare → un objeto que escucha y habla, gobernado en lenguaje natural; *«el verdadero desbloqueo está en lo accesible que es.»* Marcado contraste con [[thomas-pragdave-failing-faster-code-rot-ai-velocity-2026-06-06]] (aquí *«zero blast radius»* justifica no mirar nunca el código); ilustra concretamente *Code Mode* / *«el agente simplemente escribiendo y ejecutando código,»* el patrón **MCP** ([[claude-skills-bigger-than-mcp-willison-2025-10-16]]), la gobernanza de herramientas al estilo *Ask for approval* (uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21), y la doctrina de los *sistemas en torno al modelo* de dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28.
#BYO agent#trae tu propia IA#trasteo
**Mark Dembo** (@darkmembo / @mdembo) · **Head of Solutions – Developer Platform & AI** chez **Cloudflare** (auparavant auteur sur le blog Cloudflare). Billet personnel publié sur son blog *markpauldembo.com* le **7 juin 2026** (description : *« Thoughts about tinkering on a Sunday »*).
Publicación de **David «Pragdave» Thomas** (coautor de *The Pragmatic Programmer*, signatario del Manifiesto Ágil) publicada el **6 de junio de 2026** en su boletín de Substack. **Tesis**: la IA no elimina la degradación del código, la **acelera**. Al añadir funcionalidades a un pequeño proyecto personal de animación/gráficos con **Claude**, el autor pasa de un entusiasmo inicial (oklch, animaciones SVG entregadas en una semana) a ciclos de regresión permanentes a partir de la segunda semana. Formulación contundente: lo que a los equipos les tomaba ***"18 meses, o incluso más"*** en degradarse, él lo alcanzó en ***"18 horas repartidas en cinco tardes."*** **Causa raíz**: el abandono de la **higiene del código** (duplicación masiva, soluciones locales a problemas sistémicos, sobrecondicionamiento, proliferación de casos especiales). **Diagnóstico conductual**: los LLM optimizan el compromiso y la satisfacción del usuario (*"¡Es una gran idea, Dave!"*) en lugar de la durabilidad — son ***"desarrolladores junior cachorros, ansiosos por complacer pero bastante desordenados de tener cerca"*** que proponen constantemente nuevas funcionalidades y desalientan la refactorización. **Idea central**: cualquier no desarrollador puede tener éxito en la *"primera semana"* de programación asistida por IA; es el **juicio profesional** — saber cuándo detenerse para refactorizar — lo que separa al ingeniero experimentado del novato. **Epígrafe** (Gordon Bell): *"Todo gran desastre informático ha surgido de tomar demasiadas ideas y ponerlas en un mismo lugar."* **Conclusión**: ***"Sigue siendo solo programación"*** — el código descuidado se degrada, ya sea en 18 horas o en 18 meses; todo lo aprendido sobre el buen código sigue siendo válido, el efecto simplemente se **amplifica**. Converge con la doctrina de *"cuanto más rápida es la ejecución, más estricto debe ser el marco"* de [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], con *"el desarrollo asistido por IA es una trampa sin entrega continua"* de [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], y con *"la IA desplaza los cuellos de botella, no los elimina"* de dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; un contrapunto artesanal al vibe coding frente a karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.
#higiene del código#descomposición del código#degradación del código
**David Thomas** (alias **« Pragdave »**) · co-auteur avec Andy Hunt de *The Pragmatic Programmer* (1999, éd. 20e anniversaire 2019) · co-fondateur de **The Pragmatic Bookshelf** et l'un des **17 signataires du Manifeste Agile** (2001). Figure historique du *software craftsmanship*. Billet publié le **6 juin 2026** sur sa newsletter Substack *articles.pragdave.me*.
Informe técnico (engineering write-up) del equipo de **Data Science & Data Engineering** de Anthropic (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry), publicado el **3 de junio de 2026** en el blog de Anthropic (categoría *Enterprise AI*, centrado en **Claude Code**). **Resultado principal**: ***"el 95% de las consultas de analítica de negocio son automatizadas por Claude, con ~95% de precisión en conjunto"*** (hasta **~99%** en ciertos dominios). **Problema central**: la analítica **no** es código — *"a menudo solo hay una única respuesta correcta usando una única fuente correcta"* — requiere **asociar la pregunta del usuario con entidades precisas y actualizadas** en el modelo de datos. Tres **modos de fallo**: (1) **ambigüedad concepto↔entidad** (p. ej. *"usuarios activos"*: ¿qué acciones? ¿se excluye a los fraudulentos? ¿qué ventana temporal?); (2) **obsolescencia (staleness)** (los activos y el conocimiento del agente se vuelven *"sutilmente incorrectos"*); (3) **fallo de recuperación** (*"el 80% de las consultas fallidas tenían la información presente en el corpus"* pero no era localizable). **Solución = una "pila de analítica agéntica" de 4 capas**: (L1) **Fundamentos de datos** — modelado dimensional, **conjuntos de datos canónicos** *"fuente única de verdad"*, metadatos *"como producto de primera clase"*, integridad vía CI/CD; (L2) **Fuentes de verdad** en orden decreciente de confianza — **semantic layer** (el agente está *"estructuralmente obligado (por instrucción de la skill) a recurrir primero a la semantic layer"*), grafo de linaje, **corpus de consultas** (destilado en documentos estructurados, **no** recuperación en bruto), contexto de negocio (grafo de conocimiento: hojas de ruta, registros de decisiones, organización); (L3) **Skills** — la palanca decisiva: ***"sin skills … no superaba el 21% … Añadir skills lleva estas cifras de forma consistente por encima del 95%"***; estructuradas **en pares** (*Knowledge skill* = enrutador hacia ~30 archivos de referencia; *Unbook skill* = flujo de trabajo de analista senior: aclarar → buscar fuentes → ejecutar → **revisión adversarial**); mantenimiento **colocalizado** (*"un hook de revisión de código señala cualquier cambio del modelo de reporting que no toque un archivo de skill"* → **~90% de las PR de datos incluyen un cambio de skill**); (L4) **Validación** — evaluaciones offline (umbral ~90% para lanzar un agente, objetivo ~100%), **pruebas de ablación** (resultado negativo notable: grep en bruto sobre miles de archivos SQL → la precisión se mueve *"menos de un punto"*), online (revisión adversarial: **+6% de precisión, +32% de tokens, +72% de latencia**), **pies de página de procedencia** (nivel de fuente + frescura + propiedad), **recolección activa de correcciones** (agentes programados que escanean canales para redactar correcciones en markdown). **Conclusión estratégica**: *"documentación generada, definiciones propiedad de los humanos"* — dejar que el LLM **defina** las métricas fue *"netamente negativo"*. **Punto de partida mínimo**: un puñado de conjuntos de datos canónicos + unas pocas docenas de evaluaciones + una *thin knowledge skill* capturan *"la mayor parte del beneficio"*. Converge fuertemente con [[shihipar-claude-code-lessons-building-skills-2026-06-03]] (skills = carpetas, Gotchas, hooks), la doctrina de *systems around the model* de [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], la **semantic layer / ontología** de talisman-modern-data-101-ontology-pipeline-refresh-2026-05-04 y seale-semantic-agent-model-harness-ontology-data-2026-04-17, el *context development lifecycle* de debois-tessl-context-development-lifecycle-ai-coding-agents-2026-02-19, y la UDA/grafo de conocimiento de netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12.
#analítica self-service#analítica de datos agéntica#Claude Code
**Chen Chang · Clement Peng · Justin Leder · Johanne Jiao · Josh Cherry** — équipe **Data Science & Data Engineering d'Anthropic**. Article publié le **3 juin 2026** sur le blog Anthropic (claude.com/blog) · catégorie *Enterprise AI* · ~5 min de lecture.
Entrada de blog de **Anthropic / claude.com** por **Thariq Shihipar** (Member of Technical Staff, equipo Claude Code), publicada el **3 de junio de 2026**, que destila la **experiencia interna** de Anthropic sobre el diseño y uso de las **Skills**. **Tesis de encuadre**: una Skill no es un simple archivo markdown sino una **carpeta** (instrucciones + scripts + recursos + configuración + hooks) que el agente **descubre y manipula**; *« You should think of the entire file system as a form of context engineering and progressive disclosure. »* El artículo aporta dos contribuciones estructurantes. **(A) Una taxonomía de 9 categorías de skills** observadas en Anthropic: (1) **Library/API Reference** (documentación de libs/CLIs internas con *gotchas* — p. ej. `billing-lib`, `internal-platform-cli`, `sandbox-proxy`); (2) **Product Verification** (pruebas/verificación mediante Playwright o tmux — `signup-flow-driver`, `checkout-verifier`, `tmux-cli-driver`); (3) **Data Fetching & Analysis** (acceso a stacks de datos/monitorización — `funnel-query`, `cohort-compare`, `grafana`, `datadog`); (4) **Business Process Automation** (flujos de trabajo repetitivos — `standup-post`, `weekly-recap`, `create-<ticket>-ticket`); (5) **Code Scaffolding** (boilerplate de frameworks — `new-migration`, `create-app`); (6) **Code Quality & Review** (`adversarial-review`, `code-style`, `testing-practices`); (7) **CI/CD & Deployment** (`babysit-pr`, `deploy-<service>`, `cherry-pick-prod`); (8) **Runbooks** (diagnósticos multi-herramienta — `<service>-debugging`, `oncall-runner`, `log-correlator`); (9) **Infrastructure Operations** (mantenimiento con salvaguardas — `<resource>-orphans`, `cost-investigation`). **(B) Un conjunto de buenas prácticas**: no repetir lo obvio (*« Claude already knows how to code and can read your codebase »* → apuntar a lo que **contradice el comportamiento por defecto**); pulir la **sección Gotchas** (*« the highest-signal content in any skill »*); **divulgación progresiva** a través del árbol de archivos (dirigir hacia archivos de referencia según la situación en lugar de cargar todo por adelantado); **descripciones escritas para el modelo** (*« the description field is not a summary, it's a description of when to trigger this skill »*); **flujos de configuración** (config en `config.json`, o en su defecto preguntar vía `AskUserQuestion`); **memoria persistente** (logs append-only / JSON mediante la variable `${CLAUDE_PLUGIN_DATA}`); **scripts auxiliares** (*« lets Claude spend its turns on composition… rather than reconstructing boilerplate »*); **hooks conditionnels** (habilitados solo durante la skill — p. ej. un hook de seguridad que bloquea comandos destructivos). **Distribución en Anthropic**: las skills se almacenan en `./.claude/skills`, se comparten de forma informal vía Slack en una carpeta sandbox, y luego se promueven mediante **PR** al **marketplace** interno una vez que ganan tracción; **medición de uso** mediante un **hook PreToolUse** que registra las invocaciones (revelando las skills populares frente a las infrautilizadas). Continuación directa de la fiche [[shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10]] (mismo autor) y complemento concreto a las fiches sobre Skills de Anthropic/Willison/Vincent y al *harness engineering*.
#skills#Claude Code#Anthropic
**Thariq Shihipar** (Member of Technical Staff chez Anthropic, équipe **Claude Code** ; @trq212 / @trq sur X, thariqs.github.io) · pour le blog **claude.com**. Même auteur que la fiche *Using Claude Code: The Unreasonable Effectiveness of HTML* (2026-05-10). Publié le **3 juin 2026**.
Guía del medio **Every** (every.to/guides) publicada el **2 de junio de 2026**, firmada conjuntamente por **Mike Taylor, Laura Entis y Claude**, que propone una **escala de madurez de 8 niveles para la adopción de IA**. **Tesis central**: la adopción de la IA **no es una carrera hacia la máxima sofisticación** — ***« un nivel más alto no es necesariamente mejor »*** ; hay que identificar el nivel que **se ajusta al propio flujo de trabajo y nivel de confianza**, y luego reevaluar regularmente si subir un escalón aporta **valor real**. ***« La mejor manera de encontrar valor en la IA es usarla de una forma que encaje con tu trabajo. »*** **Eje estructurante**: en cada nivel, *« delegas más de tu trabajo en la IA, y depositas más confianza en ella »* (delegación + confianza crecientes). **Los 8 niveles**: **(1) Chatbot** — interfaz conversacional sin contexto integrado (ChatGPT, Claude, Gemini); **(2) Copilot** — IA integrada en el espacio de trabajo con acceso al archivo actual (Cursor, Claude en Excel, Gemini en Docs); **(3) Agent** — sistema reactivo que ejecuta paso a paso solicitando aprobación (Cowork, Codex); **(4) Autopilot** — se describe el **resultado** y el agente ejecuta de forma autónoma, revisión únicamente del **resultado final** (Lovable, Codex, Claude Code; vinculado al *vibe coding*); **(5) Workflows** — ingenieros que construyen **harnesses** en torno a los agentes (planificación, revisión, verificaciones de confianza, salvaguardas; Compound engineering, Claude Workflows, Copilot AI Studio; paso del vibe coding puntual → **agentic engineering**); **(6) Assistant** — agentes **proactivos y siempre activos** que monitorizan un dominio y presentan información sin que se les solicite (OpenClaw, Hermes Agent, Claude Managed Agents; p. ej. `heartbeat.md` cada 30 minutos); **(7) Multi-agent** — gestión simultánea de **varios agentes de larga duración** con roles distintos (Claude Managed Agents, OpenClaw, Codex Goals; *« firmemente en el terreno de la ingeniería senior »*); **(8) Orchestrator** — un **gestor de agentes** dirige un equipo de subagentes (planificación, delegación, monitorización, consolidación; Gas Town, Paperclip, Symphony/OpenAI; *« altamente experimental »* — incluso los propios ingenieros de vanguardia ocupan este rol). **Puntos óptimos por rol**: los **trabajadores del conocimiento** suelen operar entre los niveles **1-4**, los **ingenieros** entre **5-8**. **Paralelismo canónico con la incorporación de un becario**: *« Espera invertir un esfuerzo similar con tus agentes antes de poder confiar en ellos… en el siguiente nivel de autonomía »* ; y la frase marcadora ***« No presumirías de tener ocho becarios trabajando toda la noche en un proyecto clave sin haber revisado su trabajo. »*** El nivel adecuado depende de **4 criterios**: calidad del resultado, coste, fiabilidad (confianza), riesgo en caso de fallo; y la **capacidad del modelo** desplaza progresivamente el nivel de autonomía "seguro". Un marco directamente utilizable para estructurar una **doctrina de adopción** en el ámbito de la consultoría. Convergencia con *los sistemas alrededor del modelo* (Dropbox/Okumura), la *harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines), y la doctrina del *agent manager* (BFM/Girard).
#adopción de IA#escala de madurez#ocho niveles
**Mike Taylor** · **Laura Entis** et **Claude** (co-auteurs déclarés) · pour **Every** (every.to) · rubrique *Guides*. Mike Taylor est un auteur connu sur les sujets prompt/AI (co-auteur de *Prompt Engineering for Generative AI*) ; Laura Entis est journaliste/éditrice. La co-signature explicite de **Claude** comme auteur fait partie du positionnement éditorial d'Every (entreprise AI-native). Publié le **2 juin 2026**.
Tribuna de opinión de **Olivier Rafal** (Director de Consultoría Estrategia, **WeNvision** — grupo **SFEIR**; exredactor jefe de *Le Monde Informatique*) publicada el **1 de junio de 2026** en **CIO-Online**, estructurada en torno a una **paradoja**: en la era de la IA, la ingeniería de software **lo cambia todo… y no cambia nada**. **Lo que cambia es el modelo operativo.** Los roles se redefinen: el **Product Owner** pasa de la descomposición del backlog a **generar contexto utilizable por la IA**; el **desarrollador** pasa de escribir código a **enmarcar, dirigir y revisar** la ejecución de los agentes; el **QA** adquiere la capacidad de definir de antemano la **prueba esperada**. La estructura de los equipos pasa de los *"double pizza teams"* (cadenas de traspaso de ~8 personas) a los ***"sandwich teams"***: un **binomio estrecho formado por un experto de negocio y un tech lead, ambos potenciados por IA**, con otras competencias en apoyo. Cifra interna de **Sfeir**: *"este binomio impulsa ahora aproximadamente el 80% de la cadena de producción"*, quedando el ~20% restante (arquitectura, gobernanza de datos, seguridad) centralizado. Cita pivote: ***"El problema no es un problema de herramientas, es un problema de modelo operativo."*** **Lo que no cambia es la disciplina del ciclo.** Las fases del **SDLC** (definir → construir → verificar → desplegar → mantener) permanecen idénticas y no negociables; la IA no elimina ninguna, las **intensifica**: ***"todo el margen que el ritmo humano solía absorber, aunque fuera de forma imperfecta, se convierte, a la velocidad de la IA, en defectos de nivel industrial"*** (una metáfora del deporte amateur frente al profesional). De ahí **tres *gates* inviolables** (control humano): **especificación, planificación, revisión de entrega**; validación **por prueba** (no por las propias afirmaciones de la IA); **capitalización sistemática** (cada ciclo alimenta al siguiente) → resultado medido: **−30% de iteraciones de corrección tras ~10 ciclos**. Principio: ***"cuanto más rápida la ejecución, más estricto debe ser el marco."*** Conceptos invocados: el **harness** (reglas agénticas adaptadas al contexto), el **vibe-coding** calificado de **insostenible en la empresa**. **Tercer pilar = gobernanza, FinOps y gestión orientada al valor**: costes de IA **variables y recurrentes** (~**10 €/hora** por rol potenciado), paso de la licencia a tarifa plana a la facturación por uso (un paralelismo con la nube de la década de 2010); el **FinOps** no busca recortar costes sino *"optimizar la eficiencia de las herramientas"* (coste en relación con el valor); alineación previa de las **métricas de negocio** (time-to-market, funcionalidades, rendimiento, ecodiseño). **Conclusión**: la aceleración hace que los fundamentos sean **no negociables**; el reto es **organizativo y cultural**, no tecnológico — sin asegurar la relación con el negocio y la disciplina colectiva, un SDLC potenciado por IA no hace más que **amplificar los problemas** (chocar contra el muro más rápido). Prolonga la doctrina de WeNvision de [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] y [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]]; converge con *los sistemas alrededor del modelo* dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28, la *harness engineering* osmani-agent-harness-engineering-2026-04-19, el Salesforce agéntico, y el debate sobre el *agent manager* (BFM/Girard, SFEIR).
#ingeniería de software#IA#todo cambia nada cambia
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (groupe **SFEIR**). Ancien **rédacteur en chef du *Monde Informatique*** · et auparavant consultant analyste du marché IT (~10 ans). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Publié le **1er juin 2026**.
Publicación del **blog Dropbox Tech** (sección *culture*), publicada el **28 de mayo de 2026** por **Kazuaki Okumura** (Dropbox, rol no especificado en el artículo), que recapitula una charla en la conferencia **DX Annual 2026** (productividad de desarrollo). **Tesis central**: la productividad de ingeniería debe ir más allá de la *generación de código*. *« Acelerar la generación de código simplemente desplazó algunos cuellos de botella aguas abajo »* — la IA ha aumentado masivamente el rendimiento de código, pero *« cuanto más rápido se mueve el código, más presión ejerce sobre las colas de revisión, los sistemas de CI, los flujos de validación, la coordinación de releases y las operaciones de producción »*. El verdadero desafío ya no es escribir código más rápido, sino permitir que todo el SDLC **absorba, valide y despliegue de forma segura** un volumen mucho mayor. **De copiloto a agente**: la primera ola (explicación de código, snippets, preguntas y respuestas) operaba *« como copilotos junto al ingeniero »*; el agente, en cambio, *« puede tomar una tarea acotada, inspeccionar la base de código, editar archivos, ejecutar pruebas, iterar sobre fallos y devolver un artefacto para revisión humana »* — con el ingeniero permaneciendo *« responsable de la intención, la arquitectura, la calidad y las decisiones de release »* (más trabajo en paralelo, más opciones, delegación de la ejecución repetitiva). **Nova** = la plataforma **interna** de agente de codificación de Dropbox: describir una tarea en lenguaje natural, ejecución en un entorno controlado con contexto de la base de código. Dato canónico: ***« el valor de Nova proviene menos del propio modelo que de los sistemas que lo rodean »*** (contexto de la base de código, prácticas internas, ejecución segura, integración en el flujo de trabajo, revisión humana); Nova representa hoy **aproximadamente 1 de cada 12 PR en Dropbox** (adopción creciente), y se extiende más allá de las funcionalidades a **migraciones, corrección de tests inestables (flaky), investigación de errores, actualizaciones de dependencias** (trabajo de alto desgaste). **Medir la velocidad del producto, no la producción de código**: el *rendimiento de PR*, una señal útil cuando la velocidad de codificación era la limitación, *« ya no era suficiente »*. Un modelo de medición en **4 etapas**: ***Fuel*** (¿se están usando las herramientas de IA?) → ***Adoption*** (cómo están cambiando los flujos de trabajo en los equipos) → ***Output*** (¿la IA contribuye al trabajo de producción?) → ***Impact*** (*« mejorar la velocidad del producto y reducir el tiempo que se tarda en pasar de la idea al valor para el cliente »*). Señales de calidad monitorizadas: **tiempo de resolución de revisión de código, tasa de éxito de pruebas en la primera ejecución, tasa de defectos, tasa de retrabajo**. *« La calidad y la confianza importan tanto como la velocidad »* — el núcleo del cambio: *« pasar de métricas de actividad local hacia resultados de sistema más amplios »*. **Los flujos de trabajo también deben evolucionar**: esto no es *« solo un cambio de herramientas »* sino un cambio de **modelo operativo** — el rol del ingeniero se desplaza hacia *« definir la intención, mapear los problemas, revisar los cambios generados y tomar decisiones arquitectónicas y de calidad de mayor contexto »*. La **capacitación** (enablement) es tan crucial como la propia herramienta (aprendizaje práctico, hackathons, workflow spotlights, bootcamps, ejemplos liderados por pares); la adopción avanza a ritmos variables según los equipos; *« el objetivo no es forzar cada flujo de trabajo a través de un agente »* — el objetivo es hacerlo *« útil, seguro, medible y repetible allí donde genera un apalancamiento significativo »*. **Lo que aprendimos**: ***« la IA no elimina los cuellos de botella en el desarrollo de software, pero sí los desplaza »*** (aguas abajo: revisión, validación, pruebas, release, operaciones de producción) → optimizar el antiguo cuello de botella ya no genera el mismo apalancamiento. *« La ventaja no vendrá del acceso a los mismos modelos fundacionales que todos pueden usar. Vendrá de los sistemas construidos alrededor de esos modelos: contexto, herramientas internas, controles de calidad y los flujos de trabajo que los conectan. »* La presión también se acumula **aguas arriba** (producto y diseño): especificaciones estructuradas, claridad de diseño, un planteamiento más preciso de los problemas. Cierre: ***« el futuro de la productividad de ingeniería no estará definido únicamente por quién tiene los mejores modelos. Estará definido por quién construye los mejores sistemas alrededor de ellos »***; *« el verdadero desafío ya no es solo generar más código, sino construir sistemas de ingeniería que puedan convertir de forma fiable la producción asistida por IA en experiencias valiosas para nuestros clientes »*. Convergencia directa con **Salesforce/Tallapragada** (Effective Output: medir el valor, no el volumen; sin compensación velocidad/calidad), **Gupta** (atribución de token a resultado, coste de un resultado completado), **DORA** (más allá del rendimiento), y el desplazamiento del KPI hacia el **resultado de sistema** (idea→valor para el cliente).
#productividad de ingeniería#productividad de ingeniería#más allá de la generación de código
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.
Entrada oficial del blog **Salesforce News** (sección *Agentic Enterprise*, serie *"Pioneering the Agentic Shift Within Salesforce Engineering"*), publicada el **27 de mayo de 2026** (lectura de 6 minutos) por **Srinivas "Srini" Tallapragada**, *President and Chief Engineering and Customer Success Officer* en Salesforce. Continuación directa de una entrada anterior (*"How we got our engineers to use AI — without breaking everything"*) que relataba haber superado el **>90% de adopción**. **Tesis del giro**: Salesforce Engineering pasó de un mundo en el que la IA era un *copiloto* útil a otro en el que **las herramientas agénticas impulsan el propio ciclo de vida de desarrollo de software (SDLC)** — escribiendo código, revisando PRs, generando tests, actualizando documentación, gestionando despliegues, coordinando trabajo antes gestionado mediante traspasos humanos. **Decisión señal canónica**: estandarización a escala de la organización en **Claude Code** + ***"eliminamos todos los límites de tokens"*** — *"eliminar hasta el último resquicio de fricción entre nuestros ingenieros y las herramientas que los hacen más rápidos y más eficaces"*. **Resultado empírico mayor** (abril 2026 frente a abril 2025): elementos de trabajo completados por desarrollador **+50,8%**, PRs fusionadas por desarrollador **+79%**, y sobre todo la puntuación de **Effective Output** (una medida de ML del **valor real del código entregado**, no del volumen) **+151,3% interanual**. **Caso de uso emblemático**: migración de **33 endpoints de API** a una arquitectura cloud-native, estimada en **~231 persona-días** (7 por API) de forma tradicional, completada en **13 días — 18 veces más rápido** — mediante un **marco basado en reglas construido en Claude** (archivos markdown + implementaciones de referencia), con el feedback de las PRs realimentando continuamente el conjunto de reglas, **bucles LLM autónomos (build, fix, validate)** sin intervención manual, paralelizados en entornos aislados → **5 PRs**, la mayor de las cuales entregó **21 endpoints con 100% de cobertura de tests**. **Sin compromiso velocidad↔calidad**: a través de la plataforma **Engineering 360** (que centraliza datos de ingeniería de cientos de sistemas), **los incidentes totales caen un 5%** pese al aumento de PRs (*"la calidad no sufre por la velocidad. Se beneficia de ella"*), gracias a **barreras de seguridad y estándares de calidad estructuralmente integrados** en el flujo de trabajo agéntico (Trust como valor n.º 1). **Revisión del SDLC**: una vez adoptada la IA, los ingenieros **desmontan y reconstruyen** los flujos de trabajo (¿qué procesos eliminar? ¿qué traspasos ya son innecesarios? ¿dónde sigue un humano haciendo un trabajo que podría asumir un agente?). **Nuevo oficio de ingeniería**: las **skills de Claude Code** (capacidades empaquetadas y reutilizables que codifican el contexto del equipo, las convenciones de nomenclatura, los patrones) se convierten en un **artefacto de ingeniería** compartido y componible; **AI Expert Suite** + **Salesforce Foundation Plugins** = una biblioteca de skills institucionalizada y curada (benchmark interno: **mayor precisión y fiabilidad, coste innecesario reducido**); los **subagentes y equipos de agentes** paralelizan los flujos de trabajo (*"Describen el resultado, y un conjunto de agentes coordinados averigua los pasos"*). **Lo que sigue siendo difícil**: (1) la **gestión del contexto** en sesiones largas — la **calidad del archivo CLAUDE.md** varía mucho y pesa fuertemente en la calidad del resultado; (2) la **seguridad agéntica** = un modelo fundamentalmente distinto (agentes que *actúan*, no solo *sugieren* → mayor radio de impacto); (3) **roles en evolución** (¿cómo pasan los junior a senior si la IA absorbe el trabajo de nivel inicial? ¿papel del diseñador/PM? la unidad de ejecución = equipo scrum → experimentos con unidades de 1 o 3 personas). Conclusión: *"Cambió lo que era económicamente posible"*; la ambición declarada es **"el SDLC agéntico más automatizado del sector"**. Se cruza directamente con Gupta (*coste de un resultado completado*, utilidad marginal del token), Greenwald/Sierra (precios basados en resultados), DORA (ROI / coste por funcionalidad) y el debate BFM/Girard (el token como combustible de valor, no como coste a recortar).
#SDLC agéntico#sdlc agéntico#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
Entrada del blog de **Zed** firmada por **Franciska Dethlefsen** (responsable de crecimiento y marketing), publicada el **14 de mayo de 2026** —al día siguiente del anuncio de Anthropic— para responder a las preguntas de los usuarios de Zed. **Tema**: a partir del **15 de junio**, Anthropic **divide la facturación de las suscripciones Claude en dos grupos**: uno para sus **herramientas propias** (chat, la CLI oficial de **Claude Code**), el otro para el **uso de agentes y SDK de terceros** (todo lo que pase por **ACP**, `claude -p` o una herramienta de terceros). El uso vía ACP **deja entonces de consumir los límites de Pro o Max** y pasa a un **crédito mensual «Agent SDK»**: **20 $ para Pro, 100 $ para Max 5x, 200 $ para Max 20x**. Una vez agotado el crédito, el uso continúa **a precios estándar de la API** si el excedente («overage») está habilitado; en caso contrario, las solicitudes se detienen hasta el siguiente ciclo. **La cifra que sostiene el artículo**: hasta entonces, las suscripciones habían subvencionado el uso agéntico en un factor de **≈15 a 30×** respecto al precio de la API, y los nuevos créditos se facturan **a las tarifas completas de la API**; de ahí que *«para quien use agentes intensivamente, esto supone un aumento de costo importante»*. **Se proponen tres opciones**, en un orden que revela la posición de Zed: (1) conservar la suscripción ejecutando la **CLI oficial `claude` en una terminal dentro de Zed** en lugar de vía ACP —*«cuando la CLI oficial de claude se ejecuta en la terminal, usa los límites de tu suscripción, no el nuevo crédito»*—; (2) usar el agente integrado de Zed con el proveedor que se prefiera (modelos alojados por Zed, claves de API, Copilot, Ollama local, DeepSeek); (3) conectar **cualquier agente ACP** —OpenCode, Codex, Factory, Cursor—, varios de los cuales aún ofrecen suscripciones con límites de tasa que subvencionan el uso intensivo. **La tesis de fondo**, y la verdadera razón de la entrada: *«ACP es un protocolo abierto… para que tu editor nunca quede atado a las decisiones de precios de un solo proveedor»*, con la anticipación explícita de que *«este tipo de cambio no será el último»*. **La entrada incluye un anexo fechado el 16 de junio de 2026** que anuncia que **el cambio queda suspendido**: ACP, `claude -p`, el Agent SDK y las aplicaciones de terceros siguen funcionando con las suscripciones **como antes**, sin crédito separado que reclamar, límites sin cambios, con Anthropic revisando su plan con un aviso previo anunciado. **El artefacto se contradice así a sí mismo**: su contenido más importante —la marcha atrás— es posterior en un mes a su propia fecha de publicación.
#Zed#Anthropic#suscripción Claude
**Franciska Dethlefsen** — head of growth and marketing chez **Zed Industries**. Le rôle est déterminant pour lire le texte : ce n'est pas un billet d'ingénierie mais une **communication de crise produit** · écrite le lendemain d'une annonce d'un fournisseur dont Zed dépend · à destination d'utilisateurs inquiets. La signature growth/marketing explique la structure (problème → options → réassurance) et le fait que l'argument protocolaire arrive en conclusion plutôt qu'en tête.
Continuous Delivery como base innegociable del desarrollo asistido por IA — Dave Farley, en su canal *Modern Software Engineering*, sostiene que sin CD la IA no es un acelerador sino una trampa (teoría de las restricciones y paradoja de Jevons aplicadas al código generado, ATDD/BDD como salvaguarda, pipeline de despliegue como árbitro de calidad).
#Continuous Delivery#IA generativa en el SDLC#ATDD (Acceptance Test-Driven Development)
Dave Farley (Modern Software Engineering — YouTube channel)
Artículo de estilo manifiesto de **Thariq Shihipar** (Ingeniero y emprendedor serial, equipo de Claude Code en Anthropic) que anuncia un **cambio en el formato de salida por defecto para agentes**: sustituir **Markdown por HTML**. Tesis: Markdown ha sido el formato dominante entre humanos y agentes (simple, portátil, editable, legible), pero se ha convertido en **un cuello de botella** a medida que los agentes producen artefactos más largos y ricos (specs, planes, informes, revisión de código). Más allá de ~100 líneas, nadie vuelve a leer ya un archivo Markdown. HTML resuelve seis limitaciones a la vez: **densidad de información** (tablas, CSS, SVG, scripts, canvas, imágenes), **claridad visual** (diseño navegable, responsive para móvil), **facilidad para compartir** (un enlace S3 abrible directamente en un navegador), **interactividad bidireccional** (sliders, mandos, botones "copy as JSON/prompt" para reinyectar en Claude Code), **ingesta contextual nativa** (Claude Code lee el codebase + MCP Slack/Linear + historial git + Chrome) y **disfrute** (el autor afirma explícitamente que *"es placentero"*). Se detallan cinco usos canónicos: (1) **specs/planes/exploración** en una cuadrícula comparativa, (2) **revisión de PR** con diff anotado en línea, (3) **diseño y prototipos** con sliders de animación, (4) **informes/investigación/aprendizaje** (el autor generó un explicador sobre prompt-caching a partir del historial git), (5) **editores desechables a medida** (drag-and-drop de tickets de Linear, editores de feature flags, prompt-tuner lado a lado) que producen una exportación reinyectable "copy as markdown/diff/JSON". Antipatrón explícito: *"me da un poco de miedo que la gente lea este artículo y lo convierta en una skill /html"* — el autor **rechaza la skill-ificación prematura**, y recomienda partir de un prompt desde cero ("haz un archivo HTML"). FAQ pragmática: coste en tokens absorbido por el contexto de 1MM de **Opus 4.7**, generación 2-4× más lenta, diffs HTML ruidosos (un inconveniente real), estilo mantenido bajo control mediante un design system HTML de referencia.
#HTML#Markdown#formato de salida
Thariq Shihipar (Engineer & serial entrepreneur, équipe Claude Code chez Anthropic — site : thariqs.github.io/html-effectiveness ; X : @trq212)
Editorial de Andrew Ng en The Batch n°352 del 8 de mayo de 2026 — **"There Will Be No AI Jobpocalypse"** — que desmonta el relato del desempleo masivo causado por la IA, apoyándose en la **saludable tasa del 4,3%** de desempleo en EE. UU. y en una contratación tecnológica sólida. Ng identifica **tres motores** del relato del jobpocalypse: **(1) incentivos tecnológicos** — los laboratorios de IA se benefician de presentarse como transformadores-disruptivos (rondas de financiación, valoraciones, talento); **(2) poder de fijación de precios** — los proveedores cobran **10.000+ $/año** a clientes empresariales **anclando su precio al salario del empleado sustituido**, en lugar de a la tarificación SaaS tradicional (por puesto / por uso); **(3) mensajes corporativos** — las empresas reformulan sus despidos como *"eficiencia por IA"* en lugar de reconocer la **contratación excesiva de la era pandémica** de 2020-2022. Reconocimiento honesto: *"la IA perturba el trabajo"*. Pero Ng invierte esto en **"AI jobapalooza"** (un juego de palabras con Lollapalooza) — creación de empleo en ingeniería de IA y campos adyacentes con conjuntos de competencias en evolución. Tensión implícita con **Amodei** (50% de los empleos de cuello blanco eliminados de aquí a 2030) — Ng señala, sin nombrarlo, que **Anthropic se beneficia de promover este relato** (incentivos tecnológicos). Publicado **el mismo día** que el artículo de **Wallace-Wells, "AI Populism", en NYT Magazine**: una lectura en espejo perfecta — Ng = análisis económico frío / Wallace-Wells = pánico popular. Convergencia sobre el poder de fijación de precios con **"$100B cross-system labor" de Bain** (misma tesis: precios anclados en los salarios).
#Andrew Ng#The Batch#DeepLearning.AI
Andrew Ng (fondateur DeepLearning.AI, Stanford, ex-Google Brain, ex-Baidu, ex-Coursera)
Podcast de Greg Isenberg × Meng To (diseñador, fundador de Design+Code, creador de los productos Aura / New Form / Dream Cut) sobre **`design.md`** — la convención de código abierto de Google, equivalente a `agents.md` / `skills.md` / `soul.md` pero **para el sistema de diseño** (tipografía, colores, espaciado, animaciones WebGL/Three.js, reglas de revelado). Idea central: transportar el "**alma del diseño**" en un archivo markdown que se entrega a un agente (Claude Code, Codex, OpenClaude, Gemini, Stitch, Aura, V0, Lovable, Cursor) para preservar la **coherencia entre medios** (web, móvil, Replit slides, motion design con Hyperframes/Remotion). Tríada enseñada: **HTML = plato terminado, design.md = receta, skills = ingredientes** (tipografía, láseres, skeuomorphic, skills 3D — 63 en New Form). Diagnóstico principal: **design drift** en los flujos one-shot (`v0`, Lovable, Framer) que empiezan fuerte y luego derivan hacia una salida genérica. Metamensaje: el *gusto* (taste) es el único **moat** que queda — *"si algo se parece a otra cosa, su valor cae de 10× a 100×"*. Flujo de trabajo: **Reference → Design.md → Generate → Inspect → Systemize → Iterate (hasta más de 1000 prompts) → Remix → Expand → Export**. Crítica de los **gradientes morados** ("you just run") como la base genérica post-vibe coding. Meng To afirma haber gastado ~500.000 $ en tokens, haber ejecutado entre 1.000 y 10.000 iteraciones por producto, y haber gestionado 4 productos en paralelo en solitario.
#design.md#Google#sistema de diseño
Greg Isenberg (host — podcast Late Checkout / The Greg Isenberg Show, 12 mai 2026 livestream workshop ideabrowser.com) ; **Meng To** (guest — designer, fondateur Design+Code 2014, créateur Aura / New Form / Dream Cut, autodidacte parti à 18 ans, dropout, francophone d'origine canadienne)
Entrevista con Boris Cherny (creador de Claude Code, Anthropic) en un evento de Sequoia (presentadoras: Asia, Lauren Reader). Cherny afirma ***"coding is solved"***: él mismo no ha escrito **0 líneas de código** desde finales de 2025, el modelo escribe **100%**, *"unos cuantos docenas de PRs/día, récord de 150 PRs en un solo día"*. Relato de la génesis de Claude Code (incubadora Anthropic Labs, finales de 2024, Mike Krieger a cargo de la ronda 2, desarrollo pre-PMF *"para el próximo modelo"*, un primer lanzamiento que no despegó, **crecimiento exponencial iniciado con Opus 4 en mayo de 2025**, acelerándose con cada nuevo modelo 4 → 4.5 → 4.6 → 4.7). Configuración personal actual: **"la mayor parte de mi trabajo lo hago desde el móvil"** (iOS), 5-10 sesiones, **"unos cientos de agentes en marcha, unos miles por la noche"**, **`/loop` es el futuro** (cron + trabajos repetidos, agentes vigilando la CI, haciendo rebase de PRs, agrupando el feedback de Twitter). **Routines** = el equivalente del lado servidor, funcionando con el portátil cerrado. Perspectiva SaaS: sin apocalipsis, pero una **reorganización del marco de las 7 Powers de Helmer** (costes de cambio ↓, poder de proceso ↓, efectos de red/economías de escala/recursos acaparados sin cambios) y **10 veces más startups disruptivas** en los próximos 10 años. Analogía del giro: la **imprenta de Gutenberg** (10% de alfabetización en el siglo XV → 70% en los siglos siguientes, libros 100 veces más baratos en 50 años), *"el software se democratizará de forma similar, pero más rápido que en 50 años"* — *"la mejor persona para escribir software de contabilidad no es un ingeniero, es un muy buen contable."*
#Boris Cherny#Anthropic#Claude Code
Boris Cherny (créateur de Claude Code, Anthropic) interviewé par Lauren Reader (Sequoia) avec introduction d'Asia (Sequoia).
Repositorio de GitHub `techygarg/lattice` que formaliza un framework de **skills componibles** para instalar una *disciplina de ingeniería* en asistentes de codificación con IA (Claude Code, Cursor). Arquitectura distintiva de tres niveles: **Atoms** (guardarraíles de principio único: código limpio, DDD, seguridad, calidad de tests, design-first), **Molecules** (flujos de trabajo multietapa que componen los atoms: diseño, implementación, refactorización, corrección, revisión), **Refiners** (entrevistas guiadas que producen estándares específicos del proyecto que personalizan el comportamiento de los atoms). Pipeline operativo `lattice-init` → `design-blueprint` → `code-forge` → `review`, con `refactor-safely` y `bug-fix` como derivaciones. Tres principios centrales: *"Skills over prompts"*, *"Composability over monoliths"*, ***"Living context over static config"*** — la carpeta `.lattice/` se vuelve más inteligente con cada ciclo de funcionalidades. MIT, shell puro, 18 stars / 52 commits, una serie de artículos en martinfowler.com que explican cinco *patrones de colaboración*. Fuerte convergencia con Vincent *Superpowers* (2026-04-02), Habert *PROJ-AI* (2026-05-05), Wescale *Usine Logicielle Augmentée* (2026-05-03) y — la convergencia doctrinal más alta sin linaje declarado — **Compound Engineering** de Every (Shipper/Klaassen 2025-12-11): pipelines isomórficos (lattice-init→design-blueprint→code-forge→review ↔ ce:brainstorm→ce:plan→ce:work→ce:review), capa de contexto vivo (`.lattice/` ↔ `docs/plans/+solutions/+brainstorms/`), una postura compartida de design-first, revisión obligatoria al final. La doctrina de *coding agent harness* de 2026 converge en un vocabulario estable, sin influencia directa.
#lattice#techygarg#composable AI skills
techygarg (auteur GitHub, identité réelle non précisée dans le README ; auteur d'une série d'articles publiée sur martinfowler.com).
Whitepaper de Google (la entrega "Day 1" de una serie, de Addy Osmani, Shubham Saboo y Sokratis Kartakis) que traza la transformación del ciclo de vida del desarrollo de software (SDLC) en la era de los agentes de codificación. Tesis: el cambio fundamental no es un nuevo lenguaje, sino el paso de escribir código a **expresar intención**. El documento plantea un espectro que va del *vibe coding* (proponer y aceptar) a la *agentic engineering* (la IA implementa bajo restricciones, pruebas y bucles de retroalimentación diseñados por humanos), con la **context engineering** como habilidad central, el modelo de **software factory** (el entregable del desarrollador = el sistema que produce el código), la **harness engineering** (Agente = Modelo + Harness), y un análisis económico CapEx/OpEx del coste total de propiedad.
Entrevista con Andrej Karpathy (cofundador de OpenAI, ex Tesla Autopilot) sobre el paso de *vibe coding* a *agentic engineering*: December 2025 transition como punto de inflexión ("nunca se sintió más rezagado como programador"), la taxonomía Software 1.0/2.0/3.0, el ejemplo openclaw (script bash → texto para copiar y pegar en el agente) y MenuGen vuelto obsoleto por Nanobanana de Gemini, la teoría de la *verifiability* que explica por qué los LLM son *jagged* (picos en matemáticas/código, fallo al "caminar a un lavadero de coches a 50 m"), la distinción entre *vibe coding* (elevar el piso) y *agentic engineering* (preservar el estándar de calidad), la metáfora "animales vs fantasmas", la refundación de la contratación mediante proyectos agente contra agente, y la fórmula clave: ***"Puedes externalizar tu pensamiento pero no puedes externalizar tu comprensión."***
#Andrej Karpathy#vibe coding#agentic engineering
Andrej Karpathy (co-fondateur OpenAI, ex-Tesla Autopilot, créateur du terme "vibe coding")
Hilo de X en formato manifiesto de Rohit (@rohit4verse) que expone la *2026 AI engineer roadmap*: una brecha de 150.000 $ entre el prompt engineer y el systems architect, el fin de los *wrappers genéricos* «sherlocked por las grandes tecnológicas», y 5 proyectos de portafolio clasificados por nivel de complejidad (SLM móvil offline, agente de codificación autoperfectible, *Cursor for video editors* multimodal, agente de sistema operativo de vida personal centrado en la privacidad, agente autónomo de flujos de trabajo empresariales). Cada proyecto describe sus *decisiones arquitectónicas clave* (lazy loading, sliding window, sandboxing, detección de escenas, grafo de conocimiento personal, multiagente basado en eventos, registro de auditoría, RBAC, observabilidad). Eslogan estructurante: *«lo reemplazable: construir wrappers / lo indespedible: desplegar sistemas autónomos»*. Tono imperativo y viral, típico de X en 2026.
#2026 AI engineer roadmap#Rohit#rohit4verse
Rohit (@rohit4verse) — créateur de contenu IA sur X · vulgarisateur d'architecture et roadmaps de carrière en ingénierie IA.
Publicación del **blog de Ahrefs** publicada el **28 de abril de 2026** por **Ryan Law** (Director of Content Marketing, Ahrefs) que describe un sistema interno de **ingeniería de contenido** construido en torno a **Claude Code**: un pipeline editorial que produce **borradores listos para publicar en 6 a 12 minutos**. **Tesis central**: ***« El contenido de IA no es, por defecto, bueno. Este proceso funciona bien porque refleja nuestro proceso editorial humano existente »*** — la calidad no proviene del modelo sino de la **reproducción fiel de un proceso editorial humano** probado durante décadas. Arquitectura: **~23 skill files**, cada uno correspondiente a una etapa editorial (investigación de palabras clave, análisis de brechas temáticas, esquematización estructural, compilación de investigación, generación de borradores, formateo), **orquestados por una skill maestra `blog-pipeline`** que los encadena para producir un artículo completo. **Siete principios de diseño**: (1) **imitar los flujos de trabajo humanos** encadenando skills adaptadas de la documentación editorial existente de Ahrefs; (2) **generar cada etapa por separado** para facilitar el diagnóstico (*« si al final de una ejecución de diez minutos obtienes un artículo malo, es difícil diagnosticar con precisión dónde y por qué falló el proceso »* → guardar las salidas intermedias); (3) **crear casos de prueba** mediante la skill `skill-creator` de Anthropic para evaluar y mejorar las instrucciones; (4) **conectar fuentes de datos de calidad** — el **Ahrefs MCP** (métricas de palabras clave, parent topic, temas de cola larga, resúmenes de SERP, análisis competitivo), análisis competitivo y documentación de producto; (5) **anticipar la dirección humana** mediante parámetros de contexto que permiten orientación editorial; (6) **construir vistas previas interactivas** en formato HTML para su revisión antes de la publicación; (7) **permitir la personalización** (cada miembro del equipo puede hacer un fork del sistema y modificarlo). **Volumen**: ~**15 artículos publicados** y ~**30 artículos actualizados** mediante este flujo de trabajo; el desarrollo comenzó en **febrero de 2026** (el proceso anterior, de **agosto de 2025**, requería varios días e intervención manual). **Advertencias explícitas** (anti-sobreventa): *« la experiencia importa »* — el proceso refleja décadas de experiencia editorial; la selección de temas se centra en **contenido SEO informacional** que el autor conoce bien; Ahrefs **no tiene previsto "escalar" el contenido de forma masiva**, sino que mantiene una **biblioteca evergreen**. Filosofía: automatizar *« las partes formulaicas del trabajo »* para eliminar las tareas tediosas y liberar tiempo para la investigación, el liderazgo de pensamiento, los webinars y la optimización del sistema — **no** reemplazar el esfuerzo humano. Referencia canónica citada por Pasquale Pillitteri (*Opus 4.8 SEO workflow*) como prueba de campo de la ganancia « 6-12 min/borrador ». Convergencia directa con la doctrina **skills-over-prompts** (Lattice, PROJ-AI), los **sistemas alrededor del modelo** (Dropbox/Okumura), y el uso de **HTML como artefacto de revisión** (Shihipar).
#ingeniería de contenido#ingeniería de contenido#Claude Code
**Ryan Law** — Director of Content Marketing chez **Ahrefs**. Praticien senior du content marketing SEO ; le billet est un retour d'expérience personnel (*« How I do… »*) publié sur le **blog Ahrefs** (ahrefs.com/blog) le **28 avril 2026**.
El editorial de Andrew Ng en The Batch #350 establece una **jerarquía de aceleración para agentes de codificación** por tipo de trabajo de software: **Frontend (máxima) > Backend (moderada) > Infraestructura (baja) > Investigación (mínima)**. El razonamiento se basa en la *verificabilidad* implícita (fluidez en TypeScript/JavaScript junto con un bucle autónomo de pruebas agente-navegador en el frontend) y en los puntos ciegos de los LLM (casos límite / seguridad / migraciones de bases de datos para el backend, compensaciones de red opacas para la infraestructura, formación irreducible de hipótesis para la investigación). El número se completa con 4 noticias estructurantes: **GLM-5.1 (Z.ai)**, un modelo con licencia MIT de 754B de parámetros (40B activos) capaz de tareas autónomas de hasta 8 horas de duración (líder de SWE-Bench Pro con 58,4%); **Digit (Agility Robotics) en Schaeffler**, el primer despliegue industrial de humanoides (1,75 m / 65 kg, 10-25 $/h frente a 20 $/h para un humano); la **revuelta antidata centers** (~64.000 M$ bloqueados entre mayo de 2024 y marzo de 2025, moratoria en Maine sobre instalaciones de 20MW o más, cóctel molotov en la casa de Sam Altman); y el **"eje del asistente"** (Christina Lu, MATS / Oxford / Anthropic), que reduce la deriva de persona y los jailbreaks (Qwen3 32B: 83%→41%; Llama 3.3 70B: 65%→33%) sin degradar IFEval/GSM8k/MMLU-Pro/EQ-Bench.
#Andrew Ng#The Batch#DeepLearning.AI
Andrew Ng (édito principal — fondateur DeepLearning.AI, Stanford, ex-Google Brain, ex-Baidu) ; rédaction The Batch (DeepLearning.AI) pour les sections actualités
Síntesis de Addy Osmani (Google, Chrome/Cloud) sobre el campo emergente de la *harness engineering*: la ecuación `agent = model + harness`, el principio *ratchet* ("cada error se convierte en una regla"), el replanteamiento "skill issue" de HumanLayer, la evidencia de Terminal Bench (de Top 30 a Top 5 solo con un cambio de harness), la arquitectura en capas de Claude Code, la visión de Anthropic "los harnesses no se reducen, se desplazan", y Harness-as-a-Service (Claude Agent SDK, Codex SDK, OpenAI Agents SDK). Artículo bisagra que consolida a Trivedy, HumanLayer, Anthropic y Böckeler en una doctrina.
#harness engineering#agent harness#Addy Osmani
Addy Osmani (Software Engineer at Google, Cloud + Gemini)
Agente semántico: la simetría entre modelo+harness y ontología+datos, el colapso de los frameworks de agentes, la ontología como el único activo no comoditizado
Actualización pública de Darragh Curran (I+D, Intercom) nueve meses después de su compromiso de duplicar la productividad de I+D en 12 meses mediante IA. Resultado: **3x alcanzado en 16 meses, sin señales de estancamiento**. Datos cuantificados de una organización de I+D de 500 personas / 8,5 M líneas de código: **93,6 % de los PR son impulsados por agentes**, **19,2 % aprobados por IA** (objetivo >50 %), coste/PR **-50 %**, backlog de defectos **-54 %**, tiempo hasta el despliegue **-39 %**, tiempo de inactividad por cambios disruptivos **-35 %**, el 5 % superior de los desarrolladores alcanza **6x el rendimiento mediano de PR**, **497 PR autónomos** en las primeras 4 semanas, **153 contribuyentes / 267 skills especializadas** en una *Skills-Based Plugin Architecture* privada. Curran declara: ***"Todo el trabajo técnico se está volviendo agent-first. Esta es la máxima prioridad para I+D."*** Artículo clave del dossier sobre la *organización agent-first*, comparable únicamente con Stripe Minions y StrongDM en el corpus de 2026.
#Darragh Curran#Intercom#Fin Ideas
Darragh Curran (R&D leader, Intercom — publication via Fin Ideas, plateforme média Intercom).
El rol del desarrollador frente a los agentes de codificación con IA, experimento de un día con el método BMAD, evolución hacia el supervisor de agentes - Blog técnico
QMD, motor de búsqueda local para bóvedas de Obsidian, skill /recall para memoria persistente en Claude Code, búsqueda BM25 + semántica + híbrida frente a grep
Infraestructura de contexto codificado para agentes de IA: arquitectura de 3 niveles, memoria persistente, 283 sesiones, MCP, agentes especializados, base de código compleja
#contexto codificado#infraestructura de agentes de IA#memoria persistente
Aristidis Vasilopoulos (Chercheur indépendant, USA)
Manual de referencia de compound engineering: bucle agéntico de 7 pasos (Ideate→Brainstorm→Plan→Work→Review→Polish→Compound), plugin de 40+ agentes, escala de adopción de 5 niveles, regla 50/50 — Kieran Klaassen (Cora / Every) - Every Source Code
#compound engineering#filosofía nativa de IA#bucle de 7 pasos
Kieran Klaassen (avec Claude & GPT crédités co-auteurs du guide complet)
Every Marketplace - Compounding Engineering Plugin - Claude Code - GitHub - Flujo de Trabajo de Desarrollo con IA - Calidad del Código - Reducción de Deuda Técnica
#Compounding Engineering#Claude Code#Desarrollo con IA
EveryInc (Organization) · Contributors from Every.to engineering community
Lanzamiento de la Agentic AI Foundation - Linux Foundation - OpenAI Anthropic Block - Estándares abiertos para agentes de IA - AGENTS.md MCP goose - Interoperabilidad
Anthropic Interviewer - AI Workforce Study - Professional Perspectives - AI Adoption - Workplace Transformation - Creative Industries - Scientific Research - Economic Impact - Sociological Research - AI Sentiment Analysis
Anthropic Research - AI Work Transformation - Claude Code Impact - Software Engineering - AI Adoption - Productivity Study - Workplace Evolution - AI Collaboration - Skills Development - Future of Work
#Anthropic#AI Transformation#Workplace Impact
Anthropic Research Team (132 engineers and researchers surveyed, 53 in-depth interviews conducted)
Diseño frontend con Claude Skills - Convergencia distribucional - Context Engineering - Mejora de la calidad de la interfaz - Tipografía color movimiento - Anthropic
8 estrategias de planificación con IA - Agentes de investigación en paralelo - Anclaje en el código base - Historial de git - Prototipado vibe - Agentes de estilo - Compounding engineering - Every Source Code - Kieran Klaassen
#estrategias de planificación#agentes de investigación#operaciones en paralelo
Planificación vs Vibe Coding - Compounding Engineering - Three Fidelities - Agentes de IA - Cora Email Bankruptcy - Plans Teach Systems - Every Source Code
Microsoft Magentic Marketplace - pruebas de manipulación de agentes de IA - Claude Sonnet 4 único resistente - Paradoja de la elección - Prompt injection - Parálisis por análisis - Webb Wright - ZDNet
#agentes de IA#investigación de Microsoft#Magentic Marketplace
Enfoque funcional de la IA generativa en el desarrollo de software, código generado al 100 %, onboarding del LLM, tareas atómicas, spec-driven, capitalización continua - Soufiane Keli - OCTO Technology - LinkedIn
#IA generativa#generación de código#desarrollo de software
Agentes de IA autónomos, evolución de los roles de los desarrolladores, flujos de trabajo asíncronos, orquestación multiagente - Addy Osmani - Substack
#agentes de IA autónomos#codificación agéntica#evolución del rol del desarrollador
Estrategia de software de Nvidia, SLMs para flujos de trabajo agénticos, Nemotron Nano, estación de trabajo DGX Spark, ajuste fino con data flywheel, hardware moat, vision-RAG - Cobus Greyling - Medium
Producción de IA agéntica, observabilidad del razonamiento de agentes, memoria organizacional estructurada, supervisión adaptativa, despliegue en fintech
Cat Wu y Boris Cherny (Anthropic) explican cómo usar Claude Code como sus creadores: antfooding, plan mode, subagents, hooks y extensibilidad — podcast AI & I de Every
#Claude Code#Cat Wu#Boris Cherny
Rhea Purohit (interviewer: Dan Shipper) · Cat Wu · Boris Cherny
Ethan Mollick - Agentes de IA y Trabajo Real - Impacto Económico - Estudio de OpenAI - Replicación de Investigación - Futuro del Trabajo - One Useful Thing
#AI Agents#trabajo real#impacto económico
Ethan Mollick · Professeur à la Wharton School · University of Pennsylvania