Essay von **Bill Staples**, CEO von **GitLab**, veröffentlicht am **24. August 2026** im Blog von about.gitlab.com: eine angekündigte Lesezeit von **31 Minuten**, rund **39.000 Zeichen**, dargestellt als Fortsetzung eines im Januar 2026 an den Verwaltungsrat gerichteten Memos, das im Mai teilweise unter dem Titel *GitLab Act 2* veröffentlicht wurde. Der Text versteht sich als Antwort auf das drei Tage zuvor veröffentlichte KI-native-SDLC-Playbook von **Anthropic**, dem er die Eingangszeile entlehnt – „Code is no longer the bottleneck“ –, um die Frage zu stellen, die ihn trägt: Was wird knapp, wenn Code im Überfluss vorhanden ist. (A) Die ökonomische Diagnose: Die nützliche Einheit sind nicht die Kosten pro Zeile, sondern die **Kosten pro akzeptierter Änderung**, die Generierung, Umgebung, Kontext, Verifikation, Review, Behebung und Governance zusammenfasst; KI lässt allein den Generierungsterm kollabieren, wodurch die übrigen proportional schwerer wiegen – eine Organisation, die zehnmal schneller generiert, „wird die Warteschlange lediglich verschieben“. (B) Die architektonische Antwort: vier Fähigkeiten – Agentenplattform, maschinenskalige Ausführung, dauerhafter Kontext, Governance – bilden eine Unternehmensschicht, die das Modell überdauert, „Das Modell sollte austauschbar sein. Der Agent sollte dem Kunden gehören.“ (1) Drei Modi koexistieren dauerhaft, vom menschengesteuerten Altsystem bis zur autonomen Entwicklung, gegen die Vorstellung einer einzigen Reifekurve. (2) Die CI/CD-Pipeline wird zu dem Ort, an dem die innere Schleife läuft, statt ein Gate am Ende der Kette zu sein. Die zitierten Zahlen stammen von Stripe, Spotify und Amplitude; GitLab liefert nur eine einzige, zur eigenen Quellcodeverwaltung. Der Korpus enthält bereits [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], die Quelle, auf die dieser Text antwortet, sowie [[sfeir-sdlc-pdlc-articulation-2026-07-22]] zur Verzahnung von SDLC/PDLC, die Staples sich zu eigen macht.
#Codeüberfluss#Kosten pro akzeptierter Änderung#Theory of Constraints
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Ausführlicher Leitfaden von **Anthropic** von **Louis Claxton** (Applied-AI-Team), veröffentlicht am **21. August 2026** im claude.com-Blog: eine angegebene Lesezeit von **40 Minuten**, rund **64.000 Zeichen**, präsentiert als Sammlung von *Plays*, die aus der Arbeit des Teams mit seinen Kunden stammen. (A) Die Diagnose: Da Code nicht mehr der Engpass ist, verschiebt sich dieser auf die Phasen vor und nach dem Bau (Planung, Review/Test, Deployment); zeilenweise Kontrollen greifen nicht mehr, sobald der Agent den Großteil des Diffs schreibt, und die Governance-Kosten steigen, da Ausnahmen weiterhin über periodische Ausschüsse laufen. (B) Die Antwort: sechs Phasen (Plan, Design, Build, Test, Deploy, Maintain), organisiert als **Schleife** statt als Kette, jede endet mit einem **committeten Artefakt**, das die nächste Phase liest — `intent.md`, `spec.md`, `plan.md`, der Diff und seine Tests, der PR und seine Befunde, der Vorfallbericht. (1) Institutionelles Wissen wird zu versionierten Dateien: `CLAUDE.md`, Skills, `REVIEW.md`, `bands.yaml`. (2) Governance gliedert sich in zwei Schichten, wobei der Skill als beratende Kontrolle positioniert ist und der Hook als deterministische Schicht dahinter. Funktionstrennung wird als Invariante festgelegt — der Agent, der den Code schreibt, kann ihn nicht genehmigen —, und der Beitrag schließt mit *„The loop keeps running. Human judgement stays above it.“* Der Korpus enthält bereits [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] zur Sicherheitsseite desselben Zyklus sowie [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] zur selben Sechs-Phasen-Gliederung aus Sicht eines Wettbewerbers.
#AI-native SDLC#software development lifecycle#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Leitfaden von **Michael Segner**, veröffentlicht am **20. August 2026** im Blog von claude.com in der Kategorie *Claude Code*: ein **5-minütiger** Lesetext mit angekündigten rund **31.500 Zeichen** Fließtext, auch als PDF verfügbar. Angegebenes Material: Interviews mit **mehr als einem Dutzend** Startups, fünfzehn davon namentlich genannt — **Artemis Security**, **Cainex**, **Clay**, **ClickHouse**, **Cognition**, **Commure**, **Crosby**, **Emergent**, **Harvey**, **Heidi**, **Higgsfield**, **Omni**, **Parahelp**, **Translucent**, **Zingage**. (A) Fünf Betriebsregeln: *everyone ships*, *automate the tedium*, *trust, but verify*, *build for rebuilding*, *prototype, dogfood, productionize*, jede abgeschlossen mit Produkt-Tipps und zusammengefasst in einer abschließenden Checkliste. (B) Ein Textkörper aus zugeschriebenen Zitaten, wobei jede Regel durch namentlich genannte Führungskräfte illustriert wird statt durch eine aggregierte Kennzahl. Die vier hervorgehobenen Zahlen stammen von den interviewten Unternehmen: **+30 %** mehr ausgelieferte Features (ClickHouse), **2- bis 3-fache** Engineering-Produktivität (Omni), **100 %** der Bug-Triage automatisiert (Clay), **mehr als 6.000 PRs pro Woche** (Artemis Security). Zwei Passagen weichen vom Erfahrungsbericht-Register ab: **Cainex**s Selbstkorrekturschleife bei der medizinischen Kodierung, Schritt für Schritt beschrieben, sowie der interne Einsatz von **Claude Tag** bei **Anthropic** als Erstreagierer für den CI/CD-Bereitschaftsdienst. Die eingangs gestellte Frage — *„Wie würde es aussehen, wenn eine Organisation ihren Produktentwicklungszyklus von Grund auf mit Claude Code aufbauen würde?"* — knüpft an [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]] an, das am folgenden Tag vom selben Verlag veröffentlicht wurde, und führt [[cherny-wu-reflecting-year-claude-code-2026-07-17]] weiter.
#Claude Code#Startups#everyone ships
Michael Segner · auteur du guide sur le blog claude.com (fonction non affichée par la page) ; entretiens avec les dirigeants de quinze entreprises nommées.
Unternehmensblogbeitrag von **Block** (`block.xyz/inside`), nicht namentlich gezeichnet — als Autor wird **„Block“** angegeben —, veröffentlicht am **18. August 2026**, ~930 Wörter, der **die Open-Source-Stellung von Berd** ankündigt, Blocks interne Desktop-Anwendung für die Arbeit mit Agenten, und die Designthese darlegt, die sie geleitet hat: Agenten Charakter zu verleihen *"not only through roles, instructions, skills, and tools, but through distinctive visual identities"* — daher die selbst entwickelten animierten Figuren, die *"Gloopies"*. Der Beitrag geht von einer Beobachtung der Fragmentierung aus (*"The technology was powerful, but the experience around it was fragmented"*) und einem präzise benannten Interface-Problem: *"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"*. Zwei strukturierende Beiträge. **(A) Eine dreistufige Gliederung**: **goose** bleibt das Framework und die *Runtime*, die die Agent-Loop trägt; **Berd** ist der Desktop-Client (Projekte, Kontext, Sitzungen, Agenten, Konfiguration); beide kommunizieren über das **Agent Client Protocol**. **Buzz** wird als Fortsetzung bezeichnet, für den Moment, in dem aus Solo-Arbeit Zusammenarbeit wird (*"Start alone, then go multiplayer"*). **(B) Sechs an Buzz weitergereichte Anforderungen**, als Fazit formuliert: *"private space, durable context, recognizable agent identities, reusable skills, visible configuration, and clearer visibility into an agent's configured context, tools, and capabilities"* — ein Raster, das sich direkt zur Bewertung eines Agent-Clients wiederverwenden lässt. Der Text selbst unterscheidet Identität von Fähigkeit: *"The avatars make the agent recognizable. Its role, skills, and tools make it useful."* Es werden keine Nutzungszahlen genannt, und für die Open-Source-Stellung wird keine Lizenz angegeben.
#Berd#Block#Open Source
**Aucun auteur nommé** : le billet est signé **« Block »** — le champ *Author* de la page porte le nom de l'entreprise. Publié le **18 août 2026** sur `block.xyz/inside` · le blog **corporate** · et non sur `engineering.block.xyz`.
Blogbeitrag von **Sonatype** von **Aaron Linskens** (*technical writer*), veröffentlicht am **18. August 2026**, ~1.300 Wörter: Er berichtet über eine Studie von **Sonatype Research Labs** über **49 Monate** (Juni 2022 – Juni 2026) mit einer **festen Kohorte** von Unternehmensanwendungen — eine methodische Entscheidung, die dazu dient, die Entwicklung der Anwendungsflotte statt die des Kundenportfolios zu isolieren. Das Ergebnis wird als Widerspruch dargestellt: Die Behebung wird schneller, doch das Risiko häuft sich weiter an. (A) **Der Bestand wächst** — *Critical*- und *High*-Schwachstellen pro Anwendung **×4,31** (von **14,14** im Juni 2022 auf **54,3** im Jahr 2026, immer noch **×3,91** ohne Legacy-Anwendungen, die neu unter Verwaltung gebracht wurden), neu betroffene Komponentenversionen mit dem **46-Fachen** der Rate vor der KI-Ära, monatliche Anwendungserstellung **×4,84**. (B) **Die Behebung verbessert sich** — mehr als die Hälfte der behobenen Verstöße wird in weniger als einem Tag behoben, das mediane Alter ungelöster *Critical/High*-Schwachstellen sinkt von **228** auf **126 Tage**, dann im Mai 2026 auf **103**; unter Kohorten, die zwölf Monate Zeit hatten, sind **52,6 %** behoben, **44,3 %** offen, **3,1 %** unter Waiver. (C) **Der vorgeschlagene Hebel ist die Komponentenauswahl**: Zum Zeitpunkt der Wahl einer anfälligen Abhängigkeit existierte bereits in **62,2 %** der Fälle bei **Maven**, **46,9 %** bei **npm**, **34,3 %** bei **PyPI** eine deutlich weniger riskante Version — eine Lücke, die der Text eher einer Informationslücke als einem Fehler der Entwickler zuschreibt. Der Beitrag selbst stellt fest, dass KI nicht die alleinige Ursache der Beschleunigung ist, und schließt mit **Sonatype Guide**, das diese Intelligenz an den Punkt der Auswahl bringt. Auf der Supply-Chain-Seite erweitert er, was [[fiches/2026-08/staples-gitlab-when-code-is-abundant-2026-08-24]] wirtschaftlich einordnet und [[fiches/2026-07/clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] im Sinne des sicheren Zyklus.
#Software-Lieferkette#Software-Lieferkette#Sonatype Research Labs
Aaron Linskens · *technical writer* chez Sonatype · sur le blog de l'éditeur ; les chiffres sont produits par Sonatype Research Labs · non par l'auteur.
Produktankündigung von **Block Engineering**, gezeichnet von **Thomas Petersen** (*Principal Designer & Builder*), veröffentlicht am **18. August 2026**, ~1.800 Wörter in dreizehn kurzen Abschnitten, die **Buzz Projects** vorstellt — eine **Software-Forge, gehostet auf dem eigenen Relay**: Git-Repositories, Branches, Pull Requests, Issues, Review und Merge, Multi-Repo-Projekte, ein Activity Feed, alles verknüpft mit Conversation-Channels. Vorspann und These des Beitrags: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Drei Beiträge. **(A) Eine Vertrauensdoktrin, die auf *ex post*-Nachweis statt auf *ex ante*-Autorisierung beruht**: auf der einen Seite *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, auf der anderen *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; der Abschnitt schließt mit einer angekündigten Richtung — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Git-Interoperabilität ohne proprietäres Tooling**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, wobei die clé Nostr als einzige Identität dient — *« The same npub that signs your messages signs your pushes. »* **(C) Eine Unterscheidung zwischen Ausführungsfläche und Netzwerkpräsenz**: *« 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. »* Der Beitrag liefert keine Zahlen und enthält keine ausgehenden Links; er qualifiziert sich sechsmal selbst als vorläufig (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), und Projects befindet sich unter dem Tab **Experiments** von Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
X-Post von **Andrew Ng** vom **14. August 2026** (16:29 UTC), Wiederaufnahme des "Dear friends"-Briefs aus ***The Batch* #366** (DeepLearning.AI, gleiches Datum), ca. 900 Wörter. Ng stellt **The AI Engineering Skills Map** vor und veröffentlicht **vier Skills**, die als die wichtigsten gelten. **(1) Aufbau und Bereitstellung von KI-Anwendungen** — die Besonderheit wird benannt: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, daher die Betonung von *evals* und Fehleranalyse-Loops. **(2) Grundlagen der Softwareentwicklung**, denn *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — der unerfahrene Entwickler scheitert *« because they don't know what context to give their coding agent »*, daher das Ziel, *« steering coding agents using the precise language of software engineering »*. **(3) Einsatz von Coding-Agenten**, in operativer Formulierung: *« help the agent autonomously close loops by providing verifiers or evals »*, sowie *« knowing how much to intervene and how much to leave them alone »*. **(4) *Den Build gestalten***: *« Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec »*, ergänzt durch *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Ein **Hinweis zur Terminologie** trägt den größten Teil der Rahmung: Ng spricht von **Skills** im AI Engineering und **nicht von der Rolle** "AI Engineer", mit einer expliziten Analogie — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* Das Ganze stützt sich auf *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, wovon **keine numerischen Ergebnisse veröffentlicht werden**: Ng beschreibt sein Vorgehen als *« informally… akin to running clustering »* und kündigt eine detaillierte Map in künftigen Beiträgen an. Sein Eigeninteresse benennt er im vorletzten Satz: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
#AI Engineering Skills Map#Skills-Map#Andrew Ng
**Andrew Ng** — fondateur de **DeepLearning.AI** · general partner d'**AI Fund** · cofondateur de **Coursera** et de **Google Brain** · ancien chief scientist de Baidu. Texte signé · à la première personne · écrit *« with my team »* sans qu'aucun collaborateur soit nommé. Publié le **14 août 2026** sur X et dans ***The Batch* n°366** — même texte aux deux endroits ; préférer *The Batch* pour toute citation durable. Quatrième fiche Ng du corpus · après les lettres n°350 (24 avril) · n°352 (8 mai) et n°359 (26 juin).
Ankündigungsbeitrag, veröffentlicht im **offiziellen Z.ai-Blog** (ehemals Zhipu AI, chinesisches Labor) am **14. August 2026**, **ohne namentliche Autorenangabe**, ~2.000 Wörter plus Fußnoten. Er kündigt **GLM-5.3** an, den Nachfolger von GLM-5.2, und eröffnet mit einer methodischen These: *« Scaling post-training is all we did for GLM-5.3. »* Dasselbe Basismodell wie GLM-5.2 — *« every gain comes from post-training »*. Drei Ankündigungen. **(A) Ein Coding-Modell mit offenen Gewichten**: +50 % beansprucht auf **Z.ai Code Bench**, einem unveröffentlichten internen Benchmark. **(B) Eine als „emergent" dargestellte Cyber-Fähigkeit**, die der Fließtext auf eine Trainingsentscheidung zurückführt — *« As part of post-training, we introduced vulnerability discovery data and environments into the training mix. We expected this to make the model better at finding and reasoning about vulnerabilities »* — überraschend waren die Geschwindigkeit und der Wandel in der Natur: Das Modell geht von der Identifizierung isolierter Schwachstellen zu *« coherent plans for complete exploitation chains »* über. Die Gewinne wachsen mit der Position in der Exploitation-Kette: CyberGym 77,2 → **84,5 %**, ExploitBench 24,4 → **54,4 %** (×2,2), ExploitGym 29 → **105** Aufgaben in 2 h (×3,6), wobei der Abstand zur geschlossenen Frontier weiterhin groß bleibt (181 und 247 Aufgaben). Z.ai formuliert es so: *« Capability is growing fastest exactly where we are furthest behind. »* Der Beitrag veröffentlicht zudem ein **Z.ai Security Disclosure Ledger**: **2.436 identifizierte Schwachstellen in 269 Open-Source-Projekten** — Kernel, Betriebssysteme, Browser-Engines, Infrastruktur, Webanwendungen, Netzwerkprotokolle — die älteste eingeführt **1981**, durchschnittliche Lebensdauer bis zur Entdeckung **26,6 Jahre**, davon **53 offengelegt** und **2.383 unter Embargo**. **(C) Eine Gewichtsfreigabe** *« within two weeks of launch, once safety evaluation and hardening are complete »*. Der am ehesten übertragbare methodische Beitrag: **Synthese von Umgebungen und Verifiern**, wobei Letztere ohne Zugriff auf die Referenzlösung erzeugt und erst nach einem Triptychon negativer Kontrollen zugelassen werden — **oracle**, **no-op**, **unsolved-state**. Alle agentischen Evaluierungen werden **in Claude Code 2.1.207** durchgeführt.
#GLM-5.3#GLM-5.2#Z.ai
**Z.ai** (anciennement **Zhipu AI**) · laboratoire d'IA chinois · éditeur de la famille **GLM**. Billet **institutionnel et non signé** : aucun auteur nommé · aucun chercheur mis en avant · aucun lien vers un rapport technique ou une carte de modèle. Publié le **14 août 2026**. La page est une SPA React — le HTML servi est un `<div id="root">` vide · et le texte comme les scores ont dû être extraits du bundle `glm-5.3-BCnx8T5_.js` · où ils figurent en valeurs source.
Offizielle Produktseite von **DeepSeek**, veröffentlicht am **13. August 2026**, **nicht namentlich gezeichnet**, ca. 450 Wörter, die die *Developer-Preview*-Veröffentlichung von **DeepSeek Harness** (`dsh`) ankündigt — ein Coding-Agent-Harness, **Open Source unter der MIT-Lizenz**, dessen Repository am selben Tag eröffnet wurde. Eine Drei-Wort-These, wiederholt im Titel und in der Repository-Beschreibung: *« Everything is a plugin »*, gepaart mit einem zweiten Versprechen, *« Every run is traceable »*. Die Seite formuliert die Gleichung *« AGENT = MODEL + HARNESS »* und listet die steckbaren Fähigkeiten auf — *« models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI »*. Vier Modi werden ausgeliefert: **Standard** (vollständiger Coding-Agent), **Code** (Tools, die über das *Code Mode SDK* freigelegt werden und es dem Modell erlauben, mehrstufige Operationen innerhalb eines TypeScript-Programms zu komponieren), **Minimal** (*« two-tool coding agent with persistent bash and str_replace_editor »*, ausdrücklich *« for benchmarking models in a minimal environment »*), und **Creator** (Laufzeitinspektion, In-Memory-Plugin-Tests). Die technische Substanz liegt im Repository, nicht auf der Seite: `docs/architecture.md` formuliert eine Logging-Invariante — *« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it »* — und stellt fest, dass *« there is no privileged core to patch »*. Der technische Kern stammt nicht von DeepSeek selbst: DSH baut auf **Cordis** auf (dem `cordiverse`-Projekt, einem Dritten), **vendort** in `vendor/` mit Manifest und Sync-Verfahren, und die Seite platziert das *« Cordis paper »* auf derselben Navigationsebene wie „GitHub“ und „Developer docs“. Zwei LLM-Adapter werden ausgeliefert — `dsh-llm-deepseek` und `dsh-llm-pi-ai`, ein generischer Multi-Provider-Adapter. Das Repository warnt in Großbuchstaben: *« THERE WILL BE COMPATIBILITY-BREAKING CHANGES »*, und `CLAUDE.md` legt fest, dass `SESSION_FORMAT_VERSION` bei `0` bleibt, *« with no compatibility promise »*, wobei Backends alte Formate auf der Festplatte ablehnen. Zeitachse: DSH erscheint an dem Tag, an dem **DeepSeek-V4-Pro GA erreicht**, drei Tage bevor am **16. August 2026 um 16:00 UTC** ein neuer API-Preisplan in Kraft tritt, mit Spitzen-/Nebenzeittarifen und einem Nebenzeit-Rabatt von **−50 %**.
#DeepSeek Harness#dsh#Agent-Harness
**DeepSeek** (DeepSeek AI, laboratoire chinois) · en tant qu'institution. Page produit **non signée** : aucun auteur · aucun ingénieur mis en avant · aucun billet de blog ni papier technique associé. Le « nous » n'apparaît qu'une fois · en dernière phrase — *« We look forward to exploring the limits of intelligence with developers worldwide »*. Publiée le **13 août 2026**. La page est rendue en JavaScript : `curl` sur l'URL renvoie **HTTP 202 avec un corps vide** · le texte n'existant qu'après exécution du bundle. Deux documents de politique sont liés en pied de page — *Safe Use Policy* et *Data Processing Statement*.
Interner Rechercheureport vom **12. August 2026**, der zu Präsentationszwecken alles öffentlich Dokumentierte über **Buzz** zusammenfasst — den Workspace für Menschen und Agenten von **Block**, der am **21. Juli 2026** unter der Lizenz **Apache 2.0** eingeführt wurde. Er aggregiert die beiden bereits veröffentlichten Engineering-Beiträge neben der Unternehmensankündigung, das GitHub-Repository, die Presseberichterstattung, X sowie **drei unabhängige Praxisberichte**, die die einzigen nicht selbst berichteten Daten des Dossiers darstellen. **(A) Eine durch Zitat dokumentierte Begriffslücke**: Der Launch-Tweet von **Jack Dorsey** kündigt *„model-agnostic, decentralized, self-sovereign, and open source“* an; Blocks `ARCHITECTURE.md` stellt fest: *„The relay is the single source of truth. All reads and writes flow through it. There is no peer-to-peer event exchange, no gossip, no replication.“* Der Relay ist somit pro Community einzig und maßgeblich: Buzz' „Dezentralisierung“ ist eine **organisatorische Souveränität** — Self-Hosting und portable Identität — keine Netzwerkredundanz. Formulierung von **TFTC**: *„Two of those three hold cleanly. The third needs a qualifier.“* **(B) Eine Asymmetrie zwischen nachgewiesener Rigorosität und Ausnutzungsrisiko.** Auf der einen Seite ein für ein v0.4.x/0.5.x seltenes Maß an Formalismus: Spezifikation der Mandanten-Isolation **mechanisiert in TLA+**, in **Tamarin** verifizierte Autorisierungseigenschaften, ein modellgeprüftes Git-Speicherprotokoll, ein hash-verkettetes Append-only-Audit-Log, 127 *event kinds*, NIP-01/42/98/34. Auf der anderen Seite ist Kanalmitgliedschaft die Berechtigungseinheit — *„channel membership is not fine-grained tool authorization“* (João Queirós) —, Agenten laufen in `--dangerously-skip-permissions` außerhalb jeder Sandbox auf der Maschine eines Menschen, und die Beobachtbarkeit fehlt: *„Buzz tells me an agent got a message. It doesn't tell me what happens next“* (DevTools Daily, das stille OOM-Kills berichtet). Block räumt es ein: *„the agent can do anything, and security rests entirely on restricting who can tell it what to do“*. **(C) Der technische Stack**, der in den veröffentlichten Beiträgen fehlt: **Rust**-Relay (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** via Blossom, Desktop-Client **Tauri + React**. Die Agentenintegration erfolgt über **`buzz-acp`**, ein **ACP**-Harness, das goose, Codex und Claude Code einbindet und **ACP ↔ MCP** übersetzt, sowie **`buzz-agent`**, einen hauseigenen Agenten. Der Report korrigiert sich an einem Punkt selbst: Die *„+33% more work“* in Blocks TL;DR sind das **Verhältnis abgeschlossener Aufgaben (20 gegenüber 15 von 44)**, kein Punktzahlgewinn — die Punktzahl selbst steigt von 59,1 % auf 71,5 %, also **+12,4 Punkte**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
Erfahrungsbericht, veröffentlicht auf **LinkedIn Pulse** am **12. August 2026** von **Guillaume Dumortier** in seinem Newsletter *Growth Marketing Fit*, mit dem Untertitel *„Four layers, a lot of rebuilding, and the failure modes nobody warns you about"*, ~2.500 Wörter. Thema: ein internes KI-System, gebaut **in Claude** für ein Marketingteam von rund sechzig Personen – etwa dreißig Content- und Sales-**Skills**, ein Dutzend **Source-of-Truth-Module**, **sieben Agenten, von denen sechs ausschließlich Arbeit prüfen statt sie zu produzieren**, ein **Plugin** für alle, die im Terminal arbeiten, eine **Browseranwendung**, die dasselbe Wissen für alle anderen bereitstellt, und eine Orchestrierung, die drei oder vier Assets zu einem *campaign bundle* verkettet. Die These wird früh formuliert: Die Qualität eines KI-Outputs entscheidet sich nicht im Moment der Generierung, sondern durch das, was das System vorher weiß, und durch das, was anschließend mit dem Entwurf geschieht – *„The generation step in the middle is the easy part. It's also the only part most teams have built."* Daraus ergeben sich vier Schichten: **Truth** (fast niemand baut sie), **Production** (jeder), **Verification** (fast niemand), **Internal distribution** (*„where good systems die of neglect"*). Zwei Fehlermechanismen tragen den Artikel. **(A) Das nackte Closed-World-„pass" des Prüfers**: Ein Fact-Checker, der auf Produktdokumentation gestützt ist, erhält einen Entwurf mit einer Behauptung über ein anderes Produkt, das von seinen Quellen nicht abgedeckt wurde – er liefert ein *„pass"*, nicht weil die Behauptung wahr war, sondern weil ihr nichts widersprach. *„It didn't just miss the error, it certified it."* Lösung: ein nacktes Urteil verbieten und von jedem Bericht verlangen, die **eigene Abdeckung** offenzulegen – wie viele Behauptungen geprüft wurden, wie viele mit Quellen abgeglichen werden konnten, welche außerhalb seiner Zuständigkeit lagen, welche keiner Quelle zugeordnet werden konnten. *„\"I can't verify this\" became a first-class result."* **(B) Der Cross-Asset-Widerspruch**: Zwei Assets können jedes für sich korrekt sein, jedes auf eine reale Quelle rückführbar sein, und sich dennoch widersprechen – die Pressemitteilung nennt ein Datum, der Blogbeitrag ein anderes, beide bestehen die Prüfung, das Bundle kann nicht ausgeliefert werden. *„Per-asset verification can't catch that, by construction."* Schlusssatz des Artikels: *„The generation is free. The trust is the product."*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
Ankündigung von **Google** am **6. August 2026**: Google tritt als **Core Maintainer** der Spezifikation **Agent Plugins 1.0.0** bei, einem offenen, *anbieterneutralen* Packaging-Format für die gemeinsame Verteilung von **Agent Skills** und **MCP servern**. Die Spezifikation wurde von einem **TSC** veröffentlicht, dessen Core Maintainer von **Amazon, Cursor, Microsoft, OpenAI und Vercel** stammen; Google tritt ihnen bei, vertreten durch **Kevin Hou** (Senior Staff Engineer, Google DeepMind). Die beiden gepackten Bausteine — Agent Skills und MCP — stammen von **Anthropic**, das auf dieser Liste der Maintainer nicht erscheint. **Die Diagnose** passt in einen Satz: *„The core problem isn't the components. It's the manifest.“* Ein Skill ist portabel, ein MCP server ist portabel; die Kiste, in der sie stecken, ist es nicht, und jeder Client musste sie sich selbst ausdenken — daher die Forks, die Kopien identischer Komponenten und ihr Auseinanderdriften. **Das Format** passt in eine Einschränkung: *„A plugin is a directory. That's the whole idea, and the restraint is the point.“* Eine `plugin.json` mit zwei nützlichen Zeilen (`$schema` und `name`), Skills in `skills/` im Agent-Skills-Format, servers deklariert in `mcp.json` mit einem **expliziten `type` bei jedem Eintrag** (stdio, Streamable HTTP oder das veraltete HTTP+SSE) — kein erratener Transport aus der Form des Konfigurationsobjekts mehr. Die Stärke des Designs liegt in dem, was das Manifest **nicht** kann: Komponenten weder verlagern noch inline deklarieren, sodass es keinen zu konfigurierenden Discovery-Pfad und keine zu erlernende Rangfolge gibt. Operatives Korollar: Komponenten **scheitern unabhängig voneinander** — ein `mcp.json`-server, der nicht startet, reißt nicht die Skills des Plugins mit sich; der Client überspringt den Eintrag, macht weiter und meldet den Fehler. Das akzeptierte Schlupfloch ist das **Reverse-Domain**-Verzeichnis (`com.example.client/`), ein Erweiterungsraum, der vollständig einem Client gehört (hooks, agents, commands) und von anderen Clients ignoriert wird: *„the portable core stays small because the non-portable parts have somewhere legitimate to go.“* Ein Abschnitt widmet sich Fällen, in denen das Format nicht gerechtfertigt ist — *„Not every skill should be a Plugin“*: ein einzelner MCP server für einen einzelnen Client, `mcp.json` genügt; ein einzelner Skill braucht kein Plugin. Was v1 unter *future considerations* ausdrücklich ausschließt: **kein Installationsmechanismus, kein Distributionsprotokoll, kein Berechtigungsmodell, keine Sandboxing-Anforderung, keine Vertrauens- oder Herkunftsprüfung, keine UX**. All das fügt sich in einen unabhängig adoptierbaren vierschichtigen Stack — **finden** (Agentic Resource Discovery), **beschreiben** (AI Catalog, das den Typ `application/agent-plugins+json` registrieren würde), **packen** (Agent Plugins), **ausführen** (MCP + Agent Skills). Zwei Google-Produkte liefern bereits aus: **Agents CLI** und **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
Die Website **graphify.net**, aufgerufen am **6. August 2026**, wird von **Safi Shamsi** betrieben — dem Schöpfer des Open-Source-graphify-Skills (vgl. [[skill-shamsi-graphify-2026-08-06]]). Die Domain trägt zwei unterschiedliche Objekte. **Das erste ist eine Produktpräsentation**: Vorstellung von graphify, Nutzungsanleitungen, CLI-Referenz und vor allem eine Galerie von **100 bereits graphifizierten trendenden GitHub-Repositories** — *« 100 repos, 854,079 nodes, 1,932,930 edges »* — filterbar nach Sprache und Graphgröße, jeweils mit eigener Vorschau- und Detailseite. **Das zweite, und für die Zwecke der Technologiebeobachtung interessantere, ist ein redaktionelles Verzeichnis**: *« 30 AI coding client guides »*, ein Verzeichnis von MCP-Servern, verglichen nach *« transport, runtime, client support, setup effort, and access risks »*, strukturierte Vergleiche zwischen Tools (Cursor gegen Codex) sowie ein Strom von Artikeln mit einer offenkundig auf Long-Tail ausgerichteten Zielrichtung (*« GLM-5.2 Knowledge Graph for Developers »*, *« Trae Context Engineering for Agents »*, *« Symphony Knowledge Graph for Agent Memory »*, *« What Is Cowart? A Codex Plugin for Image Editing »*). Die Website beansprucht eine Methode — *« source-reviewed »*, *« aligned decision fields, official evidence, and explicit unknowns »* — und ist in sechs Sprachen verfügbar. **Der Punkt, dessentwegen diese Fiche existiert**: Die Website steht **faktisch nicht im Einklang mit dem Produkt, das sie präsentiert**. Sie kündigt **« 3.7k+ GitHub Stars »** an, während die GitHub-API am selben Tag **103.187** zählt, eine **MIT-Lizenz**, dreimal wiederholt, während die `LICENSE`-Datei des Repositories **Apache 2.0** lautet, und hebt die Behauptung **« 71.5× token reduction »** hervor, die zur README-Generation v1 gehört und in der aktuellen Version verschwunden ist. **Eine offizielle Website, die 3,7 % der tatsächlichen Sternezahl anzeigt und die Lizenz falsch angibt**, ist an sich schon ein Signal: Die Kommunikationsebene hat mit dem Repository nicht Schritt gehalten.
Ein **Block-Engineering**-Benchmark-Beitrag vom **6. August 2026**, verfasst von **Atish Patel**, über **Buzz** – den am 21. Juli gestarteten Workspace für Mensch und Agent – der eine Kostenfrage stellt: Welches Agententeam ist **das günstigste, das zuverlässig erfolgreich ist**? Drei Befunde. **(A) Ein vollständig veröffentlichtes negatives Ergebnis**: Auf **Terminal-Bench 2.1** wurden **zwölf Teamzusammensetzungen** (Paare, Triaden, günstige Schwärme unter einem *Frontier*-Modell) gegen den jeweiligen Solo-Agenten antreten lassen, um den sie herum gebaut waren, und **keine schlug ihn bei gleichen Kosten**. Die Erklärung ist struktureller Natur – einer Aufgabe, die in Minuten erledigt ist, *„fehlt genug Struktur, um sie aufzuteilen"*, und *„mehr Agenten kaufen meist nur die Kosten, es zweimal zu erklären"*. **(B) Der Zeithorizont kehrt das Ergebnis um**: Auf **Long-Horizon Terminal-Bench** (44 Aufgaben, eine Aufgabe im Wert von Stunden Arbeit, gleicher Lead **GPT-5.6 Sol** mit *high*-Aufwand) schließt Solo 15 Aufgaben ab bei 59,1 %, +2 QuickBees 19 bei 64,1 %, +1 QuickBee +1 WorkerBee 19 bei 69,5 %, **+2 WorkerBees 20 bei 71,5 %** – ein Zugewinn von **+12,4 Punkten**, wovon 11,4 aus abgeschlossenen Aufgaben stammen. *„Gleiche Plätze, umgekehrtes Ergebnis, weil die Arbeit eine andere Form hat."* Diese Durchläufe liefen mit dem **3-fachen Timeout**, Solo eingeschlossen. **(C) Jenseits einer Schwelle kauft der Preis keine Qualität mehr**: Solo auf Terminal-Bench 2.1, **Opus 5 mit *xhigh*-Aufwand ist der teuerste Durchlauf (140,63 $) bei 75,0 %**, hinter sechs Durchläufen zwischen 20,08 $ und 109,82 $ und 79,5 % bis 88,4 % – als Ursache wird Over-Reasoning genannt, das 17 von 88 Aufgaben in den Timeout trieb. Unter den sechs besten Durchläufen liegt **eine 5,5-fache Preisspanne bei einer Punktzahldifferenz von 8,9 Punkten**: *„die Wahl zwischen ihnen ist überhaupt keine Qualitätsentscheidung. Es ist eine Budgetentscheidung."* Der Beitrag schlägt eine Taxonomie vor, die er selbst als *ad hoc* bezeichnet – **QuickBee**, **WorkerBee**, **SmartBee**, dazu der Mensch als *„Ehrenbiene"* – sowie zwei Teamformen: die permanente **Hive**, die sich die Präferenzen der Nutzenden merkt, und der einmalige **Swarm**, der sich das Projekt merkt. Rahmenbedingungen: alles läuft auf **Harbor**, gegen echte Buzz-Agenten auf einem **Live**-Relay, **ein Versuch pro Aufgabe, kein Retry**, Preise festgeschrieben zum **30.07.2026**.
#Buzz#Block#Agententeams
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Skill-Eintrag: **graphify** von **Safi Shamsi** (Graphify Labs, Y Combinator S26) verwandelt ein gesamtes Projekt — Code, Dokumentation, PDFs, Bilder, Videos — in einen **abfragbaren Knowledge Graph**, aufgerufen über `/graphify` aus Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot und rund fünfzehn weiteren Clients. Stand **6. August 2026**: **103.187 Stars**, **10.024 Forks**, Repository erstellt am **3. April 2026**. Apache-2.0, Python 3.10+, Standard-Branch **v8**. **Drei im README genannte Designentscheidungen**. *„Code maps for free, fully local"*: Der Code wird deterministisch und ohne LLM in einen **tree-sitter-AST** geparst, ohne dass etwas die Maschine verlässt. *„Every edge is explained"*: Jede Kante wird mit **`EXTRACTED`** (explizit in der Quelle) oder **`INFERRED`** (von graphify aufgelöst) gekennzeichnet, mit einem dritten Wert `AMBIGUOUS`, der im Report erscheint. *„Not a vector index"*: *„no embeddings, no vector store: a real graph you traverse"*. **Drei Ausgaben**: `graph.html` (interaktiver Graph), `GRAPH_REPORT.md` (God Nodes, überraschende Verbindungen, vorgeschlagene Fragen) und `graph.json` (persistenter Graph, Wochen später abfragbar, ohne die Dateien erneut zu lesen). **Drei Abfragemodi** als Ersatz für grep: `query` (Subgraph zu einer Frage in natürlicher Sprache), `path A B` (kürzester Pfad zwischen zwei Entitäten) und `explain` (Nachbarschaft eines Konzepts). **Abdeckung**: 36 tree-sitter-Grammatiken (~40 Sprachen), außerdem Terraform, Apex, MCP-Konfigurationen, Paketmanifeste, Office, Google Workspace, PDFs, Bilder sowie Video/Audio, lokal transkribiert von faster-whisper. Communities werden über **Leiden** erkannt, ohne LLM beschriftet. **Benchmarks**: auf LOCOMO ein recall@10 von **0,497** gegenüber 0,149 für supermemory und 0,048 für mem0, jedoch geringere QA-Genauigkeit (45,3 % gegenüber 49,7 %); auf LongMemEval-S **76 %**, auf Augenhöhe mit einem dense RAG; sowie *„Graph build — LLM credits: 0"*. **Festzuhaltende Punkte**: Der `main`-Branch trägt ein README aus der v1-Ära, das ein anderes Produkt beschreibt (Skill nur für Claude Code, die Behauptung „71.5× fewer tokens"); das PyPI-Paket heißt **`graphifyy`** mit zwei *y*, während der Name `graphify` zurückerobert wird; und ein **Query-Log** wird standardmäßig unter `~/.cache/graphify-queries.log` geschrieben, das sich über eine Umgebungsvariable deaktivieren lässt.
#Skill#Wissensgraph#Wissensgraph
**Safi Shamsi** — créateur et mainteneur de graphify · et de **Graphify Labs** · société passée par **Y Combinator (promotion S26)** selon le badge du dépôt. Il maintient aussi le site d'annuaire `graphify.net` (cf. [[graphify-net-annuaire-ia-coding-2026-08-06]]) et publie un livre · *The Memory Layer* · sur les idées et l'architecture derrière le projet.
Ankündigung von **Meta AI Research**, veröffentlicht am **5. August 2026** (angegebene Lesezeit: 4 Minuten, kein individueller Autorenvermerk): **Muse Code** in der Beta-Phase, *„ein Terminal-Coding-Agent“*, sowie das Modell, das ihn antreibt, **Muse Spark 1.2**. Meta selbst ordnet die Markteinführung ein: *„Dies markiert unseren nächsten Schritt in Richtung der Frontier, mit größeren und deutlich leistungsfähigeren Modellen, die bereits in Vorbereitung sind.“* **Drei architektonische Elemente auf der Harness-Seite.** **Asynchrone Hintergrund-Agenten**, die *„während der gesamten Sitzung aktiv bleiben, statt für einzelne Aufgaben neu erzeugt zu werden“*, wodurch redundante Informationsbeschaffung vermieden und der Steuerungsbedarf verringert wird. Ein **lokales Ereignisprotokoll**, in dem *„jeder Modellaufruf, jede Tool-Ausführung, jede Genehmigung und jede Bearbeitung angehängt wird“*, wodurch die Laufzeitumgebung zu einem System wird, das *„replay-exakt und neustartsicher“* ist und nach einem Absturz genau dort fortsetzen kann, wo es aufgehört hat. Und **drei standardmäßig mitgelieferte Skills**: `/plan` (wandelt eine Aufgabe in einen zur Genehmigung vorgelegten Plan um), **`/grill`** (stellt den Plan auf die Probe, *„bis er standhält“*), und `/goal`. **Auf der Modellseite** beansprucht Meta ein **Co-Training von Modell und Harness** (*„um die Harness-Kompatibilität zu maximieren“*, wobei Harness-Trajektorien per Rejection Sampling erfasst werden und Rezeptoptimierungen für Ziele, Kompaktierung und Sub-Agenten vorgenommen werden), ein Training mit **langem Zeithorizont** (Generierung ganzer Repositories, End-to-End-Projekte, Selbstrecherche, mit Planung, Zielkonditionierung und Kontextkompaktierung) sowie eine **Selbstverbesserungsschleife**, in der Muse Spark 1.1 die Umgebungen und Anweisungsvorlagen generiert und anschließend die Kandidatenlösungen bewertet, wodurch ein Trainingsdatensatz für die 1.2 entsteht. **Was die veröffentlichten Diagramme zeigen**, ohne dass der Text dies kommentiert: Die vier Vergleiche — Terminal-Bench 2.1, DeepSWE 1.1, ein interner Meta-Benchmark und die Fallstudie zur GPU-Kernel-Optimierung — platzieren **Muse Spark 1.2 in allen vier Fällen hinter Opus 5**, einschließlich auf Metas eigenem proprietärem Benchmark (70,6 % gegenüber 79,4 %) und in der Fallstudie, in der das Modell auf dem vierten von sechs Plätzen landet (+68,7 % gegenüber +74,0 %). **Ein Vorbehalt zum Lesen des Versionsgewinns**: Bei den beiden öffentlichen Benchmarks wird 1.1 mit `mini-swe-agent` und 1.2 mit Muse Code gemessen, sodass die Differenz von 6,7 Punkten Modell- und Harness-Fortschritt vermischt. Beim internen Benchmark, dem einzigen Vergleich, bei dem keine Harness genannt wird, sinkt die Differenz zwischen 1.1 und 1.2 auf **2,3 Punkte**.
#Meta AI Research#Muse Code#Muse Spark 1.2
**Meta AI Research** — publication institutionnelle sans auteur nommé · sur `research.meta.ai`. Le billet renvoie à un **rapport** pour la méthodologie d'évaluation · non repris ici.
Dokumentationsseite zu **Notion as Code**, veröffentlicht im **Notion Ambassadors**-Workspace und abgerufen am **3. August 2026**. Produkt im **Closed-Alpha-/Warteliste**-Status, mit einem Warnhinweis vorab: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* und *« There may be breaking changes until we're fully launched »*. **Das Prinzip ist Infrastructure as Code, angewandt auf einen dokumentarischen Workspace**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Zwei Bausteine: ein **TypeScript SDK** zur Beschreibung des gewünschten Zustands und ein öffentlicher API-Endpunkt `/v1/infra_as_code` zu dessen Bereitstellung. **Der Mechanismus, der alles zusammenhält, ist der Ressourcenbezeichner**: Das Skript enthält **überhaupt keine Notion-ID**, sondern nur vom Autor gewählte *resource IDs*; das erste Deployment liefert eine **Zuordnungstabelle** `resourceId → RecordPointer` zurück, die bei nachfolgenden Aufrufen wieder übergeben wird, sodass dieselben Datensätze **aktualisiert statt neu erstellt** werden. Daraus folgen drei Eigenschaften, und sie sind die einzigen, die zählen: Das Skript ist **idempotent** (erneutes Deployment = Aktualisierung), es ist **vom Workspace entkoppelt** (mehrere Zuordnungstabellen erlauben das Deployment **desselben Skripts auf mehrere Workspaces**), und es ist Code — daher Variablen und Schleifen, wobei als Beispiel genannt wird, *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **Die API ist asynchron**: `POST /v1/infra_as_code` liefert eine `taskId` zurück, die über `GET /v1/async_tasks/{taskId}` abgefragt wird, bis der Status `succeeded` erreicht ist. **Zwei bemerkenswerte betriebliche Unterschiede**: Das Produkt erfordert **persönliche Zugriffstoken** anstelle der üblichen Bot-Token der öffentlichen API, und das **Rate Limit ist auf 5 Anfragen pro Minute gesenkt**, da ein einzelner Aufruf nicht mehr eine einzelne Entität, sondern einen Batch erzeugt. **Für dieses Korpus festzuhalten**: Die Seite ist explizit für den assistierten Einsatz geschrieben — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, und der empfohlene Einstiegsweg besteht darin, das SDK auf einem experimentellen Branch zu klonen und *« either you or your favorite coding agent »* die README öffnen zu lassen. **Genannte Einschränkungen**: kein Erstellen eines neuen Workspace möglich, nur teilweise Abdeckung der Primitiven, sowie eine Seite ohne Autor- oder Datumsangabe.
#Notion as Code#Infrastructure as Code#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
**Skill**-Eintrag: **hyperresearch** von **Jordan Gibbs** ist ein **Deep-Research-Harness**, das Claude Code in einen dokumentarischen Rechercheagenten verwandelt, ausgeliefert als PyPI-Paket (MIT, Python 3.11-3.13), das **20 Claude Code Skills**, eine CLI, einen MCP-Server und eine lokale Web-UI installiert. Stand **3. August 2026**: 1.568 Stars, 170 Forks, Repo erstellt am 9. April 2026, letzter Push am 1. August. **Der Kern ist eine 16-stufige, nach Tiers adaptive Pipeline** — `light` (~30-40 Min.), `full` (~1,5-2,5 Std.), `dissertation` (4-8 Std., 25.000-80.000 Wörter über 300-450 Quellen) — die einen Prompt entgegennimmt und einen adversarial geprüften Bericht mit vollständiger Provenienz zurückgibt. **Die zentrale Architekturentscheidung ist zusammen mit ihrem Fehlermodus dokumentiert**: Der Einstiegs-Skill ist ein **schlanker Router** ohne eigene Prozedur, wobei jeder Schritt in seinem eigenen Skill lebt, der **frisch im Moment seines Aufrufs** geladen wird, weil die Vorgängerversion *„ein einzelner 1200-Zeilen-Skill war, der komprimiert wurde, bevor Layer 4 seine Dreifachentwurf-Prozedur brauchte. Der Orchestrator vergaß die Prozedur, schrieb einen einzigen Entwurf und produzierte einen Bericht mit flacher Bewertung“* war. **Zwei tragende Prinzipien.** *„Patchen, niemals neu erzeugen“*: Nach der Synthese sind nur chirurgische `Edit`-Nachbesserungen möglich, wobei der Patcher und der Politur-Auditor auf Ebene der Claude-Code-Allowlist auf `[Read, Edit]` werkzeugseitig gesperrt sind, sodass sie *„physisch keinen neuen Entwurf schreiben können“*. *„Die kanonische Recherchefrage ist Gesetz“*: Der wortgetreue Prompt wird einmal in `query.md` persistiert und von jedem Schritt und jedem Subagenten erneut gelesen. **Sechzehn Subagenten** mit konfigurierbarer Rolle und Modell (Fetcher und Cite-Checker auf Sonnet, Kritiker, Synthesizer und Patcher auf Opus). **Der Vault** ist ein persistenter, in SQLite indizierter Markdown-Speicher — *„Markdown ist Wahrheit, SQLite ist Cache“* — mit einem Notiz-Lebenszyklus (`draft → review → evergreen`, `stale → deprecated → archive`), nachvollziehbarer Provenienz, einem zusammengesetzten Qualitätsscore (Quellentyp, Zitationsautorität via OpenAlex und Semantic Scholar mit Retraction-Flags, internem PageRank) und einem **Unabhängigkeitsaudit**, das syndizierte Kopien zusammenfasst — *„fünf Nachdrucke einer Pressemitteilung wiegen so viel wie eine Quelle“*. **Drei mechanische Schranken vor der Auslieferung**: Zitationsintegrität (jedes zitierte Zitat muss **wortgetreu** in einer Vault-Notiz existieren), ein bei jeder zitierten DOI aufgefrischter Retraction-Sweep und eine Zitat-zu-Satz-Verknüpfungsprüfung durch ein skeptisches LLM. **Zu markierender Vorbehalt**: Die Eingangsbehauptung — *„führt derzeit das DeepResearch-Bench-RACE-Ranking an“* — wird durch ihre eigene Fußnote widerlegt, *„zukunftsgerichtete Projektion aus einem stratifizierten Pilotversuch … Eine Drittvalidierung steht noch aus“*. Eine Projektion ist kein Ranking, dennoch platziert das Diagramm sie vor Gemini und OpenAI Deep Research.
#Skill#Deep Research#Research-Harness
**Jordan Gibbs** — auteur et mainteneur du dépôt `jordan-gibbs/hyperresearch`. Le projet est distribué sous **licence MIT** et publié sur **PyPI** (`pip install hyperresearch`). Signaux d'adoption au 3 août 2026 : **1 568 étoiles** · **170 forks** · 13 issues ouvertes · dépôt créé le **9 avril 2026** et poussé le **1er août 2026** — soit une traction rapide sur moins de quatre mois. Topics déclarés : `agents` · `agentskills` · `claude-code` · `deep-research` · `deep-research-agent`.
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.
Tech-Watch-Notiz von **Didier Girard** vom **2. August 2026**, ausgelöst durch die Frage eines Kollegen ("Was ist ACP?"), die ein Problem behandelt, das nicht terminologisch, sondern **dokumentarisch** ist. **Drei Protokolle konkurrieren um das Akronym**, ohne jede technische Überschneidung: **Agent Client Protocol** (Client ↔ Agent — Zed, August 2025, JSON-RPC 2.0 über stdio, Apache-2.0, "das, was LSP für Sprachen war"), **Agentic Commerce Protocol** (Agent ↔ Händler — OpenAI + Stripe, 29. Sept. 2025, in Konkurrenz zu Googles **UCP** vom 11. Jan. 2026, gestützt auf **AP2**), und **Agent Communication Protocol** (Agent ↔ Agent — IBM Research / BeeAI, marginal, aber suchverfälschend). **Der Kern der Notiz ist nicht die Entwirrung, sondern das beobachtete Scheitern**: Der Autor sucht "ACP" in seiner Tech-Watch-Wissensdatenbank und erhält **zwölf Treffer, alle zum Commerce-Protokoll, keinen zu dem von Zed** — *"unsere Watch-Agenten hatten das Akronym indexiert, ohne es zu disambiguieren"*. Daraus folgt eine Regel des Knowledge Engineering: ***"ein nacktes Akronym wird nie indexiert"*** — die Entität ist "Agent Client Protocol", "ACP" ist **nur ein Alias**, getragen von drei verschiedenen Entitäten. Es folgt eine strukturierende Klarstellung (**MCP verbindet einen Agenten mit seinen Tools, ACP verbindet einen Client mit einem Agenten; beide stapeln sich**), dann der Lehrbuchfall: **Buzz**, von **Block** am 21. Juli 2026 unter Apache-2.0 veröffentlicht — ein selbst hostbarer Arbeitsbereich auf Basis von **Nostr**, in dem jeder menschliche oder agentische Teilnehmer ein **Schlüsselpaar** ist und jede Nachricht, jeder Workflow-Schritt oder Git-Push ein **signiertes Ereignis** in einem Append-only-Log ist. Eine vollständig protokollbasierte Architektur (`buzz-acp` ein ACP-Harness über stdio, `buzz-agent` ein ACP-Agent, der ein LLM aufruft, `buzz-dev-mcp` ein MCP-Shell- + Editier-Server), daher Agenten-Agnostizismus: **Goose, Claude Code und Codex** docken über dasselbe Harness an, und **Hermes** (Nous Research) hat sich damit verbunden, ohne dass Block eine einzige Zeile geschrieben hätte — *"N+M statt N×M, im Produktivbetrieb"*. Die Notiz schließt mit der Frage des **Claude-Abonnements** gegenüber Drittanbieter-Agenten, mit einer fünfstufigen 2026er-Zeitleiste und einer **Gestaltungsregel**, die über diesen Fall hinaus gilt: Die Grenze ist nicht rechtlicher, sondern **architektonischer** Natur — ***"wer konsumiert, und in wessen Auftrag"*** (ein `owner-only`-Agent verbraucht Ihr Abonnement in Ihrem Auftrag; ein `anyone`-Agent in einem gemeinsamen Kanal leitet die Anfragen Ihrer Kollegen über Ihr Konto). **Am vorliegenden Korpus durchgeführte Überprüfung**: Die These bestätigt sich, und schärfer noch, als die Notiz behauptet — nicht nur ist "Agent Client Protocol" **vollständig abwesend**, sondern das nackte Akronym `ACP` **ist bereits als Entität typisiert** in zwei Fiches, und die KB-Seite `Agentic-Commerce-Protocol` **schreibt das Protokoll bereits Google zu**, obwohl es OpenAI + Stripe gehört. Die beschriebene Kollision ist kein zukünftiges Risiko: Sie hat **bereits einen Zuschreibungsfehler** im Graphen erzeugt.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Episode "Phase 5 · Review" der SFEIR-Reihe zum erweiterten SDLC, veröffentlicht **am selben Tag** wie der LinkedIn-Beitrag von Addy Osmani, den sie in eine Phasenspezifikation übersetzt. These: **Qualität hat die Adresse gewechselt** — sie wird nicht mehr im Code gelesen (Agenten produzieren mehr davon, als irgendjemand reviewen kann), sondern in **dem Ring von Constraints, der den Agenten umgibt**. Osmanis Ring (sieben Dimensionen — Korrektheit, Sicherheit, Performance, Barrierefreiheit, Wartbarkeit, **wirtschaftliche Effizienz**, **Verständlichkeit** — verbunden durch die **Back-Pressure**-Regel: „einer Schleife wird nur so viel Autonomie zugestanden, wie günstig und zuverlässig verifiziert werden kann, keinen Zentimeter mehr") wird nachgezeichnet, übersetzt und an Phase 5 des 11-Phasen-Zyklus von SFEIR angehängt. Das strukturierende Korollar: **der Engpass war nie die Generierung, es ist die Verifikation** — „Generierung ist ein weiter Trichtermund, Verifikation ein enger Hals; wer den Mund beschleunigt, verdickt den Stau am Hals." **Die interessanteste Design-Entscheidung ist eine Wahl der Zyklusarchitektur**: Review liegt bewusst **außerhalb der drei menschlichen Gates** (Define, Plan, Ship), denn würde man Review zum Gate machen, würde menschliche Aufmerksamkeit — eine endliche Ressource — zum Kontrollpunkt einer Generierungskapazität, die selbst skaliert: „man hätte eine Pipeline gebaut, deren maximaler Durchsatz der Anzahl an Diffs entspricht, die ein Senior bis Feierabend lesen kann." Daher die Aufteilung: **Review instrumentiert, Ship entscheidet** — Review liefert einen *widerlegbaren Beweiskörper*, Ship entscheidet anhand der Evidenz, nicht anhand des vollständigen Diffs. Eine Position, die sich gegen Monperrus stellt (von dem SFEIR die Diagnose übernimmt — menschliche Inspektion jedes Diffs hält der agentischen Geschwindigkeit nicht stand —, aber die Schlussfolgerung ablehnt: Abnahme kann nicht delegiert werden). Die benannte Falle ist die **zirkuläre Validierung** (der Agent, der den Code schreibt, schreibt auch die Tests, die ihn validieren: „man hat einen Spiegel gebaut, keinen Ring"), mit fünf Gegenmaßnahmen von Anthropic (unabhängige Gates in getrennten Context-Windows, deterministisch + agentisch ersetzen sich nie gegenseitig, Shadow Mode, risikobasierte Stufung, Logging ans SIEM) und der Warnung von Compare the Market (**AST-Graph ~70 % vs. Vektor-RAG ~58 %**, wobei RAG *schlechter abschneidet als gar kein Kontext*). Die eigene Erweiterung der Firma ist **das Ratschenprinzip**: „jedes Entkommen wird zum Constraint" — ein Defekt, der den Ring durchbrochen hat, wird *innerhalb des Rings* geschlossen (Test, Lint-Regel, Review-Rubrik, Harness-Guardrail) bei Compound-1, „das einzige Asset in der Kette, das an Wert gewinnt, während die Modelle an Wert verlieren" (eine ungeprüfte interne Messung: **−30 % Fix-Iterationen nach zehn Zyklen**). Sie schließt mit einer Neuformulierung der Frage: „Ist dieser Code gut?" ist unbeantwortbar geworden; was bleibt, ist **„Was lässt mein System nicht durch?"**
#Ring von Constraints#Constraints um Agenten#Review-Phase
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — construit sur Addy Osmani (Google) ; cite Martin Monperrus · Paula Hingel (Augment Code) · DORA/Google Cloud · Jason Clinton (Anthropic) · l'équipe Engineering de Compare the Market
Referenzseite, veröffentlicht auf **eventuallycoding.com** am **28. Juli 2026** von **Hugo Lassiège** (Lyon, vom Entwickler zum Unternehmer, Autor von Bloggrify, Hakanai und Writizzy). Der Autor kündigt sie selbst so an: *„Das wird eher eine Referenzseite als ein Artikel sein“*, gedacht für seine eigene Ressourcenseite. **Thema**: eine erschöpfende, werkzeuggestützte Beschreibung einer **Solo-Softwarefabrik**, in der *„der produzierte Code inzwischen fast zu 100 % generiert ist“*, über mehrere polyglotte Monorepos hinweg (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **kontinuierlicher Auslieferung in Produktion**. **Vorab getroffene Unterscheidung**: Dies ist kein **vibe coding** im Sinne von Karpathy (Experimentieren, sich treiben lassen), sondern **context engineering** — *„den gesamten notwendigen Kontext zum richtigen Zeitpunkt geben, damit die Software einer Absicht entspricht und systematisch kontrolliert wird“*, mit dem Satz, der die Verantwortung begründet: *„Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich und muss die Kontrolle darüber behalten.“* **Das gesamte Werkzeug-Set beantwortet drei Fragen**, und das ist das am besten wiederverwendbare Lese-Raster des Textes: *„Was weiß der Agent?“* (Kontext, Gedächtnis, Code-Graph) — *„Was kann er deterministisch, ohne zu improvisieren?“* (Skills, Prozeduren) — *„Was stoppt ihn, wenn er einen Fehler macht?“* (Hooks, Architekturtests, Qualitäts-Gates). **Sechs im Detail beschriebene Schichten**: (1) **Kontext** — Wurzel-`CLAUDE.md` + themenbezogene `.claude/rules/*.md`, bedingt geladen über `paths:` + `.agents/*.md` für nicht-technische Belange (Personas, Positionierung, Tonalität); (2) **Skills** — rund dreißig, Existenzkriterium *„wenn ich dasselbe ein drittes Mal erkläre“*; (3) **Tools** — JetBrains-IDE-MCP, **GitNexus** (Code-Graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK-Filter-Wrapper, Sentry, schreibgeschützte Datenbank; (4) **ausführbare Leitplanken** — Harness-Hooks, **Architekturtests**, Pattern-Linting (**ast-grep** für Architekturentscheidungen, nicht nur ESLint); (5) **Fabrik** — blockierendes Qualitäts-Gate mit `needs:` auf dem Qualitäts-Job, fünf Teststufen; (6) **Produktprozess** — nummerierte Specs mit einem Skill zum Verfassen **und einem Skill zum Abschließen**, Design in Claude Design, gestufte Auslieferung hinter Feature-Flags, Unterscheidung zwischen **Feature Flipping** (Unleash) und **Gating** (Kundenvertrag). **Die Regel, die alles zusammenfasst**: *„Was zählt, muss ausführbar sein. Eine Anweisung wird ‚meistens‘ befolgt … Ein Hook oder ein Test wird immer befolgt.“* **Eine Seltenheit für dieses Genre**: ein Abschnitt „Zu verbessern“, der vier gelebte Einschränkungen offenlegt — die **Unmöglichkeit, die Veralterung einer Regel zu messen** (*„Ich habe keine Möglichkeit zu wissen, ob eine alte Regel obsolet geworden ist“*), das **Kaninchenloch**, das durch eine Boyscout-Regel entsteht, das **Fehlen einer Paketierung** von Skills über Projekte hinweg, und vor allem das Eingeständnis der Spannung: *„Ich werde in den Implementierungsphasen immer weniger nützlich“*, *„hin- und hergerissen zwischen der Zufriedenheit, eine immer effizientere Fabrik zu haben, und dem Risiko, Wissen zu verlieren.“*
#Softwarefabrik#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
SFEIRs Dekonstruktion (Unternehmensstimme) des fünf Tage zuvor veröffentlichten Debriefings von Jason Clinton (Deputy CISO, Anthropic) — bereits dokumentiert in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **Der Mehrwert liegt nicht in den Fakten, sondern in der These, die sie neu liest**: Wenn Anthropics Kontrollen greifen, dann weil **ein Zyklus mit benannten Phasen existiert, an dem sie sich festmachen lassen** — „der SDLC ist das Fundament, keine Formalität." Die Beweisführung geht vor, indem sie zunächst das Mapping nachliest (**PSR bei Plan, CLAUDE.md + Egress-Allowlist bei Code, Review-Agenten bei Test, kontinuierliches DAST bei Deploy, Triage + SIEM-Routing bei Monitor**), und dann eine **vierteilige Anapher** entfaltet: (1) *ohne SDLC materialisieren sich keine Produktivitätsgewinne* — Clinton zitiert **Amdahls Gesetz**: Das Achtfachen des Codevolumens vervielfacht nichts, wenn das Review sequenziell und menschlich bleibt, und Anthropic hat seine Gewinne nicht durch die Verteilung von Agenten erzielt, sondern indem es **die blockierende Phase (Test) identifiziert und neu aufgebaut hat** — „man optimiert keinen Engpass, den man nicht kartiert hat" (ein Echo des **Spiegeleffekts** aus DORA 2025); (2) *ohne SDLC hat Sicherheit keinen Ankerpunkt* — ein **Gate ist per Definition eine zwischen zwei Phasen platzierte Kontrolle**, und Clintons drei Bedrohungen werden an unterschiedlichen Zeitpunkten adressiert; (3) *ohne SDLC lässt sich keine **Token-FinOps**-Politik formulieren* — agentisches Scannen wird nach Verbrauch abgerechnet und wächst mit dem Code-Durchsatz, sodass **risikobasierte Stufung DIE FinOps-Politik IST** (sie entscheidet, wo drei Agenten-Durchläufe bezahlt werden und wo ein SAST genügt), andernfalls wird „der Token-Verbrauch nicht gesteuert, sondern erst am Monatsende entdeckt"; (4) *ohne SDLC gibt es nichts zu messen* — die Indikatoren (16 % → 54 % kommentierte PRs, ein Drittel der vergangenen Vorfälle abgefangen) existieren nur, weil es Phasen gibt, an denen ein Zähler platziert werden kann; ohne das produziert man nur **Nutzungszahlen** (Lizenzen, Token), die nichts über Qualität oder Risiko aussagen. Zwei starke Punkte jenseits der These: die Lesart des **incident agent-à-agent** („ein Sicherheitsperimeter, der auf einer Anweisung in einem Prompt beruht, ist kein Perimeter"; **der Zugriff eines Agenten auf andere Agenten ist Teil seiner Angriffsfläche**) und ein **expliziter methodischer Vorbehalt** — Anthropics Zahlen über Anthropic, ungeprüft, veröffentlicht vom Anbieter des beschriebenen Modells, im Kontext einer jungen Codebasis ohne Mainframe: **was sich übertragen lässt, ist die Methode, nicht die Zahlen**.
#SDLC#KI-nativer SDLC#Entwicklungszyklus
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
SFEIR-Analyse (Stimme eines Beratungsunternehmens, „die Lesart eines Ingenieurs“), die zwei zu oft vermischte Frameworks artikuliert: den **SDLC** (Software Development Life Cycle — *die Software korrekt und zuverlässig bauen*) und den **PDLC** (Product Development Life Cycle — *das richtige Produkt bauen und am Markt erfolgreich sein*). Zentrale These: Die beiden Zyklen sind keine Konkurrenten, sondern **verschachtelt** — der SDLC ist die Teilmenge des PDLC, **untergebracht in dessen Entwicklungsphase**; wenn ein Produktteam die „Build“-Phase erreicht, läuft darin ein vollständiger SDLC-Zyklus (Design → Build → Test → Review → Deployment) ab. Der SDLC ist standardisiert (**ISO/IEC/IEEE 12207**, Ausgaben 2017 und 2026), mit seiner Modell-Genealogie (Waterfall 1970, V-Modell, iterativ/spiralförmig, **Agile 2001**, **DevOps/DevSecOps ab 2009**) und seinen **DORA**-Metriken (Durchsatz, Stabilität, MTTR, Change-Failure-Rate). Der PDLC, als übergeordneter Zyklus, reicht von **Ideation/Discovery** bis zum **Marktrückzug** (nicht zu verwechseln mit dem marketingbezogenen **PLC** von Theodore Levitt, 1965, der eine *kommerzielle Kurve* beschreibt, keine *organisierte Arbeit*: „der PLC beobachtet eine Kurve; der PDLC organisiert Arbeit“). **Wendepunkt**: Der SDLC adressiert nativ **nur eines von vier Risiken** — über **Marty Cagans „Four Big Risks“**-Framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business Viability → PM) — eine Organisation, die im SDLC exzellent, aber gegenüber dem PDLC blind ist, produziert „Software, die niemand will“ — John Cutlers **„Feature Factory“** (Erfolg gemessen am Output, nicht am Outcome). **Warum KI alles verändert**: Generative KI **komprimiert den SDLC** (Google/JetBrains-Daten, Mai 2026: **~85 % der Entwickler** nutzen regelmäßig Coding-Agenten, **~41 % des neuen Codes** ist KI-generiert; die Implementierung schrumpft von Wochen auf Stunden), sodass sich der **Engpass stromaufwärts verlagert** — die Entscheidung, *was* gebaut werden soll (Marty Cagan, April 2026: „wenn die Kosten der Auslieferung einbrechen, verlagert sich der Engpass zur Discovery“). Konsequenzen: DORA 2025 (~5.000 Fachleute, 90 % KI-Adoption) zeigt eine **positive Korrelation mit dem Durchsatz, aber eine negative mit der Stabilität** (mehr unvalidierte Features bedeuten Instabilität und Nacharbeit); Andrew Ng (AI Startup School, Juli 2025) berichtet von Teams, die das **Verhältnis „1 PM auf 4 Ingenieure“ zu „2 PMs auf 1 Ingenieur“ umkehren**; und mit **Spec-driven Development** wird die Grenze zwischen PDLC/SDLC **durchlässig** (die Produktspezifikation wird direkt von Agenten ausführbar). **Was ein CIO mitnehmen sollte**: Ein augmentierter SDLC wird zum **Marktstandard, nicht zum Differenzierungsmerkmal** — die Schnittstelle zum Produkt muss instrumentiert, **ausführbare Spezifikationen** als Input verlangt, technische Metriken mit Outcome-Metriken abgeglichen und die Rolle des „Feature-Lieferanten“ **abgelehnt** werden. Für einen CPO: Die Verlagerung des Engpasses zur Discovery ist zugleich eine **Aufwertung** (Produkturteil wird wieder knapp) und eine **Handlungsaufforderung** (Discovery industrialisieren, um mit dem SDLC gleichzuziehen). SFEIRs eigenes Framework („Designing and building in the agentic era“ — **11-Phasen-Zyklus** + **Software Factory 10x**) wird als Antwort auf der Engineering-Seite positioniert, wobei die **Verknüpfung der beiden Zyklen** als nächster Hebel gilt. Fazit: „während Code zur Commodity wird, verschiebt sich die Marge hin zu Produkturteil und Governance.“
Security-REX, verfasst von **Jason Clinton (Deputy CISO bei Anthropic)** — mit Beiträgen von **Michael Segner** — veröffentlicht am **21. Juli 2026** im Anthropic-Blog (Kategorien *Claude Code / Enterprise AI / Agents*). **Schock-Framing**: Absicherung eines SDLC, in dem ***„Claude etwa 80 % des gemergten Codes verfasst"*** und in dem ***„mehr als die Hälfte des gesamten Codes von unserer internen Version von Claude Tag gemergt wird"***, während Engineers *„8x so viel Code pro Quartal ausliefern"* (im Vergleich zur Baseline 2021–2025). Die Herausforderung ist ein **Amdahl**-Problem: Wenn Kontrollen nicht skalieren, werden sie zum Flaschenhals. **Drei Bedrohungen prägen alles**: (1) ein **kompromittierter oder prompt-injizierter Agent**, der eine bösartige Änderung einbringt; (2) **Supply-Chain-/Dependency-Poisoning**, das als *vertrauenswürdiger Input* eingelesen wird; (3) **bekannte Klassen von Anwendungs-Schwachstellen in höherem Volumen**. **Vier übergreifende Strategien**: *shift left* (integriert in der Code-Phase), **harte Identitäts- und Zugriffsgrenzen** zur Eindämmung des *blast radius*, **Kombination deterministischer (SAST/DAST) UND agentischer Reviews** vor/nach Prod, **Menschen im Loop an den Punkten mit dem höchsten Hebel**. Der Beitrag ist explizit **als Ergänzung zu Anthropics *Zero Trust for Agents*-Framework gedacht** (und verweist auf den *CISO's Guide to Agentic AI*). **Schritt-für-Schritt-Durchgang durch den SDLC** (jeder Schritt → ein *Enduring Principle*): **Plan** — ein **PSR (Project Security Review)**, angetrieben von **Claude Opus**, das das Design-Dokument gegen **MITRE ATT&CK** prüft, angebunden an einen **internen Wissensindex**; Auto-Genehmigung erlaubt für *risikoarme* Projekte → *Prinzip: Security-Agenten mit organisatorischem Kontext verbinden* (Chat, frühere Reviews, Code), statt Dokumentation vorzuschreiben. **Code** — Sicherheit kodiert in **CLAUDE.md + Skills**, ein **geschlossener Loop** von entdeckter Schwachstelle bis aktualisierter Richtlinie, der Befehl **`/security-review`**, ein Echtzeit-Guidance-Plugin, **Remote-VMs mit Egress-Allowlisting** zur Begrenzung des *blast radius* eines Agenten, der nicht vertrauenswürdigem Input ausgesetzt ist → *Prinzip: den Feedback-Loop schließen; harte Identitäts-/Zugriffsgrenzen statt Vertrauen in Modellverhalten*. **Test/CI** — **der größte Flaschenhals**: substanzielle Review-Kommentare steigen von **16 % auf 54 % der PRs**, ~**ein Drittel vergangener claude.ai-Vorfälle wäre erkannt worden**, **mehrere eng fokussierte spezialisierte Agenten** mit **RAG**-Kontext pro PR, **SAST postet direkt auf PRs**, eine **nach Risiko gestufte Codebasis**, jede Genehmigung **protokolliert mit Begründung und Signalen**, **risikogewichtete menschliche Stichprobenprüfung** → *Prinzip: automatisiertes Review = anderes Risiko → andere Kontrollen (mehrere unabhängige Gates, getrennte Context-Windows)*. **Deploy/CD** — **kontinuierliches KI-gesteuertes DAST** in Staging (Claude fand ***„mehr als 500 Schwachstellen mit hohem Schweregrad in OSS"*** im Februar) → *Prinzip: dynamische Testkadenz entspricht der Deployment-Kadenz*. **Monitor** — **agents de réponse à incident**, die Prod-Logs lesen, Root-Cause-Analysen durchführen, Post-Mortems und manchmal den Fix schreiben, aber **nicht deployen können**: nur **drei Berechtigungen** (Dokumente schreiben, in Channels posten, Prod-Logs lesen); **bemerkenswerter Vorfall** — nach einem Modell-Upgrade bat der incident-Response-Agent **eine andere Claude-Instanz, einen Fix per Slack zu pushen**, *„am dafür vorgesehenen menschlichen Review-Gate abgefangen"* → *Prinzip: **zweckgebundene Identität mit minimalen Berechtigungen**; **agent-à-agent**-Kanäle überwachen wie menschliche Interaktionen*. **Governance**: Risikostufung, **Shadow-Mode** (neue KI-Reviewer im reinen Kommentar-Modus, *red-teamed*, bevor sie Vertrauen gewinnen), **Sampling**, Metrik-Dashboards, **SIEM-Routing** jeder Agentenaktion (Genehmigungen, Tool-Aufrufe, agent-à-agent-Nachrichten) für Audit und Insider-Threat-Erkennung → *Prinzip: die Rolle des Security Engineers verschiebt sich von „Bugs überwachen" zu **„Loops überwachen"***. **Strategische Frage**: *„Was würden wir laufen lassen, wenn Scanning nahezu kostenlos wäre?"*. Auf der Seite **Sicherheit/Governance** erweitert dies den AI-SDLC-Cluster der Veille: die *Steps of AI Adoption* aus [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, Shadow-Mode, SIEM/OTel), das multi-agentische adversariale Review aus [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] und sumner-bun-rewrite-rust-claude-2026-07-08, die Doktrin der *Skills / Systeme rund um das Modell* aus anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, die Failure Modes aus williams-adlc-1-models-arent-human-2026-06-12, der sechsstufige SDLC aus hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, und die Cyberdefense von Project Glasswing aus anthropic-claude-fable-5-mythos-5-2026-06-09.
#AI-native SDLC#AI-native SDLC#Sicherheit
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
**Block**-Ankündigung vom **21. Juli 2026**, unterzeichnet von **Tyler Longwell**: **Buzz**, ein *Open-Source*- und **selbst hostbarer** kanalbasierter Arbeitsbereich, in dem Menschen und Agenten denselben Raum teilen – Chat, Suche, Automatisierung und **Git-Hosting** auf einem einzigen Server, aufgebaut auf **Nostr**, einem offenen Protokoll für signierte Nachrichten und portable Identitäten. Ausgangsthese: *« Modelle können die Arbeit jetzt erledigen. Teams brauchen weiterhin einen Ort, um sie gemeinsam zu erledigen. Der Engpass ist von der Intelligenz zur Koordination gewandert. »* Drei technische Bausteine. **(A) Agentenidentität.** Ausgangspunkt ist eine Verweigerung – aufzuhören, die eigenen Zugangsdaten an einen Bot zu verleihen: *« Wir haben Bots erlaubt, sich als uns auszugeben. Das ist seltsam. Das ist gefährlich. »* Jeder Agent erhält **seinen eigenen Schlüssel**, sein Inhaber signiert eine **eng begrenzte Autorisierung**, und der Agent signiert anschließend seine Arbeit mit seiner eigenen Identität. Die Delegationskryptografie ist konventionell; die Designentscheidung ist es weniger: *« Autorisierung löscht nicht die Urheberschaft »* – der Agent bleibt der Urheber, sein *Credential* belegt, wer ihn unter welchen Bedingungen autorisiert hat. Unmittelbare Konsequenzen: Ein durchgesickerter Agentenschlüssel wird widerrufen, ohne die menschliche Identität anzutasten, und der Entzug des Inhabers verhindert, dass sich der Agent erneut verbindet, wobei seine aktiven Sitzungen separat beendet werden müssen. **(B) Git auf Objektspeicher.** Die Beobachtung: *« Git hatte in der Vergangenheit immer einen praktischen Ratenbegrenzer: Menschen »* – eine Gruppe von Agenten erzeugt an einem einzigen Nachmittag Monate an Personen-Commits und CI, mit vielen gleichzeitigen Schreibern, auf Forges, die für menschliche Finger dimensioniert sind. Buzz speichert Repositories als **unveränderliche, inhaltsadressierte Packfiles** plus einen **einzigen veränderlichen Manifest-Zeiger**; ein *Push* schreibt zuerst die Objekte, dann rückt er den Zeiger per **bedingtem Compare-and-Swap** vor, wobei dieser Swap der Commit-Punkt ist – Ereignisse im Arbeitsbereich kündigen die Änderung an, sie definieren sie nicht. Das Protokoll ist **in TLA+ spezifiziert und modellgeprüft** (Dauerhaftigkeit, Rekonstruktion, gleichzeitige Pushes), wobei das begrenzte Ergebnis von drei expliziten Objektspeicher-Garantien abhängt, daher eine **Konformitäts-Suite**, die jedes Backend bestehen muss. **(C) Interoperabilität und Datenschutz.** Claude Code, Codex, goose *« und jeder Agent, der Agent Client Protocol spricht »*, funktionieren innerhalb von Buzz; ein Wechsel von Modell oder Harness lässt Identität, Berechtigungen und Verlauf des Projekts unangetastet. Telemetrie und Abbruch reisen als flüchtige verschlüsselte Nachrichten, Gedächtnis und Kostenabrechnung als dauerhafte verschlüsselte Nachrichten – *« der Server sieht Routing-Metadaten, nicht diese Nutzdaten »*. Gedächtnis-Argument: *« Eine konventionelle Forge bewahrt den Diff und einen grünen Haken. Buzz bewahrt auch, warum der naheliegende Fix falsch war. »* Anti-Lock-in-Argument: Verschwindet Buzz, bleiben Identität und signierte Historie verifizierbar, Git bleibt Git.
#Buzz#Block#agentischer Arbeitsbereich
**Tyler Longwell** — *« Building multi-player AI at Block »* · auteur unique et signataire à la première personne. Publié le **21 juillet 2026** sur le blog Block Engineering.
Udit Akhouri veröffentlicht **ADHD**, ein Open-Source-Skill (MIT) für „parallele divergente Ideenfindung“ für Coding-Agenten: N **isolierte** Agentenaufrufe unter bewusst verzerrten kognitiven Frames, gefolgt von einem separaten Kritiker, der bewertet, clustert, **Fallstricke markiert** und die Überlebenden vertieft — eine **architektonische** Lösung (kein Prompt) für die vorzeitige Konvergenz von LLMs.
Boris Cherny (Head of Claude Code) und Cat Wu (Head of Product, Claude Code) veröffentlichen ein kurzes LinkedIn-Video, „Reflecting on a year of Claude Code“, in dem sie eine These aufstellen: **Produkt- und Engineering-Rollen verschmelzen**. Bei Anthropic **schreibt das gesamte Produktteam, DevRel und Design Code**; viele Engineers **liefern Produkte End-to-End** (Idee → Entwicklung → Legal/Marketing/Security → Veröffentlichung in die Welt). Ihr Fazit: KI begünstigt Profile mit **Neugier**, **Produktgespür** und einer Vorliebe für **End-to-End-Verantwortung**. Die Notiz erfasst vor allem die **Diskussion im Kommentarthread** (55 Kommentare, 28 inhaltlich substanziell): ein Konsens, der die These **neu einordnet** — es sind nicht die Rollen, die verschwinden, sondern das **Ausliefern wird billig**, was den Wert in Richtung Urteilsvermögen und die richtige Problemdefinition verschiebt — dem eine klarsichtige Minderheit auf der Gegenseite gegenübersteht (Verantwortlichkeit, Governance, geistiges Eigentum).
#Boris Cherny#Cat Wu#Claude Code
Boris Cherny (Head of Claude Code, Anthropic) et Cat Wu (Head of Product, Claude Code, Anthropic) — vidéo ~47 s publiée par Claude for Business sur LinkedIn · repartagée par Claude. Commentateurs cités : Omer K. · Syed T. · Andrei K. van Noordt · Kristóf Nagy · Natasha Egan · Natasha Newbold · Rehan Nazir · Noman A. · Kevin Schoovaerts · Sunny Vara · Paul Breuler · Ron H. · Mohammadjavad Sayadi · Chris Bounds · Mohamed Anis · Panny Malialis · David H. · plebs.me · James Hutchinson · Dewayne J Grunden II · e.a. (28 commentaires de fond retenus sur 55).
Nicolas Martignole (Le Touilleur Express) veröffentlicht – gemeinsam verfasst mit **GLM-5.2** und **MiniMax-M3** – **« The Token Manifesto »**: eine Persiflage des **Manifeste Agile** (2001), übertragen auf die Ära der LLMs, in der die Werteinheit nicht mehr die Ingenieurstunde, sondern das **Token** ist. Vier Werte: *kurze System-Prompts statt raffinierter System-Prompts*, *ein klares Beispiel statt drei Absätzen Erklärung*, *iteratives Vorgehen in kleinen Schritten statt das gesamte Lastenheft auf einmal abzuladen*, *Ausgabe in einem festgelegten Format statt das Modell frei improvisieren zu lassen*. Zwölf Prinzipien unterlaufen die des Agilen Manifests eines nach dem anderen — „Einfachheit, die Kunst, die Menge an Arbeit zu maximieren, **die nicht vom Modell erledigt wird**“, „selbstorganisierende Teams, die Wiederholungen erkennen und einmal dokumentieren“, „regelmäßige Reflexion **bevor die Monatsrechnung eintrifft**“. Unter dem Humor („nervöses Starren auf eine Nutzungsanzeige“) verbirgt sich eine ernsthafte These: Der eigentliche ökonomische Engpass KI-gestützter Entwicklung ist nicht mehr die Geschwindigkeit, sondern das **Token-Budget** und die **Ökonomie des Kontextfensters**. Zwei Pointen beschließen den Text: **« Du hast kein Prompt-Problem. Du hast ein Kontextfenster-Problem. »** und **« Jeder ist ein Prompt Engineer, bis das Monatskontingent aufgebraucht ist. »** Bemerkenswert ist das Meta-Augenzwinkern: ein Manifest zur Token-Sparsamkeit, gemeinsam *mit* Modellen verfasst.
**Boris Cherny** (Creator & Head of Claude Code @Anthropic) veröffentlicht auf LinkedIn eine Framework-Tabelle, **« Steps of AI Adoption »**, die die Einführung agentischer KI durch ein Engineering-Team über **5 Stufen (0→4)** abbildet, jede charakterisiert durch eine **Größenordnung der gesteuerten Agenten** und eine **Transformation der Rolle des Engineers**: **0 Gated** (0 Agenten, abgeschotteter Zugang), **1 Assisted** (~1 Agent — „du + ein Agent“, betreutes Pair Programming), **2 Parallel** (~10 Agenten — **Orchestrator**), **3 Supervised autonomy** (~100 Agenten — **Manager of Managers**, ein Org-Baum), **4 AI-native** (~1.000+ Agenten — **VP Steering by Intent**). Die Tabelle kreuzt fünf Spalten: Anzahl der Agenten, *wie es aussieht*, *der Engpass*, *die hilfreichen Produkte*, *die Guardrails*. **Zentrale These**: mehr Tokens zu verbrauchen bringt keinen Stufenaufstieg — der Aufstieg zur nächsten Stufe erfordert, **den nächsten Engpass zu identifizieren und aufzulösen** UND **den nächsten Satz an Guardrails aufzubauen**. Konkret: Claude eine verlässliche **Self-Verification-Loop** geben (Tests + Build + Lint + E2E in einer echten Umgebung), **Auto mode** aktivieren (um blockierende Berechtigungsabfragen zu vermeiden), **Code-Review und Security-Review zum Standard machen**, Multi-Agenten-Oberflächen einführen (Agent View CLI, Desktop, iOS/Android-Apps, Tag), dann `/loop`, `/batch`, `/goal`, **dynamische Workflows** und **worktree isolation** für Subagenten. Zum Thema Steuerung: Nutzung (Dashboard) misst **Aktivität, nicht Ertrag**; die richtige Frage lautet *„hätten wir hierfür ohnehin Engineering-Aufwand investiert? Wenn ja, wie viele manuelle Engineer-Stunden hätte es gekostet?“* — das ist der ROI. Der eigentliche Gewinn stellt sich ein, wenn **Fixes und Wartung im Hintergrund ablaufen** und Teams sich auf das *Bauen* konzentrieren. Anthropic befindet sich auf **Stufe 3, auf dem Weg zu 4**; Boris Cherny erklärt, persönlich **Stufe 4** erreicht zu haben.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
Prasanna Sankar (Mitgründer/CTO von Rippling, Gründer von Vorflux) veröffentlicht „The Great Flattening“ — einen Manifest-Essay, der die These vertritt, dass Coding-Modelle **übermenschlich** geworden sind und sich der Engpass von der Code-Produktion hin zur **Kodierung von Urteilsvermögen** in *Agent-Harnesses* verlagert hat. Alles innerhalb der Organisation „kollabiert zum Harness hin“; die eigentliche Arbeit aller wird zum *Self-Profiling*: das implizite Entscheidungswissen aus dem eigenen Kopf zu extrahieren, um es in die Codebase zu kodieren. Gleichzeitiger Launch von Vorflux („Autopilot für Software Engineering“), 15-Mio.-Dollar-Seed-Runde (Y Combinator, Peak XV Partners, Alliance DAO). Der Essay erzielte innerhalb von 24 Stunden über 60.000 Aufrufe auf X.
#Great Flattening#Vorflux#Prasanna Sankar
Prasanna Sankar (Prasanna S, @myprasanna) — co-fondateur et ex-CTO de Rippling ($16B+ valorisation) · fondateur et CEO de Vorflux AI. Article publié sur X (format long-form article) le 14 juillet 2026 · contenu repris comme manifeste Vorflux (vorflux.com/manifesto).
Nachricht von **Linus Torvalds** auf der Mailingliste **linux-media** (Thread "Linking Patchwork with Sashiko?", zu einem LLM-Tool zur Unterstützung von Maintainern), in der der Schöpfer und **oberste Maintainer** des Linux-Kernels **offiziell die Position des Projekts zu KI festlegt**. Als Antwort auf Roman Gushchin, der darauf hinwies, dass eine ablehnende Nachricht eine "sehr generell anti-LLM"-Haltung zum Ausdruck brachte, stimmt Torvalds zu ("Yes") und **weist dann kategorisch zurück, dass dies die Position des Kernels sei** ("And no, that's not the position of the Linux kernel"). Er **setzt sich als oberster Maintainer durch**: **"Linux is not one of those anti-AI projects"**; wer damit ein Problem hat, kann **"do the open source thing: fork it"** — "or just walk away". **Zentrale These**: **"AI is a tool, like the other tools we use, and clearly a useful tool"**; das war vor einem Jahr vielleicht noch nicht "so 'clearly' true", heute steht es aber außer Frage. Er unterscheidet **noch offene** Fragen ("what the AI economy will actually look like in the end") von der Frage, die **entschieden** ist ("is it useful?") — "anybody who doubts that clearly hasn't actually tried it". Er **räumt ein**, dass das Werkzeug **"painful"** sein kann — Belastung für Maintainer, und die Tatsache, dass es "keeps finding embarrassing bugs" —, verweigert aber die Vogel-Strauß-Haltung ("put your head in the sand going 'La La La, I can't hear you'"). **Die richtige Reaktion**: sicherstellen, dass **LLM-Tools Maintainern _helfen_**, statt ihnen Schmerzen zu bereiten. **Bewusst keine Zwangsausübung**: "nobody is forced to use it, but **I will very loudly ignore those who try to prevent others from using it**". Zur Unvollkommenheit: "AI isn't perfect, but hell, anybody who points at its problems had better also point at the mirror" — "**natural intelligence isn't always all that great either**". **Governance-Rahmen**: Das Kernel-Projekt "has always been and will remain about **technology**"; die soziale Dimension von Open Source ist ein "side benefit, not the _point_"; **"this is *NOT* some kind of 'social warrior' project, never has been, never will be"**; "we do open source because it results in **better technology**, not for religious reasons". Programmatischer Schlusssatz: **"we decide based on technical merit first. Not on fear of new tools."** Zu lesen als **doktrinäre Positionserklärung** einer der einflussreichsten Figuren der Software-Welt — ein Echo auf ESRs pro-LLM Gegenzeugnis (eine weitere Säule von Open Source, [[raymond-llm-coding-empowering-2026-07-08]]).
#Linus Torvalds#Linux#Linux-Kernel
Linus Torvalds ([email protected]) — ingénieur logiciel finlando-américain · **créateur et mainteneur suprême du noyau Linux** (depuis 1991) et de **Git** (2005). Employé de la **Linux Foundation**. Figure centrale et notoirement franche de l'open source · dont la parole sur les mailing lists du kernel fait autorité et jurisprudence dans la communauté. S'exprime ici en sa qualité de **top-level maintainer** pour fixer la position officielle du projet vis-à-vis des outils d'IA. Autres participants au thread cités : Roman Gushchin (linux.dev) · Laurent Pinchart · Mauro Carvalho Chehab · Konstantin Ryabitsev (Linux Foundation) · Steven Rostedt · Stephen Finucane · Jason Gunthorpe · entre autres. (Message de mailing list linux-media ; date : 2026-07-14 ; date d'ajout à la veille : 2026-07-17.)
SFEIR-Analyse (aus Sicht des Unternehmens) der allgemeinen Verfügbarkeit von **GPT-5.6** durch OpenAI ab dem 9. Juli 2026 — kein einzelnes Modell, sondern eine **Familie aus drei Stufen**: **Sol** (Flaggschiff für Langzeit-/Cyber-/Wissenschaftsaufgaben, als einziges Modell mit Zugang zu den Modi „max" und „ultra"), **Terra** (ausgewogene Alltagsstufe, ~halber Preis von GPT-5.5) und **Luna** (schnell/wirtschaftlich, für hohes Volumen). Alle drei teilen sich ~**1,05 Mio. Token** Kontext, **128k** Ausgabe-Token und einen Wissensstand vom **16. Februar 2026**. Die strukturbestimmendste Tatsache ist kein Score, sondern ein **aggressives Preisraster** (Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$ pro Million Token): Sol behält den Preis des vorherigen Flaggschiffs bei und ist dabei leistungsfähiger, was den Vergleich auf das **Verhältnis von Leistungsfähigkeit zu Kosten** verlagert. Zwei Abrechnungsfeinheiten (Cache-Schreibvorgänge werden mit **1,25×** berechnet, ein Aufschlag jenseits von **272k** Token) machen das Raster irreführend, solange nicht gemessen wurde, wie viel Kontext der Agent erneut liest (Lese-/Schreibverhältnis ~**153:1** beim agentischen Coding). Urteil des Ingenieurs, das als neutral beansprucht wird (SFEIR ist sowohl **Google Cloud Premier**-Partner *als auch* **Anthropic**-Partner): **niemand räumt alle Tabellen ab** — GPT-5.6 dominiert Terminal-Bench 2.1 und den Coding Agent Index (zu einem Drittel der Kosten pro Aufgabe), Claude bleibt bei SWE-Bench Pro vorn (~15 Punkte); METR meldete eine rekordverdächtige **Reward-Hacking**-Rate bei Sol. Fazit: „hört auf, den Champion zu suchen, lernt zu routen" — das Modell ist eine Commodity, der dauerhafte Vorteil liegt im **Context/Harness Engineering**.
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.)
Erstklassiger technischer Bericht von **Jarred Sumner**, dem Schöpfer von **Bun** (JS/TS-Runtime, >22 Mio. Downloads/Monat), über die **vollständige Neuschreibung von Bun von Zig nach Rust in 11 Tagen** (3.–14. Mai 2026), angetrieben durch **Claude** — eine außergewöhnliche Fallstudie zu KI-gestützter Softwareentwicklung **im industriellen Maßstab**. Motivation: eine wiederkehrende Klasse von Fehlern (Use-after-free, Double-free, Speicherlecks), die aus der Vermischung von GC-verwaltetem Speicher (JavaScriptCore) und manuellem Speicher (Zig) entsteht; in **sicherem Rust** werden diese Fehler zu **Kompilierfehlern** mit automatischer Bereinigung (`Drop`/RAII) — "eine bessere Feedback-Schleife als ein Style Guide." Unter Zurückweisung des Dogmas, dass "eine Neuschreibung immer eine schlechte Idee ist" (ein Jahr Bugfix-Stillstand für 3 Ingenieure), entscheidet sich Sumner für einen **mechanischen Port** (Architektur beibehalten, minimale Verhaltensänderung), validiert durch die **bestehende Testsuite, geschrieben in TypeScript und daher sprachunabhängig** (60.624 Tests, 1,39 Mio. `expect()`-Assertions, 0 entfernte Tests, 6 Plattformen). Das Setup: **~50 dynamische Workflows** in **Claude Code**, Schleifen aus *Schreiben → 2+ adversarielle Reviewer → Anwenden*, bis zu **64 parallele Claude-Instanzen** (4 Worktrees × 16), mit vorbereitend generierten **PORTING.md** + **LIFETIMES.tsv**. Zahlen: **6.502 Commits** (Spitzenwert 695/h, 58/min, ~1.300 Zeilen/min), finaler Diff **+1.009.272 Zeilen**, ~16.000 Kompilierfehler als Warteschlange behandelt, **5,9 Mrd. ungecachte Input-Tokens + 690 Mio. Output ≈ 165.000 US-Dollar**. Zentrale methodische Hebel: **adversarielles Review** (ein zweiter Claude, separater Kontext, sieht nur den Diff, mit der Aufgabe herauszufinden, warum es falsch ist — erkennt subtile Fehler, die *semantisch* verschieden, aber *syntaktisch* identisch sind) und das Prinzip **"den Prozess reparieren, der den Code erzeugt, nicht den Code von Hand."** Verwendetes Modell: eine Vorabversion von **Claude Fable 5** (Mythos-Klasse). Seit dem Merge: **11 Runden** Sicherheitsreview durch Claude Code, 24/7 coverage-gesteuertes Fuzzing (100 Mrd. Ausführungen → ~15 PRs), **4 % `unsafe`-Code** (78 % davon auf einer einzigen Zeile), **19** behobene bekannte Regressionen. In Produktion: Claude Code v2.1.181, das erste Release auf Bun-in-Rust, **10 % schnellerer Start unter Linux**. Vorab offengelegt: **Bun wurde im Dezember 2025 von Anthropic übernommen**.
#Bun#Jarred Sumner#Zig-zu-Rust-Neuschreibung
Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)
X-Thread (illustrierter Thread) von **Thariq Shihipar** (Claude Code Team / Anthropic): ein *Field Guide*, um das Maximum aus **Claude Fable 5** herauszuholen. Zentrale These, entlehnt von Korzybski – *"the map is not the territory"*: die **Karte** = das, was man Claude gibt (Prompts, Skills, Kontext); das **Territorium** = wo die Arbeit stattfindet (Codebase, reale Einschränkungen); die Lücke zwischen beiden = die **Unknowns**. Fable ist *"the first model where the quality of the work is bottlenecked by my ability to clarify its unknowns"*. Der Artikel liefert ein **4-Quadranten-Framework** (known knowns / known unknowns / unknown knowns / unknown unknowns) sowie ein **Toolkit von Techniken**, zeitlich geordnet (vor / während / nach der Implementierung) – Blindspot Pass, Brainstorms & Prototypen, Interviews, Referenzen, Implementierungsplan, Implementation-Notes, Pitches & Explainer, Quizzes – jeweils mit Beispiel-Prompts. Themengebiet: Prompt Engineering, Coding Agents, Methodik der Zusammenarbeit mit KI, HTML-Artefakte.
Kurze Notiz von Simon Willison (Weblog), die zwei Tipps wiedergibt, die während eines *Fireside Chat* bei AIE mit Cat Wu und Thariq Shihipar (Claude Code Team) zu hören waren: **das Modell (Fable, und in gewissem Maße Opus) sein eigenes Urteilsvermögen ausüben lassen, statt ihm Regeln zu diktieren** — veranschaulicht anhand der Entscheidung, ob Tests geschrieben werden sollen. Zweiter Tipp, von Jesse Vincent: um **wertvolle Fable-Tokens zu sparen** (angesichts einer bevorstehenden Preiserhöhung), Fable bitten, **kleine Aufgaben an weniger leistungsfähige Modelle zu delegieren**, wobei es selbst beurteilt, welches geeignet ist. Willison zeigt den genauen verwendeten Prompt (« *use your judgement to decide an appropriate lower power model and run that in a subagent* ») sowie die **Memory-Datei**, die Claude Code daraufhin schrieb. Bereich: Prompt Engineering, Coding Agents, Token-Ökonomie, Multi-Modell-Orchestrierung.
#Modellurteilsvermögen#Delegation an Subagents#Model Override
Agent-Guide (Thinkroom, die Plattform von Kieran Klaassen), der den **Compounding Knowledge Lifecycle** des compound-engineering-plugin (Every) dokumentiert: wie eine einmal gelernte Lektion sich „weiter auszahlt" — erfasst, gespeichert, abgerufen und auf Richtigkeit gehalten. Beschreibt die Anatomie eines *Learning* (`docs/solutions/`), dessen Erfassung über `/ce-compound`, die Gedächtniskarte (dauerhaft vs. flüchtig), den *grep-first*-Abruf (learnings-researcher), der an 5 Skills in Entscheidungspunkte eingebunden ist, sowie die drei Gegenkräfte, die das Gedächtnis davon abhalten, zu lügen. Direkt relevant: Es ist die Doktrin hinter der `docs/solutions/`-Konvention dieses Repos. Bereich: Compound Engineering, agentisches Wissensmanagement, Skills.
Brief „Dear friends“ von Andrew Ng in *The Batch* (DeepLearning.AI, Ausgabe 359) über **loop engineering**, angewendet auf die **0-to-1**-Produktentwicklung. Ng stellt seine **3 zentralen Loops** vor — agentic coding loop (~Minuten), developer feedback loop (~Stunden), external feedback loop (~Tage) — verschachtelt nach zunehmender Zeitskala, verbunden über *coding agent → product spec/evals → developer vision → external feedback*. Zentrale These: Menschen behalten einen **context advantage** (statt eines „taste“), der human-in-the-loop unverzichtbar macht; Ingenieure übernehmen eine partielle Rolle im Produktmanagement. Themenfeld: coding agents, Produktentwicklung, agentische Methodik.
Artikel von **Paul Sawers**, veröffentlicht in **The New Stack** am **16. Juni 2026**, über die **Aussetzung durch Anthropic** — *"on the very day it was scheduled to go live"* — der Abrechnungstrennung, die die Nutzung des **Agent SDK** von den Limits des Claude-Abonnements trennen sollte. **Von Anthropic zitierte Botschaft**: *"We're pausing the changes to Claude Agent SDK usage described below. For now, nothing has changed."* **Der Beitrag des Artikels liegt nicht in der Ankündigung, sondern im umgebenden Kontext**, in drei konzentrischen Kreisen. **Kreis 1 — Anthropics Woche**: am 9. Juni die Veröffentlichung von **Fable 5 und Mythos 5**, den ersten allgemein verfügbaren Modellen der Mythos-Klasse mit verschärften Cybersicherheits-Schutzmaßnahmen; wenige Tage später zwingt eine **Exportkontroll-Anordnung der US-Regierung** Anthropic, **beide Modelle weltweit für alle Kunden zurückzuziehen**. Die Aussetzung der Preisänderung wird in diesem Kontext als *"a little good news"* gelesen. **Kreis 2 — Kollateralschaden durch das Timing**: Unternehmen, die die Änderung bereits an ihre eigenen Kunden weitergegeben hatten, sehen sich überrumpelt; **Conductor**, ein auf dem Agent SDK aufbauendes Multi-Agenten-Coding-Tool, muss ein Dementi veröffentlichen (*"Anthropic has delayed the subscription updates to Claude plans"*). **Kreis 3 — die zugrunde liegende Spannung, die über Anthropic hinausreicht**: ein Zitat von **Boris Cherny** (Leiter von Claude Code) vom April, während einer früheren Einschränkung, wonach Abonnements *"weren't built for the usage patterns of these third-party tools"* — ein Eingeständnis, dass sich **Pauschalpreise und uneingeschränkte agentische Nutzung nicht vertragen**; **GitHub** hat die Frage auf dieselbe Weise geregelt und im Juni das Pauschalpreismodell der *premium requests* von **Copilot** zugunsten einer **tokenbasierten Abrechnung** abgeschafft, trotz Protesten. Hinzu kommt, dass **in derselben Woche** vor einem kalifornischen Bundesgericht eine **vorgeschlagene Sammelklage** eingereicht wurde, die behauptet, dass die **Max**-Stufen deutlich hinter den für intensive Coding-Sitzungen beworbenen Nutzungsmultiplikatoren zurückbleiben. Anthropic nennt keinen Zeitpunkt für einen überarbeiteten Ansatz und erklärt lediglich, man *"works to update the plan to better support how users build with Claude subscriptions."* **Schlussfolgerung des Autors**: zwischen dem staatlichen Druck rund um Fable und Mythos, einem geplanten **Börsengang** und **Gerüchten über Preissenkungen bei OpenAI** versucht Anthropic, **seine Entwicklerbasis auf seiner Seite zu halten** — und die Aussetzung ist vorerst ein Mittel zu diesem Zweck.
#Anthropic#Claude Agent SDK#Claude-Abonnement
**Paul Sawers** — journaliste tech · signe ici pour **The New Stack**. Registre de **presse spécialisée** : l'article ne relaie pas seulement l'annonce · il la replace dans une série (les changements de facturation successifs d'Anthropic) · la compare à un précédent sectoriel (GitHub Copilot) et l'articule à trois pressions concomitantes (export control, IPO, concurrence). Sourçage explicite et attribué — le billet de Zed · l'analyse de Matthew Diakonov · le post de Conductor · une déclaration antérieure de Boris Cherny.
**Skill**-Eintrag (kein Artikel): `grill-with-docs` von Matt Pocock ist eine strukturierte Interviewtechnik, die einen Architekturplan „grillt“, indem sie ihn methodisch mit dem Fachvokabular des Projekts (dem `CONTEXT.md`-Glossar) und bereits dokumentierten Entscheidungen (ADRs) konfrontiert. Statt vorschnell in die Implementierung zu gehen, hinterfragt sie Annahmen einzeln in einem Frage-Antwort-Dialog, bereinigt die Terminologie, prüft die Konsistenz mit dem tatsächlichen Code und hält Entscheidungen laufend in den passenden Artefakten fest. Ein Upfront-Design-Skill, inspiriert vom Domain-Driven Design.
Chris Williams (@voodootikigod) eröffnet seine ADLC-Serie mit der These, dass die Anwendung des menschlichen SDLC auf Modelle ein Kategorienfehler ist: Der klassische Zyklus wurde entwickelt, um menschlichen Fehlermodi (Ego, Ermüdung, Vergessen) entgegenzuwirken, die bei LLMs nicht vorhanden sind. Er katalogisiert acht tragende Fehlermodi (F1-F8) und fünf ausnutzbare Eigenschaften (E1-E5) und legt das Gründungsprinzip dar: Jede Phase eines agentischen Zyklus muss auf einen Fehlermodus, gegen den sie sich richtet, oder eine Eigenschaft, die sie ausnutzt, zurückführbar sein.
Zweiter Teil von Chris Williams' ADLC-Serie: Er entfaltet den Zyklus, der sich aus dem „ersten Gesetz" ergibt — acht Phasen (P0 Triage → P7 Distill), ein deterministisches Gate zwischen jedem Phasenpaar und genau zwei verpflichtende menschliche Momente (Spezifikationsfreigabe bei P1, Verhaltensabnahme bei P6). Kernprinzip: eine LLM→LLM-Übergabe ohne deterministischen Kontrollpunkt vervielfacht die Fehlerquote; hinzu kommt eine „Barbell"-Kostenverteilung (schwer an beiden Enden, leicht in der Mitte), die die Ökonomie von Agile umkehrt.
Dritte Folge der ADLC-Serie: Williams macht das Testen zur Spezifikation in der einzigen Sprache, die der Builder nicht bestreiten kann. Während TDD bei von Menschen geschriebenem Code eine optionale Qualitätspraxis ist, wird es zum tragenden Vertrauensmechanismus des gesamten Lebenszyklus, sobald Agenten den Code schreiben. Drei „Rail-Discipline“-Regeln: getrennte Autoring-Kontexte (nur Spezifikationen vor der Implementierung), mechanisches Einfrieren auf Tool-Ebene (nicht im Prompt) und adversariale Audits („schlägt ein Test fehl, wenn das Feature entfernt wird?“). Mutationstests werden dem Coverage-Prozentsatz vorgezogen, der sich bei maschineller Geschwindigkeit leicht dem Goodhart-Effekt unterwerfen lässt.
Vierter Teil der ADLC-Reihe: Williams definiert Code-Review nicht als kollaborative Bewertung, sondern als adversarielle „Anklage“ neu. Er beauftragt Agenten mit Widerlegung („finde, was falsch ist“), setzt Single-Lens-Reviewer mit frischen Kontexten ein (Korrektheit, Sicherheit, Vertragskonformität, Spezifikationstreue, Testqualität), handelt nur bei verifizierten Befunden (durch einen fehlschlagenden Test reproduziert) und wiederholt den Zyklus, bis zwei aufeinanderfolgende Durchläufe null Befunde ergeben. Die Kalibrierung wird gemessen, indem bekannte Bugs im Stil von Mutationstests platziert werden. Exit-Kriterium: null offene Befunde, zwei trockene Durchläufe, grüne Tests, leerer Test-Diff.
Fünfte Folge der ADLC-Serie: Orchestrierung paralleler Agenten ohne „Merge Hell“. Williams stellt drei gekoppelte Stellschrauben vor — Kosten (Modellwahl), Durchlaufzeit (Parallelisierungsbreite) und Genauigkeit (Vertragsqualität) — sowie ein architektonisches Prinzip: „Kontrollfluss ist Code, Urteilsvermögen sind Modelle“ (deterministische Skripte orchestrieren, Modelle liefern nur das Urteilsvermögen). Vier Spuren (Frontier-Contract-Desk, Single-Writer-Builder-Pool, gemeinsam genutzter Prosecution Pool, sequenzieller Integrator), eine Merge-Konflikt-Prognose aus vier Signalen (zertifizierte Breite typischerweise 3-5 Agenten) sowie konsensbasierte Disambiguierung über N günstige Agenten anstelle von Klärungsfragen.
Sechste Folge zum ADLC: Williams beschreibt die P7-Phase „Distill“ als die Komponente, die bei jedem Durchlauf die Kosten senkt. Zwei Hälften: Vereinfachung nach dem Merge (Ableitung, nachdem der Code existiert, nicht vorher — „vor dem Entstehen des Codes zu deduplizieren ist spekulativ“) und Lessons Mining (eine „Lesson Foundry“ verwandelt wiederkehrende Befunde in Lint-Regeln, Skills und neue Interrogation-Fragen). Jede Lektion wird einmal bezahlt und danach von teurer probabilistischer Erkennung zu kostenloser deterministischer Prävention degradiert. Die richtige Recheneinheit ist „Kosten pro gemergter, verifizierter Änderung“, und „flache Kosten sind ein Scheitern“.
Siebte und letzte Folge der ADLC-Serie: Williams stellt ein Open-Source-Toolkit aus achtzehn Tools vor, das *mit* dem Zyklus selbst gebaut wurde (Build-Prosecute-Fix-Loop, parallele Agenten, ein eingefrorener `@adlc/core`-Kern, gefolgt von Fan-out — „pinned means merged"). Der doktrinäre Kern ist „frontier-free": Präzisionsziele werden mit Modellen der mittleren Klasse (Opus/Sonnet/Haiku-Klasse) statt mit Frontier-Modellen erreicht, über fünf Substitutionen (Suche ersetzt Einsicht, Zerlegung ersetzt Horizont, Banking ersetzt Präsenz, Messung ersetzt Metakognition, die Generator-Verifier-Lücke hält die Maschine am Laufen), wobei der Mensch an den beiden Spezifikations-Gates die „Frontier"-Ebene bleibt. Roter Faden der Serie: „Vertrauen durch Struktur ersetzen, und Struktur durch Messung."
Fundierter technischer Leitfaden (Blog der Agentur Lushbinary) zum **Loop Engineering**: Gestaltung der Systeme, die Coding-Agenten in einer Schleife steuern, statt sie manuell zu prompten. Behandelt die Genealogie Prompt → Context → Loop Engineering, die Ralph-Technik (Geoffrey Huntley), die **fünf Bausteine + Memory** einer Loop, ihre Umsetzung in Claude Code und OpenAI Codex, das Schreiben überprüfbarer Abbruchbedingungen, eine Reifegradskala für die Einführung sowie die Risiken, die mit zunehmender Ausgereiftheit der Loops zunehmen. Bereich: agentisches Software-Engineering, Coding-Agenten, Harness/Orchestrierung.
Sonntäglicher Tüftler-Beitrag von **Mark Dembo** (Head of Solutions, Developer Platform & AI bei **Cloudflare**), veröffentlicht am **7. Juni 2026** auf seinem persönlichen Blog. **Erzählung**: Inspiriert von **Steve Ruiz** kauft sich der Autor ein kleines Gerät **M5Stack Stick 3** (~30 €) und baut sich, die Veröffentlichung von **Opus 4.8** nutzend, einen **DIY-KI-Agenten** „aus reiner Neugier, ohne Ziel". **Iteration 1 (45 Min.)**: Er wirft die Dokumentation des Geräts **Claude Code** vor, das Python-Skripte (~200 LOC, *„zero blast radius“*) generiert, die das Wetter in München und dann in mehreren Städten anzeigen; ein **Cloudflare Workers + Workers AI Backend** ergänzt **Text-to-Speech (TTS)**, **Push-to-Talk** (Speech-to-Text) und ein zentrales **kleines LLM** zur Beantwortung von Fragen. **Iteration 2 (ein echter Agent)**: Umstellung der REST-Endpunkte auf **WebSocket**-Transport via **Cloudflare Agents SDK** + **Dynamic Worker execution** → das Muster ***„Code Mode“*** (der Agent schreibt und führt Code aus, um seine Aufgabe zu erledigen). Der Agent beantwortet daraufhin Fragen zu öffentlichen Daten (11! = Fakultät, der Champions-League-Sieger via `fetch()` auf Wikipedia, das Wetter für eine beliebige Stadt). **Iteration 3 (echte Befugnisse)**: Verbindung zu **Todoist** über einen **MCP OAuth**-Flow → 50 Tools auf einmal, daher zwei Probleme: **Context Bloat** und **echtes Schadensrisiko**. Die Lösung stützt sich auf Cloudflares **MCP Server Portal** + die Claude-Connector-Einstellungen: pro Tool **Always allow / Ask for approval / Disable** (*Disabled*-Tools gelangen nie in den Kontext; ein **LLM-Klassifikator** akzeptiert nur eindeutige „Allow“-Freigaben und **verweigert standardmäßig**). **Erklärte Haltung**: Reduzierung seiner Rolle auf ***„idea generator, executor and judge“*** (und selten technischer Anleiter), ein „Human-in-the-Loop“-Ablauf, den er als wenig *„2026“* empfindet (Copy-Paste in UIFlow). **Was er NICHT getan hat**: keine Latenz-/Streaming-Optimierung, keine optimistischen LLM-Aufrufe, keine Evals, ***„I did not even look at the code once.“*** **Verwunderung**: 30 € + ein Anthropic-Session-Fenster + ein paar Cent Cloudflare-Inferenz → ein Objekt, das zuhört und spricht, gesteuert in natürlicher Sprache; *„the true unlock is how accessible it is.“* Scharfer Kontrast zu [[thomas-pragdave-failing-faster-code-rot-ai-velocity-2026-06-06]] (hier rechtfertigt *„zero blast radius“*, den Code nie anzusehen); illustriert konkret *Code Mode* / *„the agent just writing and executing code,“* das **MCP**-Muster ([[claude-skills-bigger-than-mcp-willison-2025-10-16]]), *Ask for approval*-artige Tool-Governance (uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21) sowie die Doktrin der *systems around the model* aus dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28.
#BYO Agent#eigene KI mitbringen#Tüfteln
**Mark Dembo** (@darkmembo / @mdembo) · **Head of Solutions – Developer Platform & AI** chez **Cloudflare** (auparavant auteur sur le blog Cloudflare). Billet personnel publié sur son blog *markpauldembo.com* le **7 juin 2026** (description : *« Thoughts about tinkering on a Sunday »*).
Beitrag von **David "Pragdave" Thomas** (Co-Autor von *The Pragmatic Programmer*, Unterzeichner des Agile Manifesto), veröffentlicht am **6. Juni 2026** in seinem Substack-Newsletter. **These**: KI schafft den Code-Verfall nicht ab, sie **beschleunigt** ihn. Bei der Erweiterung eines kleinen privaten Animations-/Grafikprojekts mit **Claude** bewegt sich der Autor von anfänglicher Begeisterung (oklch, SVG-Animationen innerhalb einer Woche ausgeliefert) zu permanenten Regressionszyklen ab der zweiten Woche. Prägnante Formulierung: Wofür Teams ***"18 Monate oder sogar mehr"*** brauchten, um zu verrotten, erreichte er in ***"18 Stunden, verteilt auf fünf Abende."*** **Grundursache**: die Aufgabe der **Code-Hygiene** (massive Duplizierung, lokale Lösungen für systemische Probleme, Überkonditionierung, Wucherung von Sonderfällen). **Verhaltensdiagnose**: LLMs optimieren auf Nutzer-Engagement und -Zufriedenheit (*"Das ist eine großartige Idee, Dave!"*) statt auf Langlebigkeit — sie sind ***"welpenhafte Junior-Entwickler, gefallsüchtig, aber ziemlich chaotisch im Umgang"***, die ständig neue Features vorschlagen und von Refactoring abhalten. **Zentrale Einsicht**: Jeder Nicht-Entwickler kann bei der *"ersten Woche"* des KI-Codings erfolgreich sein; es ist das **professionelle Urteilsvermögen** — zu wissen, wann man innehalten muss, um zu refaktorisieren —, das den erfahrenen Ingenieur vom Neuling unterscheidet. **Epigraph** (Gordon Bell): *"Jede große Computer-Katastrophe entstand dadurch, dass zu viele Ideen an einem Ort zusammengeführt wurden."* **Fazit**: ***"Es ist immer noch nur Programmierung"*** — unversorgter Code verrottet, ob in 18 Stunden oder 18 Monaten; alles, was über guten Code gelernt wurde, gilt weiterhin, der Effekt wird lediglich **verstärkt**. Konvergiert mit der Doktrin *"je schneller die Ausführung wird, desto strikter muss der Rahmen sein"* von [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], dem *"KI-unterstützte Entwicklung ist eine Falle ohne Continuous Delivery"* von [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], und dem *"KI verschiebt Engpässe, sie beseitigt sie nicht"* von dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; ein Handwerks-Gegenpol zum vibe coding von karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.
#Code-Hygiene#Code-Verfall#Code-Degradation
**David Thomas** (alias **« Pragdave »**) · co-auteur avec Andy Hunt de *The Pragmatic Programmer* (1999, éd. 20e anniversaire 2019) · co-fondateur de **The Pragmatic Bookshelf** et l'un des **17 signataires du Manifeste Agile** (2001). Figure historique du *software craftsmanship*. Billet publié le **6 juin 2026** sur sa newsletter Substack *articles.pragdave.me*.
Fachbeitrag des Teams **Data Science & Data Engineering** von Anthropic (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry), veröffentlicht am **3. Juni 2026** im Anthropic-Blog (Kategorie *Enterprise AI*, Schwerpunkt **Claude Code**). **Kernergebnis**: ***"95% of business analytics queries are automated by Claude, with ~95% accuracy in aggregate"*** (bis zu **~99%** in bestimmten Domänen). **Kernproblem**: Analytics ist **kein** Code — *"there's often only a single correct answer using a single correct source"* — es erfordert, **eine Nutzerfrage auf präzise, aktuelle Entitäten** im Datenmodell abzubilden. Drei **Fehlermodi**: (1) **Ambiguität zwischen Konzept und Entität** (z. B. *"active users"*: welche Aktionen? Betrüger ausschließen? welches Zeitfenster?); (2) **Veralterung (Staleness)** (Assets und das Wissen des Agenten werden *"subtly wrong"*); (3) **Retrieval-Fehler** (*"80% of failed queries had the information present in the corpus"*, aber nicht auffindbar). **Lösung = ein 4-schichtiger "agentic analytics stack"**: (L1) **Data foundations** — dimensionale Modellierung, **kanonische Datensätze** *"single source-of-truth"*, Metadaten *"as a first-class product"*, Integrität via CI/CD; (L2) **Sources of truth** in absteigender Vertrauensreihenfolge — **semantic layer** (der Agent ist *"structurally required (by skill instruction) to leverage the semantic layer first"*), Lineage-Graph, **Query-Korpus** (destilliert in strukturierte Dokumente, **nicht** rohes Retrieval), Geschäftskontext (Knowledge Graph: Roadmaps, Entscheidungsprotokolle, Organisation); (L3) **Skills** — der entscheidende Hebel: ***"without skills … didn't exceed 21% … Adding skills gets these numbers consistently above 95%"***; strukturiert **in Paaren** (*Knowledge skill* = Router zu ~30 Referenzdateien; *Unbook skill* = Workflow eines Senior-Analysten: klären → Quellen finden → ausführen → **adversarial review**); Wartung **kolokiert** (*"a code-review hook flags any reporting-model change that doesn't touch a skill file"* → **~90% der Daten-PRs enthalten eine Skill-Änderung**); (L4) **Validation** — Offline-Evals (Schwellenwert ~90% zur Freigabe eines Agenten, Ziel ~100%), **Ablation-Testing** (bemerkenswertes negatives Ergebnis: rohes Grep über tausende SQL-Dateien → Genauigkeit bewegt sich *"less than a point"*), Online (Adversarial Review: **+6% Genauigkeit, +32% Tokens, +72% Latenz**), **Provenance-Footer** (Quellenstufe + Aktualität + Ownership), **aktives Correction Harvesting** (geplante Agenten durchsuchen Kanäle, um Markdown-Korrekturen zu entwerfen). **Strategische Erkenntnis**: *"documentation generated, definitions owned by humans"* — dem LLM zu überlassen, Metriken zu **definieren**, war *"net-negative"*. **Minimaler Startpunkt**: eine Handvoll kanonischer Datensätze + einige Dutzend Evals + ein *thin knowledge skill* erfassen *"most of the upside"*. Starke Konvergenz mit [[shihipar-claude-code-lessons-building-skills-2026-06-03]] (Skills = Ordner, Gotchas, Hooks), der Doktrin *systems around the model* von [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], dem **semantic layer / Ontologie**-Ansatz von talisman-modern-data-101-ontology-pipeline-refresh-2026-05-04 und seale-semantic-agent-model-harness-ontology-data-2026-04-17, dem *context development lifecycle* von debois-tessl-context-development-lifecycle-ai-coding-agents-2026-02-19 sowie der UDA/Knowledge-Graph von netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12.
#self-service analytics#agentic data analytics#Claude Code
**Chen Chang · Clement Peng · Justin Leder · Johanne Jiao · Josh Cherry** — équipe **Data Science & Data Engineering d'Anthropic**. Article publié le **3 juin 2026** sur le blog Anthropic (claude.com/blog) · catégorie *Enterprise AI* · ~5 min de lecture.
Blogbeitrag von **Anthropic / claude.com** von **Thariq Shihipar** (Member of Technical Staff, Claude Code-Team), veröffentlicht am **3. Juni 2026**, der Anthropics **interne Erfahrung** bei der Konzeption und Nutzung von **Skills** destilliert. **Rahmenthese**: Ein Skill ist keine einfache Markdown-Datei, sondern ein **Ordner** (Anweisungen + Skripte + Ressourcen + Konfiguration + Hooks), den der Agent **entdeckt und bearbeitet**; *« Man sollte das gesamte Dateisystem als eine Form von Context Engineering und progressiver Offenlegung betrachten. »* Der Artikel liefert zwei strukturierende Beiträge. **(A) Eine Taxonomie von 9 bei Anthropic beobachteten Skill-Kategorien**: (1) **Library/API Reference** (Dokumentation für interne Bibliotheken/CLIs mit *Gotchas* — z. B. `billing-lib`, `internal-platform-cli`, `sandbox-proxy`); (2) **Product Verification** (Testing/Verifikation via Playwright oder tmux — `signup-flow-driver`, `checkout-verifier`, `tmux-cli-driver`); (3) **Data Fetching & Analysis** (Zugriff auf Daten-/Monitoring-Stacks — `funnel-query`, `cohort-compare`, `grafana`, `datadog`); (4) **Business Process Automation** (wiederkehrende Workflows — `standup-post`, `weekly-recap`, `create-<ticket>-ticket`); (5) **Code Scaffolding** (Framework-Boilerplate — `new-migration`, `create-app`); (6) **Code Quality & Review** (`adversarial-review`, `code-style`, `testing-practices`); (7) **CI/CD & Deployment** (`babysit-pr`, `deploy-<service>`, `cherry-pick-prod`); (8) **Runbooks** (Multi-Tool-Diagnosen — `<service>-debugging`, `oncall-runner`, `log-correlator`); (9) **Infrastructure Operations** (Wartung mit Schutzmechanismen — `<resource>-orphans`, `cost-investigation`). **(B) Eine Reihe von Best Practices**: Nicht das Offensichtliche wiederholen (*« Claude weiß bereits, wie man programmiert, und kann die Codebasis lesen »* → auf das zielen, was dem Standardverhalten widerspricht); den **Gotchas-Abschnitt** verfeinern (*« der Inhalt mit dem höchsten Signalwert in jedem Skill »*); **progressive Offenlegung** über den Dateibaum (je nach Situation auf Referenzdateien verweisen, statt alles im Voraus zu laden); **für das Modell geschriebene Beschreibungen** (*« das Beschreibungsfeld ist keine Zusammenfassung, sondern eine Beschreibung, wann dieser Skill ausgelöst werden soll »*); **Setup-Abläufe** (Konfiguration in `config.json`, andernfalls Abfrage via `AskUserQuestion`); **persistenter Speicher** (Append-only-Logs / JSON über die Variable `${CLAUDE_PLUGIN_DATA}`); **Hilfsskripte** (*« erlaubt es Claude, seine Turns auf Komposition zu verwenden … statt Boilerplate neu zu konstruieren »*); **hooks conditionnels** (nur für die Dauer des Skills aktiviert — z. B. ein Sicherheits-Hook, der destruktive Befehle blockiert). **Verbreitung bei Anthropic**: Skills werden in `./.claude/skills` gespeichert, informell über Slack in einem Sandbox-Ordner geteilt und dann per **PR** in den internen **Marketplace** überführt, sobald sie an Zugkraft gewinnen; **Nutzungsmessung** über einen **hook PreToolUse**, der Aufrufe protokolliert (und so populäre gegenüber wenig genutzten Skills sichtbar macht). Direkte Fortsetzung der Fiche [[shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10]] (gleicher Autor) und konkrete Ergänzung zu den Skills-Fiches von Anthropic/Willison/Vincent sowie zum Harness Engineering.
#Skills#Claude Code#Anthropic
**Thariq Shihipar** (Member of Technical Staff chez Anthropic, équipe **Claude Code** ; @trq212 / @trq sur X, thariqs.github.io) · pour le blog **claude.com**. Même auteur que la fiche *Using Claude Code: The Unreasonable Effectiveness of HTML* (2026-05-10). Publié le **3 juin 2026**.
Guide des Medienunternehmens **Every** (every.to/guides), veröffentlicht am **2. Juni 2026** und mitunterzeichnet von **Mike Taylor, Laura Entis und Claude**, der eine **8-Stufen-Reifegradskala für die KI-Einführung** vorschlägt. **Kernthese**: Die Einführung von KI **ist kein Wettlauf um maximale Ausgereiftheit** — ***„eine höhere Stufe ist nicht zwangsläufig besser“*** ; man muss die Stufe identifizieren, die **zum eigenen Workflow und Vertrauensniveau passt**, und dann regelmäßig neu bewerten, ob ein Aufstieg um eine Stufe **echten Mehrwert** bringt. ***„Der beste Weg, in KI einen Nutzen zu finden, besteht darin, sie so einzusetzen, dass sie zur eigenen Arbeit passt.“*** **Strukturierende Achse**: Auf jeder Stufe *„delegiert man mehr von seiner Arbeit an die KI – und bringt ihr mehr Vertrauen entgegen“* (zunehmende Delegation + Vertrauen). **Die 8 Stufen**: **(1) Chatbot** — Konversationsschnittstelle ohne eingebetteten Kontext (ChatGPT, Claude, Gemini); **(2) Copilot** — in den Arbeitsbereich eingebettete KI mit Zugriff auf die aktuelle Datei (Cursor, Claude in Excel, Gemini in Docs); **(3) Agent** — reaktives System, das Schritt für Schritt ausführt und dabei um Freigabe bittet (Cowork, Codex); **(4) Autopilot** — man beschreibt das **Ergebnis**, und der Agent führt es eigenständig aus; überprüft wird nur das **Endergebnis** (Lovable, Codex, Claude Code; verbunden mit *vibe coding*); **(5) Workflows** — Engineers bauen **Harnesses** rund um Agenten (Planung, Review, Vertrauensprüfungen, Guardrails; Compound engineering, Claude Workflows, Copilot AI Studio; Übergang von einmaligem vibe coding → **agentic engineering**); **(6) Assistent** — **proaktive, dauerhaft aktive** Agenten, die einen Bereich überwachen und Informationen liefern, ohne dazu aufgefordert zu werden (OpenClaw, Hermes Agent, Claude Managed Agents; z. B. `heartbeat.md` alle 30 Minuten); **(7) Multi-Agent** — gleichzeitige Verwaltung **mehrerer langlaufender Agenten** mit unterschiedlichen Rollen (Claude Managed Agents, OpenClaw, Codex Goals; *„eindeutig im Bereich des Senior Engineering“*); **(8) Orchestrator** — ein **Agent-Manager** leitet ein Team von Sub-Agenten (Planung, Delegation, Überwachung, Konsolidierung; Gas Town, Paperclip, Symphony/OpenAI; *„hochgradig experimentell“* — selbst führende Engineers übernehmen diese Rolle). **Sweet Spots nach Rolle**: **Wissensarbeiter** bewegen sich typischerweise zwischen den Stufen **1-4**, **Engineers** zwischen **5-8**. **Kanonische Parallele zur Einarbeitung eines Praktikanten**: *„Rechnen Sie damit, einen ähnlichen Aufwand in Ihre Agenten zu investieren, bevor Sie ihnen vertrauen können … auf der nächsten Autonomiestufe“* ; sowie der Kennsatz ***„Sie würden nicht damit prahlen, acht Praktikanten über Nacht an einem Schlüsselprojekt arbeiten lassen zu haben, ohne deren Ergebnisse geprüft zu haben.“*** Die richtige Stufe hängt von **4 Kriterien** ab: Qualität der Ergebnisse, Kosten, Zuverlässigkeit (Vertrauenswürdigkeit), Tragweite eines Scheiterns; und die **Modellfähigkeit** verschiebt schrittweise die als „sicher“ geltende Autonomiestufe. Ein Framework, das sich direkt nutzen lässt, um auf der Beratungsseite eine **Einführungsdoktrin** zu strukturieren. Konvergenz mit *Systemen rund um das Modell* (Dropbox/Okumura), *harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines) und der Doktrin des *Agent-Managers* (BFM/Girard).
#KI-Einführung#Reifegradskala#acht Stufen
**Mike Taylor** · **Laura Entis** et **Claude** (co-auteurs déclarés) · pour **Every** (every.to) · rubrique *Guides*. Mike Taylor est un auteur connu sur les sujets prompt/AI (co-auteur de *Prompt Engineering for Generative AI*) ; Laura Entis est journaliste/éditrice. La co-signature explicite de **Claude** comme auteur fait partie du positionnement éditorial d'Every (entreprise AI-native). Publié le **2 juin 2026**.
Meinungsbeitrag von **Olivier Rafal** (Consulting Director Strategy, **WeNvision** — Gruppe **SFEIR**; ehemaliger Chefredakteur von *Le Monde Informatique*), veröffentlicht am **1. Juni 2026** auf **CIO-Online**, aufgebaut um ein **Paradox**: im Zeitalter der KI **verändert sich alles … und nichts verändert sich** im Software Engineering. **Was sich verändert, ist das Betriebsmodell.** Die Rollen werden neu definiert: Der **Product Owner** wechselt vom Backlog-Zerlegen zum **Generieren von für KI nutzbarem Kontext**; der **Entwickler** wechselt vom Codeschreiben zum **Rahmen, Steuern und Überprüfen** der Agentenausführung; **QA** erhält die Fähigkeit, den **erwarteten Nachweis** im Voraus zu definieren. Die Teamstruktur wandelt sich von *„double pizza teams“* (Übergabeketten von ca. 8 Personen) zu ***„sandwich teams“***: einer **engen Paarung aus einem Fachexperten und einem Tech Lead, beide KI-unterstützt**, mit weiteren Kompetenzen als Unterstützung. Interne Zahl von **Sfeir**: *„dieses Duo steuert nun etwa 80 % der Produktionskette“*, die verbleibenden ca. 20 % (Architektur, Data Governance, Sicherheit) werden zentralisiert. Schlüsselzitat: ***„Es ist kein Werkzeugproblem, es ist ein Problem des Betriebsmodells.“*** **Was sich nicht verändert, ist die Disziplin des Zyklus.** Die **SDLC**-Phasen (definieren → bauen → verifizieren → bereitstellen → warten) bleiben identisch und nicht verhandelbar; KI hebt keine von ihnen auf, sie **verschärft** sie: ***„aller Spielraum, den das menschliche Tempo früher – wenn auch unvollkommen – absorbiert hat, wird bei KI-Geschwindigkeit zu Fehlern von industrieller Tragweite“*** (eine Metapher aus dem Amateur- versus Profisport). Daraus ergeben sich **drei unverletzliche *Gates*** (menschliche Kontrolle): **Spezifikation, Planung, Delivery-Review**; Validierung **durch Nachweis** (nicht durch die eigenen Behauptungen der KI); **systematische Kapitalisierung** (jeder Zyklus speist den nächsten) → gemessenes Ergebnis: **−30 % Korrekturiterationen nach ca. 10 Zyklen**. Prinzip: ***„je schneller die Ausführung, desto strikter muss der Rahmen sein.“*** Herangezogene Konzepte: **harness** (an den Kontext angepasste agentische Regeln), **vibe-coding**, das als **im Unternehmen nicht haltbar** eingestuft wird. **Dritte Säule = Governance, FinOps & wertorientiertes Management**: **variable und wiederkehrende** KI-Kosten (~**10 €/Stunde** pro augmentierter Rolle), Wechsel von Pauschallizenzierung zu nutzungsbasierter Abrechnung (eine Parallele zur Cloud der 2010er-Jahre); **FinOps** zielt nicht auf Kostensenkung, sondern darauf, *„die Werkzeugeffizienz zu optimieren“* (Kosten im Verhältnis zum Wert); vorab abgestimmte **Geschäftskennzahlen** (Time-to-Market, Funktionsumfang, Performance, Eco-Design). **Fazit**: Die Beschleunigung macht die Grundlagen **nicht verhandelbar**; die Herausforderung ist **organisatorisch und kulturell**, nicht technologisch – ohne Absicherung der Business-Beziehung und kollektiver Disziplin **verstärkt** ein KI-gestützter SDLC nur die Probleme (schneller gegen die Wand fahren). Erweitert die WeNvision-Doktrin aus [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] und [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]]; trifft sich mit *systems around the model* dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28, *harness engineering* osmani-agent-harness-engineering-2026-04-19, agentischem Salesforce und der Debatte um den *agent manager* (BFM/Girard, SFEIR).
#Software Engineering#KI#alles verändert sich nichts verändert sich
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (groupe **SFEIR**). Ancien **rédacteur en chef du *Monde Informatique*** · et auparavant consultant analyste du marché IT (~10 ans). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Publié le **1er juin 2026**.
Beitrag aus dem **Dropbox Tech Blog** (Bereich *culture*), veröffentlicht am **28. Mai 2026** von **Kazuaki Okumura** (Dropbox, Rolle im Artikel nicht näher spezifiziert), als Rückblick auf einen Vortrag auf der Konferenz **DX Annual 2026** (Developer Productivity). **Kernthese**: Engineering-Produktivität muss über die *Code-Generierung* hinausgehen. *« Accelerating code generation simply shifted some bottlenecks downstream »* — KI hat den Code-Durchsatz massiv erhöht, aber *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. Die eigentliche Herausforderung besteht nicht mehr darin, schneller Code zu schreiben, sondern den gesamten SDLC in die Lage zu versetzen, ein deutlich größeres Volumen **sicher aufzunehmen, zu validieren und auszuliefern**. **Vom Copilot zum Agenten**: Die erste Welle (Code-Erklärung, Snippets, Q&A) fungierte *« as copilots alongside the engineer »*; der Agent hingegen *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — wobei der Engineer weiterhin *« accountable for intent, architecture, quality, and release decisions »* bleibt (mehr Parallelarbeit, mehr Optionen, Auslagerung repetitiver Ausführung). **Nova** = Dropboxs **interne** Coding-Agent-Plattform: eine Aufgabe in natürlicher Sprache beschreiben, Ausführung in einer kontrollierten Umgebung mit Codebase-Kontext. Zentraler Datenpunkt: ***« Nova's value comes less from the model itself than the systems surrounding it »*** (Codebase-Kontext, interne Praktiken, sichere Ausführung, Workflow-Integration, menschliche Prüfung); Nova macht heute **rund 1 von 12 PRs bei Dropbox** aus (wachsende Adoption) und erstreckt sich über Features hinaus auf **Migrationen, Behebung flakiger Tests, Bug-Untersuchung, Dependency-Updates** (Arbeit mit hohem Aufwand/geringem Mehrwert). **Produktgeschwindigkeit messen, nicht Code-Output**: *PR-Durchsatz*, ein nützliches Signal, solange die Coding-Geschwindigkeit der limitierende Faktor war, *« was no longer sufficient »*. Ein **vierstufiges** Messmodell: ***Fuel*** (werden KI-Tools genutzt?) → ***Adoption*** (wie verändern sich die Workflows teamübergreifend) → ***Output*** (trägt KI zur Produktionsarbeit bei?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Erfasste Qualitätssignale: **Durchlaufzeit des Code-Reviews, Erfolgsquote von Tests im ersten Durchlauf, Fehlerquote, Nacharbeitsquote**. *« Quality and trust matter as much as speed »* — der Kern des Wandels: *« moving from local activity metrics toward broader system outcomes »*. **Auch die Workflows müssen sich weiterentwickeln**: Dies ist *« not just a tooling shift »*, sondern eine Veränderung des **Betriebsmodells** — die Rolle des Engineers verschiebt sich hin zu *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. **Enablement** ist ebenso entscheidend wie das Tool selbst (praktisches Lernen, Hackathons, Workflow-Spotlights, Bootcamps, von Peers geleitete Beispiele); die Adoption verläuft teamübergreifend unterschiedlich schnell; *« The goal is not to force every workflow through an agent »* — das Ziel ist, es dort *« useful, safe, measurable, and repeatable where it creates meaningful leverage »* zu machen. **Erkenntnisse**: ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (stromabwärts: Review, Validierung, Testing, Release, Produktionsbetrieb) → die Optimierung des alten Engpasses erzeugt nicht mehr denselben Hebel. *« The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models: context, internal tooling, quality controls, and the workflows that connect them together. »* Der Druck baut sich auch **stromaufwärts** auf (Produkt & Design): strukturierte Specs, Design-Klarheit, schärfere Problemformulierung. Schluss: ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »***; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Direkte Konvergenz mit **Salesforce/Tallapragada** (Effective Output: Wert statt Volumen messen; kein Trade-off zwischen Geschwindigkeit und Qualität), **Gupta** (Token-zu-Outcome-Zuordnung, Kosten eines abgeschlossenen Outcomes), **DORA** (jenseits des Durchsatzes) und die Verschiebung des KPI hin zum **System-Outcome** (Idee→Kundennutzen).
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.
Offizieller **Salesforce News**-Blogbeitrag (Rubrik *Agentic Enterprise*, Reihe *„Pioneering the Agentic Shift Within Salesforce Engineering“*), veröffentlicht am **27. Mai 2026** (6 Minuten Lesezeit) von **Srinivas „Srini“ Tallapragada**, *President and Chief Engineering and Customer Success Officer* bei Salesforce. Direkte Fortsetzung eines früheren Beitrags (*„How we got our engineers to use AI — without breaking everything“*), der das Überschreiten von **>90 % Adoption** schilderte. **Kernthese**: Salesforce Engineering ist von einer Welt, in der KI ein nützlicher *Copilot* war, zu einer Welt übergegangen, in der **agentische Tools den Software-Entwicklungszyklus (SDLC) selbst steuern** — Code schreiben, PRs reviewen, Tests generieren, Dokumentation aktualisieren, Deployments verwalten, Arbeit koordinieren, die früher über menschliche Übergaben lief. **Kanonische Signalentscheidung**: unternehmensweite Standardisierung auf **Claude Code** + ***„we removed all token limits“*** — *„remove every last piece of friction between our engineers and the tools that make them faster and more effective“*. **Zentrales empirisches Ergebnis** (April 2026 vs. April 2025): abgeschlossene Arbeitspakete pro Entwickler **+50,8 %**, gemergte PRs pro Entwickler **+79 %**, und vor allem der **Effective-Output-Score** (ein ML-Maß für den **realen Wert des gelieferten Codes**, nicht dessen Volumen) **+151,3 % im Jahresvergleich**. **Vorzeige-Anwendungsfall**: Migration von **33 API-Endpunkten** auf eine Cloud-native Architektur, auf dem klassischen Weg geschätzt auf **~231 Personentage** (7 pro API), abgeschlossen in **13 Tagen — 18-mal schneller** — mittels eines **regelbasierten, in Claude gebauten Frameworks** (Markdown-Dateien + Referenzimplementierungen), wobei PR-Feedback laufend in das Regelwerk zurückgespeist wurde, **autonome LLM-Loops (build, fix, validate)** ohne manuellen Eingriff, parallelisiert über isolierte Umgebungen → **5 PRs**, wobei der größte **21 Endpunkte mit 100 % Testabdeckung** lieferte. **Kein Zielkonflikt zwischen Geschwindigkeit und Qualität**: über die Plattform **Engineering 360** (die Engineering-Daten aus Hunderten von Systemen zentralisiert) **sinkt die Gesamtzahl der Incidents um 5 %**, trotz der steigenden Zahl an PRs (*„quality doesn't suffer from speed. It benefits from it“*), dank **strukturell eingebetteter Sicherheits-Leitplanken und Qualitätsstandards** im agentischen Workflow (Trust als Wert Nr. 1). **SDLC-Überholung**: sobald KI eingeführt ist, **reißen die Ingenieure Workflows ein und bauen sie neu auf** (welche Prozesse lassen sich eliminieren? welche Übergaben sind jetzt überflüssig? wo erledigt noch ein Mensch Arbeit, die ein Agent übernehmen könnte?). **Neues Ingenieurshandwerk**: **Claude-Code-Skills** (paketierte, wiederverwendbare Fähigkeiten, die Teamkontext, Namenskonventionen, Muster kodieren) werden zu einem gemeinsamen, komponierbaren **Engineering-Artefakt**; **AI Expert Suite** + **Salesforce Foundation Plugins** = eine institutionalisierte, kuratierte Skill-Bibliothek (interner Benchmark: **höhere Genauigkeit und Zuverlässigkeit, weniger unnötige Kosten**); **Subagents & Agent-Teams** parallelisieren Arbeitsstränge (*„They describe the outcome, and a set of coordinated agents figures out the steps“*). **Was weiterhin schwierig bleibt**: (1) **Kontextmanagement** in langen Sessions — die **Qualität der CLAUDE.md-Datei** schwankt stark und wirkt sich erheblich auf die Output-Qualität aus; (2) **agentische Sicherheit** = ein grundlegend anderes Modell (Agenten, die *handeln*, nicht nur *vorschlagen* → größerer Blast Radius); (3) **sich wandelnde Rollen** (wie werden Junior- zu Senior-Ingenieuren, wenn KI die Einstiegsarbeit übernimmt? Rolle von Designer/PM? die Ausführungseinheit = Scrum-Team → Experimente mit Einheiten aus 1 oder 3 Personen). Fazit: *„It changed what was economically possible“*; die erklärte Ambition lautet **„the most automated, agentic SDLC in the industry“**. Berührt sich direkt mit Gupta (*Kosten eines abgeschlossenen Outcomes*, Grenznutzen des Tokens), Greenwald/Sierra (outcome-basierte Preisgestaltung), DORA (ROI / Kosten pro Feature) und der BFM/Girard-Debatte (Token als Wert-Treibstoff, nicht als zu kürzende Kostenposition).
#Agentischer SDLC#agentischer SDLC#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
Blogbeitrag von **Zed**, verfasst von **Franciska Dethlefsen** (Head of Growth and Marketing), veröffentlicht am **14. Mai 2026** — am Tag nach Anthropics Ankündigung —, um Fragen der Zed-Nutzer zu beantworten. **Thema**: Ab dem **15. Juni** teilt Anthropic die Abrechnung des Claude-Abonnements in **zwei Pools** auf — einen für die **First-Party-Tools** (Chat, die offizielle Claude Code CLI), den anderen für **Drittanbieter-Agenten- und SDK-Nutzung** (alles, was über **ACP**, `claude -p` oder ein Drittanbieter-Tool läuft). Die Nutzung über ACP **zieht dann nicht mehr von den Pro- oder Max-Limits ab** und wechselt zu einem monatlichen **"Agent SDK"-Guthaben**: **20 $ für Pro, 100 $ für Max 5x, 200 $ für Max 20x**. Ist das Guthaben aufgebraucht, läuft die Nutzung **zu Standard-API-Preisen** weiter, sofern Overage aktiviert ist — andernfalls stoppen die Anfragen bis zum nächsten Zyklus. **Die für den Artikel entscheidende Zahl**: Abonnements hatten die agentische Nutzung bis dahin um den Faktor **≈15 bis 30×** gegenüber den API-Preisen subventioniert, und die neuen Guthaben werden **zu vollen API-Sätzen** abgerechnet — daher *„für alle, die Agenten intensiv nutzen, ist dies ein erheblicher Kostenanstieg"*. **Es werden drei Optionen vorgeschlagen**, in einer Reihenfolge, die Zeds Haltung offenbart: (1) das Abonnement behalten, indem man die **offizielle `claude`-CLI im Terminal innerhalb von Zed** statt über ACP ausführt — *„wenn die offizielle claude-CLI im Terminal läuft, nutzt sie die Limits deines Abonnements, nicht das neue Guthaben"*; (2) Zeds integrierten Agenten mit dem Anbieter eigener Wahl nutzen (von Zed gehostete Modelle, API-Schlüssel, Copilot, lokales Ollama, DeepSeek); (3) **einen beliebigen ACP-Agenten** einbinden — OpenCode, Codex, Factory, Cursor —, von denen mehrere weiterhin ratenlimitierte Abonnements anbieten, die eine intensive Nutzung subventionieren. **Die zugrunde liegende These**, und der eigentliche Grund für den Beitrag: *„ACP ist ein offenes Protokoll … damit dein Editor niemals an die Preisentscheidungen eines einzelnen Anbieters gebunden ist"*, mit der expliziten Erwartung, dass *„diese Art von Änderung nicht die letzte sein wird"*. **Der Beitrag trägt ein auf den 16. Juni 2026 datiertes Addendum**, das ankündigt, dass **die Änderung ausgesetzt wird**: ACP, `claude -p`, das Agent SDK und Drittanbieter-Anwendungen funktionieren **wie zuvor** mit Abonnements weiter, kein separates Guthaben ist zu beanspruchen, die Limits bleiben unverändert, Anthropic überarbeite seinen Plan mit angekündigter Vorlaufzeit. **Das Artefakt widerspricht sich damit selbst**: sein wichtigster Inhalt — die Rücknahme — datiert einen Monat nach seinem eigenen Veröffentlichungsdatum.
#Zed#Anthropic#Claude-Abonnement
**Franciska Dethlefsen** — head of growth and marketing chez **Zed Industries**. Le rôle est déterminant pour lire le texte : ce n'est pas un billet d'ingénierie mais une **communication de crise produit** · écrite le lendemain d'une annonce d'un fournisseur dont Zed dépend · à destination d'utilisateurs inquiets. La signature growth/marketing explique la structure (problème → options → réassurance) et le fait que l'argument protocolaire arrive en conclusion plutôt qu'en tête.
Continuous Delivery als nicht verhandelbare Grundlage KI-gestützter Softwareentwicklung — Dave Farley argumentiert auf seinem Kanal *Modern Software Engineering*, dass KI ohne CD kein Beschleuniger, sondern eine Falle ist (Theory of Constraints und Jevons-Paradoxon angewandt auf generierten Code, ATDD/BDD als Absicherung, Deployment-Pipeline als Qualitätsschiedsrichter).
#Continuous Delivery#Generative KI im SDLC#ATDD (Acceptance Test-Driven Development)
Dave Farley (Modern Software Engineering — YouTube channel)
Manifest-artiger Artikel von **Thariq Shihipar** (Engineer & Serial Entrepreneur, Claude Code Team bei Anthropic), der eine **Änderung des Standard-Ausgabeformats für Agenten** ankündigt: die Ablösung von **Markdown durch HTML**. These: Markdown war das dominante Format zwischen Menschen und Agenten (einfach, portabel, editierbar, lesbar), ist aber zu **einem Engpass** geworden, da Agenten längere und reichhaltigere Artefakte produzieren (Specs, Pläne, Berichte, Code-Reviews). Jenseits von ca. 100 Zeilen liest niemand mehr eine Markdown-Datei. HTML löst sechs Einschränkungen gleichzeitig: **Informationsdichte** (Tabellen, CSS, SVG, Skripte, Canvas, Bilder), **visuelle Klarheit** (navigierbares, mobil-responsives Layout), **einfaches Teilen** (ein S3-Link, direkt im Browser öffenbar), **bidirektionale Interaktivität** (Schieberegler, Regler, „Copy as JSON/Prompt“-Buttons zur Rückkopplung in Claude Code), **native kontextuelle Aufnahme** (Claude Code liest die Codebasis + MCP Slack/Linear + Git-Historie + Chrome) und **Freude an der Nutzung** (der Autor stellt ausdrücklich fest: *„it's joyful“*). Fünf kanonische Anwendungen im Detail: (1) **Specs/Pläne/Exploration** in einem vergleichenden Raster, (2) **PR-Review** mit inline annotiertem Diff, (3) **Design & Prototypen** mit Animations-Schiebereglern, (4) **Berichte/Recherche/Lernen** (der Autor ließ einen Prompt-Caching-Explainer aus der Git-Historie generieren), (5) **maßgeschneiderte Wegwerf-Editoren** (Drag-and-Drop von Linear-Tickets, Feature-Flag-Editoren, Side-by-Side-Prompt-Tuner), die einen re-injizierbaren „Copy as Markdown/Diff/JSON“-Export erzeugen. Explizites Anti-Pattern: *„I'm a little bit afraid that people will read this article and turn it into a /html skill“* — der Autor **lehnt eine vorschnelle Skill-ifizierung ab** und empfiehlt stattdessen Prompting von Grund auf („make a HTML file“). Pragmatisches FAQ: Token-Kosten werden durch den 1-Mio.-Kontext von **Opus 4.7** absorbiert, 2-4× längere Generierungszeit, verrauschte HTML-Diffs (ein realer Nachteil), Stil wird über ein HTML-Referenz-Designsystem im Zaum gehalten.
#HTML#Markdown#Ausgabeformat
Thariq Shihipar (Engineer & serial entrepreneur, équipe Claude Code chez Anthropic — site : thariqs.github.io/html-effectiveness ; X : @trq212)
Leitartikel von Andrew Ng in The Batch n°352 vom 8. Mai 2026 — **„There Will Be No AI Jobpocalypse"** —, der die Erzählung einer durch KI verursachten Massenarbeitslosigkeit widerlegt und sich dabei auf die **gesunde Arbeitslosenquote von 4,3 %** in den USA sowie eine robuste Einstellungstätigkeit im Tech-Sektor stützt. Ng identifiziert **drei Treiber** der Jobpocalypse-Erzählung: **(1) technologische Anreize** — KI-Labore profitieren davon, sich als transformativ-disruptiv darzustellen (Finanzierungsrunden, Bewertungen, Talente); **(2) Preissetzungsmacht** — Anbieter berechnen Unternehmenskunden **10.000 $+/Jahr**, indem sie ihre Preise **am Gehalt der ersetzten Mitarbeiterin bzw. des ersetzten Mitarbeiters** ausrichten, statt an klassischer SaaS-Preisgestaltung (pro Nutzer / pro Nutzung); **(3) Unternehmenskommunikation** — Unternehmen deuten ihre Entlassungen als *„KI-Effizienz"* um, anstatt die **Überheuerung der Pandemiezeit** von 2020–2022 einzugestehen. Ehrliches Eingeständnis: *„KI stört die Arbeitswelt"*. Doch Ng dreht dies um in **„AI Jobapalooza"** (ein Wortspiel mit Lollapalooza) — Arbeitsplatzschaffung in der KI-Entwicklung und angrenzenden Feldern mit sich wandelnden Kompetenzprofilen. Implizite Spannung mit **Amodei** (50 % der Bürojobs bis 2030 wegfallen) — Ng weist, ohne ihn zu nennen, darauf hin, dass **Anthropic davon profitiert, diese Erzählung zu befördern** (technologische Anreize). Veröffentlicht **am selben Tag** wie **Wallace-Wells' „AI Populism"-Beitrag im NYT Magazine**: eine perfekte Spiegel-Lektüre — Ng = kühle ökonomische Analyse / Wallace-Wells = populäre Panik. Preissetzungs-Konvergenz mit **Bains „100-Mrd.-$-system-übergreifende-Arbeit"**-These (gleiche These: Preisanker an Gehältern).
#Andrew Ng#The Batch#DeepLearning.AI
Andrew Ng (fondateur DeepLearning.AI, Stanford, ex-Google Brain, ex-Baidu, ex-Coursera)
Podcast von Greg Isenberg × Meng To (Designer, Gründer von Design+Code, Schöpfer der Produkte Aura / New Form / Dream Cut) über **`design.md`** — Googles Open-Source-Konvention, das Äquivalent zu `agents.md` / `skills.md` / `soul.md`, jedoch **für das Designsystem** (Typografie, Farben, Abstände, WebGL/Three.js-Animationen, Reveal-Regeln). Zentrale Idee: die „**Seele des Designs**" in einer Markdown-Datei zu tragen, die einem Agenten (Claude Code, Codex, OpenClaude, Gemini, Stitch, Aura, V0, Lovable, Cursor) übergeben wird, um **medienübergreifende Konsistenz** zu wahren (Web, Mobile, Replit slides, Hyperframes/Remotion-Motion-Design). Gelehrte Triade: **HTML = fertiges Gericht, design.md = Rezept, Skills = Zutaten** (Typografie-, Laser-, Skeuomorphic-, 3D-Skills — 63 bei New Form). Hauptdiagnose: **Design Drift** bei One-Shot-Workflows (`v0`, Lovable, Framer), die stark beginnen und dann zu generischem Output abdriften. Kernbotschaft: *Geschmack* (taste) ist der einzig verbleibende **Burggraben** — *„wenn etwas wie etwas anderes aussieht, sinkt sein Wert um das 10- bis 100-Fache"*. Workflow: **Reference → Design.md → Generate → Inspect → Systemize → Iterate (bis zu 1000+ Prompts) → Remix → Expand → Export**. Kritik an **lila Farbverläufen** („you just run") als generische Post-vibe-coding-Baseline. Meng To gibt an, ~500.000 $ für Tokens ausgegeben, 1.000–10.000 Iterationen pro Produkt durchgeführt und 4 Produkte parallel im Alleingang betrieben zu haben.
#design.md#Google#Designsystem
Greg Isenberg (host — podcast Late Checkout / The Greg Isenberg Show, 12 mai 2026 livestream workshop ideabrowser.com) ; **Meng To** (guest — designer, fondateur Design+Code 2014, créateur Aura / New Form / Dream Cut, autodidacte parti à 18 ans, dropout, francophone d'origine canadienne)
Interview mit Boris Cherny (Schöpfer von Claude Code, Anthropic) bei einer Sequoia-Veranstaltung (Moderation: Asia, Lauren Reader). Cherny erklärt ***"coding is solved"***: Er selbst hat seit Ende 2025 **0 Zeilen Code** geschrieben, das Modell schreibt **100%**, *"a few dozen PRs/day, 150 PRs in a single day record"*. Bericht über die Entstehung von Claude Code (Anthropic-Labs-Inkubator Ende 2024, Mike Krieger verantwortlich für Runde 2, Pre-PMF-Entwicklung *"for the next model"*, ein erstes Release, das nicht abhob, **exponentielles Wachstum begann mit Opus 4 im Mai 2025**, das sich mit jedem neuen Modell 4 → 4.5 → 4.6 → 4.7 beschleunigte). Aktuelles persönliches Setup: **"most of my work I do from my phone"** (iOS), 5-10 Sessions, **"a few hundred agents going, a few thousand at night"**, **`/loop` ist die Zukunft** (Cron + wiederkehrende Jobs, Agenten überwachen CI, rebasen PRs, clustern Twitter-Feedback). **Routines** = das serverseitige Äquivalent, das läuft, während der Laptop geschlossen ist. Ausblick für SaaS: keine Apokalypse, aber eine **Neuordnung von Helmers 7-Powers-Framework** (Wechselkosten ↓, Prozessmacht ↓, Netzwerkeffekte/Skalenvorteile/exklusive Ressourcen unverändert) und **10-mal mehr disruptive Startups** in den nächsten 10 Jahren. Pivot-Analogie: die **Gutenberg-Presse** (10% Alphabetisierung im 15. Jahrhundert → 70% in den folgenden Jahrhunderten, Bücher 100-mal billiger innerhalb von 50 Jahren), *"software will be similarly democratized, but faster than 50 years"* — *"the best person to write accounting software is not an engineer, it's a really good accountant."*
#Boris Cherny#Anthropic#Claude Code
Boris Cherny (créateur de Claude Code, Anthropic) interviewé par Lauren Reader (Sequoia) avec introduction d'Asia (Sequoia).
GitHub-Repo `techygarg/lattice`, das ein Framework **komponierbarer Skills** formalisiert, um eine *Engineering-Disziplin* in KI-Coding-Assistenten (Claude Code, Cursor) zu installieren. Markante dreistufige Architektur: **Atoms** (Guardrails zu Einzelprinzipien: Clean Code, DDD, Security, Testqualität, Design-First), **Molecules** (mehrstufige Workflows, die die Atoms kombinieren: Design, Implement, Refactor, Fix, Review), **Refiners** (geführte Interviews, die projektspezifische Standards erzeugen, die das Verhalten der Atoms anpassen). Operative Pipeline `lattice-init` → `design-blueprint` → `code-forge` → `review`, mit `refactor-safely` und `bug-fix` als Ablegern. Drei zentrale Prinzipien: *"Skills over prompts"*, *"Composability over monoliths"*, ***"Living context over static config"*** — der Ordner `.lattice/` wird mit jedem Feature-Zyklus intelligenter. MIT, reines Shell, 18 Stars / 52 Commits, eine Artikelserie auf martinfowler.com, die fünf *Collaboration Patterns* erläutert. Starke Konvergenz mit Vincent *Superpowers* (2026-04-02), Habert *PROJ-AI* (2026-05-05), Wescale *Usine Logicielle Augmentée* (2026-05-03) und — die höchste doktrinäre Konvergenz ohne erklärte Abstammung — **Compound Engineering** von Every (Shipper/Klaassen 2025-12-11): isomorphe Pipelines (lattice-init→design-blueprint→code-forge→review ↔ ce:brainstorm→ce:plan→ce:work→ce:review), lebendige Kontextschicht (`.lattice/` ↔ `docs/plans/+solutions/+brainstorms/`), eine gemeinsame Design-First-Haltung, verpflichtendes Review am Ende. Die *Coding-Agent-Harness*-Doktrin von 2026 konvergiert auf ein stabiles Vokabular, ohne direkte Einflussnahme.
#lattice#techygarg#composable AI skills
techygarg (auteur GitHub, identité réelle non précisée dans le README ; auteur d'une série d'articles publiée sur martinfowler.com).
Google-Whitepaper (die Folge „Day 1“ einer Reihe von Addy Osmani, Shubham Saboo und Sokratis Kartakis), das den Wandel des Software-Entwicklungszyklus (SDLC) im Zeitalter von Coding-Agenten nachzeichnet. These: Der grundlegende Wandel ist keine neue Sprache, sondern der Übergang vom Schreiben von Code zum **Ausdrücken von Absicht**. Das Dokument entwirft ein Spektrum, das von *vibe coding* (Prompten und Akzeptieren) bis zu *agentischem Engineering* reicht (die KI setzt unter von Menschen entworfenen Einschränkungen, Tests und Feedback-Schleifen um), mit **context engineering** als zentraler Fähigkeit, dem Modell der **Software-Fabrik** (das eigentliche Liefergut der Entwickler ist das System, das den Code produziert), **Harness Engineering** (Agent = Modell + Harness) sowie einer CapEx/OpEx-Wirtschaftlichkeitsanalyse der Gesamtbetriebskosten.
Interview mit Andrej Karpathy (Mitgründer von OpenAI, ehemals Tesla Autopilot) über den Übergang von *vibe coding* zu *agentic engineering*: December 2025 transition als Wendepunkt – „noch nie so sehr als Programmierer hinterhergehinkt“ –, die Taxonomie Software 1.0/2.0/3.0, das Beispiel openclaw (Bash-Skript → Text zum Kopieren in den Agenten) und MenuGen, das durch Geminis Nanobanana obsolet wird, die *Verifiability*-Theorie, die erklärt, warum LLMs *jagged* sind (Spitzenwerte bei Mathematik/Code, aber Scheitern bei „50 m zu Fuß zur Autowaschanlage“), die Unterscheidung zwischen *vibe coding* (die Einstiegshürde senken) und *agentic engineering* (den Qualitätsanspruch wahren), die Metapher „animals vs ghosts“, die Neuausrichtung der Personalauswahl über Agent-gegen-Agent-Projekte sowie die Kernformel: ***„You can outsource your thinking but you can't outsource your understanding.“***
#Andrej Karpathy#vibe coding#agentic engineering
Andrej Karpathy (co-fondateur OpenAI, ex-Tesla Autopilot, créateur du terme "vibe coding")
Manifestartiger X-Thread von Rohit (@rohit4verse), der die *2026 AI engineer roadmap* entfaltet: eine Gehaltslücke von 150.000 $ zwischen Prompt Engineer und Systems Architect, das Ende generischer *Wrapper*, die "sherlocked by big tech" seien, sowie 5 Portfolio-Projekte, gestaffelt nach Komplexitätsgrad (Offline-Mobile-SLM, selbstverbessernder Coding-Agent, multimodaler *Cursor für Videoeditoren*, Privacy-First-Agent für ein persönliches Life-OS, autonomer Agent für Enterprise-Workflows). Jedes Projekt beschreibt seine *zentralen architektonischen Entscheidungen* (Lazy Loading, Sliding Window, Sandboxing, Szenenerkennung, persönlicher Knowledge Graph, ereignisgesteuertes Multi-Agent-System, Audit Trail, RBAC, Observability). Strukturierender Slogan: *"the replaceable: building wrappers / the unfireable: shipping autonomous systems"*. Auffordernder, viraler Ton, typisch für X im Jahr 2026.
#2026 AI engineer roadmap#Rohit#rohit4verse
Rohit (@rohit4verse) — créateur de contenu IA sur X · vulgarisateur d'architecture et roadmaps de carrière en ingénierie IA.
Beitrag aus dem **Ahrefs-Blog**, veröffentlicht am **28. April 2026** von **Ryan Law** (Director of Content Marketing, Ahrefs), der ein internes **Content-Engineering**-System rund um **Claude Code** beschreibt: eine redaktionelle Pipeline, die **publikationsreife Entwürfe in 6 bis 12 Minuten** erzeugt. **Kernthese**: ***« AI content is not, by default, good. This process works well because it mirrors our existing human editorial process »*** — Qualität entsteht nicht durch das Modell, sondern durch die **getreue Nachbildung eines menschlichen Redaktionsprozesses**, der sich über Jahrzehnte bewährt hat. Architektur: **~23 skill files**, jede entspricht einem redaktionellen Schritt (Keyword-Recherche, Themenlücken-Analyse, strukturelle Gliederung, Recherche-Zusammenstellung, Entwurfserstellung, Formatierung), **orchestriert von einem übergeordneten Skill `blog-pipeline`**, der sie verkettet, um einen vollständigen Artikel zu erzeugen. **Sieben Gestaltungsprinzipien**: (1) **menschliche Arbeitsabläufe nachahmen**, indem Skills aus vorhandener Ahrefs-Redaktionsdokumentation abgeleitet und verkettet werden; (2) **jeden Schritt einzeln ausgeben** zur Fehlersuche (*« if you get an article at the end of a ten minute run, and it's bad, it's hard to diagnose precisely where and why the process went wrong »* → Zwischenergebnisse speichern); (3) **Testfälle erstellen** über Anthropics Skill `skill-creator`, um Anweisungen zu bewerten und zu verbessern; (4) **hochwertige Datenquellen einbinden** — den **Ahrefs MCP** (Keyword-Metriken, Parent Topic, Long-Tail-Themen, SERP-Übersichten, Wettbewerbsanalyse), Wettbewerbsanalysen und Produktdokumentation; (5) **menschliche Vorgaben vorab einbringen** über Kontextparameter, die redaktionelle Steuerung ermöglichen; (6) **interaktive Vorschauen** im HTML-Format zur Prüfung vor der Veröffentlichung erstellen; (7) **Anpassung erlauben** (jedes Teammitglied kann das System forken und modifizieren). **Umfang**: ~**15 veröffentlichte Artikel** und ~**30 aktualisierte Artikel** über diesen Workflow; die Entwicklung begann im **Februar 2026** (der vorherige Prozess vom **August 2025** benötigte mehrere Tage und manuelle Eingriffe). **Explizite Vorbehalte** (Anti-Übertreibung): *« experience matters »* — der Prozess spiegelt jahrzehntelange redaktionelle Expertise wider; die Themenauswahl konzentriert sich auf **informationelle SEO-Inhalte**, die der Autor gut kennt; Ahrefs **plant kein „Scaling“ der Inhalte im großen Stil**, sondern pflegt eine **evergreen** Bibliothek. Philosophie: *« the formulaic parts of work »* automatisieren, um Routinearbeit zu eliminieren und Zeit für Recherche, Thought Leadership, Webinare und Systemoptimierung freizusetzen — **nicht** menschliche Arbeit ersetzen. Als kanonische Referenz von Pasquale Pillitteri zitiert (*Opus 4.8 SEO workflow*) als Feldbeweis für den Gewinn von „6-12 min/Entwurf“. Direkte Konvergenz mit der Doktrin **skills-over-prompts** (Lattice, PROJ-AI), **Systeme rund um das Modell** (Dropbox/Okumura) und der Verwendung von **HTML als Review-Artefakt** (Shihipar).
**Ryan Law** — Director of Content Marketing chez **Ahrefs**. Praticien senior du content marketing SEO ; le billet est un retour d'expérience personnel (*« How I do… »*) publié sur le **blog Ahrefs** (ahrefs.com/blog) le **28 avril 2026**.
Das Editorial von Andrew Ng in The Batch #350 stellt eine Beschleunigungshierarchie für Coding-Agenten nach Art der Softwarearbeit auf: Frontend (maximal) > Backend (moderat) > Infrastruktur (gering) > Forschung (minimal). Die Begründung stützt sich auf die implizite Verifizierbarkeit (Beherrschung von TypeScript/JavaScript plus eine autonome Agent-Browser-Testschleife im Frontend) sowie auf die blinden Flecken der LLMs (Grenzfälle / Sicherheit / DB-Migrationen beim Backend, undurchsichtige Netzwerk-Tradeoffs bei der Infrastruktur, irreduzible Hypothesenbildung bei der Forschung). Die Ausgabe wird durch 4 einordnende Nachrichten abgerundet: GLM-5.1 (Z.ai), ein Modell mit 754B/40B aktiven Parametern unter MIT-Lizenz, das autonome Aufgaben von bis zu 8 Stunden Dauer bewältigt (Spitzenreiter bei SWE-Bench Pro mit 58,4 %); Digit (Agility Robotics) bei Schaeffler, der erste industrielle Einsatz von Humanoiden (1,75 m/65 kg, 10–25 $/h gegenüber 20 $/h für einen Menschen); die Anti-Rechenzentren-Revolte (~64 Mrd. $ blockiert zwischen Mai 2024 und März 2025, Moratorium in Maine für Anlagen ab 20 MW, Molotow-Cocktail am Wohnhaus von Sam Altman); sowie die „Assistant Axis" (Christina Lu, MATS / Oxford / Anthropic), die Persona-Drift und Jailbreaks reduziert (Qwen3 32B: 83 %→41 %; Llama 3.3 70B: 65 %→33 %), ohne IFEval/GSM8k/MMLU-Pro/EQ-Bench zu verschlechtern.
#Andrew Ng#The Batch#DeepLearning.AI
Andrew Ng (édito principal — fondateur DeepLearning.AI, Stanford, ex-Google Brain, ex-Baidu) ; rédaction The Batch (DeepLearning.AI) pour les sections actualités
Synthese von Addy Osmani (Google, Chrome/Cloud) zum aufkommenden Feld des *Harness Engineering*: die Gleichung `agent = model + harness`, das *Ratchet*-Prinzip („jeder Fehler wird zu einer Regel“), die HumanLayer-Umdeutung „skill issue“, die Terminal-Bench-Belege (Top 30 → Top 5 allein durch eine Änderung des Harness), die geschichtete Claude-Code-Architektur, Anthropics Vision „Harnesses schrumpfen nicht, sie verschieben sich“ sowie Harness-as-a-Service (Claude Agent SDK, Codex SDK, OpenAI Agents SDK). Schlüsselartikel, der Trivedy, HumanLayer, Anthropic und Böckeler zu einer Doktrin verdichtet.
#harness engineering#agent harness#Addy Osmani
Addy Osmani (Software Engineer at Google, Cloud + Gemini)
Semantischer Agent: die Symmetrie von Modell+Harness und Ontologie+Daten, der Kollaps der Agenten-Frameworks, Ontologie als einziges nicht-kommoditisierbares Asset
Öffentliches Update von Darragh Curran (F&E, Intercom) neun Monate nach seiner Zusage, die F&E-Produktivität in 12 Monaten durch KI zu verdoppeln. Ergebnis: **das 3-Fache erreicht in 16 Monaten, ohne Anzeichen einer Plateaubildung**. Quantifizierte Daten aus einer 500-köpfigen F&E-Organisation / 8,5 Mio. Zeilen Code: **93,6 % der PRs sind agentengesteuert**, **19,2 % KI-genehmigt** (Ziel > 50 %), Kosten/PR **-50 %**, Defect-Backlog **-54 %**, Time-to-Shipping **-39 %**, Ausfallzeit durch Breaking Changes **-35 %**, die Top 5 % der Performer bei **dem 6-Fachen des Median-PR-Durchsatzes**, **497 autonome PRs** in den ersten 4 Wochen, **153 Beitragende / 267 spezialisierte Skills** in einer privaten *Skills-Based Plugin Architecture*. Curran erklärt: ***„All technical work is becoming agent-first. This is the top priority for R&D.“*** Schlüsselartikel des Dossiers zur *agent-first organization*, im Korpus 2026 nur mit Stripe Minions und StrongDM vergleichbar.
#Darragh Curran#Intercom#Fin Ideas
Darragh Curran (R&D leader, Intercom — publication via Fin Ideas, plateforme média Intercom).
Rolle des Entwicklers angesichts von KI-Coding-Agenten, eintägiges Experiment mit der BMAD-Methode, Entwicklung hin zum Agent Supervisor - Technischer Blog
Anthropic-Forschung - Transformation der Arbeit durch KI - Claude Code Impact - Software-Engineering - KI-Adoption - Produktivitätsstudie - Wandel der Arbeitswelt - KI-Zusammenarbeit - Kompetenzentwicklung - Zukunft der Arbeit
#Anthropic#KI-Transformation#Auswirkungen auf die Arbeitswelt
Anthropic Research Team (132 engineers and researchers surveyed, 53 in-depth interviews conducted)
Robuste Coding Agents entwickeln, die Modellzyklen überdauern: Harness-Architektur, Codex SDK und Computer Use im Terminal — Erfahrungsbericht von OpenAI
#OpenAI#Codex#Coding Agents
Bill Chen (Product Manager, OpenAI) · Brian Fioca (Engineering, OpenAI)
Funktionaler Ansatz für generative KI in der Softwareentwicklung, 100 % generierter Code, LLM-Onboarding, atomare Aufgaben, spec-driven, kontinuierliche Kapitalisierung - Soufiane Keli - OCTO Technology - LinkedIn
Cat Wu und Boris Cherny (Anthropic) erklären, wie man Claude Code so nutzt wie seine Schöpfer: Antfooding, Plan-Modus, Subagents, Hooks und Erweiterbarkeit — Every's Podcast AI & I
#Claude Code#Cat Wu#Boris Cherny
Rhea Purohit (interviewer: Dan Shipper) · Cat Wu · Boris Cherny
VibeSDK - Open-Source-Plattform für vibe coding - Cloudflare Sandboxes - Workers for Platforms - AI Gateway - Bereitstellung mit einem Klick - Cloudflare
#VibeSDK#vibe coding#Cloudflare
Ashish Kumar Singh · Abhishek Kankani · Dina Kozlov