Landingpage der **offiziellen Spezifikation** des **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), abgerufen am **2. August 2026**. Es handelt sich nicht um einen datierten Artikel, sondern um ein **lebendes Artefakt**: Die Fiche ist nach ihrem Beobachtungszeitpunkt datiert, nicht nach einem Veröffentlichungsdatum. **Ein-Satz-Missionsaussage**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **Das genannte Problem** lässt sich in drei Zeilen fassen: Coding Agents und Editoren sind **eng gekoppelt**, und *« interoperability isn't the default »* — jeder Editor muss für jeden Agenten eine eigene Integration bauen, jeder Agent muss editorspezifische APIs implementieren. Drei benannte Konsequenzen: **Integrationsaufwand** (jedes Agent-Editor-Paar erfordert individuelle Arbeit), **eingeschränkte Kompatibilität** (ein Agent erreicht nur eine Teilmenge der Editoren), **Developer-Lock-in** (*« choosing an agent often means accepting their available interfaces »*). **Die Lösung ist explizit an LSP orientiert** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — mit gegenseitigem Nutzen: Ein Agent, der ACP spricht, funktioniert mit **jedem** kompatiblen Editor, ein Editor, der ACP unterstützt, erhält Zugang zum **gesamten** ACP-Agenten-Ökosystem. **Zwei Deployment-Modi, und das ist der am meisten unterschätzte Punkt**: **Lokale** Agenten laufen als Subprozess des Editors über **JSON-RPC auf stdio**, aber **Remote**-Agenten sind über **HTTP oder WebSocket** geplant — die Unterstützung wird als *« work in progress »* deklariert, mit laufender Zusammenarbeit mit agentischen Plattformen. **Technische Abstammung von MCP, stärker als bloße Komplementarität**: ACP *« re-uses the JSON representations used in MCP where possible »* und ergänzt Typen, die spezifisch auf die UX-Bedürfnisse des agentischen Codings zugeschnitten sind (die **Diff**-Anzeige wird als Beispiel genannt); das Standardformat für lesbaren Text ist **Markdown**, gewählt, damit der Editor nicht zum Rendern von HTML gezwungen ist. **Zwei Beobachtungen zu Governance und Versionierung**, die der Seite selbst entnommen sind, nicht dem umgebenden Diskurs: Die Navigation zeigt **v1 (Latest)** und **v2 (Draft)** — und **nicht ein „ACP 1.2“** —, und die Navigationsleiste verlinkt **Zed Industries *und* JetBrains** gleichrangig nebeneinander, neben einer **ACP Registry**, **RFDs**, einem **Community**-Bereich, **Publications**, **Updates** und einer **Brand**-Seite. Angekündigte offizielle Bibliotheken: **Kotlin, Java, Python, Rust, TypeScript**, plus ein Community-Track.
#Agent Client Protocol#ACP#offenes Protokoll
**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 von **Eric S. Raymond** (ESR, Autor von *The Cathedral and the Bazaar*, Mitbegründer der Open Source Initiative, ~50 Jahre Programmiererfahrung) — **ein frontales Gegenzeugnis zur Erzählung, dass „LLMs schrottigen Code produzieren und halluzinieren, unbrauchbar zum Programmieren“.** Seine These: Das **passiert ihm fast nie**, und **überhaupt nicht mehr in den letzten zwei Generationen** der von ihm genutzten Modelle („ChatGPT 5.4 und 5.5“ unter **codex**). Das frühere Symptom — ein Modell, das „entgleist“, wenn es sich seinem Kontextlimit nähert — ist verschwunden: codex zeigt jetzt eine **rote Warnung** an, die den Nutzer auffordert, die **Sitzung zu leeren**, statt abzudriften. **Nutzungsumfang**: KI angewandt auf **Feature-Änderungen, Refactoring und Debugging über 63 Projekte** in **C, Go, Rust, Python und Shell**; das Verfassen von Dokumentation; **das Dekompilieren einer DOS-Binärdatei in lesbaren Quellcode**. Eine etablierte **Arbeitsroutine**: Beim Wiederöffnen eines Projekts führt er zunächst die **Regressionstests** aus, startet dann codex und bittet es, den Code zu **auditieren** (Bugs + Verbesserungsvorschläge). Fazit: LLMs sind **„exzellent und enorm empowernd“**; ihre **größte Schwäche** ist der **„architektonische Tunnelblick“** — hervorragend darin, Code nach Spezifikation zu erzeugen, aber manchmal **blind für übergeordnete Muster** — was er als die **Aufgabe seines „Fleischhirns“** ansieht. Der stärkste, kontraintuitive Punkt: LLMs **liegen bei Details und Randfällen NICHT falsch**; er sagt, er sei diesbezüglich **schlechter als sie** (trotz 50 Jahren Erfahrung), denn wenn eine Änderung **fünf Stellen berühren** muss, findet das Modell **zuverlässig alle fünf**, während der Mensch vier korrigiert und **stundenlang debuggt**, bevor er die vergessene fünfte findet. Er stellt daraufhin die **„Herunterschreier“** in Frage: Leben sie in einem **anderen Universum**? Nutzen sie **alte, schwache Modelle**? Gibt es ein **Skill-Problem**, das er nicht sieht, weil seine **Denkgewohnheiten und Kommunikation** gut zu den „Griffen“ dieser Werkzeuge passen? Eine Frage, die er für wichtig hält zu klären, da „**Milliarden von Dollar durch fehlgeleiteten Token-Einsatz verschwendet würden**“. Sein Rezept, „ganz einfach“: **„Denke klar, sag dem Modell präzise, was du willst, und gute Dinge geschehen“** — mit dem Schlusssatz: „Was übersehe ich hier?“ Zu lesen als ein **Pro-LLM-Gegenpunkt einer historischen Figur der Open-Source-Bewegung** in der wiederkehrenden Debatte über die (Ab-)Wertung von Coding-Agenten — anklingend an das „Skill-Problem“ und die Spezifikationsdisziplin (vgl. [[martignole-token-manifesto-2026-07-17]]) und ein Diptychon bildend mit **Linus Torvalds'** doktrinärer Pro-KI-Werkzeug-Haltung im Namen des Linux-Kernels ([[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.)