Rapport de recherche interne du **12 août 2026** consolidant, en vue d'une présentation, tout ce qui est publiquement documenté sur **Buzz** — le workspace humains + agents de **Block**, lancé le **21 juillet 2026** sous licence **Apache 2.0**. Il agrège les deux billets d'ingénierie déjà fichés avec l'annonce corporate, le dépôt GitHub, la presse, X, et **trois retours d'expérience indépendants** qui constituent les seules données non auto-déclarées du dossier. **(A) Un écart de vocabulaire documenté par citation** : le tweet de lancement de **Jack Dorsey** annonce *« model-agnostic, decentralized, self-sovereign, and open source »* ; l'`ARCHITECTURE.md` de Block écrit *« The relay is the single source of truth. All reads and writes flow through it. There is no peer-to-peer event exchange, no gossip, no replication. »* Le relais est donc unique et autoritaire par communauté : la « décentralisation » de Buzz est une **souveraineté organisationnelle** — auto-hébergement et identité portable — non une redondance réseau. Formule de **TFTC** : *« Two of those three hold cleanly. The third needs a qualifier. »* **(B) Une asymétrie entre la rigueur démontrée et le risque d'exploitation.** D'un côté, un formalisme rare pour une v0.4.x/0.5.x : spécification d'isolation multi-tenant **mécanisée en TLA+**, propriétés d'autorisation vérifiées en **Tamarin**, protocole de stockage Git model-checké, journal d'audit append-only à chaîne de hash, 127 *event kinds*, NIP-01/42/98/34. De l'autre, l'appartenance au canal est l'unité de permission — *« channel membership is not fine-grained tool authorization »* (João Queirós) —, les agents tournent en `--dangerously-skip-permissions` hors bac à sable sur le poste d'un humain, et l'observabilité manque : *« Buzz tells me an agent got a message. It doesn't tell me what happens next »* (DevTools Daily, qui rapporte des kills OOM silencieux). Block l'assume : *« the agent can do anything, and security rests entirely on restricting who can tell it what to do »*. **(C) La pile technique**, absente des billets fichés : relais **Rust** (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** via Blossom, client desktop **Tauri + React**. L'intégration agent passe par **`buzz-acp`**, harnais **ACP** qui branche goose, Codex et Claude Code et traduit **ACP ↔ MCP**, plus **`buzz-agent`**, agent maison. Le rapport se corrige lui-même sur un point : le *« +33 % de travail »* du TL;DR de Block est le **ratio de tâches terminées (20 contre 15 sur 44)**, non un gain de score — celui-ci passe de 59,1 % à 71,5 %, soit **+12,4 points**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
Page d'entrée de la **spécification officielle** de l'**Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultée le **2 août 2026**. Ce n'est pas un article daté mais un **artefact vivant** : la fiche est datée de son observation, pas d'une publication. **Énoncé de mission en une phrase** : *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **Le problème posé** tient en trois lignes : agents de codage et éditeurs sont **étroitement couplés** et *« interoperability isn't the default »* — chaque éditeur doit construire une intégration sur mesure par agent, chaque agent doit implémenter des API spécifiques à chaque éditeur. Trois conséquences nommées : **integration overhead** (chaque paire agent-éditeur demande du travail sur mesure), **limited compatibility** (un agent ne touche qu'un sous-ensemble d'éditeurs), **developer lock-in** (*« choosing an agent often means accepting their available interfaces »*). **La solution est explicitement calquée sur LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — avec le bénéfice réciproque : un agent qui parle ACP fonctionne avec **tout** éditeur compatible, un éditeur qui supporte ACP gagne accès à **tout** l'écosystème d'agents ACP. **Deux modes de déploiement, et c'est le point le plus sous-estimé** : les agents **locaux** tournent en sous-processus de l'éditeur en **JSON-RPC sur stdio**, mais les agents **distants** sont prévus en **HTTP ou WebSocket** — support déclaré *« work in progress »*, avec une collaboration en cours avec des plateformes agentiques. **Filiation technique avec MCP, plus forte qu'une simple complémentarité** : ACP *« re-uses the JSON representations used in MCP where possible »*, en ajoutant des types propres aux besoins d'UX du codage agentique (l'affichage de **diffs** est l'exemple donné) ; le format par défaut du texte lisible est le **Markdown**, choisi pour ne pas exiger que l'éditeur sache rendre du HTML. **Deux constats de gouvernance et de versionnement** relevés sur la page et non dans le discours ambiant : la navigation expose **v1 (Latest)** et **v2 (Draft)** — et **non un « ACP 1.2 »** —, et la barre de navigation lie **Zed Industries *et* JetBrains** côte à côte, aux côtés d'un **ACP Registry**, de **RFDs**, d'une section **Community**, de **Publications**, d'**Updates** et d'une page **Brand**. Bibliothèques officielles annoncées : **Kotlin, Java, Python, Rust, TypeScript**, plus un volet communautaire.
#Agent Client Protocol#ACP#protocole ouvert
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
Post X d'**Eric S. Raymond** (ESR, auteur de *The Cathedral and the Bazaar*, co-fondateur de l'Open Source Initiative, ~50 ans de code) — **contre-témoignage frontal au discours « les LLMs génèrent du code pourri et hallucinent, inutiles pour programmer »**. Sa thèse : cela **ne lui arrive quasiment jamais**, et **plus du tout depuis les deux dernières générations** de modèles qu'il utilise (« chat GPT 5.4 et 5.5 » sous **codex**). L'ancien symptôme — un modèle qui « déraille » en approchant sa limite de contexte — a disparu : codex affiche désormais un **avertissement rouge** invitant à **vider la session** au lieu de partir en vrille. **Empan d'usage** : IA appliquée à des **feature changes, refactoring et debugging sur 63 projets** en **C, Go, Rust, Python et shell** ; rédaction de documentation ; **décompilation d'un binaire DOS en source lisible**. **Routine de travail** installée : quand il rouvre un projet, il lance d'abord les **tests de régression**, puis démarre codex et lui demande d'**auditer le code** (bugs + suggestions d'amélioration). Verdict : les LLMs sont **« excellents et formidablement capacitants »** ; leur **pire limite** est une **« vision en tunnel architecturale »** — excellents pour générer du code à la spécification, mais parfois **aveugles aux patterns de plus haut niveau** — ce qu'il assume comme le **job de son « meatbrain »**. Le point le plus fort, contre-intuitif : les LLMs **ne se trompent PAS sur les détails et les cas limites** ; il se dit **moins bon qu'eux** sur ce plan (malgré 50 ans d'XP) car si un changement doit **toucher cinq endroits**, le modèle **les retrouve les cinq de façon fiable**, là où l'humain en corrige quatre et **débogue des heures** avant de trouver le cinquième oublié. Il interroge alors les **« downshouters »** : vivent-ils dans un **autre univers** ? Utilisent-ils de **vieux modèles faibles** ? Y a-t-il un **skill issue** qu'il ne voit pas parce que ses **habitudes mentales et sa communication** collent bien aux « poignées » de ces outils ? Enjeu qu'il juge important à trancher, car « des **milliards de dollars seraient gaspillés en token spend mal dirigé** ». Sa recette, « très simple » : **« Be clear in your thinking, tell the model what you want with precision, and good things happen »** — chute : « what am I missing here? ». À lire comme **contrepoint pro-LLM d'une figure historique de l'open source** au débat récurrent sur la (dé)valeur des agents de codage — écho au « skill issue » et à la discipline de spécification (cf. [[martignole-token-manifesto-2026-07-17]]), et en diptyque avec la prise de position doctrinale pro-outil-IA de **Linus Torvalds** au nom du kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
Compilateur C en Rust construit par 16 agents Claude parallèles autonomes - Anthropic
#Compilateur C#Rust#agents parallèles
Nicholas Carlini (chercheur équipe Safeguards, Anthropic)
Spec Drive Development - adéquation langages programmation pour génération code IA, TypeScript vs Python vs Go vs Rust
#Spec Drive Development#SDD#vibe coding
Deep Research Veille Interne
Augmented Coding vs Vibe Coding - Kent Beck - B+ Tree - GenAI - TDD - Rust Python - Substack
#Augmented Coding#Vibe Coding#GenAI
Kent Beck