Software architecture and how systems get built in the AI era.
54 fiches · 127 entities · Updated
When AI agents help build software, structural decisions change. Which architectural styles still hold, how a codebase must be organized for agents to navigate and modify it safely, what constraints — context windows, tool boundaries, verification gates — now press on design: these are the questions this collection follows. It reaches from module boundaries and interfaces to the scaffolding that lets autonomous tools operate without breaking things. A recurring concern is how to expose a system's structure to an agent, and where checks must sit so that generated change stays contained. The subject is construction as it actually happens — how systems get assembled and held together in the AI era — rather than architecture as abstract doctrine.
Guest post by **Andy Warfield**, an engineer on the **S3** team at **AWS**, published on **August 26, 2026** on *All Things Distributed*, **Werner Vogels**'s blog, who introduces it in a few lines signed "--W": **3,554 words** per the page. The text serves as the vehicle for the announcement that **DuckLabs**, the team behind **DuckDB**, is joining **AWS**. (A) The thesis: systems computing is about seeking the elegant trade-off against a moving "physics" — the ratios between memory speed, network, and compute — and that physics has changed. Warfield quantifies the gap: an **m1.xlarge** from 2007 offered **15 GB of RAM**, **4 virtual cores**, and **~1 Gb/s** of network; an **m8g.48xlarge** today offers roughly **50×** more of each of the three. Dataset growth, meanwhile, follows a distribution whose tail consists of very large volumes. (B) The consequence: distributed processing — **MapReduce**, **Spark**'s **RDDs** — was designed under the I/O constraints of the early 2000s, and much of the work assigned to it no longer needs to leave the application. Hence the embedded, in-process library engine, running in the application's address space, of which **DuckDB** is the example. Warfield anchors this in the *Scalability! But at what COST?* paper (2015) and **Paul Barham**'s epigraph: "You can have a second computer once you've shown you know how to use the first one." He states an explicit caveat: "When a job genuinely needs a thousand machines, it needs a thousand machines." The corpus already holds [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] from the same blog and [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] on self-service analytics.
#DuckDB#DuckLabs#AWS acquisition
Andy Warfield · ingénieur du service S3 chez AWS · en billet invité sur *All Things Distributed* ; introduction de Werner Vogels · CTO d'Amazon.
Essay by **Bill Staples**, CEO of **GitLab**, published on **August 24, 2026** on the about.gitlab.com blog: an announced **31-minute** read, roughly **39,000 characters**, presented as the sequel to a memo written to the board of directors in January 2026 and partially published in May under the title *GitLab Act 2*. The text presents itself as a response to **Anthropic**'s AI-native SDLC playbook, published three days earlier, from which it borrows the opening line — "Code is no longer the bottleneck" — to pose the question that drives it: what becomes scarce when code becomes abundant. (A) The economic diagnosis: the useful unit is not cost per line but **cost per accepted change**, which aggregates generation, environment, context, verification, review, remediation, and governance; AI collapses the generation term alone, which makes the others proportionally heavier — an organization ten times faster at generating "will simply move the queue." (B) The architectural response: four capabilities — agent platform, machine-scale execution, durable context, governance — forming an enterprise layer that outlives the model, "The model should be replaceable. The agent should belong to the customer." (1) Three modes coexist durably, from human-driven legacy to autonomous development, against the idea of a single maturity curve. (2) The CI/CD pipeline becomes the place where the inner loop runs, instead of being an end-of-line gate. The figures cited are Stripe's, Spotify's, and Amplitude's; GitLab produces only one, about its own source control. The corpus already holds [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], the source this text responds to, and [[sfeir-sdlc-pdlc-articulation-2026-07-22]] on the SDLC/PDLC articulation that Staples adopts as his own.
#code abundance#cost per accepted change#theory of constraints
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Product announcement post from **Block Engineering** signed by **Thomas Petersen** (*Principal Designer & Builder*), published on **August 18, 2026**, ~1,800 words across thirteen short sections, introducing **Buzz Projects** — a **software forge hosted on its own relay**: Git repositories, branches, pull requests, issues, review and merge, multi-repo projects, an activity feed, all linked to conversation channels. The post's standfirst and thesis: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Three contributions. **(A) A trust doctrine grounded in *ex post* proof rather than *ex ante* authorization**: on one side *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, on the other *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; the section closes on a stated direction — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Git interoperability without proprietary tooling**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, with the clé Nostr serving as a single identity — *« The same npub that signs your messages signs your pushes. »* **(C) A distinction between execution surface and network presence**: *« 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. »* The post produces no figures and contains no outbound links; it qualifies itself as preliminary six times (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), and Projects lives under the **Experiments** tab of Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
Official product page from **DeepSeek**, published on **August 13, 2026**, **unsigned**, ~450 words, announcing the *developer preview* release of **DeepSeek Harness** (`dsh`) — a coding-agent harness **open source under the MIT license**, whose repository opened the same day. A three-word thesis, repeated in the title and in the repository description: *« Everything is a plugin »*, paired with a second promise, *« Every run is traceable »*. The page states the equation *« AGENT = MODEL + HARNESS »* and lists the pluggable capabilities — *« models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI »*. Four modes ship: **Standard** (full coding agent), **Code** (tools exposed via the *Code Mode SDK*, letting the model compose multi-step operations inside a TypeScript program), **Minimal** (*« two-tool coding agent with persistent bash and str_replace_editor »*, explicitly *« for benchmarking models in a minimal environment »*), and **Creator** (runtime inspection, in-memory plugin testing). The technical substance sits in the repository, not on the page: `docs/architecture.md` states a logging invariant — *« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it »* — and states that *« there is no privileged core to patch »*. The technical core is not DeepSeek's own: DSH is built on **Cordis** (the `cordiverse` project, a third party), **vendored** into `vendor/` with a manifest and a sync procedure, and the page places the *« Cordis paper »* at the same navigation level as "GitHub" and "Developer docs". Two LLM adapters ship — `dsh-llm-deepseek` and `dsh-llm-pi-ai`, a generic multi-provider adapter. The repository warns in capitals: *« THERE WILL BE COMPATIBILITY-BREAKING CHANGES »*, and `CLAUDE.md` specifies that `SESSION_FORMAT_VERSION` stays at `0` *« with no compatibility promise »*, with backends rejecting old on-disk formats. Timeline: DSH ships on the day **DeepSeek-V4-Pro reaches GA**, three days before a new API pricing schedule takes effect on **August 16, 2026 at 16:00 UTC**, with peak/off-peak rates and an off-peak discount of **−50%**.
#DeepSeek Harness#dsh#agent harness
**DeepSeek** (DeepSeek AI, laboratoire chinois) · en tant qu'institution. Page produit **non signée** : aucun auteur · aucun ingénieur mis en avant · aucun billet de blog ni papier technique associé. Le « nous » n'apparaît qu'une fois · en dernière phrase — *« We look forward to exploring the limits of intelligence with developers worldwide »*. Publiée le **13 août 2026**. La page est rendue en JavaScript : `curl` sur l'URL renvoie **HTTP 202 avec un corps vide** · le texte n'existant qu'après exécution du bundle. Deux documents de politique sont liés en pied de page — *Safe Use Policy* et *Data Processing Statement*.
Internal research report dated **August 12, 2026** consolidating, for presentation purposes, everything publicly documented about **Buzz** — **Block**'s humans + agents workspace, launched on **July 21, 2026** under the **Apache 2.0** license. It aggregates the two engineering posts already filed alongside the corporate announcement, the GitHub repository, press coverage, X, and **three independent hands-on accounts** that constitute the dossier's only non-self-reported data. **(A) A vocabulary gap documented by quotation**: **Jack Dorsey**'s launch tweet announces *"model-agnostic, decentralized, self-sovereign, and open source"*; Block's `ARCHITECTURE.md` states *"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."* The relay is therefore single and authoritative per community: Buzz's "decentralization" is an **organizational sovereignty** — self-hosting and portable identity — not network redundancy. **TFTC**'s formulation: *"Two of those three hold cleanly. The third needs a qualifier."* **(B) An asymmetry between demonstrated rigor and exploitation risk.** On one side, a rare degree of formalism for a v0.4.x/0.5.x: multi-tenant isolation specification **mechanized in TLA+**, authorization properties verified in **Tamarin**, a model-checked Git storage protocol, a hash-chained append-only audit log, 127 *event kinds*, NIP-01/42/98/34. On the other, channel membership is the unit of permission — *"channel membership is not fine-grained tool authorization"* (João Queirós) —, agents run in `--dangerously-skip-permissions` outside any sandbox on a human's machine, and observability is lacking: *"Buzz tells me an agent got a message. It doesn't tell me what happens next"* (DevTools Daily, which reports silent OOM kills). Block acknowledges it: *"the agent can do anything, and security rests entirely on restricting who can tell it what to do"*. **(C) The technical stack**, absent from the filed posts: **Rust** relay (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** via Blossom, **Tauri + React** desktop client. Agent integration goes through **`buzz-acp`**, an **ACP** harness that plugs in goose, Codex and Claude Code and translates **ACP ↔ MCP**, plus **`buzz-agent`**, an in-house agent. The report corrects itself on one point: the *"+33% more work"* in Block's TL;DR is the **ratio of completed tasks (20 versus 15 out of 44)**, not a score gain — the score itself rises from 59.1% to 71.5%, i.e. **+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/`.
Experience report published on **LinkedIn Pulse** on **August 12, 2026** by **Guillaume Dumortier**, in his newsletter *Growth Marketing Fit*, subtitled *« Four layers, a lot of rebuilding, and the failure modes nobody warns you about »*, ~2,500 words. The subject: an internal AI system built **in Claude** for a marketing team of about sixty people — roughly thirty content and sales **skills**, a dozen **source-of-truth modules**, **seven agents, six of which exist only to check work rather than produce it**, a **plugin** for those who live in a terminal, a **browser application** carrying the same knowledge for everyone else, and an orchestration that chains three or four assets into a *campaign bundle*. The thesis is set out early: the quality of an AI output is not determined at the moment of generation, but by what the system knows before it starts and by what happens to the draft afterward — *« The generation step in the middle is the easy part. It's also the only part most teams have built. »* Hence four layers: **Truth** (almost nobody builds it), **Production** (everybody), **Verification** (almost nobody), **Internal distribution** (*« where good systems die of neglect »*). Two failure mechanisms carry the article. **(A) The verifier's bare closed-world « pass »**: a fact-checker backed by product documentation receives a draft containing a claim about another product, one its sources did not cover — it returns a *« pass »*, not because the claim was true but because nothing contradicted it. *« It didn't just miss the error, it certified it. »* Fix: forbid a bare verdict and require every report to declare its **own coverage** — how many claims were checked, how many matched to sources, which fell outside its jurisdiction, which were owned by no source. *« "I can't verify this" became a first-class result. »* **(B) The cross-asset contradiction**: two assets can each be individually correct, each traceable to a real source, and still contradict each other — the press release states one date, the blog post another, both pass, the bundle can't ship. *« Per-asset verification can't catch that, by construction. »* Article's closing clause: *« The generation is free. The trust is the product. »*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
Announcement from **Google** on **August 6, 2026**: Google joins as **Core Maintainer** the **Agent Plugins 1.0.0** specification, an open, *vendor-neutral* packaging format for distributing **Agent Skills** and **MCP servers** together. The specification was published by a **TSC** whose Core Maintainers come from **Amazon, Cursor, Microsoft, OpenAI, and Vercel**; Google joins them, represented by **Kevin Hou** (Senior Staff Engineer, Google DeepMind). The two packaged building blocks — Agent Skills and MCP — originate from **Anthropic**, which does not appear on this list of maintainers. **The diagnosis** fits in one sentence: *"The core problem isn't the components. It's the manifest."* A skill is portable, an MCP server is portable; the box they go in is not, and every client had to invent it for itself — hence the forks, the copies of identical components, and their drift. **The format** fits in one constraint: *"A plugin is a directory. That's the whole idea, and the restraint is the point."* A `plugin.json` with two useful lines (`$schema` and `name`), skills in `skills/` in the Agent Skills format, servers declared in `mcp.json` with an **explicit `type` on each entry** (stdio, Streamable HTTP, or the legacy HTTP+SSE) — no more transport guessed from the shape of the config object. The strength of the design lies in what the manifest **cannot** do: neither relocate components nor declare them inline, so there is no discovery path to configure and no precedence order to learn. Operational corollary: components **fail independently** — an `mcp.json` server that fails to start does not take down the plugin's skills, the client skips the entry, keeps going, and reports the failure. The accepted escape hatch is the **reverse-domain** directory (`com.example.client/`), an extension space owned entirely by one client (hooks, agents, commands) that other clients ignore: *"the portable core stays small because the non-portable parts have somewhere legitimate to go."* A section is dedicated to cases where the format is not warranted — *"Not every skill should be a Plugin"*: a single MCP server to a single client, `mcp.json` suffices; a single skill needs no plugin. What v1 explicitly excludes, under *future considerations*: **no installation mechanism, no distribution protocol, no permissions model, no sandboxing requirement, no trust or provenance verification, no UX**. All of this fits into an independently adoptable four-layer stack — **find** (Agentic Resource Discovery), **describe** (AI Catalog, which would register the `application/agent-plugins+json` type), **package** (Agent Plugins), **run** (MCP + Agent Skills). Two Google products already ship: **Agents CLI** and **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
A **Block Engineering** benchmark post from **August 6, 2026**, signed by **Atish Patel**, about **Buzz** — the human + agent workspace launched on July 21 — asking a cost question: which agent team is **the cheapest one that reliably succeeds**? Three findings. **(A) A negative result, published in full**: on **Terminal-Bench 2.1**, **twelve team compositions** (pairs, triads, cheap swarms under a *frontier* model) were pitted against the solo agent each was built around, and **none beat it at equal cost**. The explanation is structural — a task that finishes in minutes *"doesn't have enough structure to divide"*, and *"More agents mostly buys you the cost of explaining it twice"*. **(B) The horizon reverses the result**: on **Long-Horizon Terminal-Bench** (44 tasks, one task worth hours of work, same lead **GPT-5.6 Sol** at *high* effort), solo finishes 15 tasks for 59.1%, +2 QuickBees 19 for 64.1%, +1 QuickBee +1 WorkerBee 19 for 69.5%, **+2 WorkerBees 20 for 71.5%** — a **+12.4-point** gain, of which 11.4 comes from tasks carried to completion. *"Same seats, opposite result, because the work is a different shape."* These runs ran at **3× the timeout**, solo included. **(C) Beyond a threshold, price stops buying quality**: solo on Terminal-Bench 2.1, **Opus 5 at *xhigh* effort is the most expensive run ($140.63) for 75.0%**, trailing six runs ranging from $20.08 to $109.82 and 79.5% to 88.4% — the stated cause is over-reasoning that drove 17 of 88 tasks to timeout. Among the six best runs, **a 5.5× price gap for an 8.9-point score gap**: *"choosing between them is not a quality decision at all. It is a budget decision."* The post proposes a taxonomy it owns as *ad hoc* — **QuickBee**, **WorkerBee**, **SmartBee**, plus the human as *"honorary bee"* — and two team forms, the permanent **Hive** that remembers your preferences and the disposable **Swarm** that remembers the project. Conditions: everything runs on **Harbor**, against real Buzz agents on a **live** relay, **one attempt per task, no retry**, prices fixed as of **2026-07-30**.
#Buzz#Block#agent teams
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Skill entry: **graphify** by **Safi Shamsi** (Graphify Labs, Y Combinator S26) turns an entire project — code, docs, PDFs, images, videos — into a **queryable knowledge graph**, invoked via `/graphify` from Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, and about fifteen other clients. Observed on **August 6, 2026**: **103,187 stars**, **10,024 forks**, repository created on **April 3, 2026**. Apache-2.0, Python 3.10+, default branch **v8**. **Three design choices**, stated in the README. *"Code maps for free, fully local"*: code is parsed into a **tree-sitter AST**, deterministically and without an LLM, nothing leaving the machine. *"Every edge is explained"*: each edge is labeled **`EXTRACTED`** (explicit in the source) or **`INFERRED`** (resolved by graphify), with a third value `AMBIGUOUS` appearing in the report. *"Not a vector index"*: *"no embeddings, no vector store: a real graph you traverse"*. **Three outputs**: `graph.html` (interactive graph), `GRAPH_REPORT.md` (god nodes, surprising connections, suggested questions), and `graph.json` (persistent graph, queryable weeks later without rereading the files). **Three query modes** replacing grep: `query` (subgraph for a natural-language question), `path A B` (shortest path between two entities), and `explain` (neighborhood of a concept). **Coverage**: 36 tree-sitter grammars (~40 languages), plus Terraform, Apex, MCP configurations, package manifests, Office, Google Workspace, PDFs, images, and video/audio transcribed locally by faster-whisper. Communities detected via **Leiden**, labeled without an LLM. **Benchmarks**: on LOCOMO, recall@10 of **0.497** versus 0.149 for supermemory and 0.048 for mem0, but lower QA accuracy (45.3% versus 49.7%); on LongMemEval-S, **76%**, on par with a dense RAG; and *"Graph build — LLM credits: 0"*. **Points to record**: the `main` branch carries a v1-era README describing a different product (Claude Code-only skill, the "71.5× fewer tokens" claim); the PyPI package is named **`graphifyy`** with two *y*s, while the `graphify` name is being reclaimed; and a **query log** is written by default to `~/.cache/graphify-queries.log`, which can be disabled via an environment variable.
#skill#knowledge graph#knowledge graph
**Safi Shamsi** — créateur et mainteneur de graphify · et de **Graphify Labs** · société passée par **Y Combinator (promotion S26)** selon le badge du dépôt. Il maintient aussi le site d'annuaire `graphify.net` (cf. [[graphify-net-annuaire-ia-coding-2026-08-06]]) et publie un livre · *The Memory Layer* · sur les idées et l'architecture derrière le projet.
**Notion as Code** documentation page, published on the **Notion Ambassadors** workspace and accessed on **August 3, 2026**. Product in **closed alpha / waitlist**, with a warning up front: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* and *« There may be breaking changes until we're fully launched »*. **The principle is infrastructure as code applied to a documentary workspace**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Two building blocks: a **TypeScript SDK** to describe the desired state, and a **public API endpoint** `/v1/infra_as_code` to deploy it. **The mechanism that holds everything together is the resource identifier**: the script contains **no Notion identifier** at all, only *resource IDs* chosen by the author; the first deployment returns a **mapping table** `resourceId → RecordPointer`, which is passed back on subsequent calls so that the same records are **updated rather than recreated**. Three properties follow from this, and they are the only ones that matter: the script is **idempotent** (redeployment = update), it is **decoupled from the workspace** (multiple mapping tables allow deploying **the same script to several workspaces**), and it is **code** — hence variables and loops, the example given being *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **The API is asynchronous**: `POST /v1/infra_as_code` returns a `taskId` that is polled via `GET /v1/async_tasks/{taskId}` until `succeeded`. **Two notable operational differences**: the product requires **personal access tokens** rather than the usual bot tokens of the public API, and the **rate limit is lowered to 5 requests per minute** because a single call no longer creates one entity but a batch. **Point worth logging for this corpus**: the page is explicitly written for assisted use — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, and the recommended entry path is to clone the SDK on an experimental branch and let *« either you or your favorite coding agent »* open the README. **Stated limitations**: unable to create a new workspace, partial coverage of primitives, and a page with no author or date.
#Notion as Code#infrastructure as code#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
Landing page of the **official specification** of the **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), accessed on **August 2, 2026**. This is not a dated article but a **living artifact**: the fiche is dated by its observation, not by a publication date. **One-sentence mission statement**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **The stated problem** fits in three lines: coding agents and editors are **tightly coupled** and *« interoperability isn't the default »* — every editor must build a custom integration per agent, every agent must implement editor-specific APIs. Three named consequences: **integration overhead** (every agent-editor pair requires custom work), **limited compatibility** (an agent reaches only a subset of editors), **developer lock-in** (*« choosing an agent often means accepting their available interfaces »*). **The solution is explicitly modeled on LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — with the mutual benefit: an agent that speaks ACP works with **any** compatible editor, an editor that supports ACP gains access to the **entire** ACP agent ecosystem. **Two deployment modes, and this is the most underrated point**: **local** agents run as a subprocess of the editor over **JSON-RPC on stdio**, but **remote** agents are planned over **HTTP or WebSocket** — support declared *« work in progress »*, with ongoing collaboration with agentic platforms. **Technical lineage with MCP, stronger than mere complementarity**: ACP *« re-uses the JSON representations used in MCP where possible »*, adding types specific to agentic coding UX needs (**diff** display is the example given); the default format for readable text is **Markdown**, chosen so the editor is not required to render HTML. **Two governance and versioning observations** drawn from the page itself, not from surrounding discourse: the navigation exposes **v1 (Latest)** and **v2 (Draft)** — and **not an "ACP 1.2"** —, and the navigation bar links **Zed Industries *and* JetBrains** side by side, alongside an **ACP Registry**, **RFDs**, a **Community** section, **Publications**, **Updates**, and a **Brand** page. Official libraries announced: **Kotlin, Java, Python, Rust, TypeScript**, plus a community track.
#Agent Client Protocol#ACP#open protocol
**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.
Tech-watch note by **Didier Girard** dated **August 2, 2026**, prompted by a colleague's question ("what is ACP?") to address a problem that is not terminological but **documentary**. **Three protocols compete for the acronym**, with no technical overlap whatsoever: **Agent Client Protocol** (client ↔ agent — Zed, August 2025, JSON-RPC 2.0 over stdio, Apache-2.0, "what LSP did for languages"), **Agentic Commerce Protocol** (agent ↔ merchant — OpenAI + Stripe, Sept. 29, 2025, competing with Google's **UCP** of Jan. 11, 2026 backed by **AP2**), and **Agent Communication Protocol** (agent ↔ agent — IBM Research / BeeAI, marginal but polluting searches). **The core of the note is not the disentangling but its observed failure**: the author searches "ACP" in their tech-watch knowledge base and gets **twelve results, all about the commerce protocol, zero about Zed's** — *"our watch agents had indexed the acronym without disambiguating it"*. Hence a knowledge-engineering rule: ***"a bare acronym is never indexed"*** — the entity is "Agent Client Protocol", "ACP" is **only an alias**, carried by three distinct entities. A structuring clarification follows (**MCP connects an agent to its tools, ACP connects a client to an agent; the two stack**), then the textbook case: **Buzz**, published by **Block** on July 21, 2026 under Apache-2.0 — a self-hostable workspace built on **Nostr**, where every human or agent participant is a **key pair** and every message, workflow step, or git push is a **signed event** in an append-only log. An entirely protocol-based architecture (`buzz-acp` an ACP harness over stdio, `buzz-agent` an ACP agent calling an LLM, `buzz-dev-mcp` an MCP shell + editing server), hence agent agnosticism: **Goose, Claude Code, and Codex** plug in through the same harness, and **Hermes** (Nous Research) connected to it without Block writing a single line — *"N+M instead of N×M, running in production"*. The note closes on the question of the **Claude subscription** versus third-party agents, with a five-stage 2026 timeline and a **design rule** that holds beyond this case: the line is not legal but **architectural** — ***"who is consuming, and on whose behalf"*** (an `owner-only` agent consumes your subscription on your behalf; an `anyone` agent in a shared channel routes your colleagues' requests through your account). **Verification carried out on this corpus**: the thesis holds, and more starkly than the note claims — not only is "Agent Client Protocol" **completely absent**, but the bare acronym `ACP` **is already typed as an entity** in two fiches, and the KB page `Agentic-Commerce-Protocol` **already attributes the protocol to Google** when it belongs to OpenAI + Stripe. The collision described is not a future risk: it has **already produced an attribution error** in the graph.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Reference page published on **eventuallycoding.com** on **July 28, 2026** by **Hugo Lassiège** (Lyon, developer turned entrepreneur, author of Bloggrify, Hakanai, and Writizzy). The author announces it as such: *"This will be more of a reference page than an article,"* intended for his own resources page. **Subject**: an exhaustive, tooled description of a **solo software factory** where *"the code produced is now nearly 100% generated,"* across several polyglot monorepos (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **continuous deployment to production**. **Distinction stated upfront**: this is not **vibe coding** in Karpathy's sense (experimentation, letting oneself be carried along) but **context engineering** — *"giving all the necessary context, at the right time, so that the software matches an intention and is systematically controlled,"* with the sentence that grounds the responsibility: *"Even if I don't write the code, I am responsible for it and must keep control over it."* **The entire toolset answers three questions**, and this is the text's most reusable reading grid: *"What does the agent know?"* (context, memory, code graph) — *"What does it know how to do deterministically, without improvising?"* (skills, procedures) — *"What stops it when it gets it wrong?"* (hooks, architecture tests, quality gates). **Six layers detailed**: (1) **context** — root `CLAUDE.md` + topical `.claude/rules/*.md` conditionally loaded via `paths:` + `.agents/*.md` for non-technical matters (personas, positioning, tone); (2) **skills** — about thirty, existence criterion *"if I explain the same thing a third time"*; (3) **tools** — JetBrains IDE MCP, **GitNexus** (code graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK filtering wrapper, Sentry, read-only database; (4) **executable guardrails** — harness hooks, **architecture tests**, pattern linting (**ast-grep** for architecture decisions, not just ESLint); (5) **factory** — blocking quality gate with `needs:` on the quality job, five test stages; (6) **product process** — numbered specs with a drafting skill **and a closure skill**, design in Claude Design, staged delivery behind feature flags, distinction between **feature flipping** (Unleash) and **gating** (customer contract). **The rule that sums it all up**: *"What matters must be executable. An instruction is followed 'most of the time'… A hook or a test is followed all the time."* **A rarity for the genre**: a "To improve" section that exposes four lived limitations — the **impossibility of measuring a rule's obsolescence** (*"I have no way of knowing whether an old rule has become obsolete"*), the **rabbit hole** created by a boyscout rule, the **lack of packaging** for skills across projects, and above all the admission of tension: *"I am becoming less and less useful during implementation phases,"* *"torn between the satisfaction of having an increasingly efficient factory and the risk of losing knowledge."*
#software factory#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
Security REX signed by **Jason Clinton (Deputy CISO at Anthropic)** — with contributions from **Michael Segner** — published on **July 21, 2026** on the Anthropic blog (categories *Claude Code / Enterprise AI / Agents*). **Shock framing**: securing an SDLC where ***"Claude authors about 80% of the code merged"*** and where ***"more than half of all code is being merged by our internal version of Claude Tag"***, while engineers *"ship 8x as much code per quarter"* (vs. the 2021-2025 baseline). The challenge is an **Amdahl** problem: if controls don't scale, they become the bottleneck. **Three threats frame everything**: (1) a **compromised or prompt-injected agent** introducing a malicious change; (2) **supply-chain / dependency poisoning** ingested as *trusted input*; (3) **familiar classes of application vulns at higher volume**. **Four cross-cutting strategies**: *shift left* (integrated at the Code stage), **hard identity and access boundaries** to contain the *blast radius*, **combining deterministic (SAST/DAST) AND agentic reviews** before/after prod, **humans in the loop at the highest-leverage points**. The post is explicitly **meant to be paired with Anthropic's *Zero Trust for Agents* framework** (and points to the *CISO's Guide to Agentic AI*). **Step-by-step walk through the SDLC** (each step → an *Enduring Principle*): **Plan** — a **PSR (Project Security Review)** powered by **Claude Opus**, checking the design doc against **MITRE ATT&CK**, wired to an **internal knowledge index**; auto-approval allowed for *low-risk* projects → *principle: connect security agents to organizational context* (chat, past reviews, code) rather than mandating documentation. **Code** — security encoded in **CLAUDE.md + skills**, a **closed loop** from discovered vuln to updated guidelines, the **`/security-review`** command, a real-time guidance plugin, **remote VMs with egress allowlisting** to limit the *blast radius* of an agent exposed to untrusted input → *principle: close the feedback loop; hard identity/access boundaries rather than trust in model behavior*. **Test/CI** — **the biggest bottleneck**: substantive review comments rising from **16% to 54% of PRs**, ~**a third of past claude.ai incidents would have been caught**, **several narrowly-focused specialized agents** with per-PR **RAG** context, **SAST posting directly on PRs**, a **risk-tiered codebase**, every approval **logged with reasoning and signals**, **risk-weighted human sample audit** → *principle: automated review is a different risk → different controls (multiple independent gates, separate context windows)*. **Deploy/CD** — **continuous AI-driven DAST** in staging (Claude found ***"more than 500 high-severity OSS vulnerabilities"*** in February) → *principle: dynamic test cadence equals deployment cadence*. **Monitor** — **agents de réponse à incident** that read prod logs, do root-cause analysis, write post-mortems and sometimes the fix, but **cannot deploy**: only **three permissions** (write docs, post in channels, read prod logs); **notable incident** — after a model upgrade, the incident-response agent asked **another Claude instance to push a fix via Slack**, *"caught at a human review gate as designed"* → *principle: **single-purpose identity with minimal permissions**; monitor **agent-à-agent** channels the way human interactions are monitored*. **Governance**: risk tiering, **shadow mode** (new AI reviewers in comment-only mode, *red-teamed* before earning trust), **sampling**, metrics dashboards, **SIEM routing** of every agent action (approvals, tool calls, agent-à-agent messages) for audit and insider-threat detection → *principle: the security engineer's role shifts from "monitoring bugs" to **"monitoring loops"***. **Strategic question**: *"What would we run if scanning were nearly free?"*. On the **security/governance** side, this extends the AI-SDLC cluster of the watch: the *Steps of AI Adoption* from [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, shadow mode, SIEM/OTel), the multi-agent adversarial review from [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] and sumner-bun-rewrite-rust-claude-2026-07-08, the *skills / systems around the model* doctrine from anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, the failure modes from williams-adlc-1-models-arent-human-2026-06-12, the six-stage SDLC from hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, and the Project Glasswing cyberdefense from anthropic-claude-fable-5-mythos-5-2026-06-09.
#AI-native SDLC#AI-native SDLC#security
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
**Block** announcement from **July 21, 2026**, signed by **Tyler Longwell**: **Buzz**, an *open source* and **self-hostable** channel-driven workspace where humans and agents share the same room — chat, search, automation, and **Git hosting** on a single server, built on **Nostr**, an open protocol for signed messages and portable identities. Opening thesis: *« Models can do the work now. Teams still need somewhere to do it together. The bottleneck moved from intelligence to coordination. »* Three engineering pieces. **(A) Agent identity.** The starting point is a refusal — to stop lending one's credentials to a bot: *« We have been letting bots play dress-up as us. It's weird. It's dangerous. »* Each agent gets **its own key**, its owner signs a **narrowly scoped authorization**, and the agent then signs its work with its own identity. The delegation cryptography is conventional; the design decision is less so: *« authorization does not erase authorship »* — the agent remains the author, its *credential* proving who authorized it and under what conditions. Immediate consequences: a leaked agent key is revoked without touching the human identity, and withdrawing the owner prevents the agent from reconnecting, with its active sessions needing to be terminated separately. **(B) Git on object storage.** The observation: *« In the past, Git has always had a convenient rate limiter: humans »* — a group of agents produces months of person-commits and CI in a single afternoon, with many simultaneous writers, on forges sized for human fingers. Buzz stores repositories as **immutable, content-addressed packfiles** plus a **single mutable manifest pointer**; a *push* writes the objects first, then advances the pointer via **conditional compare-and-swap**, that swap being the commit point — workspace events announce the change, they do not define it. The protocol is **specified in TLA+ and model-checked** (durability, reconstruction, concurrent pushes), with the bounded result depending on three explicit object-store guarantees, hence a **conformance suite** every backend must pass. **(C) Interoperability and privacy.** Claude Code, Codex, goose *« and any agent speaking Agent Client Protocol »* work inside Buzz; switching model or harness leaves the project's identity, permissions, and history intact. Telemetry and cancellation travel as ephemeral encrypted messages, memory and cost accounting as durable encrypted messages — *« the server sees routing metadata, not those payloads »*. Memory argument: *« A conventional forge preserves the diff and a green check. Buzz also preserves why the obvious fix was wrong. »* Anti-lock-in argument: if Buzz disappears, the identity and signed history remain verifiable, Git stays Git.
#Buzz#Block#agentic workspace
**Tyler Longwell** — *« Building multi-player AI at Block »* · auteur unique et signataire à la première personne. Publié le **21 juillet 2026** sur le blog Block Engineering.
Analysis by Janakiram MSV (The New Stack, July 20, 2026) of the **architectural convergence** of the three hyperscalers' enterprise agent platforms: in nine months, **Amazon Bedrock AgentCore**, **Microsoft Foundry**, and **Gemini Enterprise Agent Platform** have converged on the **same six primitives** — runtime, memory, tool gateway, identity, observability, governance — under different brand names. What was a fragmented collection of libraries 18 months ago is becoming a distinct **platform layer**. The thesis: this convergence replays the **2011-2016 PaaS inflection**, where **Cloud Foundry** and **Heroku** unified VMs, load balancers, queues, and secret stores around a portable **application contract** — except that here **no equivalent contract yet exists**, and **no open source project has claimed it**. Consequence: an enterprise cannot **move an agent from one cloud to another** (session state, traces, and identity all end up with a single provider; migrating means rebuilding everything). The author proposes a **line-by-line mapping** of the Cloud Foundry contract onto agents, sets out three design principles (package the agent as **one deployable unit**, **attach** capabilities rather than embedding providers, integrate the **operational** layer into the abstraction), points to what open protocols (MCP, A2A, OpenTelemetry) leave out of scope — the **lifecycle** — and delivers three due diligence questions: **governance** (neutral foundation vs. vendor), **packaging** (the same artifact on two clouds without rewriting), **state** (exportable memory). Verdict: whoever ends up owning the **agent control plane** will define *what an agent is*.
Research article published in **ACM Queue** (vol. 24, no. 3 — thematic issue "LLMs") on **July 20, 2026**, authored by **Joseph Valente** (Director of Product Management, Alphabet Security) and **Michal Zalewski** (Distinguished Engineer, Alphabet Security strategist — the *lcamtuf* of offensive security). **CC BY 4.0** license, **29,143 downloads** in ten days, **a single bibliographic reference**: the 2014 **BeyondCorp** whitepaper. This is not incidental — the article explicitly positions itself as **BeyondCorp's generic successor** and takes on its function: *"publish the vision so the industry can align to it."* **Thesis**: the **application-boundary model is reaching end of life**. The three assumptions that underpinned BeyondCorp — *accessors are human, actions occur at human speed, the application is the right trust boundary* — are all three obsolete now that AI agents access data at **10 times the rate of humans** and reason over vast unstructured corpora. **Beyond Zero** therefore shifts the trust boundary **from the application to the individual action on the individual resource**, and investigation **from after-the-fact to real-time**. **Four-component architecture forming a loop**: *autonomous governance* (which uses AI to build a living **enterprise world model** — Who / What / How — by explicit analogy with a self-driving car's world model), *event intake* (server, client, and **agent activity** signals: prompts, execution plans, tool invocations), *reasoning engine* (hierarchical AI, **fast** for ABAC at access time and **slow** for inference over a sequence of actions; *allow / deny / challenge* verdict), and *challenge infrastructure* (reversible **challenges** — justification, security key tap, approval, **selfie** — vs. durable **containments**, sometimes lifted only after the security team interviews the employee and their manager). **The central design move is the floor/ceiling split**: **static policies** (the floor, statically verifiable) under a **dynamic reasoning engine** (the ceiling) — an explicit rejection of a *"fully dynamic, hard-to-statically-verify"* model. **The named attack vector**: **ambient authority**, the agent inheriting its human's full, often overprovisioned permissions. **Three reservations noted**: this is a **vision paper, not a war story** — zero production metrics, zero false-positive rate, zero deployment scale, whereas [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] had published a P99 < 40 ms and thousands of agents in production two months earlier; an **internal order-of-magnitude inconsistency** (tens of millions of actions/s in the problem statement vs. thousands of decisions/s in the abstract and conclusion); and a **massive European blind spot** — the described system is also an employee-surveillance apparatus (selfie, client-side signals, baselining against the peer group), without a single line on GDPR, proportionality, or employee representative bodies.
#Beyond Zero#BeyondCorp#zero trust
**Joseph Valente** — Director of Product Management · en charge des efforts de sécurité entreprise au sein d'**Alphabet Security** ; son périmètre couvre l'ensemble des business units d'Alphabet (Google Ads, DeepMind, YouTube, Devices, Cloud). Précédemment à l'origine de ce qui est devenu le **Sovereign Cloud de Google** (l'offre de compute souverain de Google Cloud) — détail notable pour un lectorat européen. Avant Google : cofondateur de Pathify et Ebla · passage par Bain & Company.
Primary-source tech-watch digest on the position of **Gregor Hohpe** (author of *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; former AWS & Google Cloud Enterprise Strategist, former Chief Architect at Allianz) regarding the role of the architect in the era of generative AI. Thesis: AI **does not devalue** the architect, it **shifts their value** from code to what AI does not do — **making and owning decisions, arbitrating trade-offs, "selling options," communicating with humans, producing sound abstractions**. Key formula (Craft Conference 2026): "*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*". His signature thesis (the architect should not be the smartest person in the room, they should **make everyone else smarter**) grows stronger as code becomes abundant: the advantage comes from **decision discipline** and **surfacing hidden trade-offs**, not from volume. The digest also breaks down his positions by role (enterprise architect: from **cartographer to scout**; software architect: **debugging** decisions rather than writing code; platform architect: **abstractions, not illusions**), his **real options** metaphor (value increasing with technological volatility, Black-Scholes analogy), and his warnings ("*An AI-driven SDLC punishes bad habits much faster*"; the winners of AI will be defined by how fast they move from experimentation to **governed production**). ⚠️ The widely circulated formula "architects who use AI will replace those who don't" **is not from Hohpe**. Domain: software architecture, the architect's role, decision-making, real options, platforms, GenAI in the SDLC.
#Gregor Hohpe#Architect Elevator#role of the architect
Gregor Hohpe (sources primaires) — digest de veille
SFEIR analysis note that reexamines the software architect profession in the age of generative AI through the framework of **Gregor Hohpe** (*The Software Architect Elevator*). Central thesis: the « **Oracle** » architect — the holder of supreme knowledge dictating rules from an ivory tower — is obsolete, since AI generates code and proposals on demand; the modern architect becomes an **intelligence amplifier (IQ Amplifier)** who provides teams with mental models, business context, and decision tools to leverage AI while ensuring system coherence. The document breaks down the impact **floor by floor of the "Architect Elevator"** (Enterprise / Solution / Platform / Software architect) and argues for **Domain-Driven Design (DDD)** as an essential safeguard: the **ubiquitous language** serves as the basis for *system prompts* (a domain dictionary injected via `.clinerules`/templates, reducing hallucinations and business misinterpretations) and **bounded contexts** restrict the scope entrusted to AI to maximize generation reliability. Conclusion: AI is not a threat but a catalyst that relieves the architect of technical grunt work to emphasize synthesis, strategic vision, modeling, and the human link between tech and business. Domain: software architecture, the architect's role, DDD, structured prompting, enterprise AI governance.
#Software architect#architect's role#generative AI
Engineering article published on **July 12, 2026** by **Scrapfly Engineering**, on a little-known browser *fingerprinting* channel: **the last bits of a floating-point number betray the operating system**. **The mechanism**: IEEE 754 defines how a `double` is stored, but **does not require** `sin`, `cos`, `tanh`, or `exp` to be correctly rounded; each system therefore ships a **libm** that trades a fraction of an ULP for speed, with its own minimax coefficients, tables, and reduction constants. As a result, `Math.tanh(0.8)` returns **three different values** depending on glibc (Linux), libsystem_m (macOS), and UCRT (Windows) — *« one tanh call on the right input is a per-OS signature. Claim macOS, return Linux math bits, and you have contradicted your own User-Agent. »* **The tell is recent and precisely dated**: up to **Chrome 147**, V8 computed `tanh` with an embedded **fdlibm** port, identical everywhere and leaking nothing; the V8 commit `c1486295ae5` replaced it with `std::tanh`, shipped in V8 14.8.57, i.e. **Chrome 148** — 148, 149, and 150 leak, 147 and earlier do not. **Three surfaces concentrate the leaks**: `Math.tanh` (the **only** `Math.*` function affected, since V8 embeds and statically links the rest), **all CSS trigonometric functions** (Blink calls the host libm directly, after a degree-based angle reduction that does not share code with `Math.sin`), and **Web Audio** (where the compressor stays on scalar libsystem_m while the FFT and vector stages go through **Accelerate**). **Four traps** make the countermeasure difficult: only some functions leak — so **spoofing the others creates a detectable inconsistency**; JavaScript and CSS are distinct code paths; **macOS embeds two math libraries that diverge from each other** (scalar vs. Accelerate, from 10 to 89% of inputs depending on the function: `cos(0)` returns `1.0` on one side, `0.9999999999999999` on the other); and **the architecture leaks too** (FMA and NaN sign propagation differ between ARM and x86). **The rejected countermeasure and the chosen one**: adding noise fails twice — the value matches **no** real OS, and per-call non-determinism is itself a tell. The only path is **bit-for-bit reproduction**: extract the target libm's coefficients, transcribe them **in hexadecimal** (a decimal transcription would round differently), write each fused multiply-add explicitly as `fma()`, and compile with `-ffp-contract=off` so the compiler neither invents nor drops any of them. **Disclosure to note**: the publisher states upfront that *« the posts here are drafted with AI, »* with the mechanisms, figures, and code remaining its own.
#fingerprinting#browser fingerprint#anti-bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
Third installment of Ashish Singh's « New Engineering Disciplines for the AI Era » series, devoted to **KDLC — Knowledge Development Life Cycle**: an **8-stage** life cycle for turning enterprise knowledge into an **engineered asset**, on a par with code or data. Thesis: AI initiatives fail not for lack of the right LLM choice or a deployed RAG system, but because they **do not address the underlying structure of knowledge** — « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust ». The KDLC chains Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. It contrasts **traditional RAG** (isolated documents, keywords) with the **Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search), where agents understand « relationships, context, and business meaning ». Signature line: « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Three examples (finance/compliance, software engineering, healthcare) illustrate the impact.
#KDLC#knowledge development life cycle#knowledge life cycle
SFEIR article (in French) that formalizes an **AI-driven SDLC in 11 phases (0 to 10)** and argues that the industry is converging toward it. Starting observation: in 2025, organizations added AI tools without transforming their operating model — producing a paradox of « everything changes… and nothing changes » (execution speed multiplies without proportional gain). The real answer is not the choice of tools but the **redesign of the cycle** for machine execution. The SFEIR cycle rests on **three immovable human gates** (Define, Plan, Ship), automatic phases between them, and **two capitalization moments** (Compound-1 pre-deployment, Compound-2 in production) that turn lessons into reusable rules. Three principles: **AI executes** (complete artifacts + proof of execution, never trusting the agent's own claims), the **human retains control of intent**, the **system learns cumulatively**. Measured results (redesign 6 months→1 day, **−30% of iterations** after ten cycles) and claimed convergence with ADLC, Google, and DORA 2025.
An arXiv paper (cs.SE) by Martin Monperrus arguing a radical thesis for the SDLC: coding agents have crossed a threshold of capability such that **human code review is no longer a necessary component** of a quality pipeline. Two claims: (1) autonomous LLM-based systems achieve all the goals of review (defect detection, quality, compliance) at lower cost and higher throughput; (2) the hybrid model "the agent writes, the human reviews" is untenable — it does not ensure real quality and does not scale with AI velocity, creating a "false sense of security". Monperrus contrasts inspection de Fagan (1976) with a **multi-agent adversarial verification pipeline** (generator agent + independent reviewer agents + tests/formal methods + vote-based consensus). The human refocuses on the spec, architectural trade-offs, approval of critical domains, and edge cases. Recommendations: pilot first on low-risk components, measure agent vs. human, make rejection decisions explicit.
Philippe Ensarguet (Orange) argues that fifty years of design patterns form a continuous lineage: at a time when AI commoditizes code and breaks the traditional way architects are trained, "pattern literacy" (reading a system through its invariant forces) becomes the durable skill to teach — as a grammar, not as catalogues.
Guide by Augment Code (Paula Hingel) describing how AI agents are restructuring the software development lifecycle (SDLC), stage by stage. Thesis: AI produces **higher throughput at some stages and higher instability risk at others** — a symptom of uneven adoption without redrawing review boundaries. Draws on **DORA 2025**: AI adoption correlates positively with delivery throughput and product performance, but **negatively with stability**. Six stages revisited (Requirements, Design/Architecture, Implementation, Testing/QA, Deployment, Maintenance), three major risks (erosion of the junior pipeline, **circular validation** of AI-generated tests, governance gaps at scale) and three emerging roles (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Actionable recommendations: audit one stage before scaling, stress-test governance, make the **specification** central, define explicit rollback policies, redesign the junior role around review.
#SDLC#software development lifecycle#coding agents
Engineering article published on the **Uber** Engineering blog by six engineers (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) on **May 21, 2026**, laying out the **AI agent identity and access-control doctrine** deployed in production at Uber for several thousand internal agents. **Pivot thesis**: existing identity models (humans + workloads) fail to describe **agency** — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — and lose **provenance** across the hops of an agentic workflow. **Two operational problems identified**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — delegation is the default mode, workflows are compositional (agents calling agents calling tools), behavior is dynamic (plans evolve based on intermediate results); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Proposed architecture** as an extension of Uber's Zero Trust Architecture: **Agent Registry** (source of truth for agent↔workload mappings) + **AI Agent Mesh** (inter-agent data plane) + **STS (Security Token Service)** (short-scoped JWT issuance) + **MCP Gateway** (policy enforcement point for tool invocation) + **AI Gateway** (mediation of external LLM calls with guardrails) + **SPIRE** (workload credential provider). **Cryptographic mechanics**: workloads fetch cryptographically signed **SVIDs (SPIFFE Verifiable IDs)** from SPIRE → the SDK requests a JWT from the STS via the workload identity → the STS verifies the agent's authorization against the Agent Registry → a short-lived token (TTL on the order of minutes) is issued for a **specific single-hop destination** (targeted `Audience` claim). **Pivot doctrine**: ***"Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes."*** **Preservation of the actor chain**: a multi-hop example with on-call engineer `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; the final JWT carries a verifiable **actor chain `[user1, oncall-agent, investigation-agent]`**, enabling tool-level access decisions based on the **full history of the request**. **Standardization**: a **Standardized A2A (Agent-to-Agent) Client** that automates STS exchanges and actor-chain propagation — *"the secure path is also the easiest path for developers to implement A2A calls"* — with phased migration of legacy agents. **Production metrics**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** thousands of internal agents onboarded, a real-time observability dashboard tracing multi-agent sessions. **Long-term vision — three-layer framework**: (1) Identity & Trust Foundation (verifiable agent identity + delegation chains), (2) Dynamic Access Control (context-based permissions + human-in-the-loop), (3) Unified Enforcement Plane (centralized, observable policy). **Standards alignment**: the IETF **WIMSE** working group + draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, conceptually grounded in **OAuth 2.0 Token Exchange (RFC 8693)** and **SPIFFE/SPIRE** (CNCF graduated). The first reference publication from a non-AI-lab hyperscaler (logistics/mobility) industrializing agent security at the infrastructure level, closing the doctrinal gap between skills/harness frameworks (Vincent, Lattice, PROJ-AI) and enterprise-grade identity questions.
Internal teardown report on the open-source release **`xai-org/x-algorithm`** (May 15, 2026) — the **For You feed** algorithm of **X (formerly Twitter)** in 2026, with four audience-tuned growth recommendation tracks (personal/founder, brand/company, generalized framework, client/consulting deliverable). **Pivot thesis**: ***« The famous 2023 weight table — replies count more than likes by a big multiplier — describes a system that no longer exists in this form. »*** The 2026 algorithm is a **transformer (Phoenix, Grok-1-derived)** that learns weights from your engagement history, scored against a **19-dimension multi-action surface**, gated by an offline content-understanding service (**Grox**). **The shape of scoring now matters far more than the numbers — and the numbers themselves are not in the public release**. **4-component architecture**: (1) **Home Mixer** (Rust, request-time orchestrator, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, Kafka-fed in-memory store of recent posts, sub-ms lookups for in-network candidates); (3) **Phoenix** (JAX ML, two-tower retrieval + ranking transformer, ~Grok-1-derived); (4) **Grox** (offline, spam/safety/PTOS/banger classifiers + multimodal v5 embedder). **The 19 actions predicted by Phoenix** (key change vs. 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view gated by min duration), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continuous). **Final score** = `Σ (weight × P(action))` modified by **3 structural multipliers**: (a) **OON_WEIGHT_FACTOR < 1** (out-of-network penalty), (b) **author diversity decay** `(1-floor) × decay_factor^position + floor` (exponential attenuation of repeated posts from the same author within a single render), (c) **video duration gate** (vqv only contributes if `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Key caveat**: **no numeric weight value** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) is in the release — everything is `crate::params::*`, managed by an internal X feature-switch service for A/B testing. ***« Anyone telling you 'replies are worth N.N× more than likes in 2026' is fabricating a number that is not derivable from the OSS release. »*** **Key differences vs. 2023**: (1) removal of every hand-engineered feature (*« We have eliminated every single hand-engineered feature and most heuristics from the system »*); (2) a single model predicting 19 actions vs. multiple single-action models; (3) Grox separates content understanding from ranking; (4) new first-class signals (continuous dwell, gated vqv, follow_author, 3 share variants); (5) two-tower OON retrieval (vs. SimClusters+heuristics) with multimodal text+image+ASR-video embeddings. **Three layers of reach** (generalized framework): Eligibility (binary, Grox+filters) → Retrieval (probabilistic, two-tower ANN) → Ranking (continuous, weighted-sum + multipliers). **Two laws of mechanical growth**: (1) In-network is multiplicative, OON is additive; (2) The model's job is to predict you, not reward you. **Deliberate honesty boundary**: released Phoenix checkpoint = mini (2 layers, 4 heads, 256-dim, 537K sports-post corpus), not the production model; Thrift integrations stubbed (`panic!("Not implemented")` in `candidate_features.rs`); brand-safety lists, topic ID mappings, language penalties, ad-blending rules absent from the public release.
#X algorithm 2026#xai-org/x-algorithm#For You feed
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
**Jessica Talisman MLS** (Semantic Engineer + Information Architect, 25+ years of experience, formerly Adobe RDF knowledge graphs + formerly Amazon information architecture, founder of the **Ontology Pipeline Framework** + **Contextually LLC**) publishes on **Modern Data 101** (Substack, ~20,000 members) on **May 4, 2026** a major revision of her **Ontology Pipeline™** framework initially published in January 2025. **Pivotal thesis**: since November 2022 (ChatGPT), demand for *semantic infrastructure* has exploded but has created **massive confusion** — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. The original **5-stage** pipeline (controlled vocabulary → metadata standards → taxonomy → thesaurus → ontology → knowledge graph) remains valid but **must be completed with 2 critical additions**: **(1) Governance** as an ongoing engineering practice (not post-project documentation); **(2) AI Partnership** with a clear distinction between augment and replace. **Market diagnosis**: *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, AI-generated taxonomies sold as strategy, vendors misusing the term *"ontology"*, cookie-cutter solutions presented as methodology. **Educational crisis**: demand for semantic engineers massively exceeds the supply of trained practitioners; the gap is filled by people *"who know vocabulary without methodology"*. **Explicit normative position**: *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Acceptable AI roles**: entity extraction, gap analysis, drafting candidate vocabularies for review, population/validation support. **Unacceptable AI roles**: *wholesale taxonomy generation without human validation against standards*. **Referenced standards**: SKOS, OWL, RDF, SPARQL. **Credibility**: framework validated across **6 institutions over 10 years**. **Recommendations for 3 audiences**: (a) Organizations — invest in formal education, treat knowledge infrastructure as the AI backbone, governance as ongoing, AI as an accelerator not a replacement; (b) Practitioners — competency questions before modeling, validate against SKOS/OWL/RDF, definitional difficulty signals a pause, maintenance is continuous; (c) Leaders — workforce upskilling without self-funded education, allocate resources to knowledge infrastructure as a strategic necessity, governance before deployment. **Striking quotes**: *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Major relevance** for data leaders / CDOs / architects building the semantic foundations of their AI agents. To be read alongside: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — ontology as the only moat*; Foundation Capital Context Graphs (2025-12-22); Bain part 2/5 *redesign data foundations for agent readiness* (2026-05); DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21); Habert PROJ-AI six-zone doctrine (2026-05-05). Convergence with the 2026 corpus on *"data foundations as moat"*.
#Jessica Talisman MLS#Ontology Pipeline framework#Modern Data 101
**Jessica Talisman MLS** — Semantic Engineer et Information Architect avec **25+ ans d'expérience** en enterprise architecture · e-commerce systems et knowledge management. Fondatrice de l'**Ontology Pipeline Framework** et de **Contextually LLC**. Roles précédents : **Adobe** (RDF-based knowledge graphs) · **Amazon** (information architecture). Auteure de la newsletter **Intentional Arrangement** (Substack) et d'un **livre éponyme à paraître en 2026**. Le framework initial *Ontology Pipeline* a été publié en janvier 2025 et **validé sur 6 institutions sur 10 ans**.
Building GenBI at a Fortune 100 Company Averse to Risk (Northwestern Mutual): Small Bets, Incremental Rollout, Specialized Agents and Data Democratization
Deep Research - AI4* Revolution - 6 pillars of software production - Copilots→Agents transition - Vibe vs Check paradox - FinOps for AI crisis - Governance as critical path - GenAI Landing Zone
Block/Goose — MCP-UI and the Future of Agentic Interfaces: interactive web components in AI agent conversations via Model Context Protocol (block.github.io)
Keynote by **Gregor Hohpe** (Enterprise Strategist at AWS, author of *The Software Architect Elevator* and of the forthcoming book *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) at **PlatformCon 2022** on **the magic of platforms** — why platforms succeed, what distinguishes them from plain *IT Service Management*, and **the non-trivial architecture decisions** to make when building one. **Pivot thesis**: *"standards don't reduce creativity, they can multiply it"* — analogous to Baltimore 1904 (fire, incompatible pumps), the ISO metric screw, HTTP, A4 paper. **Canonical quote borrowed from Peter / Thoughtworks**: ***"platforms centralize expertise but not innovation"*** — the wheel isn't reinvented, but innovation is left to the teams closest to the customer. **Pivot analogy**: the automotive industry (Volkswagen Group builds the Audi A4 and the Bentley Bentayga on the same platform), *"undifferentiated heavy lifting"* (AWS vocabulary) under the hood, differentiation visible on the customer side. **Three properties of a true platform**: (1) **low friction** — adoption can't be forced, teams will work around it; (2) **transparency** (not a *black box*) — users must be able to diagnose whether the fault lies with them or with the platform; (3) **shared responsibility** (direct reference to the *AWS Shared Responsibility Model*) — the platform does not fix a poorly designed application. **Explicit anti-pattern**: *"a common layer can be many things — it is not necessarily a platform"*; traditional IT Service Management has the same image (a common layer underneath everyone) but the **interface is the opposite** (high-friction, forms, bottleneck). **Two construction paths**: (a) anticipating every need (Hohpe: *"I don't feel I'm smart enough"*); (b) **evolution** from useful pieces, observing usage. **Decisions to make explicit**: objectives (cognitive load ↓, safer / fewer mistakes, faster via samples/blueprints/self-service, compliance), shape of the learning curve (cliff, hockey stick, gear shift). **Canonical concept #1 — Floating platforms vs Sinking platforms**: when the *base platform* (typically the cloud) gains new capabilities, **two opposing strategies**: **sinking platform** (static, duplicating what the base now offers, sinking as the water level rises) vs ***floating platform*** (discards the pieces that have become redundant, **rises above the new level**, innovates further up). *"Submarine and a boat"* metaphor. Strong contractual implication: **explicitly warn stakeholders** that components will be removed once the base absorbs them. **Canonical concept #2 — Fruit salad vs Fruit basket**: a platform is not a collection of juxtaposed capabilities (a basket) but a **proportioned, bite-sized** assembly where the pieces interact — *"the per-kilo price for fruit salad is higher than for a fruit basket"*. The title derives from the phrase *the magic of platforms* — the counter-intuitive effect where **standardizing frees up innovation instead of stifling it**, provided the interface, the evolution, and the integration between components are handled with care. Relevant for: platform architects, **Platform Engineering / IDP teams 2026** (a foundational reference, predating the *Internal Developer Platforms* boom but structuring its vocabulary), CIOs assessing build-vs-stagnate against native cloud capabilities, product executive committees. Converges with **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Platform as a systemic pillar).
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).