thekb.eu — AI Coding Agents & Skills

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.

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

Fri, 21 Aug 2026 00:00:00 GMT

Louis Claxton, of Anthropic's Applied AI team, published an implementation guide for an "AI-native" software development lifecycle on August 21, 2026. The starting point is an imbalance: organizations now write code at a speed unimaginable a year earlier, but the processes around it — approval gates, reviews, handoffs, policies — haven't moved. The traditional SDLC was designed for a world where writing code was the longest and costliest stage; its controls also assume that every action is taken by a human. Three consequences follow. The bottleneck shifts to the stages that still run at human speed, on either side of the build. Controls stop being applicable: reading every line made sense when a person had written it. And governance cost rises, as exceptions route through periodic committees. The response keeps the control objectives and changes how they're executed. The process becomes a loop, with AI embedded at every point, organized into six stages — Plan, Design, Build, Test, Deploy, Maintain — broken down into *plays* that all follow the same grid, down to the metrics. The throughline is the committed artifact. Intent is captured by its original author as `intent.md`; requirements and design merge into a single session producing `spec.md`, constrained by the brand, security, compliance and UX skills; the build starts in plan mode and locks `plan.md` before any code is written. The commit chain serves as the audit trail. Institutional knowledge becomes versioned files: `CLAUDE.md` for repository context, skills for cross-cutting policies, `REVIEW.md` for review doctrine, `bands.yaml` for production thresholds. Governance splits into two layers, with the skill as an advisory control and the hook as the deterministic layer that blocks or requests approval. A *managed settings* example details, key by key, what each setting buys in terms of control, from refusing to read secrets to enforcing a minimum version floor. The Maintain stage closes the loop: a deterministic script monitors a metric, and crossing a band invokes Claude with no human in the call path, at an autonomy level set by the tier. What the agent finds is rewritten as `intent.md` and fed back into the cycle. Claude Tag, in public beta on Slack, extends the pattern to incidents arriving via chat. No quantified results are put forward: the guide provides metrics to measure and names their source.

The Claude Code guide for startups

Thu, 20 Aug 2026 00:00:00 GMT

Michael Segner publishes a guide on the claude.com blog on August 20, 2026, drawn from interviews with more than a dozen fast-growing startups, fifteen of them named, on how they use Claude Code. The document extracts five operating rules from it and closes with a checklist of technical tips. First rule, "everyone ships": agentic coding lowers the barrier to entry, so the person who understands the problem can ship the first version of the fix. Parahelp reports contributions from non-technical employees, Crosby lawyers who carry the best product intuitions, Heidi the disappearance of a broken-telephone effect where the idea degraded as it passed from the originator to the product manager, then the designer, then the engineer. The guide immediately narrows the scope: the division of labor remains, only the move from zero to one opens up. Three mechanisms make it systemic — connecting the tool to sources of truth via MCP or CLI, ritualizing prototype demos, sharing skills. Second rule, automate the tedium: agents take on the mechanical eighty percent of the cycle and engineers keep the judgment calls. ClickHouse says it has turned almost every step into an autonomous loop, with two single-purpose agents becoming the second and third contributors to its repository. At Anthropic, Claude Tag serves as first responder on-call for continuous integration failures. Third rule, trust but verify: a process is not automated without a reliable way to check it. Cainex, on medical coding, describes a self-improvement loop where auditor corrections feed back into the agent's instructions, tested against a golden set, under a single rule — fix the principle, not the example. Zingage recounts having granted too much autonomy at first, getting code that was plausible but drifting from its architecture, then writing its invariants. The guide points to hooks for deterministic gates and stresses the upkeep of evaluation sets. Fourth rule, build for rebuilding: model capability keeps moving, so little is treated as permanent. Commure sets the end criterion for a rebuild — when the old path has disappeared — and git worktrees make the exercise affordable. Fifth rule, prototype, dogfood, productionize: the internal agent built with Claude Code becomes, if it proves convincing, a customer-facing product via the API, the SDK, or Claude Managed Agents. The four headline figures remain as declared by the interviewed companies, with no survey method described.

Designing AI with character: what we learned building Berd

Tue, 18 Aug 2026 00:00:00 GMT

Corporate blog post from **Block** (`block.xyz/inside`), **unsigned**, published on **August 18, 2026**, announcing **the open-sourcing of Berd** and laying out the design thesis that guided it. **What Berd is.** *"Berd is a desktop application our teams use to work with AI agents across projects, skills, tools, and models."* Born of an internal problem: Block had access to capable agents — **goose**, **Claude Code**, **Codex** — but each imposed *"different interfaces, configuration systems, and ways of managing context"*. The conclusion drawn: *"we didn't need another model or agent harness, **we needed a consistent environment around them**"*. Berd brings together conversations, files, folders, instructions, agents and skills around **persistent projects**, to stop rebuilding context for every task. **The design thesis.** Give agents **character** — not only through roles, instructions, skills and tools, but through **distinct visual identities**, including a collection of animated characters, the *"Gloopies"*. The problem invoked is that of the empty prompt box: *"the product gives people little sense of how the agent is configured, which context and tools are available to it, and how it differs from another agent"*. The post places the approach in the lineage of **Square** and **Cash App** — bringing design where the category had none. **But the problem stated is a configuration-legibility problem, and the avatar solves distinguishability**; the text acknowledges this in one line it does not develop: *"The avatars make the agent recognizable. **Its role, skills, and tools make it useful.**"* **The architecture.** Berd descends from **goose**, the open source agent framework launched by Block in **January 2025**, contributed to the **Agentic AI Foundation** (Linux Foundation, December 2025) alongside **MCP** and **AGENTS.md**. Explicit division: *"goose remains the open agent framework and runtime. Berd is a desktop application built around it. **Berd connects to goose through the Agent Client Protocol.**"* goose holds the agent loop, Berd holds the experience. **The sequel is Buzz.** Berd served to explore **solo** work; *"But work rarely stays private"*. What Berd showed — *"private space, durable context, recognizable agent identities, reusable skills, visible configuration"* — will feed **Buzz**, the shared human+agent space. *"Start alone, then go multiplayer."* **Caveats.** **No figures, no user testing, no license named**; one isolated overreach (*"create custom agents to do any task they want"*); and a post whose title announces a retrospective while keeping the product in the present tense — **Berd is not declared deprecated, but the roadmap points to Buzz**.

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

Tue, 18 Aug 2026 00:00:00 GMT

Sonatype publishes, written by its *technical writer* Aaron Linskens, a synthesis of a longitudinal study by its research labs spanning forty-nine months, from June 2022 to June 2026. The method is stated upfront: a fixed cohort of applications tracked continuously, so that the measured variations reflect the evolution of the software fleet rather than that of the customer portfolio. The central result is presented as a contradiction: organizations remediate faster than before, yet their applications accumulate more risk. Four measures frame the finding. *Critical* and *High* vulnerabilities per application were multiplied by 4.31, rising from an average of 14.14 in June 2022 to 54.3 in 2026; the effect is not driven by legacy alone, since excluding legacy applications recently brought under management still leaves a factor of 3.91. Newly affected component versions are advancing at forty-six times the pre-AI rate. The median age of vulnerabilities has fallen 59% since its peak in January 2024. Finally, the average monthly creation of applications was multiplied by 4.84, and with it the dependency decisions. The progress in remediation is real: more than half of resolved violations are resolved in under a day, and the median age of unresolved *Critical/High* vulnerabilities drops from 228 to 126 days, then to 103 days in May 2026. Among cohorts with at least twelve months to act, 52.6% are resolved, 44.3% remain open, and 3.1% are under waiver. The proposed shift concerns the upstream. The researchers examined the vulnerable dependencies that entered the period's applications and asked a simple question: at the time of selection, did a substantially less risky version already exist? The answer is yes in 62.2% of cases on Maven, 46.9% on npm, and 34.3% on PyPI. The text declines to read this as developer fault: some vulnerabilities are unavoidable, others stem from an information gap at the time of the choice — a point that becomes sensitive when an AI assistant can introduce a component in seconds without having up-to-date intelligence on its risk and on organizational policy. The post acknowledges that AI is not the sole cause of the expanding vulnerability landscape and cites four competing factors. It concludes on Sonatype Guide, which brings this intelligence to the point of selection, and points to the full report, *The AI-Era Software Assembly Line*, for the underlying data.

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

The AI Engineering Skills Map

Fri, 14 Aug 2026 00:00:00 GMT

X post by **Andrew Ng** from **August 14, 2026**, reprised from the "Dear friends" letter of ***The Batch* #366** (DeepLearning.AI). **What is announced.** *The AI Engineering Skills Map*: **four skills** presented as the most important for a developer, backed by *« an analysis of more than 10,000 job postings »*, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data. Explicit dual audience: helping developers **prioritize what they learn** and employers **hire**. **The four skills.** **(1) Building and deploying AI applications** — their difference lying in the **unpredictability of outputs**, one must know the building blocks (LLM, context engineering, RAG, agentic workflows, machine learning, deep learning) and above all the **statistical techniques to measure, steer, and govern**, including *« disciplined evals and error-analysis loops »*. **(2) Software engineering fundamentals** — understanding them lets you *« recognize what tradeoffs exist »* (cost, scalability, reliability, speed, security, privacy) and thus steer the agent *« in the precise language of software engineering »*; the inexperienced vibe coder fails because *« they don't know what context to give their agent »*. **(3) Using coding agents** — a mental model of their limits, context management, planning/execution tradeoffs, **providing verifiers or evals so the agent closes its loops on its own**, working with a clear spec *« and when not to bother doing so »*, multi-agent orchestration, guardrails. **(4) *Shaping the build*** — since agents deliver well against a clear spec, the work shifts toward **deciding what the spec should contain**: product sense, business context, project ownership. **Underlying all four: a mindset of continuous learning**, with *« routines for trying new tools »*. **The real thesis, slipped into a terminology note.** Ng talks about **skills** in AI engineering and not the **role** "AI Engineer": *« all developers should know how to work with the cloud, only a small number carry the "Cloud engineer" title »*. **AI engineering becomes a baseline, not a specialty** — you don't hire, you requalify. **Two caveats.** **No numeric results are published**: no weighting, no sub-skills, a clustering described as an *« informal »* analogy, and the detailed map deferred to future posts. **This is the announcement of a map, not the map.** And the author states his interest: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities

Fri, 14 Aug 2026 00:00:00 GMT

Announcement post published on **August 14, 2026** on the **Z.ai** blog (formerly Zhipu AI), **unsigned**, for the launch of **GLM-5.3**. **The methodological thesis.** *« Scaling post-training is all we did for GLM-5.3. »* Same base model as GLM-5.2: **all the gain comes from post-training**, built on the stack from the previous cycle — **IndexShare** (long context), **SAO** (long-horizon RL) and **slime** (asynchronous training, Megatron + SGLang). The bottleneck has shifted from the model to **the environment**: Z.ai describes pipelines that **synthesize** environments and reward signal — a judge agent verifies solvability, **verifiers are synthesized without access to the reference solution**, and are admitted only after a triptych of **oracle / no-op / unsolved-state** controls. The work remains *« human-in-the-loop »*. End-to-end RL throughput improved by **more than 2.3×**. **The coding results.** Terminal-Bench 3.0 goes from **4.6 to 28.3**, DeepSWE v1.1 from **46.2 to 66.9**, Agents' Last Exam from **23.8 to 28.5**. On **Z.ai Code Bench**, an **in-house, private** benchmark, +50% over GLM-5.2, with a simultaneous gain in **token efficiency**: 34.5% at ~75K output tokens at Max effort (versus 23.4% at 96K for GLM-5.2), and 31.4% at ~50K at High effort — ahead of Claude Opus 4.8 (29.5% at 120K). **Claude Fable 5 remains ahead at 39.5%.** The claim *« most capable open-weights model for coding »* **does not follow from the table**: against **Kimi K3**, the score is **3–3 with one tie**. **The cyber capability.** Presented as *« emergent »*, it was **deliberately trained** — the post writes *« we expected this to make the model better »*. What came as a surprise was the **speed**, and the shift from isolated flaws to the **complete exploitation chain**. CyberGym **84.5%** (best in the table), ExploitBench **54.4%** (×2.2), ExploitGym **105/130 tasks** (×3.6 over GLM-5.2, throughput-normalized budgets). Key sentence: ***« Capability is growing fastest exactly where we are furthest behind. »*** **The heaviest number.** Working with Chinese security teams, the model identified **2,436 vulnerabilities in 269 open source projects** — kernels, OSes, browser engines, network protocols — the oldest introduced in **1981**, average lifetime **26.6 years**. The **Security Disclosure Ledger** shows **53 disclosed** and **2,383 under embargo**: **2.2% published**. **Governance.** Weights announced *« in two weeks, once safety evaluation and hardening are complete »* — **a date, not a criterion**: no definition of hardening, no condition for non-release, no third-party evaluator. **Miscellaneous.** `thinking.type: "disabled"` **is no longer supported** (migration required); GLM Coding Plan quotas in points, **50% outside 14:00–18:00 UTC+8**; **nearly all evaluations are conducted in Claude Code 2.1.207**.

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.

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

Thu, 06 Aug 2026 00:00:00 GMT

The **graphify.net** site, accessed on August 6, 2026, officially owned by **Safi Shamsi**, creator of the open source graphify skill. The domain carries three things distinct from the commercial platform `graphify.com` and the GitHub repository. **A product showcase**, first: presentation of graphify, usage guides, CLI reference, pages on tree-sitter and Leiden clustering. **A demo gallery**, next, and it is the most compelling part: **100 already-graphified GitHub Trending repositories**, totaling **854,079 nodes and 1,932,930 edges**, filterable by language and size, each showing its node, edge, and community counts, with a graph preview and detail page. Showing the tool running on well-known repositories is worth more than a pitch, and it produces, as a byproduct, a public dataset of comparable graphs. **An editorial directory**, finally, which has value independent of the product it promotes: **30 AI coding client guides** compared on workflow, agents, pricing, security, and delivery fit; an **MCP server directory** rated on transport, runtime, supported clients, setup effort, and **access risks**; pairwise comparisons on aligned fields. The site claims a method — *« source-reviewed »*, official evidence, explicit unknowns — and is available in six languages. **This fiche exists mainly to record a discrepancy.** On the same day, the site announces **« 3.7k+ GitHub stars »** when the API counts **103,187**; it states **three times** an **MIT** license when the repository's `LICENSE` file is **Apache 2.0**; and it highlights the **« 71.5× token reduction »** claim, which belongs to the v1-generation README and has disappeared from the current version in favor of LOCOMO and LongMemEval benchmarks. The site thus describes a product several generations old. **The license error is the most serious one**: MIT and Apache 2.0 do not carry the same obligations, notably on patents and the disclosure of modifications. A strategic observation remains: **a tool vendor building the directory of its own category** occupies the evaluation query ahead of its competitors. The claim of neutrality does not remove the conflict of interest — graphify appears among the site's featured skills. A useful entry point, not an arbiter.

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.

Introducing Muse Code and Muse Spark 1.2

Wed, 05 Aug 2026 00:00:00 GMT

Announcement from **Meta AI Research** dated **August 5, 2026**: **Muse Code** in beta, a terminal coding agent, and **Muse Spark 1.2**, the model that powers it. Meta itself frames the launch — *« our next step toward the frontier, with larger and much more capable models on the way »*. **On the harness side, three decisions.** **Asynchronous background agents** that *« remain active throughout each session, rather than being spawned for individual tasks »*, avoiding redundant information gathering and deciding for themselves when to escalate to the main agent. A **local event log** recording every model call, tool run, approval, and edit, which makes the runtime *« replay-exact and restart-safe »*: after a crash, the agent resumes exactly where it left off. And three **skills shipped out of the box**: `/plan` (a plan submitted for approval), **`/grill`** (stress-tests the plan until it holds up), and `/goal`. **On the model side**, Meta claims **co-training with the harness** *« to maximize harness compatibility »*, long-horizon training (whole repo, end-to-end projects, self-research, context compaction), and a self-improvement loop where version 1.1 generates the environments and grades the solutions, producing the training set for 1.2. **The central fact of this announcement is nowhere stated in its text.** The four published comparisons exist only as images, and they place Muse Spark 1.2 **behind Opus 5 in all four cases**: 82.9% versus 86.7% on Terminal-Bench 2.1, 59.3% versus 65.0% on DeepSWE 1.1, **70.6% versus 79.4% on Meta's own internal benchmark**, and +68.7% versus +74.0% on the GPU kernel optimization case study, where the model finishes **fourth out of six**, behind GPT 5.6 Sol and behind Anthropic's previous generation. **And the model's own gain is smaller than it appears.** On the two public benchmarks, version 1.1 is evaluated with `mini-swe-agent` and 1.2 with Muse Code: the 6.7-point gap conflates model and harness. On the internal benchmark, the only comparison with no harness indicated, it drops to **2.3 points**. The announcement therefore stands mainly as **empirical confirmation** of a thesis already stated: value is shifting toward the harness, and a harness co-trained with its own weights makes those weights all the more non-interchangeable.

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.

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

Mon, 03 Aug 2026 00:00:00 GMT

**Skill** entry: **hyperresearch** by **Jordan Gibbs** is a **deep research harness** that turns Claude Code into a documentary research agent, shipped as a PyPI package (MIT, Python 3.11-3.13) installing **20 Claude Code skills**, a CLI, an MCP server, and a local web UI. Observed on **August 3, 2026**: 1,568 stars, 170 forks, repo created on April 9, 2026, last push on August 1. **The core is a 16-step pipeline adaptive by tiers** — `light` (~30-40 min), `full` (~1.5-2.5 h), `dissertation` (4-8 h, 25,000-80,000 words across 300-450 sources) — which takes a prompt and returns an adversarially audited report with full provenance. **The central architecture decision is documented alongside its failure mode**: the entry skill is a **thin router** with no procedure, each step living in its own skill loaded **fresh at the moment it is invoked**, because the previous version was *« one 1200-line skill that got compacted away by the time Layer 4 needed its triple-draft procedure. The orchestrator forgot the procedure, wrote a single draft, and produced a flat-scoring report. »* **Two load-bearing principles.** *« Patch, never regenerate »*: after synthesis, only surgical `Edit` touch-ups are possible, with the patcher and the polish auditor tool-locked to `[Read, Edit]` at the Claude Code allowlist level, so that they *« physically cannot Write a new draft »*. *« Canonical research query is gospel »*: the verbatim prompt is persisted once in `query.md` and re-read by every step and every subagent. **Sixteen subagents** with configurable role and model (fetchers and cite-checker on Sonnet, critics, synthesizer, and patcher on Opus). **The vault** is a persistent markdown store indexed in SQLite — *« Markdown is truth, SQLite is cache »* — with a note lifecycle (`draft → review → evergreen`, `stale → deprecated → archive`), traceable provenance, a composite quality score (source type, citation authority via OpenAlex and Semantic Scholar with retraction flags, internal PageRank), and an **independence audit** that groups syndicated copies together — *« five reprints of one press release argue with the weight of one source »*. **Three mechanical gates before shipping**: citation integrity (every quoted citation must exist **verbatim** in a vault note), a retraction sweep refreshed on every cited DOI, and a citation-to-sentence link check by a skeptical LLM. **Reservation to flag**: the opening claim — *« currently leads the DeepResearch-Bench RACE leaderboard »* — is contradicted by its own footnote, *« forward-looking projection from a stratified pilot… Third party validation is pending »*. A projection is not a ranking, yet the chart places it ahead of Gemini and OpenAI Deep Research.

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.

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

Thu, 30 Jul 2026 00:00:00 GMT

Episode "Phase 5 · Review" of the SFEIR series on the augmented SDLC, published **the same day** as the Addy Osmani LinkedIn post that it translates into a phase specification. Thesis: **quality has changed address** — it is no longer read in the code (agents produce more of it than anyone can review) but in **the ring of constraints surrounding the agent**. Osmani's ring (seven dimensions — correctness, security, performance, accessibility, maintainability, **economic efficiency**, **comprehensibility** — linked by the **back-pressure** rule: "a loop is only granted the autonomy that can be verified cheaply and reliably, not an inch more") is redrawn, translated, and attached to phase 5 of SFEIR's 11-phase cycle. The structuring corollary: **the bottleneck has never been generation, it is verification** — "generation is a wide mouth, verification a narrow neck; speeding up the mouth thickens the pile at the neck." **The most interesting design decision is a cycle-architecture choice**: Review is deliberately **outside the three human gates** (Define, Plan, Ship), because making Review the gate would put human attention — a finite resource — as the control point of a generation capacity that itself scales: "you would have built a pipeline whose maximum throughput is the number of diffs a senior can read before the end of the day." Hence the split: **Review instruments, Ship decides** — Review delivers an *opposable body of evidence*, Ship decides on the evidence, not on the full diff. A position staked against Monperrus (from whom SFEIR retains the diagnosis — human inspection of every diff cannot withstand agentic speed — but rejects the conclusion: acceptance cannot be delegated). The named trap is **circular validation** (the agent that writes the code writes the tests that validate it: "you built a mirror, not a ring"), with five countermeasures drawn from Anthropic (independent gates in separate context windows, deterministic + agentic never substituting for one another, shadow mode, risk-based tiering, logging to the SIEM) and Compare the Market's warning (**AST graph ~70% vs vector RAG ~58%**, with RAG performing *worse than no context at all*). The firm's own extension is **the ratchet**: "every escape becomes a constraint" — a defect that has crossed the ring is closed *within the ring* (test, lint rule, review rubric, harness guardrail) at Compound-1, "the only asset in the chain that appreciates while the models depreciate" (an unaudited internal measurement: **−30% fix iterations after ten cycles**). It closes by reformulating the question: "is this code good?" has become unanswerable; what remains is **"what does my system refuse to let through?"**

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

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

Sun, 26 Jul 2026 00:00:00 GMT

Five days after Jason Clinton's (Anthropic's Deputy CISO) debrief on securing a development cycle that has become AI-native, SFEIR publishes a decryption that disputes nothing and adds no fact: it **shifts the subject**. The reader comes looking for security controls; they are shown that what is missing first is a cycle. The account is faithful. Three input measures, self-reported by Anthropic: ×8 code shipped per engineer per quarter, ~80% of merged code written by Claude, more than half merged by the internal version of Claude Tag. A problem posed by **Amdahl's law**: if review and monitoring do not scale at the same rate as production, acceleration becomes a bottleneck. An explicit threat model (compromised or prompt-injected agent, dependency poisoning, increased volume of classic vulnerabilities). Then a control mapped per stage: **PSR** at Plan, **CLAUDE.md** and **egress allowlist** at Code, **specialized review agents** at Test, **continuous DAST** at Deploy, **triage and SIEM routing** at Monitor. The thesis holds in a four-part anaphora. **Without an SDLC, gains do not materialize**: multiplying code volume by 8 multiplies nothing if review stays sequential — Anthropic gained not by distributing agents but by identifying the blocking stage, Test, and rebuilding it; "you don't optimize a bottleneck you haven't mapped." **Without an SDLC, security has no anchor**: a gate is by definition a control placed between two stages. **Without an SDLC, no token FinOps policy can be formulated**: scanning is billed on consumption and grows with code throughput, so the **risk-based tiering is the FinOps policy** — it decides where three agent passes get paid for and where a SAST suffices; otherwise "token spend is not steered, it is discovered at month's end." **Without an SDLC, there is nothing to measure**: the shift from 16% to 54% of PRs commented presupposes a stage where a counter can be placed; absent that, one produces only usage figures, silent on quality and risk. Two contributions beyond the thesis. The reading of the incident agent-à-agent — an incident-response agent asking another Claude instance, via Slack, to push a fix, stopped by a human gate: "a perimeter that rests on an instruction in a prompt is not a perimeter," and an agent's access to other agents is part of its attack surface. And a clear caveat: these figures come from the vendor of the model, on a young codebase with no mainframe. **What transposes is the method, not the figures.**

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

Wed, 22 Jul 2026 00:00:00 GMT

SFEIR analysis (consulting-firm voice, "an engineer's reading") articulating two frameworks too often conflated: the **SDLC** (Software Development Life Cycle — *building the software correctly and reliably*) and the **PDLC** (Product Development Life Cycle — *building the right product and succeeding in the market*). Central thesis: the two cycles are not competitors but **nested** — the SDLC is the subset of the PDLC **housed under its development phase**; when a product team reaches the "build" stage, a full SDLC cycle (design → build → test → review → deployment) runs inside it. The SDLC is standardized (**ISO/IEC/IEEE 12207**, 2017 and 2026 editions), with its lineage of models (Waterfall 1970, V-model, iterative/spiral, **Agile 2001**, **DevOps/DevSecOps 2009+**) and its **DORA** metrics (throughput, stability, MTTR, change failure rate). The PDLC, being the umbrella cycle, runs from **ideation/discovery** to **market withdrawal** (not to be confused with the marketing **PLC** of Theodore Levitt, 1965, which describes a *commercial curve*, not *organized work*: "the PLC observes a curve; the PDLC organizes work"). **Tipping point**: the SDLC natively addresses **only one risk in four** — via **Marty Cagan's "Four Big Risks"** framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business viability → PM) — an organization excellent at SDLC but blind to PDLC produces "software nobody wants" — John Cutler's **"feature factory"** (success measured by output, not outcome). **Why AI changes everything**: generative AI **compresses the SDLC** (Google/JetBrains data, May 2026: **~85% of developers** regularly use coding agents, **~41% of new code** is AI-generated; implementation goes from weeks to hours), so the **bottleneck shifts upstream** — deciding *what* to build (Marty Cagan, April 2026: "when the cost of delivery collapses, the bottleneck shifts to discovery"). Consequences: DORA 2025 (~5,000 professionals, 90% AI adoption) shows a **positive correlation with throughput but a negative one with stability** (more unvalidated features means instability and rework); Andrew Ng (AI Startup School, July 2025) reports teams **reversing the "1 PM for 4 engineers" ratio to "2 PMs for 1 engineer"**; and with **spec-driven development**, the PDLC/SDLC boundary becomes **porous** (the product spec becomes directly executable by agents). **What a CIO should take away**: an augmented SDLC becomes a **market standard, not a differentiator** — the junction with the product must be instrumented, **executable specifications** demanded as input, technical metrics cross-referenced with outcome metrics, and the role of "feature supplier" **refused**. For a CPO: the shift of the bottleneck toward discovery is both a **promotion** (product judgment becomes scarce again) and a **notice to act** (industrialize discovery to reach parity with the SDLC). SFEIR's in-house framework ("Designing and building in the agentic era" — **11-phase cycle** + **Software Factory 10x**) is positioned as the answer on the engineering side, with the **articulation of the two cycles** as the next lever. Conclusion: "as code becomes a commodity, margin shifts toward product judgment and governance."

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.

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

Mon, 20 Jul 2026 00:00:00 GMT

Udit Akhouri releases **ADHD** ("a skill for agents"), an open source project (MIT, v0.1.4, ~1,000 stars) that tackles the **premature convergence** of autoregressive reasoning: an LLM anchors on its first idea, and tree-based methods don't really escape it — "Tree-of-Thought widens the search but traverses a single shared context, so the anchoring persists across branches." The project's stance: this is an **architecture problem, not a prompting problem**. The mechanics consist of two **watertight** phases. *Diverge*: N parallel, **isolated** agent calls — no shared context — each receive the problem through one of **15 cognitive frames** deliberately distorted (with selection logic and custom frames), under a system prompt that **forbids evaluating**. *Focus*: a **separate** critic, with an opposite system prompt, scores the ideas (originality, viability, fit), clusters them by underlying angle, **flags the traps with their reasons**, and deepens the best survivors. The generator/critic separation is "mechanical": distinct LLM calls, not roles simulated within a single context — the same intuition as the separate-context adversarial review of the Bun project ([[sumner-bun-rewrite-rust-claude-2026-07-08]]). The signature demo compares, on "a CLI that calls an LLM and sometimes freezes for 90s," the baseline (4 textbook patterns: progressive timeouts, exponential backoff, hedged requests, streaming — "the answer a senior gives in 30 seconds") against ADHD: 30+ ideas across 6 clusters, **20 named traps**, and a non-obvious pick — the **"rage-quit"** button that animates with the wait and instantly reroutes the request to a faster, cheaper model, because "the slow model might just be the wrong model for this prompt." On 6 open problems, the author's evaluation (LLM judge) gives breadth 9.00 vs 4.83, novelty 7.83 vs 2.67, **trap detection 9.50 vs 1.83**, actionability 9.50 vs 6.50 — self-reported figures, to be read as claims. Distribution runs through the **skills** ecosystem (same channel as [[skill-pocock-grill-with-docs-2026-06]]): `npx skills add UditAkhourii/adhd` auto-detects ~50 agents (Claude Code, Cursor, Codex, Cline, Gemini CLI, Windsurf…), invocation via `/adhd` or auto-triggering on ideation intents, a CLI and an npm library, all built on the Claude and Codex Agent SDKs. Traction is tangible: a feature on The New Stack, a preprint, adoption by repowire (PR #313 merged — the frames become "peers" of the mesh-orchestrator), mstack (`think` plugin), zk-flow-oss, and an independent research review (testdouble/han) whose findings live on in public issues. Takeaway: useful divergence isn't prompted, it's **architected** — through context isolation and the mechanical generator/critic opposition.

Reflecting on a year of Claude Code

Fri, 17 Jul 2026 00:00:00 GMT

Boris Cherny (**Head of Claude Code**) and Cat Wu (**Head of Product, Claude Code**) publish on LinkedIn, via Claude for Business, a short (~47 s) video titled **"Reflecting on a year of Claude Code."** Their thesis: in the age of coding agents, **product and engineering roles are merging**. "Is everyone going to be a PM or is everyone going to be an engineer? Everyone's going to be both." **Proof by example: the internal case.** Cherny describes how Anthropic operates as a demonstration: the product team, devrel, and design **all write code**; conversely, many engineers **ship products end to end** — they have an idea of what to build, they build it, then work with legal, marketing, and security to communicate and ensure safety. Conclusion: AI **benefits profiles** with **curiosity**, **product taste**, and an appetite for **end-to-end ownership**. **The real content: the comment thread.** Of 55 comments, 28 contribute a substantive idea, forming a public peer review across eight axes. The **dominant** reframing: it is not roles disappearing, it is the **shortening of the feedback loop**. Rehan Nazir — when a PM validates an idea with a same-day prototype, "org charts stop mattering"; Noman A. — ideas get tested in hours rather than weeks, changing *how companies learn*; Kevin Schoovaerts — Claude Code builds 80% of the product, the power lies in the tight loop with the user. Second, deeper axis: the **scarce skill is shifting** from "knowing how to build" toward **judgment** and **defining the right problem** (Omer K., most-liked comment: "choosing the right problems, knowing what NOT to build"; Syed T.; Andrei van Noordt: the scarce hire becomes the person with taste about *what* to build who can also build it; Natasha Newbold: one becomes an **architect** writing the specs that teams of agents execute). Sunny Vara shifts the stakes from the prompt to **context**. **The counterpoint.** One layer raises the questions the video sidesteps: Paul Breuler and Ron H. — ownership rises, so **accountability** rises too; "when everyone can build, someone still needs to be able to say no." Mohammadjavad Sayadi — the **demo/production gap** remains significant in regulated domains (healthcare). The **skeptics** (Chris Bounds, Mohamed Anis, Panny Malialis, David H.) warn against generalizing a startup-mode way of operating. Finally, two **frontal critiques** (James Hutchinson, Dewayne J Grunden II) denounce the **theft of intellectual property** and call for open-sourcing models and compensating creators. In one sentence: the consensus validates the thesis but reframes it — **shipping becomes cheap**, which shifts value toward **judgment, product taste, and the right problem**, while accountability, governance, and reliability have not yet caught up.

The Token Manifesto

Fri, 17 Jul 2026 00:00:00 GMT

**Nicolas Martignole** publishes on *Le Touilleur Express* **« The Token Manifesto »**, a short satirical text co-written with two models (**GLM-5.2** and **MiniMax-M3**). The mechanics are clear: take the exact structure of the **Manifeste Agile** from 2001 — its preamble, its four values in "X over Y" form, its twelve principles — and transpose it to the world of LLMs, where the unit of account is no longer the engineer-hour but the **token**. The preamble sets the tone: "We are uncovering better ways of consuming context by doing it… Through the work of producing tokens, deleting tokens, and **staring at a usage bar nervously**, we have come to value… ". **The four values** sketch an aesthetic of the frugal prompt: *short system prompts over clever system prompts*; *one clear example over three paragraphs of explanation*; *iterating in small steps over dumping the whole spec at once*; *outputting in a defined format over letting the model freestyle*. Each pits an economical practice (concision, example, iteration, constrained format) against a costly temptation (sophistication, verbosity, a massive spec, an unconstrained answer). **The twelve principles** subvert those of Agile one by one. The priority becomes delivering "**the answer, not the climb toward the answer**"; the manifesto "welcomes changing requirements, even late in the conversation"; it builds "around motivated individuals with an **adequate context window**"; "working prompts measure progress **and credit the bills**." The most-cited principle flips Agile's famous tenth: "**Simplicity — the art of maximizing the amount of work not done by the model**." Others target context debt ("spot repetition and document it once") and economic sustainability ("a prompting pace that can be sustained indefinitely," "regular reflection **before the monthly bills arrive**"). Two punchlines close the manifesto and carry its serious thesis under the humor: **« You don't have a prompt problem. You have a context-window problem. »** — shifting attention from *prompt engineering* to the **economics of the context window** — and **« Everyone's a prompt engineer until they run out of monthly quota. »** — an ironic reminder that real skill is measured at the usage meter. Beyond the joke, the text crystallizes a cultural shift: in the era of AI-assisted dev, the structuring constraint is no longer **velocity** (Agile's obsession) but the **token budget** and context management. The human-plus-models co-authorship acts as a meta-signature: an argument for token frugality, written with the help of the very models it teaches to conserve.

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

Thu, 16 Jul 2026 00:00:00 GMT

Boris Cherny, Creator & Head of Claude Code at Anthropic, publishes a framework table — **« Steps of AI Adoption »** — born from a recurring observation: in many companies, *one* person multiplies their output tenfold with Claude, but the rest of the organization doesn't follow. From this he derives a **5-stage maturity scale (0→4)**, structured around the **order of magnitude of agents an engineer drives** — and the role transformation this imposes. **0 — Gated (0 agents)**: locked-down access, older models, no MCP governance nor infrastructure to host Claude's code; bottleneck = legacy security/approvals and an obsession with cost-per-token. **1 — Assisted (~1)**: "you + one agent", supervised pair programming, synchronous work; bottleneck = your attention, since without self-verification you review everything. **2 — Parallel (~10)**: you become the **orchestrator** of 5–10 agents on separate worktrees; Claude self-verifies (tests/build/lint/security), Auto mode and automated reviews by default; bottleneck = reviewing multiple streams. **3 — Supervised autonomy (~100)**: **manager of managers**, Claude writes almost everything, maintenance runs in the background; bottleneck = trust in the loop and decision throughput. **4 — AI-native (~1,000+)**: **VP steering by intent**, a closed loop where Claude launches most agents, monitoring by exception. **Central thesis**: tokens don't move you up a level. Each tier has its own bottleneck; progress comes from **breaking it** and **building the next set of guardrails** that makes the output trustworthy. The levers named: self-verification loop (tests + build + lint + e2e on a real environment), **Auto mode** against blocking prompts, **code review + security review by default**, multi-agent interfaces (Agent view, Desktop, mobile, Tag), then `/loop`, `/batch`, `/goal`, **dynamic workflows**, **worktree isolation**, **CLAUDE.md + Skills** to encode standards, and finally the **Claude Agent SDK** to program/schedule fleets of agents. On steering, Cherny dismisses the vanity metric: usage measures **activity, not return**. The right question — *would we have spent this effort anyway, and how many **manual engineer-hours** would it have cost?* — gives the true ROI. The decisive gain comes when fixing/maintaining moves to the background, freeing teams to *build* what wasn't even within reach before. An honest benchmark: Anthropic is at stage 3 and pushing toward 4; he himself has just reached level 4.