thekb.eu — Arquitectura y Construcción

DuckDB and the changing physics of analytics

Wed, 26 Aug 2026 00:00:00 GMT

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

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.

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

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.

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.

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.

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.

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

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.

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

Mon, 20 Jul 2026 00:00:00 GMT

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

Beyond Zero: Enterprise security for the AI era

Mon, 20 Jul 2026 00:00:00 GMT

Artículo de investigación publicado en **ACM Queue** (vol. 24, n.º 3 — número temático «LLMs») el **20 de julio de 2026**, escrito por **Joseph Valente** (Director de Product Management, Alphabet Security) y **Michal Zalewski** (Distinguished Engineer, estratega de Alphabet Security — el *lcamtuf* de la seguridad ofensiva). Licencia **CC BY 4.0**, **29.143 descargas** en diez días, **una única referencia bibliográfica**: el whitepaper de **BeyondCorp** de 2014. Esto no es casual — el artículo se posiciona explícitamente como el **sucesor genérico de BeyondCorp** y asume su función: *«publicar la visión para que la industria pueda alinearse con ella.»* **Tesis**: el **modelo de frontera a nivel de aplicación está llegando al final de su vida útil**. Los tres supuestos sobre los que se sustentaba BeyondCorp — *quienes acceden son humanos, las acciones ocurren a velocidad humana, la aplicación es la frontera de confianza correcta* — quedan los tres obsoletos ahora que los agentes de IA acceden a datos **10 veces más rápido que los humanos** y razonan sobre vastos corpus no estructurados. **Beyond Zero** desplaza por tanto la frontera de confianza **de la aplicación a la acción individual sobre el recurso individual**, y la investigación **de a posteriori a tiempo real**. **Arquitectura de cuatro componentes que forman un bucle**: *gobernanza autónoma* (que usa IA para construir un **modelo vivo del mundo empresarial** — Quién / Qué / Cómo — por analogía explícita con el modelo del mundo de un coche autónomo), *captación de eventos* (señales de servidor, cliente y **actividad del agente**: prompts, planes de ejecución, invocaciones de herramientas), *reasoning engine* (IA jerárquica, **rápido** para ABAC en el momento del acceso y **lento** para la inferencia sobre una secuencia de acciones; veredicto *allow / deny / challenge*), e **infraestructura de desafío** (**desafíos** reversibles — justificación, toque de llave de seguridad, aprobación, **selfie** — frente a **contenciones** duraderas, levantadas a veces solo tras entrevistar al empleado y a su responsable por parte del equipo de seguridad). **El movimiento de diseño central es la división floor/ceiling**: **políticas estáticas** (el suelo, verificable estáticamente) bajo un **reasoning engine** dinámico (el techo) — un rechazo explícito de un modelo *«totalmente dinámico y difícil de verificar estáticamente.»* **El vector de ataque señalado**: la **ambient authority**, el agente que hereda los permisos completos, a menudo sobreaprovisionados, de su humano. **Tres reservas señaladas**: se trata de un **vision paper, no de un relato de guerra** — cero métricas de producción, cero tasa de falsos positivos, cero escala de despliegue, mientras que [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] había publicado una P99 < 40 ms y miles de agentes en producción dos meses antes; una **incoherencia interna de orden de magnitud** (decenas de millones de acciones/s en el planteamiento del problema frente a miles de decisiones/s en el resumen y la conclusión); y un **punto ciego europeo considerable** — el sistema descrito es también un dispositivo de vigilancia de empleados (selfie, señales del lado cliente, comparación de referencia con el grupo de pares), sin una sola línea sobre el RGPD, la proporcionalidad o los órganos de representación de los empleados.

Gregor Hohpe et le rôle de l'architecte à l'ère de l'IA

Wed, 15 Jul 2026 00:00:00 GMT

Este digesto de vigilancia tecnológica consolida, a partir de fuentes primarias (libros, el blog architectelevator.com, resúmenes de conferencias, publicaciones de LinkedIn, podcasts), la posición de Gregor Hohpe sobre el papel del arquitecto en la era de la IA generativa. Tesis central: la IA no devalúa al arquitecto, desplaza su valor del código hacia lo que la IA no hace — tomar y asumir decisiones, arbitrar compromisos, "vender opciones" y comunicarse con humanos. Su formulación más incisiva (Craft Conference 2026): "los desarrolladores interactúan principalmente con máquinas (compiladores, intérpretes, GenAI); los arquitectos, en cambio, se comunican con humanos — patrocinadores, partes interesadas, reguladores. La IA genera código y diagramas estándar, pero los arquitectos se apoyan en abstracciones poderosas que destilan decisiones críticas, eliminan la incertidumbre y alinean a las partes interesadas." Su tesis distintiva — el arquitecto no necesita ser la persona más inteligente de la sala, necesita "hacer que todos los demás sean más inteligentes" (QCon SF 2024) compartiendo modelos de decisión y revelando puntos ciegos — se refuerza a medida que el código se vuelve abundante: la ventaja proviene de la disciplina en la toma de decisiones, no del volumen de producción. La metáfora de las "opciones" (2016) también gana valor: mediante una analogía con Black-Scholes, Hohpe sostiene que cuanto mayor es la volatilidad tecnológica, mayor es el valor de las opciones que vende la arquitectura — por lo que conviene invertir más en arquitectura en momentos de incertidumbre como el actual momento de la IA. En cuanto al código, Hohpe prefiere "depurar" decisiones antes que producir líneas: el código generado incorpora decisiones arquitectónicas por defecto, y es el papel del arquitecto hacerlas conscientes. Advierte que "un SDLC impulsado por IA castiga los malos hábitos mucho más rápido": la IA amplifica todo, incluida la disfunción (deuda, inconsistencias); los ganadores se definirán por la rapidez con la que pasen de la experimentación a la "producción gobernada". Por rol: el arquitecto empresarial debe pasar de cartógrafo a explorador y evitar "la ilusión de la previsibilidad"; el arquitecto de plataforma debe entregar abstracciones, no ilusiones; el arquitecto jefe es un multiplicador (comunicación × tecnología × organización). Adopta la automatización específica (Amazon Q Code Transformation: 1000 aplicaciones Java 8→17 migradas en dos días) en lugar de la IA como oráculo de decisión, y desmiente cifras de marketing. Dos salvaguardas en el digesto: la fórmula "los arquitectos que usan IA reemplazarán a los que no lo hacen" NO es de Hohpe; algunas citas de LinkedIn solo son accesibles como extractos.

Le Rôle de l'Architecte à l'Ère de l'Intelligence Artificielle

Wed, 15 Jul 2026 00:00:00 GMT

Esta nota de análisis de SFEIR revisa el papel del arquitecto de software a la luz de la IA generativa, apoyándose en el marco conceptual de Gregor Hohpe (*The Software Architect Elevator*). El punto de partida es un cambio de paradigma: el arquitecto « Oráculo », poseedor de un conocimiento supremo que dicta reglas rígidas desde una torre de marfil, ahora está obsoleto, ya que la IA genera código y propuestas de diseño bajo demanda. El valor del arquitecto ya no reside en memorizar sintaxis o escribir "fontanería de software", sino en un nuevo papel de **amplificador de inteligencia (IQ Amplifier)**: proveer a los equipos los modelos mentales, el contexto empresarial y las herramientas de apoyo a la decisión para hacer el mejor uso de la IA, garantizando al mismo tiempo la coherencia global del sistema. El documento desglosa este impacto mediante la metáfora del "Architect Elevator", que va de la sala de máquinas (técnica) al ático (estrategia). El **arquitecto de Empresa** gestiona el hype, arbitra las decisiones de Build vs Buy sobre los modelos (propietarios, open-source afinados, APIs de terceros) y estructura la ética y la gobernanza de datos. El **arquitecto de Soluciones** "diseña para la incertidumbre" — arquitecturas modulares y desacopladas que permiten sustituir los LLM sin reescrituras — y "compra opciones" mediante sistemas extensibles. El **arquitecto de Plataforma** estandariza las capacidades de IA en forma de APIs robustas y seguras, tratando la plataforma como un producto (con referencia a *Platform Engineering is Domain-Driven Design*). El **arquitecto de Software / Tech Lead** implementa barreras de protección (arquitecturas hexagonales/Clean) para impedir que el código generado por IA contamine el núcleo de negocio, y documenta el "por qué" de las decisiones, ya que la IA solo genera el "cómo". El núcleo metodológico es el **Domain-Driven Design**, presentado como la mejor herramienta para encauzar la IA. Dos palancas: el **lenguaje ubicuo**, un diccionario de dominio sin ambigüedades inyectado en el contexto de la IA (vía `.clinerules` o plantillas de prompt), que reduce las alucinaciones y las malinterpretaciones de negocio; y los **bounded contexts**, que confinan la IA a un alcance restringido para maximizar la fiabilidad de la generación, con el arquitecto diseñando las interfaces y las capas anticorrupción (ACL) y delegando la fontanería de integración. En conclusión, la IA no es una amenaza sino un catalizador: libera al arquitecto de la entrada técnica repetitiva y revaloriza sus competencias más nobles — síntesis, visión estratégica, modelado de conceptos complejos y empatía humana para conectar la tecnología con las necesidades de negocio.

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

Sun, 12 Jul 2026 00:00:00 GMT

Artículo de ingeniería publicado el **12 de julio de 2026** por **Scrapfly Engineering**, sobre un canal de *fingerprinting* de navegador poco conocido: **los últimos bits de un número de coma flotante delatan el sistema operativo**. **El mecanismo**: IEEE 754 define cómo se almacena un `double`, pero **no exige** que `sin`, `cos`, `tanh` o `exp` estén correctamente redondeados; cada sistema distribuye por tanto una **libm** que sacrifica una fracción de ULP a cambio de velocidad, con sus propios coeficientes minimax, tablas y constantes de reducción. En consecuencia, `Math.tanh(0.8)` devuelve **tres valores distintos** según glibc (Linux), libsystem_m (macOS) y UCRT (Windows) — *« una sola llamada a tanh sobre la entrada correcta es una firma por sistema operativo. Afirma ser macOS, devuelve bits matemáticos de Linux, y te has contradicho con tu propio User-Agent. »* **El indicio es reciente y está fechado con precisión**: hasta **Chrome 147**, V8 calculaba `tanh` con un port de **fdlibm** embebido, idéntico en todas partes y sin fugas; el commit de V8 `c1486295ae5` lo sustituyó por `std::tanh`, publicado en V8 14.8.57, es decir **Chrome 148** — 148, 149 y 150 tienen fuga, 147 y anteriores no. **Tres superficies concentran las fugas**: `Math.tanh` (la **única** función `Math.*` afectada, ya que V8 embebe y enlaza estáticamente el resto), **todas las funciones trigonométricas de CSS** (Blink llama directamente a la libm del sistema anfitrión, tras una reducción de ángulo basada en grados que no comparte código con `Math.sin`), y **Web Audio** (donde el compresor permanece en libsystem_m escalar mientras que las etapas de FFT y vectoriales pasan por **Accelerate**). **Cuatro trampas** dificultan la contramedida: solo algunas funciones tienen fuga — de modo que **falsificar las demás crea una incoherencia detectable**; JavaScript y CSS son rutas de código distintas; **macOS embebe dos bibliotecas matemáticas que divergen entre sí** (escalar frente a Accelerate, del 10 al 89% de las entradas según la función: `cos(0)` devuelve `1.0` por un lado, `0.9999999999999999` por el otro); y **la arquitectura también deja fuga** (FMA y la propagación del signo de NaN difieren entre ARM y x86). **La contramedida rechazada y la elegida**: añadir ruido falla dos veces — el valor no coincide con **ningún** sistema operativo real, y la no determinación entre llamadas es en sí misma un indicio. El único camino es la **reproducción bit a bit**: extraer los coeficientes de la libm objetivo, transcribirlos **en hexadecimal** (una transcripción decimal redondearía de forma distinta), escribir cada multiplicación-suma fusionada explícitamente como `fma()`, y compilar con `-ffp-contract=off` para que el compilador no invente ni elimine ninguna. **Divulgación a señalar**: el editor declara de entrada que *« las publicaciones aquí se redactan con IA, »* mientras que los mecanismos, las cifras y el código siguen siendo propios.

New Engineering Disciplines for the AI Era Part 3: KDLC — Knowledge Development Life Cycle

Sun, 28 Jun 2026 00:00:00 GMT

Tercera entrega de la serie «New Engineering Disciplines for the AI Era», este artículo de Ashish Singh instituye el **KDLC — Knowledge Development Life Cycle** como una disciplina de ingeniería por derecho propio. Su tesis invierte el diagnóstico dominante: si tantas iniciativas de IA empresarial fracasan, no es por falta de elegir el modelo adecuado o de desplegar un sistema RAG, sino porque ignoran la **estructura subyacente del conocimiento**. La frase clave resume lo que está en juego: «la IA es solo tan eficaz como el conocimiento que puede descubrir, comprender, recuperar y en el que puede confiar.» El conocimiento debe, por tanto, tratarse como un **activo de ingeniería**, al mismo nivel que el código (SDLC) o los datos. El KDLC organiza este trabajo en **ocho** etapas ordenadas. **Discovery** localiza el conocimiento disperso en bases de datos, SharePoint, wikis, CRM, ERP y artefactos de ingeniería. **Extraction** extrae la información relevante preservando el contexto de negocio, los metadatos, las relaciones y la propiedad. **Structuring** convierte lo informal en objetos de conocimiento estandarizados y reutilizables. **Knowledge Graph Creation** mapea las interconexiones entre clientes, productos, proyectos, equipos, normativas y aplicaciones. **Embedding** produce representaciones semánticas que permiten la comprensión por significado. **Index Optimization** refina los índices vectoriales y los pipelines de recuperación. **Retrieval Evaluation** mide la relevancia, la precisión, la exhaustividad y el impacto de negocio. Por último, **Knowledge Refresh** mantiene el conjunto actualizado frente a nuevas políticas, normativas y versiones. El núcleo argumentativo contrapone dos arquitecturas. El **RAG tradicional** recupera documentos aislados mediante búsquedas basadas en palabras clave. El **Enterprise Knowledge Fabric** —una combinación de Knowledge Graphs, Semantic Search, Vector Databases y Hybrid Search— aspira a una comprensión interconectada: en lugar de recuperar documentos, los agentes de IA captan «relaciones, contexto y significado de negocio». Una segunda tríada enmarca los roles respectivos de las capas: «Los modelos aportan razonamiento. La memoria aporta continuidad. El conocimiento aporta comprensión.» Tres ilustraciones sectoriales concretan el impacto: un asistente de **cumplimiento normativo financiero** que vincula normativas vigentes y políticas internas; un asistente de **ingeniería de software** que consulta arquitectura, contratos de API, estándares e incidentes antes de recomendar; un asistente **clínico** que cruza guías de tratamiento, protocolos, literatura y expedientes de pacientes. Singh concluye que, en la era de la IA agéntica, la ingeniería del conocimiento se vuelve tan crítica como la ingeniería de software y la ingeniería de datos. La limitación del artículo reside en su naturaleza **conceptual y no cuantificada**: sin datos de referencia ni cifras de coste, y los verdaderos puntos de dolor —la gobernanza y el mantenimiento continuo de la etapa Refresh— quedan fuera de alcance.

Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Tue, 16 Jun 2026 00:00:00 GMT

Este artículo de SFEIR formaliza un ciclo de desarrollo de software impulsado por IA en once fases (0 a 10) y sostiene que el sector converge hacia este tipo de modelo. El punto de partida es un diagnóstico: en 2025, las organizaciones desplegaron herramientas de IA sin transformar su modelo operativo, produciendo una paradoja resumida en la frase «todo cambia… y nada cambia»: la velocidad de ejecución se multiplica sin una ganancia proporcional. El verdadero desafío no es, por tanto, elegir las herramientas adecuadas, sino repensar el propio ciclo de vida del software para una ejecución liderada por máquinas. El ciclo de SFEIR encadena: **0 Setup** (detección de la pila tecnológica, memoria del proyecto), **1 Define** (especificación — puerta humana), **2 Plan** (arbitraje de arquitectura — puerta humana), **3 Build** (desarrollo por el agente), **4 Verify** (pruebas automatizadas y cobertura), **5 Review** (cuatro auditorías paralelas: código, seguridad, pruebas, rendimiento), **6 Compound-1** (captura de lecciones antes del despliegue), **7 Ship** (aceptación en producción — puerta humana), **8 Ops** (monitorización y rollback), **9 Compound-2** (lecciones del entorno de producción) y **10 Deprecation** (retirada y capitalización). Tres **puertas humanas inamovibles** —Define, Plan, Ship— enmarcan un conjunto de fases por lo demás automáticas; dos **momentos de capitalización** (Compound-1 y Compound-2) convierten las lecciones en reglas reutilizables que alimentan los ciclos siguientes. Tres principios estructuran el enfoque. Primero, **la IA ejecuta, no asiste**: los agentes producen artefactos completos (código, pruebas, documentación) a lo largo de fases enteras, y una disciplina de **prueba de ejecución** captura los resultados reales —el sistema nunca confía en las afirmaciones del propio agente—. A continuación, **el humano conserva el control de la intención** mediante las tres puertas: decide qué construir, la máquina optimiza la ejecución. Por último, **el sistema aprende de forma acumulativa**, cada ciclo enriquece al siguiente. Los resultados presentados respaldan la tesis: un rediseño de sitio web que pasó de seis meses a un día, **−30 % de iteraciones de corrección tras diez ciclos** (un error reportado dos veces se convierte en una regla automatizada), revisiones bajo cuatro ángulos paralelos, un coste de aumento de alrededor de 10 €/hora, y un objetivo de 850 consultores plenamente aumentados por IA para finales de 2026. El artículo reivindica una **convergencia sectorial** con el ADLC (dos puertas, «la intención se verifica exactamente dos veces»), el whitepaper de Google sobre el nuevo SDLC (41% de código generado por IA, 85% de desarrolladores usando agentes) y DORA 2025 (la IA como «amplificador»). Finalmente, delimita los usos adecuados (back-offices, API, migraciones, resultados verificables automáticamente) y los inadecuados (diseño novedoso sin restricciones, sistemas críticos para la seguridad a la espera de normas, entornos de datos sin gobernanza), y recomienda empezar por una puerta de especificación rigurosa y por la prueba de ejecución. Primera entrega de una serie de siete.

The End of Code Review: Coding Agents Supersede Human Inspection

Thu, 11 Jun 2026 00:00:00 GMT

En este position paper publicado en arXiv (categoría de ingeniería de software), Martin Monperrus defiende una tesis que choca frontalmente con una práctica fundacional del SDLC: los agentes de codificación han alcanzado un nivel de capacidad tal que **la revisión de código humana ya no es un componente necesario de un pipeline de calidad**. El argumento se apoya en dos afirmaciones. Primero, una **paridad — o incluso una superioridad — de capacidad**: los sistemas autónomos basados en LLM cumplen todos los objetivos tradicionales de la revisión (encontrar defectos, mejorar la calidad, garantizar el cumplimiento, compartir conocimiento) con menor coste y mayor rendimiento, sin la fatiga ni la inconsistencia humanas. Segundo, un **problema de escalabilidad**: el modelo híbrido dominante — el agente escribe el código, el humano lo revisa — no proporciona una garantía real de calidad ni la capacidad de seguir el ritmo de la velocidad de producción asistida por IA; sobre todo, genera una **falsa sensación de seguridad**. Monperrus sitúa su objetivo históricamente, apuntando a la inspection de Fagan (1976), y se apoya en el trabajo de Bacchelli & Bird, que muestra que la revisión detecta, en la práctica, menos errores de los que los desarrolladores imaginan. Los benchmarks (SWE-bench, ~20-40% de issues resueltos según el modelo, con curvas de progresión rápidas) sirven como evidencia de capacidad. En lugar de la revisión humana, propone un **pipeline de verificación adversarial multi-agente**: un agente genera el código; uno o varios agentes revisores independientes lo inspeccionan (defectos, seguridad, estilo); una capa de verificación añade tests automatizados y métodos formales; un mecanismo de consenso hace que varios agentes voten para aceptar o rechazar. El cuello de botella de un único revisor humano se sustituye por una inspección distribuida e incansable. El humano no desaparece: se reenfoca en la especificación y los requisitos de alto nivel, las decisiones arquitectónicas, la supervisión de dominios críticos, los casos límite, y sigue siendo la puerta de aprobación final para sistemas sensibles. El autor aborda explícitamente las objeciones — alucinaciones e inyección de prompts indirecta, los límites de los tests automatizados (de ahí el property-based testing), la pérdida de experiencia de dominio (compensada mediante fine-tuning y RAG) — sin eludirlas. En cuanto al SDLC, vincula la revisión con las métricas DORA: acelerar el rendimiento de la revisión acelera el pipeline de despliegue. Sus recomendaciones son pragmáticas: pilotar primero en componentes de bajo riesgo, mantener un flujo de trabajo híbrido inicial (los agentes señalan, los humanos aprueban), medir las tasas de detección agente frente a humano, hacer explícitas las decisiones de rechazo y construir bucles de retroalimentación. Un texto deliberadamente provocador, pero una contratesis valiosa frente al dogma de la "puerta de revisión humana inviolable".

The pattern lineage: Why fifty years of design patterns may hold the key to growing the architects AI cannot replace

Wed, 10 Jun 2026 00:00:00 GMT

Philippe Ensarguet (Orange) parte de una pregunta en apariencia administrativa —diseñar una vía de capacitación hacia el rol de arquitecto— para articular una intuición más profunda. Este rol es crítico para la "platformización" de un operador de telecomunicaciones (unir los mundos de IT y de red, separados durante décadas, en plataformas programables). Sin embargo, se vuelve crítico justo en el momento en que su cadena de formación se está desmoronando: la demanda de arquitectos aumenta (la plataformización, el cloud-native, el giro de la IA agentique desplazan la complejidad de los componentes hacia las relaciones entre ellos), mientras que la cadena de suministro de talento se desmantela a sí misma. La vía tradicional pasaba por años escribiendo código; la IA absorbe ahora una parte creciente de ese trabajo. Si el trabajo de nivel inicial que antaño forjaba a los arquitectos se delega a las máquinas, ¿de dónde vendrá la próxima generación? La respuesta, según Ensarguet, lleva cincuenta años esperando en el estante. Retoma el sentido original de un patrón, tal como lo definió el arquitecto de edificios Christopher Alexander (1977): una solución recurrente y nombrada a un problema dentro de un contexto, incluyendo las fuerzas en tensión y las consecuencias. No es una receta: es un juicio transmisible. El libro del Gang of Four (1994), surgido del Hillside Group convocado por Kent Beck y Grady Booch, dio a la industria su primer vocabulario compartido — su valor perdurable reside en el formato (problema, contexto, fuerzas, solución, consecuencias), no en los 23 patrones en sí. Ensarguet traza un árbol genealógico: POSA (1996), Fowler (2002), Hohpe & Woolf (2003), Nygard (2007, Circuit Breaker), los catálogos de nube (2012 en adelante), microservicios y Kubernetes (2018-2019), hasta los corpus agentique que se están formando ahora ("Building Effective Agents" de Anthropic, los cuatro patrones de Andrew Ng, el marco de dos ejes de Huang & Zhou en 2026 — que retoma los dos ejes del GoF treinta años antes). Bajo los catálogos persisten seis fuerzas invariantes: acoplamiento/cohesión, frontera de abstracción, aislamiento de fallos, gobernanza del estado, indirección, bucle de retroalimentación — a las que se suma una séptima, el no determinismo introducido por los sistemas agentique. Esta "pattern literacy" es la competencia resiliente, y la única que finalmente tiende un puente entre IT y red (control plane / user plane = indirección; network slicing = Bulkhead; intent-based networking = bucle de retroalimentación). La IA se convierte entonces en un aliado: liberada de la implementación, la formación puede volverse deliberada — la máquina produce opciones, el humano aporta el juicio. Lo que hay que enseñar es la gramática, no los catálogos: los catálogos envejecen; la forma de pensar que codifican no. Ensarguet publica esta tesis precisamente para someterla a debate.

How AI Changes the SDLC: A Six-Stage Guide

Mon, 08 Jun 2026 00:00:00 GMT

Esta guía de Augment Code, redactada por Paula Hingel, propone un modelo de **seis etapas** para comprender cómo los agentes de IA están reestructurando el ciclo de vida del desarrollo de software. Su tesis central: la IA no mejora uniformemente el SDLC — aumenta el rendimiento en algunas etapas mientras eleva el riesgo de inestabilidad en otras. Este desequilibrio no es una fatalidad tecnológica, sino el síntoma de una adopción desigual llevada a cabo **sin redefinir los límites de revisión**. El artículo se apoya en el **informe DORA 2025**, que establece una correlación positiva entre la adopción de IA y el rendimiento/desempeño del producto, pero una **correlación negativa con la estabilidad de la entrega**: la madurez del proceso importa más que la herramienta. Las seis etapas se releen bajo este prisma. (1) **Requisitos y planificación**: la especificación se convierte en el mecanismo de control que dirige al agente; los humanos se centran en la calidad del requisito y en resolver la ambigüedad. (2) **Diseño y arquitectura**: más decisiones requieren revisión humana explícita, para evitar el "vibe architecting" — decisiones de infraestructura o integración tomadas en segundos, más rápido de lo que la gobernanza puede seguir. (3) **Implementación**: el desarrollador pasa de escribir código a orquestar, validar y aprobar. (4) **Pruebas y QA**: el riesgo central es la **validación circular**, donde las pruebas generadas por IA confirman código generado por IA en lugar de verificar el requisito real; una especificación precisa es la salvaguarda. (5) **Despliegue**: las ganancias de rendimiento crean riesgos de estabilidad, de ahí la necesidad de controles de rollback más sólidos. (6) **Mantenimiento y operaciones**: los agentes se encargan de la detección y la corrección, los humanos gestionan las excepciones y el endurecimiento. Se nombran tres riesgos estructurales: **erosión del pipeline junior** (automatizar tareas fundamentales más rápido de lo que se rediseñan los roles junior reduce la futura reserva de seniors), la validación circular y las brechas de gobernanza a escala. En paralelo, surgen tres roles: **Intent Engineering** (traducir objetivos ambiguos en especificaciones comprobables), Agentic DevOps/Infra (orquestar agentes) y AI Governance/Assurance. La guía se respalda en datos: el 70% del tiempo del desarrollador dedicado a comprender código existente, un estudio de CMU (807 repositorios) que muestra +30% de incidencias de análisis estático y +40% de complejidad, y el sistema DRS de Meta (>10.000 cambios desplegados durante una congelación de código). Concluye con cinco recomendaciones operativas: auditar una etapa antes de escalar, someter la gobernanza a pruebas de estrés, situar la especificación en el centro, definir políticas explícitas de rollback y rediseñar el rol junior en torno a la revisión.

Solving the Identity Crisis for AI Agents

Thu, 21 May 2026 00:00:00 GMT

Artículo de ingeniería publicado en el blog de **Uber** Engineering por seis ingenieros (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) el **21 de mayo de 2026**, que expone la **doctrina de identidad y control de acceso de agentes de IA** desplegada en producción en Uber para varios miles de agentes internos. **Tesis central**: los modelos de identidad existentes (humanos + cargas de trabajo) no logran describir la **agencia** — *"un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar"* — y pierden la **procedencia** a lo largo de los saltos de un flujo de trabajo agéntico. **Dos problemas operativos identificados**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delegación es el modo por defecto, los flujos de trabajo son composicionales (agentes que llaman a agentes que llaman a herramientas), el comportamiento es dinámico (los planes evolucionan según resultados intermedios); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"El contexto de ejecución (usuario de origen, agentes intermedios) se pierde a través de los saltos entre agentes."* **Arquitectura propuesta** como extensión de la Zero Trust Architecture de Uber: **Agent Registry** (fuente de verdad para las asignaciones agente↔carga de trabajo) + **AI Agent Mesh** (plano de datos entre agentes) + **STS (Security Token Service)** (emisión de JWT de alcance breve) + **MCP Gateway** (punto de aplicación de políticas para la invocación de herramientas) + **AI Gateway** (mediación de las llamadas a LLM externos con barreras de seguridad) + **SPIRE** (proveedor de credenciales de carga de trabajo). **Mecánica criptográfica**: las cargas de trabajo obtienen de SPIRE **SVID (SPIFFE Verifiable IDs)** firmados criptográficamente → el SDK solicita un JWT al STS mediante la identidad de la carga de trabajo → el STS verifica la autorización del agente contra el Agent Registry → se emite un token de vida corta (TTL del orden de minutos) para un **destino específico de un único salto** (claim `Audience` dirigido). **Doctrina central**: ***"Tokens de un único salto y de vida corta. Cada JWT emitido por el STS está pensado para un único salto, con un claim Audience específico y un tiempo de vida corto, del orden de minutos."*** **Preservación de la cadena de actores**: un ejemplo multisalto con el ingeniero de guardia `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; el JWT final transporta una **cadena de actores** verificable `[user1, oncall-agent, investigation-agent]`, lo que permite decisiones de acceso a nivel de herramienta basadas en el **historial completo de la solicitud**. **Estandarización**: un **Standardized A2A (Agent-to-Agent) Client** que automatiza los intercambios con el STS y la propagación de la cadena de actores — *"la ruta segura es también la ruta más fácil para que los desarrolladores implementen llamadas A2A"* — con una migración por fases de los agentes heredados. **Métricas de producción**: ***"la latencia P99 de la API STS Token Exchange se mantiene sistemáticamente por debajo de 40 milisegundos,"*** miles de agentes internos incorporados, un panel de observabilidad en tiempo real que traza las sesiones multiagente. **Visión a largo plazo — marco de tres capas**: (1) Identity & Trust Foundation (identidad de agente verificable + cadenas de delegación), (2) Dynamic Access Control (permisos basados en contexto + human-in-the-loop), (3) Unified Enforcement Plane (política centralizada y observable). **Alineación con estándares**: el grupo de trabajo IETF **WIMSE** + el draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, fundamentado conceptualmente en **OAuth 2.0 Token Exchange (RFC 8693)** y **SPIFFE/SPIRE** (graduado por la CNCF). La primera publicación de referencia de un hyperscaler ajeno a los laboratorios de IA (logística/movilidad) que industrializa la seguridad de los agentes a nivel de infraestructura, cerrando la brecha doctrinal entre los frameworks de skills/harness (Vincent, Lattice, PROJ-AI) y las cuestiones de identidad de nivel empresarial.

How the X Algorithm Actually Works in 2026 — and What That Means for Growth

Sat, 16 May 2026 00:00:00 GMT

Informe interno de desmontaje técnico sobre el lanzamiento de código abierto **`xai-org/x-algorithm`** (15 de mayo de 2026) — el algoritmo del **feed For You** de **X (antes Twitter)** en 2026, con cuatro líneas de recomendaciones de crecimiento adaptadas a la audiencia (personal/fundador, marca/empresa, marco generalizado, entregable de consultoría/cliente). **Tesis central**: ***« La famosa tabla de pesos de 2023 —las respuestas cuentan más que los me gusta por un gran multiplicador— describe un sistema que ya no existe en esa forma. »*** El algoritmo de 2026 es un **transformer (Phoenix, derivado de Grok-1)** que aprende pesos a partir del historial de interacción de cada usuario, evaluado frente a una **superficie multiacción de 19 dimensiones**, filtrado por un servicio offline de comprensión de contenido (**Grox**). **La forma de la puntuación importa ahora mucho más que las cifras — y las cifras en sí no están en el lanzamiento público**. **Arquitectura de 4 componentes**: (1) **Home Mixer** (Rust, orquestador en tiempo de solicitud, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, almacén en memoria alimentado por Kafka con publicaciones recientes, búsquedas de sub-milisegundo para candidatos in-network); (3) **Phoenix** (ML en JAX, recuperación two-tower + transformer de ranking, ~derivado de Grok-1); (4) **Grox** (offline, clasificadores de spam/seguridad/PTOS/banger + embedder multimodal v5). **Las 19 acciones predichas por Phoenix** (cambio clave respecto a 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (visualización de calidad de video condicionada por duración mínima), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continua). **Puntuación final** = `Σ (weight × P(action))` modificada por **3 multiplicadores estructurales**: (a) **OON_WEIGHT_FACTOR < 1** (penalización por fuera de red), (b) **decaimiento de diversidad de autor** `(1-floor) × decay_factor^position + floor` (atenuación exponencial de publicaciones repetidas del mismo autor dentro de un mismo render), (c) **umbral de duración de video** (vqv solo contribuye si `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Advertencia clave**: **ningún valor numérico de peso** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) está en el lanzamiento — todo es `crate::params::*`, gestionado por un servicio interno de feature-switch de X para pruebas A/B. ***« Cualquiera que diga que 'las respuestas valen N,N× más que los me gusta en 2026' está inventando una cifra que no se puede derivar del lanzamiento OSS. »*** **Diferencias clave frente a 2023**: (1) eliminación de todas las características diseñadas manualmente (*« Hemos eliminado cada una de las características diseñadas manualmente y la mayoría de las heurísticas del sistema »*); (2) un único modelo que predice 19 acciones frente a múltiples modelos de una sola acción; (3) Grox separa la comprensión de contenido del ranking; (4) nuevas señales de primer nivel (dwell continuo, vqv condicionado, follow_author, 3 variantes de share); (5) recuperación OON two-tower (frente a SimClusters+heurísticas) con embeddings multimodales de texto+imagen+video-ASR. **Tres capas de alcance** (marco generalizado): Elegibilidad (binaria, Grox+filtros) → Recuperación (probabilística, ANN two-tower) → Ranking (continuo, suma ponderada + multiplicadores). **Dos leyes del crecimiento mecánico**: (1) La red interna (in-network) es multiplicativa, la externa (OON) es aditiva; (2) La función del modelo es predecirte, no recompensarte. **Límite deliberado de honestidad**: el checkpoint de Phoenix publicado = versión mini (2 capas, 4 cabezas, 256 dimensiones, corpus de 537K publicaciones deportivas), no el modelo de producción; las integraciones Thrift están simuladas (`panic!("Not implemented")` en `candidate_features.rs`); las listas de brand-safety, los mapeos de ID de temas, las penalizaciones por idioma y las reglas de mezcla de anuncios están ausentes del lanzamiento público.

The Ontology Pipeline™, Refresh: Where We Were, Where We Are, and Where We're Headed

Mon, 04 May 2026 00:00:00 GMT

**Jessica Talisman MLS** (Ingeniera Semántica + Arquitecta de Información, más de 25 años de experiencia, anteriormente en Adobe en grafos de conocimiento RDF + anteriormente en Amazon en arquitectura de información, fundadora del **Ontology Pipeline Framework** + **Contextually LLC**) publica en **Modern Data 101** (Substack, ~20.000 miembros) el **4 de mayo de 2026** una revisión importante de su framework **Ontology Pipeline™** publicado inicialmente en enero de 2025. **Tesis central**: desde noviembre de 2022 (ChatGPT), la demanda de *infraestructura semántica* se ha disparado, pero ha generado una **confusión masiva** — *"proveedores que ofrecen atajos que evitan el trabajo fundacional esencial, creando pasivos disfrazados de activos"*. El pipeline original de **5 etapas** (vocabulario controlado → estándares de metadatos → taxonomía → tesauro → ontología → grafo de conocimiento) sigue siendo válido, pero **debe completarse con 2 adiciones críticas**: **(1) Gobernanza** como práctica de ingeniería continua (no como documentación posterior al proyecto); **(2) Asociación con IA** (AI Partnership) con una distinción clara entre aumentar y reemplazar. **Diagnóstico del mercado**: *"una taxonomía estructuralmente inválida no es una taxonomía"*, *"las listas no son infraestructura de conocimiento"*, taxonomías generadas por IA vendidas como estrategia, proveedores que hacen un uso indebido del término *"ontología"*, soluciones genéricas (cookie-cutter) presentadas como metodología. **Crisis educativa**: la demanda de ingenieros semánticos supera ampliamente la oferta de profesionales formados; la brecha la llenan personas *"que conocen el vocabulario sin la metodología"*. **Posición normativa explícita**: *"la IA que genera una taxonomía de forma masiva está produciendo un pasivo disfrazado de activo; la IA que asiste a ingenieros formados es simplemente inteligente."* **Roles aceptables de la IA**: extracción de entidades, análisis de brechas, redacción de vocabularios candidatos para revisión, apoyo en la población/validación. **Roles inaceptables de la IA**: *generación masiva de taxonomías sin validación humana frente a estándares*. **Estándares referenciados**: SKOS, OWL, RDF, SPARQL. **Credibilidad**: framework validado en **6 instituciones a lo largo de 10 años**. **Recomendaciones para 3 audiencias**: (a) Organizaciones — invertir en formación formal, tratar la infraestructura de conocimiento como la columna vertebral de la IA, gobernanza continua, IA como acelerador y no como reemplazo; (b) Profesionales — preguntas de competencia antes del modelado, validar frente a SKOS/OWL/RDF, la dificultad de definición señala una pausa, el mantenimiento es continuo; (c) Líderes — actualización de competencias de la plantilla sin formación autofinanciada, asignar recursos a la infraestructura de conocimiento como necesidad estratégica, gobernanza antes del despliegue. **Citas destacadas**: *"el trabajo no se puede saltar"*, *"la gobernanza es la práctica de ingeniería que mantiene una ontología coherente a través del cambio"*, *"enseñar esto es difícil. Aprenderlo es más difícil."* **Relevancia importante** para líderes de datos / CDOs / arquitectos que construyen los fundamentos semánticos de sus agentes de IA. Para leer junto con: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — la ontología como único moat*; Foundation Capital Context Graphs (2025-12-22); Bain parte 2/5 *rediseñar los fundamentos de datos para la preparación de agentes* (2026-05); DORA ROI 2026 *datos internos accesibles para IA + ecosistemas de datos saludables* (2026-04-21); doctrina de seis zonas de Habert PROJ-AI (2026-05-05). Convergencia con el corpus 2026 sobre *"los fundamentos de datos como moat"*.

There is a growing disconnect in the way people think about building AI agents

Fri, 17 Apr 2026 00:00:00 GMT

Tony Seale, The Knowledge Graph Guy, identifica una desconexión creciente en la forma en que la industria construye agentes de IA. Por un lado, la industria invierte fuertemente en frameworks de orquestación: LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK — cada uno con sus propios grafos de orquestación, máquinas de estados y lógica de enrutamiento. Por otro, los practicantes de vanguardia se han movido hacia el paradigma de "modelo potente en un harness potente" (Claude Code, Codex, OpenClaw, Hermes). **El colapso de los frameworks.** Los primeros frameworks eran necesarios cuando los modelos no podían gestionar tareas multietapa por sí solos. Cita de Anthropic: "Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions can quickly go stale as models improve." Un andamiaje construido para un modelo limitado hándicapa a un modelo inteligente. Debería disminuir con el tiempo, no acumularse. Lo que queda es simple: un modelo potente en un harness potente. Muchos, interactuando, colaborando. Sin necesidad de framework. **Los agentes aislados no bastan.** Acceso al ordenador ≠ comprensión. Se le da a un agente 1000 documentos: busca, espera, adivina. Multiplíquese eso por 50 agentes sin un modelo de mundo compartido y se obtiene una inteligencia aislada pero incoherente en combinación. A escala empresarial, el entorno de información necesita estructura — un modelo de dominio compartido, con el humano en el bucle. **La simetría.** La respuesta es aplicar la misma simplificación en el lado de los datos. El modelo se ubica en un harness que le da acceso al ordenador; los datos se ubican en una ontología que les da estructura y significado. La ontología define lo que existe, sus propiedades, sus relaciones — la interfaz mediante la cual los agentes comprenden los datos. Dos patrones simétricos: (modelo potente + harness potente) y (datos potentes + ontología potente). **El Agente Semántico.** Su combinación produce el Agente Semántico: (Modelo + Harness) + (Ontología + Datos). No solo genera, empieza a comprender. Todo lo demás es andamiaje — útil por un tiempo, pero destinado a desmontarse. **Lo que se posee.** Todos tienen acceso a los mismos modelos de frontera; cualquiera puede construir un harness. Eso es comodidad, y se diluye cada día más. Lo que NO es comodidad: la ontología propia, el modelo de dominio propio, el conocimiento estructurado y vinculado que captura cómo la organización propia comprende el mundo. Los frameworks son una fase transitoria. Los modelos se alquilan. Lo único que queda por construir — y que se posee — es el conocimiento.

Building for trillions of agents

Sat, 07 Mar 2026 00:00:00 GMT

Aaron Levie, CEO de Box, publica un ensayo estratégico sobre la transformación fundamental del software en un mundo donde los agentes de IA se convierten en los usuarios principales de cada aplicación. Observa que, desde finales de 2025, los agentes han cruzado un umbral decisivo: ahora cuentan con su propio entorno de cómputo aislado (sandbox), pueden escribir y ejecutar código, interactuar con APIs y CLIs, y gestionar sus propios archivos y memoria a largo plazo. Esta arquitectura, definida inicialmente por los agentes de codificación (Claude Code, Devin, Codex, Cursor, Replit), se ha extendido a todo el trabajo del conocimiento con agentes como Claude Cowork, Perplexity Computer, Manus y OpenClaw, este último funcionando de forma continua (24/7) en un entorno persistente. Levie predice que cada empleado dispondrá de numerosos agentes, con 100 a 1000 veces más agentes que personas dentro de una empresa, lo que equivale a billones de agentes a nivel global. Adaptando el célebre consejo de Paul Graham ("Make something people want"), Levie propone un nuevo paradigma: "Make something agents want". Los agentes elegirán ellos mismos las herramientas más adecuadas, sin dejarse influir por el marketing tradicional. La consecuencia mayor: todo debe volverse API-first. Sin una API, una funcionalidad no existe para los agentes. Las CLIs y los servidores MCP se vuelven indispensables. Levie cita a Jared Friedman, de YC, quien advierte que las herramientas que no permiten el registro (sign-up) vía API están "muertas para los agentes". Los modelos de negocio también deben evolucionar: el modelo por asiento (per-seat) ya no basta cuando un agente puede realizar horas de trabajo humano en unas pocas líneas de texto. Serán necesarios modelos basados en el consumo y el volumen, permitiendo potencialmente incluso que los agentes gestionen sus propios pagos. Levie describe a continuación el ecosistema de infraestructura necesario: entornos sandbox (E2B, Daytona, Modal, Cloudflare), gestión de archivos (Box), identidad y correo electrónico para agentes (Agentmail), búsqueda web (Parallel, Exa), pagos (Stripe, Coinbase), y potencialmente microtransacciones. La seguridad, el cumplimiento normativo (compliance) y la gobernanza se convierten en cuestiones mayores cuando los agentes manejan datos sensibles en flujos de trabajo regulados (farmacéutico, banca). Los agentes necesitarán identidades propias con controles estrictos sobre sus acciones y el acceso a los datos. En conclusión, Levie afirma que estamos entrando en una nueva era del software en la que las herramientas deben diseñarse específicamente para agentes que operan a una escala sin precedentes.