Landing page of the **official specification** of the **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), accessed on **August 2, 2026**. This is not a dated article but a **living artifact**: the fiche is dated by its observation, not by a publication date. **One-sentence mission statement**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **The stated problem** fits in three lines: coding agents and editors are **tightly coupled** and *« interoperability isn't the default »* — every editor must build a custom integration per agent, every agent must implement editor-specific APIs. Three named consequences: **integration overhead** (every agent-editor pair requires custom work), **limited compatibility** (an agent reaches only a subset of editors), **developer lock-in** (*« choosing an agent often means accepting their available interfaces »*). **The solution is explicitly modeled on LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — with the mutual benefit: an agent that speaks ACP works with **any** compatible editor, an editor that supports ACP gains access to the **entire** ACP agent ecosystem. **Two deployment modes, and this is the most underrated point**: **local** agents run as a subprocess of the editor over **JSON-RPC on stdio**, but **remote** agents are planned over **HTTP or WebSocket** — support declared *« work in progress »*, with ongoing collaboration with agentic platforms. **Technical lineage with MCP, stronger than mere complementarity**: ACP *« re-uses the JSON representations used in MCP where possible »*, adding types specific to agentic coding UX needs (**diff** display is the example given); the default format for readable text is **Markdown**, chosen so the editor is not required to render HTML. **Two governance and versioning observations** drawn from the page itself, not from surrounding discourse: the navigation exposes **v1 (Latest)** and **v2 (Draft)** — and **not an "ACP 1.2"** —, and the navigation bar links **Zed Industries *and* JetBrains** side by side, alongside an **ACP Registry**, **RFDs**, a **Community** section, **Publications**, **Updates**, and a **Brand** page. Official libraries announced: **Kotlin, Java, Python, Rust, TypeScript**, plus a community track.
#Agent Client Protocol#ACP#open protocol
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
X post by **Eric S. Raymond** (ESR, author of *The Cathedral and the Bazaar*, co-founder of the Open Source Initiative, ~50 years of coding) — **a frontal counter-testimony to the narrative that "LLMs produce crap code and hallucinate, useless for programming."** His thesis: this **almost never happens to him**, and **not at all anymore over the last two generations** of models he uses ("chat GPT 5.4 and 5.5" under **codex**). The former symptom — a model "going off the rails" as it approaches its context limit — has disappeared: codex now displays a **red warning** prompting the user to **clear the session** instead of spiraling. **Scope of use**: AI applied to **feature changes, refactoring and debugging across 63 projects** in **C, Go, Rust, Python and shell**; documentation writing; **decompiling a DOS binary into readable source**. An established **work routine**: when reopening a project, he first runs the **regression tests**, then starts codex and asks it to **audit the code** (bugs + improvement suggestions). Verdict: LLMs are **"excellent and tremendously empowering"**; their **worst limitation** is **"architectural tunnel vision"** — excellent at generating code to specification, but sometimes **blind to higher-level patterns** — which he takes to be the **job of his "meatbrain."** The strongest, counter-intuitive point: LLMs **do NOT get details and edge cases wrong**; he says he is **worse than them** on this front (despite 50 years of experience), because if a change must **touch five places**, the model **reliably finds all five**, whereas the human fixes four and **spends hours debugging** before finding the forgotten fifth. He then questions the **"downshouters"**: do they live in a **different universe**? Are they using **old, weak models**? Is there a **skill issue** he doesn't see because his **mental habits and communication** fit well with these tools' "handles"? An issue he considers important to settle, since "**billions of dollars would be wasted on misdirected token spend**." His recipe, "very simple": **"Be clear in your thinking, tell the model what you want with precision, and good things happen"** — closing with: "what am I missing here?" To be read as a **pro-LLM counterpoint from a historic figure of open source** to the recurring debate on the (de)valuation of coding agents — echoing the "skill issue" and specification discipline (cf. [[martignole-token-manifesto-2026-07-17]]), and forming a diptych with **Linus Torvalds'** doctrinal pro-AI-tool stance on behalf of the Linux kernel ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
SFEIR article (in French) that formalizes an **AI-driven SDLC in 11 phases (0 to 10)** and argues that the industry is converging toward it. Starting observation: in 2025, organizations added AI tools without transforming their operating model — producing a paradox of « everything changes… and nothing changes » (execution speed multiplies without proportional gain). The real answer is not the choice of tools but the **redesign of the cycle** for machine execution. The SFEIR cycle rests on **three immovable human gates** (Define, Plan, Ship), automatic phases between them, and **two capitalization moments** (Compound-1 pre-deployment, Compound-2 in production) that turn lessons into reusable rules. Three principles: **AI executes** (complete artifacts + proof of execution, never trusting the agent's own claims), the **human retains control of intent**, the **system learns cumulatively**. Measured results (redesign 6 months→1 day, **−30% of iterations** after ten cycles) and claimed convergence with ADLC, Google, and DORA 2025.
An arXiv paper (cs.SE) by Martin Monperrus arguing a radical thesis for the SDLC: coding agents have crossed a threshold of capability such that **human code review is no longer a necessary component** of a quality pipeline. Two claims: (1) autonomous LLM-based systems achieve all the goals of review (defect detection, quality, compliance) at lower cost and higher throughput; (2) the hybrid model "the agent writes, the human reviews" is untenable — it does not ensure real quality and does not scale with AI velocity, creating a "false sense of security". Monperrus contrasts inspection de Fagan (1976) with a **multi-agent adversarial verification pipeline** (generator agent + independent reviewer agents + tests/formal methods + vote-based consensus). The human refocuses on the spec, architectural trade-offs, approval of critical domains, and edge cases. Recommendations: pilot first on low-risk components, measure agent vs. human, make rejection decisions explicit.
Guide by Augment Code (Paula Hingel) describing how AI agents are restructuring the software development lifecycle (SDLC), stage by stage. Thesis: AI produces **higher throughput at some stages and higher instability risk at others** — a symptom of uneven adoption without redrawing review boundaries. Draws on **DORA 2025**: AI adoption correlates positively with delivery throughput and product performance, but **negatively with stability**. Six stages revisited (Requirements, Design/Architecture, Implementation, Testing/QA, Deployment, Maintenance), three major risks (erosion of the junior pipeline, **circular validation** of AI-generated tests, governance gaps at scale) and three emerging roles (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Actionable recommendations: audit one stage before scaling, stress-test governance, make the **specification** central, define explicit rollback policies, redesign the junior role around review.
#SDLC#software development lifecycle#coding agents