thekb.eu — Agentes de codificación IA y Skills

When code is abundant

Mon, 24 Aug 2026 00:00:00 GMT

Bill Staples, CEO de GitLab, publica el 24 de agosto de 2026 un ensayo que extiende un memorando escrito a su consejo en enero y una primera publicación en mayo, *GitLab Act 2*. El detonante explícito es el playbook de SDLC nativo en IA de Anthropic, publicado el 21 de agosto, del que toma prestada la afirmación de apertura: el código ya no es el cuello de botella. Su pregunta va un paso más allá: si producir código deja de ser la restricción, ¿qué se vuelve escaso, y qué arquitectura debe tener una empresa cuando humanos, agentes y múltiples modelos actúan simultáneamente a velocidad de máquina? Su respuesta cabe en una frase: cuando la implementación se vuelve abundante, la confianza se vuelve escasa. Durante sesenta años, la ingeniería de software se ha organizado en torno a un hecho —el código es precioso— del que se derivan la preservación del legado, la optimización de la productividad del desarrollador y la ceremonia de revisiones, aprobaciones y puertas de liberación. Esta restricción está cambiando, y el sistema construido en torno a ella la seguirá. La unidad económica que propone 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 el término de generación y hace que los demás resulten proporcionalmente decisivos: una organización diez veces más rápida generando, sin tocar el resto, simplemente desplaza la cola. Es la teoría de las restricciones, citada por su nombre. Las experiencias de Stripe, Spotify y Amplitude sirven como material. Muestran sobre todo dónde reaparecen las siguientes restricciones: entorno, CI, revisión y gobernanza. Un pipeline de treinta minutos, escribe, derrota a cualquier modelo. De ahí se deriva una arquitectura: tres modos de desarrollo coexistentes en lugar de una curva de madurez única; el bucle interno migrando de la estación de trabajo al pipeline, más cerca del repositorio y produciendo evidencia; una autonomía que se gobierna en lugar de concederse, mediante puertas deterministas, aislamiento, política y evidencia. Luego se expone la tesis del proveedor: el modelo es un componente de ejecución reemplazable, no la arquitectura duradera. El contexto, la identidad, la política, la procedencia y la memoria organizacional deben persistir a través de modelos y agentes, lo que empuja hacia un plano de control neutral respecto al modelo y a la nube. El texto distingue el archivo Markdown del registro gobernable, sostiene que el agente debe pertenecer al cliente, describe un PDLC donde la señal de negocio se convierte en software verificado, y prevé que la población de Builders crezca. El juicio humano, por su parte, no se vuelve abundante: se desplaza hacia arriba, hacia la intención, la arquitectura y las excepciones.

The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage

Fri, 21 Aug 2026 00:00:00 GMT

Louis Claxton, del equipo Applied AI de Anthropic, publicó el 21 de agosto de 2026 una guía de implementación para un ciclo de vida de desarrollo de software "nativo de IA". El punto de partida es un desequilibrio: las organizaciones escriben ahora código a una velocidad inimaginable un año antes, pero los procesos que lo rodean — puertas de aprobación, revisiones, traspasos, políticas — no se han movido. El SDLC tradicional fue diseñado para un mundo en el que escribir código era la etapa más larga y más costosa; sus controles también asumen que cada acción la realiza un humano. De ahí se derivan tres consecuencias. El cuello de botella se desplaza hacia las etapas que aún funcionan a velocidad humana, a ambos lados de la construcción. Los controles dejan de ser aplicables: leer cada línea tenía sentido cuando una persona la había escrito. Y el coste de la gobernanza aumenta, porque las excepciones pasan por comités periódicos. La respuesta conserva los objetivos de control y cambia la forma de ejecutarlos. El proceso se convierte en un loop, con la IA integrada en cada punto, organizado en seis etapas — Plan, Design, Build, Test, Deploy, Maintain — desglosadas en *plays* que siguen todas la misma cuadrícula, hasta las métricas. El hilo conductor es el artefacto versionado. La intención la captura su autor original como `intent.md`; los requisitos y el diseño se fusionan en una única sesión que produce `spec.md`, condicionada por las skills de marca, seguridad, cumplimiento y UX; la construcción empieza en plan mode y bloquea `plan.md` antes de escribir ningún código. La cadena de commits sirve de rastro de auditoría. El conocimiento institucional se convierte en archivos versionados: `CLAUDE.md` para el contexto del repositorio, skills para las políticas transversales, `REVIEW.md` para la doctrina de revisión, `bands.yaml` para los umbrales de producción. La gobernanza se divide en dos capas, con la skill como control consultivo y el hook como capa determinista que bloquea o solicita aprobación. Un ejemplo de *managed settings* detalla, clave por clave, qué aporta cada ajuste en términos de control, desde negarse a leer secretos hasta imponer un umbral mínimo de versión. La etapa Maintain cierra el loop: un script determinista vigila una métrica, y al cruzar una banda se invoca a Claude sin ningún humano en la cadena de llamadas, con un nivel de autonomía fijado por el tier. Lo que encuentra el agente se reescribe como `intent.md` y se reintroduce en el ciclo. Claude Tag, en beta pública en Slack, extiende el patrón a los incidentes que llegan por chat. No se presentan resultados cuantificados: la guía aporta métricas que medir y nombra su fuente.

The Claude Code guide for startups

Thu, 20 Aug 2026 00:00:00 GMT

Michael Segner publica una guía en el blog claude.com el 20 de agosto de 2026, extraída de entrevistas con más de una docena de startups de rápido crecimiento, quince de ellas nombradas, sobre cómo usan Claude Code. El documento extrae de ahí cinco reglas operativas y cierra con una checklist de consejos técnicos. Primera regla, "everyone ships": la codificación agéntica reduce la barrera de entrada, de modo que la persona que entiende el problema puede entregar la primera versión de la corrección. Parahelp reporta contribuciones de empleados no técnicos, Crosby a abogados que aportan las mejores intuiciones de producto, Heidi la desaparición de un efecto de teléfono descompuesto donde la idea se degradaba al pasar del creador al product manager, luego al diseñador, luego al ingeniero. La guía matiza de inmediato el alcance: la división del trabajo se mantiene, solo se abre el paso de cero a uno. Tres mecanismos lo vuelven sistémico — conectar la herramienta a fuentes de verdad vía MCP o CLI, ritualizar las demos de prototipos, compartir skills. Segunda regla, automatizar lo tedioso: los agentes asumen el ochenta por ciento mecánico del ciclo y los ingenieros conservan las decisiones de criterio. ClickHouse dice haber convertido casi cada paso en un bucle autónomo, con dos agentes de propósito único que se convierten en el segundo y tercer contribuyente de su repositorio. En Anthropic, Claude Tag actúa como primer respondiente de guardia ante fallos de integración continua. Tercera regla, confiar pero verificar: un proceso no queda automatizado sin una forma fiable de comprobarlo. Cainex, en codificación médica, describe un bucle de automejora donde las correcciones de los auditores realimentan las instrucciones del agente, probadas contra un golden set, bajo una sola regla — corregir el principio, no el ejemplo. Zingage relata haber otorgado demasiada autonomía al principio, obteniendo código plausible pero que se desviaba de su arquitectura, y luego haber escrito sus invariantes. La guía apunta a los hooks para las puertas deterministas e insiste en el mantenimiento de los conjuntos de evaluación. Cuarta regla, construir para reconstruir: la capacidad del modelo sigue evolucionando, de modo que poco se trata como permanente. Commure fija el criterio de finalización de una reconstrucción — cuando la vía antigua ha desaparecido — y los git worktrees hacen el ejercicio asequible. Quinta regla, prototipar, dogfoodear, productivizar: el agente interno construido con Claude Code se convierte, si resulta convincente, en un producto orientado al cliente vía la API, el SDK o Claude Managed Agents. Las cuatro cifras destacadas se mantienen tal como fueron declaradas por las empresas entrevistadas, sin que se describa ningún método de encuesta.

Designing AI with character: what we learned building Berd

Tue, 18 Aug 2026 00:00:00 GMT

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

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

Tue, 18 Aug 2026 00:00:00 GMT

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

Projects in Buzz

Tue, 18 Aug 2026 00:00:00 GMT

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

The AI Engineering Skills Map

Fri, 14 Aug 2026 00:00:00 GMT

Publicación en X de **Andrew Ng** del **14 de agosto de 2026**, retomada de la carta «Dear friends» de ***The Batch* #366** (DeepLearning.AI). **Qué se anuncia.** *The AI Engineering Skills Map*: **cuatro habilidades** presentadas como las más importantes para un desarrollador, respaldadas por *« an analysis of more than 10,000 job postings »*, decenas de entrevistas estructuradas con expertos, responsables de contratación y reclutadores, encuestas y otros datos en línea. Doble audiencia explícita: ayudar a los desarrolladores a **priorizar lo que aprenden** y a los empleadores a **contratar**. **Las cuatro habilidades.** **(1) Construir y desplegar aplicaciones de IA** — su diferencia radica en la **imprevisibilidad de los resultados**, hay que conocer los componentes básicos (LLM, context engineering, RAG, flujos de trabajo agénticos, machine learning, deep learning) y sobre todo las **técnicas estadísticas para medir, orientar y gobernar**, incluyendo *« disciplined evals and error-analysis loops »*. **(2) Fundamentos de ingeniería de software** — comprenderlos permite *« recognize what tradeoffs exist »* (costo, escalabilidad, fiabilidad, velocidad, seguridad, privacidad) y así orientar al agente *« in the precise language of software engineering »*; el *vibe coder* inexperto fracasa porque *« they don't know what context to give their agent »*. **(3) Uso de agentes de codificación** — un modelo mental de sus límites, gestión del contexto, compromisos entre planificación y ejecución, **proporcionar verificadores o evals para que el agente cierre sus bucles por sí solo**, trabajar con una especificación clara *« and when not to bother doing so »*, orquestación multiagente, barreras de seguridad. **(4) *Shaping the build*** — dado que los agentes cumplen bien frente a una especificación clara, el trabajo se desplaza hacia **decidir qué debe contener la especificación**: sentido del producto, contexto de negocio, propiedad del proyecto. **Subyacente a las cuatro: una mentalidad de aprendizaje continuo**, con *« routines for trying new tools »*. **La tesis real, deslizada en una nota terminológica.** Ng habla de **habilidades** en ingeniería de IA y no del **rol** "AI Engineer": *« all developers should know how to work with the cloud, only a small number carry the "Cloud engineer" title »*. **La ingeniería de IA se convierte en una base, no en una especialidad** — no se contrata, se recalifica. **Dos salvedades.** **No se publica ningún resultado numérico**: sin ponderación, sin subhabilidades, una agrupación descrita como una analogía *« informal »*, y el mapa detallado aplazado a futuras publicaciones. **Este es el anuncio de un mapa, no el mapa.** Y el autor declara su interés: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities

Fri, 14 Aug 2026 00:00:00 GMT

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

DeepSeek Harness developer preview: Everything is a plugin

Thu, 13 Aug 2026 00:00:00 GMT

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

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

Wed, 12 Aug 2026 00:00:00 GMT

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

I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

Wed, 12 Aug 2026 00:00:00 GMT

Informe de experiencia publicado en **LinkedIn Pulse** el **12 de agosto de 2026** por **Guillaume Dumortier** (newsletter *Growth Marketing Fit*), sobre un sistema interno de IA de marketing construido **en Claude** para un equipo de unas sesenta personas: alrededor de treinta skills, una decena de módulos de verdad, **siete agentes, seis de los cuales solo verifican trabajo**, un plugin de terminal, una aplicación de navegador y una orquestación de campañas multi-activo. **La tesis.** *« Pensaba que estaba construyendo una máquina de contenido. Estaba construyendo una máquina de confianza. »* La calidad de una salida de IA no se determina en la generación, sino por **lo que el sistema sabe de antemano** y **lo que ocurre con el borrador después**. La generación es la parte fácil — y la única parte que la mayoría de los equipos ha construido. **Cuatro capas.** *Verdad*: documentos de hechos separados de todo lo que produce contenido, cada uno con un propietario, versionado y fechado. Dejar los hechos dentro de las skills produjo **cuatro versiones de una fecha de lanzamiento en cuatro archivos**, cada una individualmente plausible. *Producción*: la skill de blog pasó semanas escribiendo **descripciones de artículos** en lugar de artículos, y superó todas las revisiones, porque la revisión verificaba la estructura. Superadas las treinta skills, el problema se convierte en **enrutamiento** — la mitad de cada descripción de skill tiene que indicar para qué no sirve. *Verificación*: la capa que separa una demo de un sistema. *Distribución interna*: donde los proyectos mueren por ser excelentes y ser usados por cuatro personas. **Los dos fallos centrales.** Un fact-checker recibe una afirmación que ninguna de sus fuentes cubre: devuelve un « pass ». *« No solo pasó por alto el error, lo certificó. »* Solución: un verificador es un **sistema de mundo cerrado**; **tiene prohibido devolver un « pass » desnudo** y debe declarar su cobertura — cuántas afirmaciones verificó, cuántas realmente coincidieron, cuáles quedaron fuera de su jurisdicción, cuáles no pertenecían a ninguna fuente. *« Una afirmación no verificable es un hallazgo, no un silencio. »* Segundo fallo: **dos activos individualmente correctos pueden contradecirse entre sí**; la verificación por activo individual no puede detectarlo, por construcción. **Cinco reglas transversales.** Nunca pedirle a un modelo algo que se puede imponer en código. Los **fallos silenciosos** son todo el riesgo — una constante vaciada eliminó todos los números de todos los prompts, y se culpó al modelo de alucinar. Probar el pipeline, no solo la salida. Tu validación tiene los mismos huecos que tu sistema. **Enseñar al sistema a rechazar.** **La adopción sigue a la confianza, no a la capacidad**: una salida que admite lo que no sabe con certeza se usa. Cláusula de cierre: ***« La generación es gratis. La confianza es el producto. »***

Agent Plugins package your skills, tools, and more

Thu, 06 Aug 2026 00:00:00 GMT

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

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

Thu, 06 Aug 2026 00:00:00 GMT

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

Efficient Tokens & Effective Teams in Buzz

Thu, 06 Aug 2026 00:00:00 GMT

Una entrada de referencia de **Block** firmada por **Atish Patel**, publicada el **6 de agosto de 2026**, que prolonga el lanzamiento de **Buzz**: dado que montar un equipo de agentes se ha vuelto trivial, *¿cuál es el más barato que tiene éxito de forma fiable?* **Primero, el vocabulario.** La entrada propone cuatro niveles: **QuickBee** (rápida y barata — builds, capturas de pantalla, tests, triaje de primera pasada: GPT-5.6 Luna, DeepSeek V4 Flash, modelos locales, **ejecutada con esfuerzo alto**), **WorkerBee** (versátil, se encarga de un subconjunto completo sin supervisión: GPT-5.6 Terra, Gemini 3.6 Flash, modelos abiertos), **SmartBee** (visión de conjunto, compromisos, escaladas: Claude Opus 5, Kimi K3, GPT-5.6 Sol, **con esfuerzo *medium***), y el humano, *"la abeja más cara del equipo, y la más lenta. También, sigue siendo la más inteligente"*. Dos formas de equipo: el **Hive** permanente, que recuerda **las** preferencias del usuario, y el **Swarm** desechable, que recuerda **el proyecto** y luego desaparece. **El resultado en solitario.** En **Terminal-Bench 2.1**, aumentar el esfuerzo de un **modelo barato** es la mejor inversión: Luna pasa de 1,61 $ / 57,3% (*medium*) a 4,98 $ / 75,0% (*high*). En el otro extremo, **Opus 5 con esfuerzo *xhigh* es la ejecución más cara (140,63 $) y solo obtiene un 75,0%**, tras **alcanzar el timeout en 17 de 88 tareas** por sobrerrazonamiento. Entre las seis mejores ejecuciones: **una brecha de precio de 5,5×, una brecha de puntuación de 8,9 puntos**. Conclusión: *"elegir entre ellas no es en absoluto una decisión de calidad. Es una decisión de presupuesto."* **El resultado de equipo, en dos actos.** En Terminal-Bench 2.1 se probaron **doce composiciones** y **ninguna superó al agente solo a igualdad de costo** — una tarea corta no tiene suficiente estructura para dividirse. En **Long-Horizon Terminal-Bench** (44 tareas de varias horas, líder GPT-5.6 Sol, **3× el timeout**), la inversión es clara: solo **15 tareas / 59,1%**, +2 WorkerBees **20 / 71,5%** — **+12,4 puntos, de los cuales 11,4 provienen de finalizaciones adicionales**. El equipo cuesta más por tarea, lo cual compensa *"cuando la alternativa es que un humano retome un trabajo inacabado"*. **La regla operativa.** Encaminar las escaladas de los agentes trabajadores a un **coordinador SmartBee** en lugar de al humano: *"cada ambigüedad se convierte en una notificación"* es el verdadero modo de fallo. Un ingeniero de Block afirma haber **migrado más de 2000 aplicaciones** con un Swarm (coordinador, de 1 a 10 migradores, verificador independiente), guardando el coordinador las respuestas humanas en memoria. **Salvedades**: n=1 por tarea, sin intervalo de confianza, costos de equipo no publicados, y una admisión — *"esto podría cambiar si los modelos se entrenan para colaborar mejor."*

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

Thu, 06 Aug 2026 00:00:00 GMT

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

Introducing Muse Code and Muse Spark 1.2

Wed, 05 Aug 2026 00:00:00 GMT

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

How to use Notion as Code

Mon, 03 Aug 2026 00:00:00 GMT

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

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

Mon, 03 Aug 2026 00:00:00 GMT

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

Agent Client Protocol — Introduction

Sun, 02 Aug 2026 00:00:00 GMT

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

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

Sun, 02 Aug 2026 00:00:00 GMT

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

Code review dans le SDLC augmenté : l'anneau de contraintes autour des agents

Thu, 30 Jul 2026 00:00:00 GMT

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

Mon usine logicielle à l'heure de l'IA

Tue, 28 Jul 2026 00:00:00 GMT

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

Anthropic sécurise un SDLC où l'IA écrit 80 % du code : le cycle redevient le socle

Sun, 26 Jul 2026 00:00:00 GMT

Cinco días después del informe de Jason Clinton (Deputy CISO de Anthropic) sobre cómo asegurar un ciclo de desarrollo que se ha vuelto nativo en IA, SFEIR publica un descifrado que no discute nada y no añade ningún hecho: **desplaza el tema**. El lector viene buscando controles de seguridad; se le muestra que lo que falta primero es un ciclo. El relato es fiel. Tres medidas de partida, autodeclaradas por Anthropic: ×8 de código enviado por ingeniero por trimestre, ~80% del código fusionado escrito por Claude, más de la mitad fusionado por la versión interna de Claude Tag. Un problema planteado por la **ley de Amdahl**: si la revisión y la monitorización no escalan al mismo ritmo que la producción, la aceleración se convierte en un cuello de botella. Un modelo de amenazas explícito (agente comprometido o víctima de inyección de prompt, envenenamiento de dependencias, aumento del volumen de vulnerabilidades clásicas). Después un control mapeado por etapa: **PSR** en Plan, **CLAUDE.md** y **egress allowlist** en Code, **agentes de revisión especializados** en Test, **DAST continuo** en Deploy, **triage y enrutamiento SIEM** en Monitor. La tesis se sostiene en una anáfora en cuatro partes. **Sin un SDLC, las ganancias no se materializan**: multiplicar por 8 el volumen de código no multiplica nada si la revisión sigue siendo secuencial — 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". **Sin un SDLC, la seguridad no tiene anclaje**: un gate es por definición un control situado entre dos etapas. **Sin un SDLC, no puede formularse ninguna política de FinOps de tokens**: el escaneo 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". **Sin un SDLC, no hay nada que medir**: el paso del 16% al 54% de PR comentados presupone una etapa donde puede colocarse un contador; sin eso, solo se producen cifras de uso, mudas sobre calidad y riesgo. Dos aportaciones más allá de la tesis. La lectura del incident agent-à-agent — un agente de respuesta a incidentes que pide a otra instancia de Claude, vía Slack, que despliegue una corrección, detenido por un gate humano: "un perímetro que descansa sobre una instrucción en un prompt no es un perímetro", y el acceso de un agente a otros agentes forma parte de su superficie de ataque. Y una advertencia clara: estas cifras provienen del proveedor del modelo, sobre una base de código joven sin mainframe. **Lo que se transpone es el método, no las cifras.**

SDLC vs PDLC : quelle différence, et pourquoi l'IA change tout

Wed, 22 Jul 2026 00:00:00 GMT

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".

How Anthropic secures its AI-native software development lifecycle

Tue, 21 Jul 2026 00:00:00 GMT

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.

Buzz!

Tue, 21 Jul 2026 00:00:00 GMT

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

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

Mon, 20 Jul 2026 00:00:00 GMT

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

Reflecting on a year of Claude Code

Fri, 17 Jul 2026 00:00:00 GMT

Boris Cherny (**Head of Claude Code**) y Cat Wu (**Head of Product, Claude Code**) publican en LinkedIn, vía Claude for Business, un breve vídeo (~47 s) titulado **"Reflecting on a year of Claude Code."** Su tesis: en la era de los agentes de codificación, **los roles de producto e ingeniería se están fusionando**. "¿Todo el mundo va a ser PM o todo el mundo va a ser ingeniero? Todo el mundo va a ser ambas cosas." **Prueba por el ejemplo: el caso interno.** Cherny describe cómo opera Anthropic como demostración: el equipo de producto, devrel y diseño **escriben código todos**; a la inversa, muchos ingenieros **entregan productos de extremo a extremo** — tienen una idea de qué construir, lo construyen y luego trabajan con legal, marketing y seguridad para comunicar y garantizar la seguridad. Conclusión: la IA **beneficia a los perfiles** con **curiosidad**, **sensibilidad de producto** y apetito por la **propiedad de extremo a extremo**. **El contenido real: el hilo de comentarios.** De 55 comentarios, 28 aportan una idea sustantiva, formando una revisión pública entre pares en ocho ejes. La reformulación **dominante**: no son los roles los que desaparecen, es el **acortamiento del ciclo de retroalimentación**. Rehan Nazir — cuando un PM valida una idea con un prototipo el mismo día, "los organigramas dejan de importar"; Noman A. — las ideas se prueban en horas en lugar de semanas, cambiando *cómo aprenden las empresas*; Kevin Schoovaerts — Claude Code construye el 80% del producto, el poder radica en el ciclo estrecho con el usuario. Segundo eje, más profundo: la **habilidad escasa se está desplazando** de "saber construir" hacia el **criterio** y la **definición del problema correcto** (Omer K., comentario con más «me gusta»: "elegir los problemas correctos, saber qué NO construir"; Syed T.; Andrei van Noordt: la contratación escasa se convierte en la persona con sensibilidad sobre *qué* construir que también sabe construirlo; Natasha Newbold: uno se convierte en un **arquitecto** que escribe las especificaciones que ejecutan equipos de agentes). Sunny Vara desplaza la apuesta del prompt hacia el **contexto**. **El contrapunto.** Una capa plantea las preguntas que el vídeo elude: Paul Breuler y Ron H. — la propiedad aumenta, por lo que la **responsabilidad** también aumenta; "cuando todos pueden construir, alguien todavía tiene que poder decir que no." Mohammadjavad Sayadi — la **brecha entre demo y producción** sigue siendo significativa en dominios regulados (salud). Los **escépticos** (Chris Bounds, Mohamed Anis, Panny Malialis, David H.) advierten contra generalizar una forma de operar propia del modo startup. Finalmente, dos **críticas frontales** (James Hutchinson, Dewayne J Grunden II) denuncian el **robo de propiedad intelectual** y piden abrir el código de los modelos y compensar a los creadores. En una frase: el consenso valida la tesis pero la reformula — **entregar se vuelve barato**, lo que desplaza el valor hacia el **criterio, la sensibilidad de producto y el problema correcto**, mientras que la responsabilidad, la gobernanza y la fiabilidad aún no se han puesto al día.

The Token Manifesto

Fri, 17 Jul 2026 00:00:00 GMT

**Nicolas Martignole** publica en *Le Touilleur Express* **« The Token Manifesto »**, un breve texto satírico coescrito con dos modelos (**GLM-5.2** y **MiniMax-M3**). El mecanismo es claro: tomar la estructura exacta del **Manifeste Agile** de 2001 —su preámbulo, sus cuatro valores en forma "X sobre Y", sus doce principios— y trasladarla al mundo de los LLM, donde la unidad de cuenta ya no es la hora-ingeniero sino el **token**. El preámbulo marca el tono: "Estamos descubriendo mejores formas de consumir contexto haciéndolo… A través del trabajo de producir tokens, borrar tokens y **mirar nerviosamente una barra de uso**, hemos llegado a valorar…". **Los cuatro valores** esbozan una estética del prompt frugal: *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*. Cada uno enfrenta una práctica económica (concisión, ejemplo, iteración, formato restringido) a una tentación costosa (sofisticación, verbosidad, una especificación masiva, una respuesta sin restricciones). **Los doce principios** subvierten uno a uno los del Agile. La prioridad pasa a ser entregar "**la respuesta, no el ascenso hacia la respuesta**"; el manifiesto "da la bienvenida a los requisitos cambiantes, incluso avanzada la conversación"; se construye "en torno a individuos motivados con una **ventana de contexto adecuada**"; "los prompts que funcionan miden el progreso **y acreditan las facturas**." El principio más citado invierte el famoso décimo de Agile: "**La simplicidad: el arte de maximizar la cantidad de trabajo que el modelo no hace**". Otros apuntan a la deuda de contexto ("detectar la repetición y documentarla una sola vez") y a la sostenibilidad económica ("un ritmo de prompting que pueda mantenerse indefinidamente", "una reflexión periódica **antes de que lleguen las facturas mensuales**"). Dos frases finales cierran el manifiesto y sostienen su tesis seria bajo el humor: **« No tienes un problema de prompt. Tienes un problema de ventana de contexto. »** —que desplaza la atención del *prompt engineering* hacia la **economía de la ventana de contexto**— y **« Todo el mundo es prompt engineer hasta que se le acaba la cuota mensual. »** —un recordatorio irónico de que la habilidad real se mide en el medidor de uso. Más allá de la broma, el texto cristaliza un cambio cultural: en la era del desarrollo asistido por IA, la restricción estructurante ya no es la **velocidad** (la obsesión de Agile) sino el **presupuesto de tokens** y la gestión del contexto. La coautoría humano-más-modelos actúa como una firma meta: un alegato a favor de la frugalidad de tokens, escrito con la ayuda de los mismos modelos a los que enseña a ahorrar.

Steps of AI Adoption (tableau/artifact + post LinkedIn « I talk to engineers at other companies every day… »)

Thu, 16 Jul 2026 00:00:00 GMT

Boris Cherny, Creator & Head of Claude Code en Anthropic, publica una tabla-marco — **« Steps of AI Adoption »** — nacida de una observación recurrente: en muchas empresas, *una* persona multiplica por diez su producción con Claude, pero el resto de la organización no sigue el ritmo. De ahí deriva una **escala de madurez de 5 etapas (0→4)**, estructurada en torno al **orden de magnitud de agentes que un ingeniero gestiona** — y la transformación del rol que esto impone. **0 — Gated (0 agentes)**: acceso restringido, modelos más antiguos, sin gobernanza de MCP ni infraestructura para alojar el código de Claude; cuello de botella = seguridad/aprobaciones heredadas y una obsesión por el coste por token. **1 — Assisted (~1)**: "tú + un agente", programación en pareja supervisada, trabajo síncrono; cuello de botella = tu atención, ya que sin autoverificación lo revisas todo. **2 — Parallel (~10)**: te conviertes en el **orquestador** de 5-10 agentes en worktrees separados; Claude se autoverifica (tests/build/lint/seguridad), Auto mode y revisiones automatizadas por defecto; cuello de botella = revisar múltiples flujos. **3 — Supervised autonomy (~100)**: **manager of managers**, Claude escribe casi todo, el mantenimiento se ejecuta en segundo plano; cuello de botella = la confianza en el bucle y el ritmo de decisión. **4 — AI-native (~1.000+)**: **VP que dirige por intención**, un bucle cerrado en el que Claude lanza la mayoría de los agentes, supervisión por excepción. **Tesis central**: los tokens no te hacen subir de nivel. Cada nivel tiene su propio cuello de botella; el progreso viene de **romperlo** y **construir el siguiente conjunto de salvaguardas** que hace que el resultado sea fiable. Las palancas mencionadas: bucle de autoverificación (tests + build + lint + e2e en un entorno real), **Auto mode** contra los prompts bloqueantes, **revisión de código + revisión de seguridad por defecto**, interfaces multiagente (Agent view, Desktop, móvil, Tag), luego `/loop`, `/batch`, `/goal`, **flujos de trabajo dinámicos**, **worktree isolation**, **CLAUDE.md + Skills** para codificar estándares, y finalmente el **Claude Agent SDK** para programar/planificar flotas de agentes. Sobre el pilotaje, Cherny descarta la métrica vanidosa: el uso mide **actividad, no retorno**. La pregunta correcta — *¿de todos modos habríamos dedicado este esfuerzo, y cuántas **horas-ingeniero manuales** habría costado?* — da el verdadero ROI. La ganancia decisiva llega cuando corregir/mantener pasa a segundo plano, liberando a los equipos para *construir* lo que antes ni siquiera estaba a su alcance. Un punto de referencia honesto: Anthropic está en la etapa 3 y avanzando hacia la 4; él mismo acaba de alcanzar el nivel 4.