thekb.eu — Architecture & Construction

DuckDB and the changing physics of analytics

Wed, 26 Aug 2026 00:00:00 GMT

Andy Warfield, an engineer on the S3 team at AWS, published a guest post on All Things Distributed on August 26, 2026, introduced by Werner Vogels. In it, he explains why embedded analytical engines like DuckDB are gaining importance, and announces that DuckLabs, the team that develops DuckDB, is joining AWS. His reading grid is one of a moving "physics." Where the physical sciences explore invariants, systems computing seeks the elegant trade-off against ratios that shift: memory speed versus network speed, richness of abstractions versus available power. He cites three moments — Berkeley's NOW project, his own work on Xen, and the MonetDB and X100 research at Amsterdam's CWI, where the bottleneck of query processing had shifted from disk to CPU — and notes that these constraints recur in cycles. Applied to data, this grid explains distributed processing. Processing is always simpler and more efficient on a single fast machine, but when a server's disk or network card can no longer read the desired volume, one partitions. That was the constraint of the early 2000s, the one that produced MapReduce and then Spark's RDDs. Warfield notes two qualities of these systems: they innovated heavily on developer ergonomics, and they accepted a fixed cost of planning and distribution, betting on throughput gained by adding machines rather than on per-unit efficiency. But the ratios have changed. A current instance offers roughly fifty times the memory, cores, and network bandwidth of the largest EC2 instance from 2007, while dataset growth follows a distribution whose extreme cases form the tail. The 2015 Scalability! But at what COST? paper had already shown that a carefully optimized single-thread implementation could beat distributed frameworks running on one hundred twenty-eight cores. DuckDB, launched in 2018 by Hannes Mühleisen and Mark Raasveldt, applies this logic: an in-process library analytical engine, running in the application's address space, following SQLite's distribution model. AWS became a DuckLabs customer and then a sponsor of the Iceberg extension, alongside its work on S3 Tables; the extension now supports Iceberg v2 and v3 and exceeds 800,000 downloads per week. Warfield does not present the embedded model as a replacement: when a job requires a thousand machines, it requires them. What is changing, he writes, is that much of the work done on data never actually needed a cluster. DuckLabs joins AWS as a subsidiary, with the project remaining open source under the MIT license and under the stewardship of the DuckDB Foundation.

When code is abundant

Mon, 24 Aug 2026 00:00:00 GMT

Bill Staples, CEO of GitLab, publishes an essay on August 24, 2026 that extends a memo written to his board in January and a first publication in May, *GitLab Act 2*. The explicit trigger is Anthropic's AI-native SDLC playbook, published on August 21, from which he borrows the opening claim: code is no longer the bottleneck. His question goes a step further: if producing code stops being the constraint, what becomes scarce, and what architecture must a company have when humans, agents, and multiple models act simultaneously at machine speed. His answer fits in one sentence: when implementation becomes abundant, trust becomes scarce. For sixty years, software engineering has organized itself around one fact — code is precious — from which descend legacy preservation, developer-productivity optimization, and the ceremony of reviews, approvals, and release gates. This constraint is shifting, and the system built around it will follow. The economic unit he proposes 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 and makes the others proportionally decisive: an organization ten times faster at generating without touching the rest simply moves the queue. This is the theory of constraints, cited by name. Stripe, Spotify, and Amplitude's experiences serve as material. They mainly show where the next constraints reappear: environment, CI, review, and governance. A thirty-minute pipeline, he writes, defeats any model. An architecture follows: three coexisting development modes rather than a single maturity curve; the inner loop migrating from the workstation to the pipeline, closer to the repository and producing evidence; autonomy that is governed rather than granted, through deterministic gates, isolation, policy, and evidence. The vendor's thesis is then laid out: the model is a replaceable execution component, not the durable architecture. Context, identity, policy, provenance, and organizational memory must persist across models and agents, which pushes toward a model- and cloud-neutral control plane. The text distinguishes the Markdown file from the governable record, argues that the agent should belong to the customer, describes a PDLC where business signal becomes verified software, and sees the population of Builders growing. Human judgment, meanwhile, does not become abundant: it moves up toward intent, architecture, and exceptions.

Projects in Buzz

Tue, 18 Aug 2026 00:00:00 GMT

Announcement post from **Block Engineering** signed by **Thomas Petersen** (*Principal Designer & Builder*), published on **August 18, 2026**, introducing **Buzz Projects** — the forge building block of **Buzz**, Block's humans+agents workspace built on **Nostr**. **The problem stated.** *« Software development tools are fragmented in ways the work itself is not. »* The bug report sits in one tool, the discussion in another, the fix on a branch, CI elsewhere, the review in a comment thread, release notes reconstructed after the fact. **The thesis: all of this is one conversation, and the history must be part of the project.** **What Projects delivers.** A **forge hosted on your own relay**: standard Git repositories accessible via `fetch/clone/pull/push` over **Smart HTTP**, *« with no custom tooling or wrapper CLI required »*; **the clé Nostr as a single identity** — *« the same npub that signs your messages signs your pushes »*, with no separate token or GitHub account; **multi-repo projects** that can include repositories one doesn't own (*« you just won't have authority over it »*); issues, pull requests, diffs, inline comments, review and merge; a server-wide **activity feed**; and the **linking of any project to any number of channels**, so that *« the context around a change doesn't disappear the moment agents start writing code »*. From a channel, an issue can be handed to an agent or the agent can be asked to open a PR, which links back to the conversation that produced it; the agent reaches out to the human via the **Inbox**. **The doctrine, in two parts the post never assembles.** On one side, **no prior constraint**: *« No forced guardrails, no limitations on what your agents are allowed to help you with. »* On the other, **a signed record of every act**: *« Every push, review, approval, and merge is a signed Nostr event »*, with a trace of **which agent** produced a patch and **which human** had authorized it. Hence the closing projection: contribution history becomes *« more than a set of colored squares on a profile »*, a **verifiable history attached to a key**, and Block states it is **exploring *« agent trust protocols informed by past behavior »***. **Trust shifts from *ex ante* authorization to *ex post* proof.** The associated framing is explicit: *« 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. »* **Caveats.** **No figures, no outbound links, no specification** anywhere in the text; **CI and release notes are promised but absent from the inventory**; Projects lives under the **Experiments tab**, and the post disqualifies itself six times — *« 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

Product launch page published on **August 13, 2026** by **DeepSeek**, **unsigned**, for the *developer preview* release of **DeepSeek Harness** (`dsh`), a coding-agent harness **open source under the MIT license** whose repository opened the same day. **What the page says.** Two promises, in four hundred words and without a single figure. **« Everything is a plugin »**: every capability — models, tools, skills, sessions, sandboxes, storage, loops, scheduling, interface — is a plugin **swappable through configuration, without modifying the source code**. **« Every run is traceable »**: everything the model sees is recorded in an **append-only session log** — system prompts, reasoning, tool calls and results, subagent scheduling, every context injection — and *« resume, fork, search and replay all operate on the same event stream »*. The core is **Cordis**, a vendored third-party framework, described in an external paper and credited prominently. Four execution modes ship: **Standard** (full tooling), **Code** (tools exposed via a TypeScript SDK to combine several operations into one program), **Minimal** (two tools, persistent bash and `str_replace_editor`, *« for benchmarking models in a minimal environment »*), and **Creator** (runtime inspection, in-memory plugin testing, composition of new modes). Getting started: `npx @deepseek-ai/dsh web`. **What the page does not say.** The strongest claim sits in `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. »*** **A guarantee asserted at runtime**, not a display claim — this is the property that actually sets DSH apart, and it is absent from the marketing copy. The same repository supplies the rebuttal: `SESSION_FORMAT_VERSION` stays at **`0` with no compatibility promise**, *« backends reject old on-disk formats »*, and the README warns in capitals that there will be breaking changes. **Traceable today does not mean archivable tomorrow.** **The business model is in the timeline.** DSH ships on the day of **DeepSeek-V4-Pro's GA** and **three days before** a new API pricing schedule (August 16, 16:00 UTC; off-peak rates at **−50%**). **Harness given away, inference made pricier** — the exact reverse of Anthropic's model. **What checks out.** Swappability holds at least at the model layer: besides the DeepSeek adapter, **`dsh-llm-pi-ai`** makes any OpenAI-compatible gateway accessible *« by configuration, not by code change »*. And the mode Minimal ships the **benchmarking harness** inside the product — an attempt to wrest the definition of the benchmark away from Claude Code, even as DSH's own repository contains a `CLAUDE.md` and a `.claude/skills`.

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

Wed, 12 Aug 2026 00:00:00 GMT

Internal research report dated **August 12, 2026** consolidating the public state of **Buzz**, **Block**'s humans+agents workspace launched on **July 21, 2026** under **Apache 2.0**, for presentation purposes. It aggregates Block's two engineering posts, the corporate announcement, the GitHub repository, press coverage, X and **three independent evaluations** — this last layer carrying most of the added value. **The concept.** Buzz merges team chat, a Git forge and automated workflows into a single space where agents are **full members, not bots**. The thesis is Tyler Longwell's: *"The bottleneck moved from intelligence to coordination."* Bradley Axen (Head of AI Capabilities) frames the market stakes: *"Every company is going to need a place where humans and agents work together. The question is whether that place is proprietary or open."* **The architecture.** A **Rust** relay on **Nostr** (NIP-01/42/98/34, 127 *event kinds*), **Postgres**, **Redis**, **S3/MinIO**, **Tauri+React** desktop. Each participant holds a keypair; every message, review, workflow step and Git event is **signed** into a hash-chained append-only audit log. A rare degree of formalism for a **v0.4.x/0.5.x**: multi-tenant isolation mechanized in **TLA+**, authorization properties verified in **Tamarin**. Agent integration goes through **`buzz-acp`**, an **ACP** harness that plugs in goose, Codex and Claude Code and **translates ACP ↔ MCP** — *"They compose through protocols, not imports."* **The central gap.** Jack Dorsey announces *"decentralized, self-sovereign"*; Block's `ARCHITECTURE.md` states: *"The relay is the single source of truth… There is no peer-to-peer event exchange, no gossip, no replication."* A single relay per community, hence a **single point of failure**: decentralization is **organizational sovereignty**, not redundancy. **The limitations, documented.** The unit of permission is **channel membership** — *"channel membership is not fine-grained tool authorization"*; agents run in **`--dangerously-skip-permissions`**, outside any sandbox; **observability is lacking** (*"It doesn't tell me what happens next"*, silent OOM kills). Signed events are *tamper-evident*, not *tamper-resistant*: a compromised relay operator can delete them. On the hosted relay, there is **no end-to-end encryption**. **A figure correction.** The "+33% more work" is the **ratio of completed tasks (20 vs 15 out of 44)**, not a score gain — which rises from 59.1% to 71.5%, i.e. **+12.4 pts**. **Reception**: ~25,900 GitHub stars, a Dorsey tweet at ~2.3-2.7M views, endorsement from Sundar Pichai, and Justin Waldron's formulation: *"the first proper multiplayer agent harness"*. Acknowledged caveats: benchmarks **self-evaluated by Block**, no published hosting price, no adoption figures.

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

Experience report published on **LinkedIn Pulse** on **August 12, 2026** by **Guillaume Dumortier** (newsletter *Growth Marketing Fit*), on an internal marketing AI system built **in Claude** for a team of about sixty people: roughly thirty skills, a dozen truth modules, **seven agents, six of which only check work**, a terminal plugin, a browser application, and multi-asset campaign orchestration. **The thesis.** *« I thought I was building a content machine. I was building a trust machine. »* The quality of an AI output is not determined at generation, but by **what the system knows beforehand** and **what happens to the draft afterward**. Generation is the easy part — and the only part most teams have built. **Four layers.** *Truth*: fact documents separated from anything that produces content, each with an owner, versioned and dated. Leaving facts inside the skills produced **four versions of a launch date across four files**, each individually plausible. *Production*: the blog skill spent weeks writing **descriptions of articles** instead of articles, and passed every review, because the review checked the structure. Past thirty skills, the problem becomes **routing** — half of each skill description has to state what it's not for. *Verification*: the layer that separates a demo from a system. *Internal distribution*: where projects die from being excellent and used by four people. **The two central failures.** A fact-checker receives a claim none of its sources cover: it returns a « pass ». *« It didn't just miss the error, it certified it. »* Fix: a verifier is a **closed-world system**; **it is forbidden from returning a bare « pass »** and must declare its coverage — how many claims checked, how many actually matched, which fell outside its jurisdiction, which were owned by no source. *« An unverifiable claim is a finding, not a silence. »* Second failure: **two individually correct assets can contradict each other**; per-asset verification can't catch it, by construction. **Five cross-cutting rules.** Never ask a model for something you can enforce in code. **Silent failures** are the whole risk — an emptied constant stripped every number from every prompt, and it blamed the model for hallucinating. Test the pipeline, not just the output. Your validation has the same gaps as your system. **Teach the system to refuse.** **Adoption follows trust, not capability**: an output that admits what it's unsure of gets used. Closing clause: ***« The generation is free. The trust is the product. »***

Agent Plugins package your skills, tools, and more

Thu, 06 Aug 2026 00:00:00 GMT

Engineering post from **Google** on **August 6, 2026** announcing that the company 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 governance fact first.** The specification was published by a TSC of Core Maintainers from **Amazon, Cursor, Microsoft, OpenAI, and Vercel**. Google joins them, represented by name through **Kevin Hou** (Google DeepMind). Six competitors agree on a packaging layer. **Anthropic does not appear on the list of maintainers**, even though the two packaged building blocks come from it. **The diagnosis.** A skill is portable, an MCP server is portable — *"The core problem isn't the components. It's the manifest."* What has never been portable is the box: directory layout, manifest metadata, the shape of the MCP configuration, and transport inference differ from one client to another. People fork, maintain two copies of identical components, and they drift apart. **The format.** *"A plugin is a directory. That's the whole idea, and the restraint is the point."* A `plugin.json` reduced to `$schema` and `name`; skills in `skills/`, in the Agent Skills format; servers in `mcp.json`, **with an explicit `type`** on each entry (stdio, Streamable HTTP, legacy HTTP+SSE). The strength of the design lies in what the manifest **cannot** do: neither relocate a component nor declare it inline. So there is no discovery path to configure, no precedence order to learn. Corollary: **components fail independently** — a server that fails to start does not take the skills down with it. A **reverse-domain** directory (`com.example.client/`) serves as a proprietary extension space, ignored by other clients: the portable core stays small because the non-portable parts have somewhere to go. **The limits, openly stated.** A whole section explains **when not to make a plugin** (a single MCP server, a single skill: unnecessary). Another lists what v1 excludes: **installation, distribution, permissions, sandboxing, trust and provenance verification, UX**. Justification: the obligations of an IDE, a CLI, and an enterprise platform genuinely differ. **The stack.** Find (**Agentic Resource Discovery**), describe (**AI Catalog**), package (**Agent Plugins**), run (**MCP + Agent Skills**) — each layer independently adoptable. **Shipping today**: **Agents CLI** (usable from Antigravity, Gemini CLI, Claude Code, or Cursor) and **Data Agent Kit** (BigQuery, Spanner, Cloud SQL). *"Those skills were already distributable. Now they're distributable in a format that isn't ours alone."* Closing line: *"Packaging is unglamorous infrastructure,"* and that is precisely what should be shared rather than reinvented five times.

Efficient Tokens & Effective Teams in Buzz

Thu, 06 Aug 2026 00:00:00 GMT

A **Block** benchmark post signed by **Atish Patel**, published on **August 6, 2026**, extending the **Buzz** launch: since assembling an agent team there has become trivial, *which one is the cheapest that reliably succeeds?* **Vocabulary first.** The post proposes four tiers: **QuickBee** (fast and cheap — builds, screenshots, tests, first-pass triage: GPT-5.6 Luna, DeepSeek V4 Flash, local models, **run at high effort**), **WorkerBee** (versatile, carries a full subset unsupervised: GPT-5.6 Terra, Gemini 3.6 Flash, open models), **SmartBee** (big picture, trade-offs, escalations: Claude Opus 5, Kimi K3, GPT-5.6 Sol, **at *medium* effort**), and the human, *"the most expensive bee on the team, and the slowest. Also still the smartest"*. Two team forms: the permanent **Hive**, which remembers **your** preferences, and the disposable **Swarm**, which remembers **the project** and then disappears. **The solo result.** On **Terminal-Bench 2.1**, raising the effort of a **cheap model** is the best buy: Luna goes from $1.61 / 57.3% (*medium*) to $4.98 / 75.0% (*high*). At the other end, **Opus 5 at *xhigh* is the most expensive run ($140.63) and scores only 75.0%**, having **hit the timeout on 17 of 88 tasks** through over-reasoning. Among the six best runs: **a 5.5× price gap, an 8.9-pt score gap**. Conclusion: *"choosing between them is not a quality decision at all. It is a budget decision."* **The team result, in two acts.** On Terminal-Bench 2.1, **twelve compositions** were tested and **none beat solo at equal cost** — a short task doesn't have enough structure to divide. On **Long-Horizon Terminal-Bench** (44 multi-hour tasks, lead GPT-5.6 Sol, **3× the timeout**), the reversal is clear: solo **15 tasks / 59.1%**, +2 WorkerBees **20 / 71.5%** — **+12.4 pts, of which 11.4 come from additional completions**. The team costs more per task, which pays off *"when the alternative is a human picking up unfinished work"*. **The operating rule.** Route worker escalations to a **SmartBee coordinator** rather than to the human: *"every ambiguity becomes a notification"* is the real failure mode. A Block engineer says they **migrated over 2,000 apps** with a Swarm (coordinator, 1–10 migrators, independent verifier), the coordinator storing human answers in memory. **Caveats**: n=1 per task, no confidence interval, team costs unpublished, and an admission — *"this might change if models are trained on better collaboration."*

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) turns an entire project into a **queryable knowledge graph**, invoked via `/graphify` from Claude Code, Cursor, Codex, Gemini CLI, and about fifteen other clients. Observed on August 6, 2026: **103,187 stars** for a repository created on April 3, Apache-2.0, Python. **Three design choices underpin the project.** **Code is parsed locally** into a tree-sitter AST, without an LLM: deterministic, nothing leaves the machine, no API key required for a code-only corpus. **Every edge carries its provenance** — `EXTRACTED` if explicit in the source, `INFERRED` if graphify resolved it —, *"so you can tell what was read directly from what was inferred"*. And the project defines itself **against vector RAG**: *"Not a vector index. No embeddings, no vector store: a real graph you traverse."* **Usage replaces grep.** `query` returns a subgraph for a natural-language question, `path A B` traces the path between two entities, `explain` unfolds a concept. Three outputs: an interactive graph, a readable report (god nodes, surprising connections, suggested questions), and a persistent `graph.json`, queryable weeks later. **Coverage extends beyond code**: 36 tree-sitter grammars, but also SQL, Terraform, Apex, **MCP configurations**, package manifests, Office, PDF, images, and video transcribed locally. `# WHY:` comments and design rationale become **first-class nodes linked to the code they explain**. **The benchmarks call for a careful reading.** On LOCOMO, graphify dominates recall (0.497 versus 0.149 and 0.048) but **loses on QA accuracy** (45.3% versus 49.7%); on LongMemEval-S it **matches a dense RAG** at 76%. The line that matters is elsewhere: *"Graph build — LLM credits: 0"*. The defensible differentiator is **cost and traceability, not answer quality**. **Three caveats.** The `main` branch carries an outdated v1-era README describing a different product: read `v8`. The PyPI package is named `graphifyy`, while the name is being reclaimed. And a **local query log** is active by default, which can be disabled via an environment variable. The skill also serves as an entry point to a commercial waitlisted platform at graphify.com, which continuously applies the same approach to the entire working context.

How to use Notion as Code

Mon, 03 Aug 2026 00:00:00 GMT

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

Agent Client Protocol — Introduction

Sun, 02 Aug 2026 00:00:00 GMT

Introduction page of the **Agent Client Protocol** specification, accessed on August 2, 2026. A living artifact with no publication date: the fiche is dated by its observation. **The problem.** *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Every editor must build a custom integration for every agent it wants to support, and every agent must implement each editor's specific APIs. Three distinct costs follow: **integration overhead** (any agent-editor combination requires specific work), **limited compatibility** (an agent reaches only a fraction of editors), and **developer lock-in** — *« choosing an agent often means accepting their available interfaces »*. **The solution.** ACP standardizes agent-editor communication *« similar to how the Language Server Protocol (LSP) standardized language server integration »*. The benefit is mutual and is what holds the ecosystem together: an agent that implements ACP works with any compatible editor; an editor that supports ACP gains access to the entire ACP agent ecosystem. *« This decoupling allows both sides to innovate independently. »* **The architecture.** ACP assumes the user is **primarily in their editor** and reaches for an agent there for a specific task. Two deployment modes: **local** agents run as a subprocess of the editor and communicate over **JSON-RPC on stdio**; **remote** agents, hosted in the cloud or on separate infrastructure, communicate over **HTTP or WebSocket** — support declared *« a work in progress »*, with active collaboration with agentic platforms. The second mode is regularly omitted from secondary coverage, even though it charts the protocol's enterprise trajectory. **The link to MCP** is closer than an architectural complementarity: ACP *« re-uses the JSON representations used in MCP where possible »*, while adding types specific to agentic coding UX — **diff** display is the example given. The default format for readable text is **Markdown**, chosen precisely so the editor is not required to render HTML. **Two observations about the source itself.** The navigation exposes **v1 (Latest)** and **v2 (Draft)** — not the "ACP 1.2" that circulates elsewhere. And it links **Zed Industries and JetBrains at the same level**, next to an **ACP Registry**, **RFDs**, a Community section, Publications, Updates, and a Brand page: the structure of a co-governed project with a process. Official libraries in Kotlin, Java, Python, Rust, and TypeScript.

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

Sun, 02 Aug 2026 00:00:00 GMT

Tech-watch note from **August 2, 2026**, born from a colleague's question — *"what is ACP?"* — which the author shows has no simple answer: **three protocols compete for the acronym**, with no technical overlap whatsoever. **Agent Client Protocol** connects **a client to an agent**. Introduced by **Zed** in August 2025, it does for agents what **LSP** did for languages: it decouples the editor from the agent. Before, N editors × M agents required **N×M** custom integrations; afterward, everyone speaks the protocol and **N+M** suffices. JSON-RPC 2.0 over stdio, Apache-2.0. The note points out that the protocol has left its creator's orbit — its own organization, an agent registry, a versioned specification, a JetBrains implementation. **Agentic Commerce Protocol** has nothing to do with it: it connects **an agent to a merchant** (discovery, cart, payment). Announced by **OpenAI and Stripe** on September 29, 2025, it faces **Google**'s **UCP** (January 11, 2026), backed by **AP2** for payment. The stakes: the "Visa/Mastercard" layer of agentic commerce. **Agent Communication Protocol** (IBM Research / BeeAI), agent-to-agent, rounds out the picture and pollutes searches. **The observed problem is documentary.** The author searches "ACP" in their tech-watch database: **twelve results, all about the commerce protocol, zero about Zed's**. The indexing agents had processed the acronym without disambiguating it. Hence the rule adopted: ***"a bare acronym is never indexed"*** — the entity is the full name, the acronym is only an **alias**, here carried by three distinct entities. The note dispels a related confusion in passing: **MCP** connects an agent to its **tools**, **ACP** connects a **client** to an **agent**, and the two **stack**. **The concrete case is Buzz**, published by **Block** on July 21, 2026 under Apache-2.0: a self-hostable workspace on **Nostr** where humans and agents share the same channels, each participant being a **key pair** and every event — message, workflow step, git push — being **signed** in an append-only log. The agent architecture is entirely protocol-based (`buzz-acp`, `buzz-agent`, `buzz-dev-mcp`), hence the agnosticism: **Goose, Claude Code, and Codex** through the same harness, and **Hermes** connected without a single line of code on Block's side. *"N+M instead of N×M, running in production."* **The punchline concerns the Claude subscription** versus third-party agents, after a turbulent 2026 (OAuth block, separate credits announced then suspended the day they took effect). The line drawn separates **ordinary, individual** usage from **routing other people's requests**. Its formulation holds beyond this case: *"the distinction is not legal, it is architectural: **who is consuming, and on whose behalf**"* — to be settled at design time rather than by reading the terms of service.

Mon usine logicielle à l'heure de l'IA

Tue, 28 Jul 2026 00:00:00 GMT

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

How Anthropic secures its AI-native software development lifecycle

Tue, 21 Jul 2026 00:00:00 GMT

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.

Buzz!

Tue, 21 Jul 2026 00:00:00 GMT

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

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

Mon, 20 Jul 2026 00:00:00 GMT

In nine months, Amazon, Microsoft, and Google have each launched or renamed an enterprise agent platform, and **all three have converged on the same architecture**: runtime, memory, tool gateway, identity, observability, and governance now appear in **Bedrock AgentCore**, **Microsoft Foundry**, and the **Gemini Enterprise Agent Platform**, under different names. What was a fragmented collection of libraries 18 months ago is becoming a distinct **platform layer**. To read where this leads, Janakiram MSV invokes the **2011-2016 PaaS inflection**. Before, teams assembled VMs, load balancers, queues, secret stores, and monitoring agents, each with its own API. **Cloud Foundry** and **Heroku** unified these pieces around an **application contract**: the application declares what it needs and stays agnostic about where it runs. What mattered was the **contract, not the implementation**. Cloud Foundry didn't win the market — Kubernetes did — but its principles survived (buildpacks → Cloud Native Buildpacks/CNCF; the Cloud Foundry abstraction rebuilt on K8s via Korifi). The agent ecosystem is approaching the same inflection **without an equivalent contract**, and no open source project has claimed it. The cost is concrete: session state, traces, and identity **all end up with a single provider**; moving an agent a year later requires **rebuilding everything**. The convergence is not a conspiracy but rational behavior — vertical integration, "that's where the margin is" — whose consequence falls on the customer. The author proposes a **mapping** of the Cloud Foundry contract onto agents (app source → code+eval; buildpack → packaging; backing service → model/memory; binding → authenticated attachment; router → MCP/A2A; logs → traces/cost/quality; promotion → eval/versioning; policy → identity), then three principles: **package the agent as one deployable unit** (AWS comes close with its *harness export* to Strands code, "the right instinct, pointed at a single cloud"), **attach capabilities rather than embed providers** (the Twelve-Factor lesson), **integrate the operational layer into the abstraction**. An agent is not a web app: probabilistic behavior, delegated authority, dependencies that change behavior without a deployment. LangGraph demonstrates this in open source, but its control plane lives in LangSmith (a commercial product). Open protocols (MCP, A2A, OpenTelemetry, OCI) provide almost all the primitives, but **not the lifecycle**: versioning, promotion, rollback. The **Linux Foundation** launched the **Agentic AI Foundation** (Dec. 2025, founding projects MCP/goose/AGENTS.md, hyperscalers as platinum members). Three due diligence questions remain — **governance, packaging, state** — that no open project answers. Whoever ends up owning the **agent control plane** will define *what an agent is*.

Beyond Zero: Enterprise security for the AI era

Mon, 20 Jul 2026 00:00:00 GMT

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.

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

Wed, 15 Jul 2026 00:00:00 GMT

This tech-watch digest consolidates, from primary sources (books, the architectelevator.com blog, conference abstracts, LinkedIn posts, podcasts), Gregor Hohpe's position on the role of the architect in the era of generative AI. Central 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," and communicating with humans. His sharpest formulation (Craft Conference 2026): "developers mainly interact with machines (compilers, interpreters, GenAI); architects, meanwhile, communicate with humans — sponsors, stakeholders, regulators. AI generates code and standard diagrams, but architects rely on powerful abstractions that distill critical decisions, remove uncertainty, and align stakeholders." His signature thesis — the architect doesn't need to be the smartest person in the room, they need to "make everyone else smarter" (QCon SF 2024) by sharing decision models and revealing blind spots — grows stronger as code becomes abundant: the advantage comes from decision discipline, not output volume. The "options" metaphor (2016) also gains value: via a Black-Scholes analogy, Hohpe argues that the higher the technological volatility, the higher the value of the options architecture sells — so more should be invested in architecture in times of uncertainty such as the current AI moment. On code, Hohpe favors "debugging" decisions over producing lines: generated code embeds architectural decisions by default, and it is the architect's role to make them conscious. He warns that "an AI-driven SDLC punishes bad habits much faster": AI amplifies everything, including dysfunction (debt, inconsistencies); the winners will be defined by how fast they move from experimentation to "governed production." By role: the enterprise architect must move from cartographer to scout and avoid "the illusion of predictability"; the platform architect must deliver abstractions, not illusions; the chief architect is a multiplier (communication × technology × organization). He embraces targeted automation (Amazon Q Code Transformation: 1000 Java 8→17 applications migrated in two days) rather than AI as a decision oracle, and debunks marketing figures. Two guardrails in the digest: the formula "architects who use AI will replace those who don't" is NOT from Hohpe; some LinkedIn quotes are only accessible as excerpts.

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

Wed, 15 Jul 2026 00:00:00 GMT

This SFEIR analysis note reexamines the software architect profession in light of generative AI, drawing on the conceptual framework of Gregor Hohpe (*The Software Architect Elevator*). The starting point is a paradigm shift: the "Oracle" architect, who holds supreme knowledge and dictates rigid rules from an ivory tower, is now obsolete, since AI generates code and design proposals on demand. The architect's value no longer lies in memorizing syntax or writing "software plumbing," but in a new role as **intelligence amplifier (IQ Amplifier)**: providing teams with mental models, enterprise context, and decision-support tools to make the best use of AI, while ensuring the overall coherence of the system. The document breaks down this impact through the metaphor of the "Architect Elevator," which runs from the machine room (technical) to the penthouse (strategy). The **Enterprise Architect** manages the hype, arbitrates the Build vs Buy decision for models (proprietary, fine-tuned open-source, third-party APIs), and structures ethics and data governance. The **Solution Architect** designs "for uncertainty" — decoupled, modular architectures allowing LLMs to be swapped without rewriting — and "buys options" via extensible systems. The **Platform Architect** standardizes AI capabilities as robust, secure APIs, treating the platform as a product (referencing *Platform Engineering is Domain-Driven Design*). The **Software Architect / Tech Lead** puts guardrails in place (hexagonal/Clean architectures) to prevent generated code from polluting the business core, and documents the "why" behind decisions, since AI only generates the "how." The methodological core is **Domain-Driven Design**, presented as the best tool for channeling AI. Two levers: the **ubiquitous language**, an unambiguous domain dictionary injected into the AI's context (via `.clinerules` or prompt templates), which reduces hallucinations and business misinterpretations; and **bounded contexts**, which confine AI to a restricted scope to maximize generation reliability, with the architect designing the interfaces and anti-corruption layers (ACL) and delegating integration plumbing. In conclusion, AI is not a threat but a catalyst: it relieves the architect of repetitive technical input and revalues their noblest skills — synthesis, strategic vision, modeling of complex concepts, and human empathy to connect technology with business needs.

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

Sun, 12 Jul 2026 00:00:00 GMT

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.

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

Sun, 28 Jun 2026 00:00:00 GMT

Third installment in the « New Engineering Disciplines for the AI Era » series, this article by Ashish Singh establishes **KDLC — Knowledge Development Life Cycle** as an engineering discipline in its own right. Its thesis reverses the dominant diagnosis: if so many enterprise AI initiatives fail, it is not for lack of choosing the right model or deploying a RAG system, but because they ignore the **underlying structure of knowledge**. The pivotal line sums up the stakes: « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust. » Knowledge must therefore be treated as an **engineered asset**, on a par with code (SDLC) or data. The KDLC organizes this work into **eight** ordered stages. **Discovery** locates knowledge scattered across databases, SharePoint, wikis, CRM, ERP, and engineering artifacts. **Extraction** pulls out the meaningful information while preserving business context, metadata, relationships, and ownership. **Structuring** converts the informal into standardized, reusable knowledge objects. **Knowledge Graph Creation** maps the interconnections among customers, products, projects, teams, regulations, and applications. **Embedding** produces semantic representations enabling understanding by meaning. **Index Optimization** refines vector indexes and retrieval pipelines. **Retrieval Evaluation** measures relevance, precision, completeness, and business impact. Finally, **Knowledge Refresh** keeps the whole up to date against new policies, regulations, and releases. The argumentative core contrasts two architectures. **Traditional RAG** retrieves isolated documents via keyword-based searches. The **Enterprise Knowledge Fabric** — a combination of Knowledge Graphs, Semantic Search, Vector Databases, and Hybrid Search — aims for interconnected understanding: rather than retrieving documents, AI agents grasp « relationships, context, and business meaning ». A second triad frames the respective roles of the layers: « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Three sector illustrations make the impact concrete: a **financial compliance** assistant linking up-to-date regulations and internal policies; a **software engineering** assistant consulting architecture, API contracts, standards, and incidents before recommending; a **clinical** assistant cross-referencing treatment guidelines, protocols, literature, and patient records. Singh concludes that, in the age of agentic AI, knowledge engineering becomes as critical as software engineering and data engineering. The article's limitation lies in its **conceptual, non-quantified** nature: no benchmark or cost figures, and the real pain points — governance and ongoing maintenance of the Refresh stage — remain out of scope.

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

This SFEIR article formalizes an AI-driven software development cycle in **eleven phases (0 to 10)** and argues that the industry is converging toward this type of model. The starting point is a diagnosis: in 2025, organizations deployed AI tools without transforming their operating model, producing a paradox summed up by the phrase « everything changes… and nothing changes » — execution speed multiplies without proportional gain. The real challenge is therefore not choosing the right tools, but **rethinking the software lifecycle** itself for machine-led execution. The SFEIR cycle chains together: **0 Setup** (stack detection, project memory), **1 Define** (specification — human gate), **2 Plan** (architecture arbitration — human gate), **3 Build** (development by the agent), **4 Verify** (automated tests and coverage), **5 Review** (four parallel audits: code, security, tests, performance), **6 Compound-1** (capturing lessons before deployment), **7 Ship** (production acceptance — human gate), **8 Ops** (monitoring and rollback), **9 Compound-2** (lessons from runtime) and **10 Deprecation** (retirement and capitalization). Three **immovable human gates** — Define, Plan, Ship — frame a set of otherwise automatic phases; two **capitalization moments** (Compound-1 and Compound-2) turn lessons into reusable rules that feed subsequent cycles. Three principles structure the approach. First, **AI executes, it does not assist**: agents produce complete artifacts (code, tests, documentation) across entire phases, and a **proof-of-execution** discipline captures actual outputs — the system never trusts the agent's own claims. Next, **the human retains control of intent** via the three gates: they decide what to build, the machine optimizes execution. Finally, **the system learns cumulatively**, each cycle enriching the next. The results put forward support the thesis: a site redesign that went from six months to one day, **−30% of correction iterations after ten cycles** (a bug reported twice becomes an automated rule), reviews across four parallel angles, an augmentation cost of around €10/hour, and a target of 850 fully AI-augmented consultants by the end of 2026. The article claims an **industry-wide convergence** with the ADLC (two gates, « intent verified exactly twice »), Google's whitepaper on the new SDLC (41% AI-generated code, 85% of developers on agents), and DORA 2025 (AI as an « amplifier »). It finally delineates suitable uses (back-offices, APIs, migrations, automatically verifiable outputs) and unsuitable ones (unconstrained novel design, safety-critical systems pending standards, ungoverned data environments), and recommends starting with a rigorous specification gate and proof of execution. First installment of a series of seven.

The End of Code Review: Coding Agents Supersede Human Inspection

Thu, 11 Jun 2026 00:00:00 GMT

In this position paper published on arXiv (software engineering category), Martin Monperrus defends a thesis that runs head-on against a founding practice of the SDLC: coding agents have reached a level of capability such that **human code review is no longer a necessary component of a quality pipeline**. The argument rests on two claims. First, a **parity — or even a superiority — of capability**: autonomous LLM-based systems fulfill all the traditional goals of review (finding defects, improving quality, ensuring compliance, sharing knowledge) at lower cost and with higher throughput, without human fatigue or inconsistency. Second, a **scaling problem**: the dominant hybrid model — the agent writes the code, the human reviews it — provides neither real quality assurance nor the ability to keep up with AI-assisted production velocity; above all, it generates a **false sense of security**. Monperrus situates his target historically, taking aim at inspection de Fagan (1976), and draws on the work of Bacchelli & Bird showing that review catches, in practice, fewer bugs than developers imagine. Benchmarks (SWE-bench, ~20-40% of issues resolved depending on the model, with rapid progression curves) serve as evidence of capability. In place of human review, he proposes a **multi-agent adversarial verification pipeline**: an agent generates the code; one or more independent reviewer agents inspect it (defects, security, style); a verification layer adds automated tests and formal methods; a consensus mechanism has several agents vote to accept or reject. The bottleneck of a single human reviewer is replaced by distributed, tireless inspection. The human does not disappear: they refocus on specification and high-level requirements, architectural trade-offs, oversight of critical domains, edge cases, and remain the final approval gate for sensitive systems. The author explicitly addresses the objections — hallucinations and prompt injection, the limits of automated testing (hence property-based testing), loss of domain expertise (offset by fine-tuning and RAG) — without dodging them. On the SDLC side, he links review to DORA metrics: speeding up review throughput speeds up deployment. His recommendations are pragmatic: pilot first on low-risk components, keep an initial hybrid workflow (agents flag, humans approve), measure agent-versus-human detection rates, make rejection decisions explicit, and build feedback loops. A deliberately provocative text, but a valuable counter-thesis to the dogma of the "inviolable human review gate".

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) starts from a seemingly administrative question — designing an upskilling path toward the architect role — to articulate a deeper intuition. This role is critical to the "platformization" of a telecom operator (bringing together the IT and network worlds, separated for decades, into programmable platforms). Yet it becomes critical at the exact moment its training pipeline is breaking down: demand for architects is rising (platforming, cloud-native, IA agentique shift complexity from components to the relationships between them), while the talent supply chain is dismantling itself. The traditional path ran through years of writing code; AI now absorbs an increasing share of that work. If the entry-level work that once forged architects is delegated to machines, where will the next generation come from? The answer, according to Ensarguet, has been sitting on the shelf for fifty years. He returns to the original meaning of a pattern, as defined by building architect Christopher Alexander (1977): a named, recurring solution to a problem within a context, including the forces in tension and the consequences. It is not a recipe — it is transmissible judgment. The Gang of Four book (1994), which emerged from the Hillside Group convened by Kent Beck and Grady Booch, gave the industry its first shared vocabulary — its lasting value being the format (problem, context, forces, solution, consequences), not the 23 patterns themselves. Ensarguet traces a genealogical tree: POSA (1996), Fowler (2002), Hohpe & Woolf (2003), Nygard (2007, Circuit Breaker), the cloud catalogues (2012+), microservices and Kubernetes (2018-2019), up to the agentic corpora now taking shape (Anthropic's "Building Effective Agents," Andrew Ng's four patterns, the two-axis framework by Huang & Zhou in 2026 — echoing the GoF's two axes thirty years earlier). Beneath the catalogues, six invariant forces persist: coupling/cohesion, abstraction boundary, failure isolation, state governance, indirection, feedback loop — joined by a seventh, the non-determinism introduced by agentic systems. This "pattern literacy" is the resilient skill, and the only one that finally bridges IT and network (control plane / user plane = indirection; network slicing = Bulkhead; intent-based networking = feedback loop). AI then becomes an ally: freed from implementation, training can become deliberate — the machine produces options, the human supplies the judgment. What must be taught is the grammar, not the catalogues: catalogues age; the way of thinking they encode does not. Ensarguet is publishing this thesis precisely to stress-test it through debate.

How AI Changes the SDLC: A Six-Stage Guide

Mon, 08 Jun 2026 00:00:00 GMT

This guide from Augment Code, authored by Paula Hingel, proposes a **six-stage** model for understanding how AI agents are restructuring the software development lifecycle. Its central thesis: AI does not uniformly improve the SDLC — it increases throughput at some stages while raising instability risk at others. This imbalance is not a technological inevitability but the symptom of uneven adoption carried out **without redrawing review boundaries**. The article draws on the **DORA 2025 report**, which establishes a positive correlation between AI adoption and throughput/product performance, but a **negative correlation with delivery stability**: process maturity matters more than the tool. The six stages are reread through this lens. (1) **Requirements & Planning**: the specification becomes the control mechanism that directs the agent; humans focus on requirement quality and resolving ambiguity. (2) **Design & Architecture**: more decisions require explicit human review, to avoid "vibe architecting" — infrastructure or integration choices made in seconds, faster than governance can keep pace. (3) **Implementation**: the developer shifts from writing code to orchestration, validation, and approval. (4) **Testing & QA**: the core risk is **circular validation**, where AI-generated tests confirm AI-generated code instead of verifying the actual requirement; a precise specification is the safeguard. (5) **Deployment**: throughput gains create stability risks, hence the need for stronger rollback controls. (6) **Maintenance & Operations**: agents handle detection and remediation, humans manage exceptions and hardening. Three structural risks are named: **erosion of the junior pipeline** (automating foundational tasks faster than junior roles are redesigned shrinks the future pool of seniors), circular validation, and governance gaps at scale. In parallel, three roles emerge: **Intent Engineering** (translating ambiguous objectives into testable specs), Agentic DevOps/Infra (orchestrating agents), and AI Governance/Assurance. The guide is backed by data: 70% of developer time spent understanding existing code, a CMU study (807 repositories) showing +30% static-analysis issues and +40% complexity, and Meta's DRS system (>10,000 changes landed during a code freeze). It closes with five operational recommendations: audit one stage before scaling, stress-test governance, make the specification central, define explicit rollback policies, and redesign the junior role around review.

Solving the Identity Crisis for AI Agents

Thu, 21 May 2026 00:00:00 GMT

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.

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

Sat, 16 May 2026 00:00:00 GMT

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.

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

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, identifies a growing disconnect in the way the industry builds AI agents. On one hand, the industry is investing heavily in orchestration frameworks: LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK — each with its own orchestration graphs, state machines, and routing logic. On the other, leading-edge practitioners have moved to the "powerful model in a powerful harness" paradigm (Claude Code, Codex, OpenClaw, Hermes). **The collapse of frameworks.** Early frameworks were necessary when models couldn't handle multi-step tasks on their own. Anthropic quote: "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." Scaffolding built for a limited model handicaps an intelligent model. It should decrease over time, not accumulate. What remains is simple: a powerful model in a powerful harness. Many, interacting, collaborating. No framework required. **Isolated agents are not enough.** Access to the computer ≠ understanding. Give an agent 1000 documents: it searches, hopes, guesses. Multiply that by 50 agents without a shared world model and you get intelligence that is isolated but incoherent in combination. At enterprise scale, the information environment needs structure — a shared domain model, with the human in the loop. **The symmetry.** The answer is to apply the same simplification on the data side. The model sits in a harness that gives it access to the computer; the data sits in an ontology that gives it structure and meaning. The ontology defines what exists, its properties, its relationships — the interface through which agents understand data. Two symmetric patterns: (powerful model + powerful harness) and (powerful data + powerful ontology). **The Semantic Agent.** Their combination produces the Semantic Agent: (Model + Harness) + (Ontology + Data). It doesn't just generate, it starts to understand. Everything else is scaffolding — useful for a while, but bound to come down. **What you own.** Everyone has access to the same frontier models; anyone can build a harness. That's commodity, and it's thinning out every day. What is NOT commodity: your ontology, your domain model, the structured and linked knowledge that captures how your organization understands the world. Frameworks are a transitional phase. Models are rented. The only thing left to build — and that you own — is knowledge.

Building for trillions of agents

Sat, 07 Mar 2026 00:00:00 GMT

Aaron Levie, CEO of Box, publishes a strategic essay on the fundamental transformation of software in a world where AI agents become the primary users of every application. He observes that since late 2025, agents have crossed a decisive threshold: they now have their own sandboxed compute environment, can write and execute code, interact with APIs and CLIs, and manage their own files and long-term memory. This architecture, initially defined by coding agents (Claude Code, Devin, Codex, Cursor, Replit), has extended to all knowledge work with agents such as Claude Cowork, Perplexity Computer, Manus and OpenClaw, the latter running 24/7 in a persistent environment. Levie predicts that every employee will have numerous agents, with 100 to 1000 times more agents than people within a company, amounting to trillions of agents globally. Adapting Paul Graham's famous advice ("Make something people want"), Levie proposes a new paradigm: "Make something agents want". Agents will themselves choose the most suitable tools, without being influenced by traditional marketing. The major consequence: everything must become API-first. Without an API, a feature does not exist for agents. CLIs and MCP servers become indispensable. Levie cites Jared Friedman of YC, who warns that tools that do not allow sign-up via API are "dead to agents". Business models must also evolve: the per-seat model no longer suffices when an agent can accomplish hours of human work in a few lines of text. Models based on consumption and volume will be needed, potentially even allowing agents to manage their own payments. Levie then describes the infrastructure ecosystem required: sandbox environments (E2B, Daytona, Modal, Cloudflare), file management (Box), identity and email for agents (Agentmail), web search (Parallel, Exa), payments (Stripe, Coinbase), and potentially microtransactions. Security, compliance and governance become major issues when agents handle sensitive data in regulated workflows (pharma, banking). Agents will need their own identities with strict controls over their actions and data access. In conclusion, Levie states that we are entering a new era of software in which tools must be designed specifically for agents operating at an unprecedented scale.