thekb.eu — KI-Coding-Agenten & Skills

When code is abundant

Mon, 24 Aug 2026 00:00:00 GMT

Bill Staples, CEO von GitLab, veröffentlicht am 24. August 2026 ein Essay, das ein im Januar an seinen Verwaltungsrat gerichtetes Memo sowie eine erste Veröffentlichung im Mai, *GitLab Act 2*, fortführt. Der explizite Auslöser ist das KI-native-SDLC-Playbook von Anthropic, veröffentlicht am 21. August, dem er die Eingangsbehauptung entlehnt: Code ist nicht mehr der Engpass. Seine Frage geht einen Schritt weiter: Wenn die Codeproduktion aufhört, die Einschränkung zu sein, was wird dann knapp, und welche Architektur muss ein Unternehmen haben, wenn Menschen, Agenten und mehrere Modelle gleichzeitig mit Maschinengeschwindigkeit handeln. Seine Antwort passt in einen Satz: Wenn Implementierung im Überfluss vorhanden ist, wird Vertrauen knapp. Sechzig Jahre lang hat sich Software-Engineering um eine Tatsache herum organisiert – Code ist kostbar –, aus der sich die Bewahrung von Altsystemen, die Optimierung der Entwicklerproduktivität und die Zeremonie von Reviews, Freigaben und Release-Gates ableiten. Diese Einschränkung verschiebt sich, und das um sie herum aufgebaute System wird folgen. Die von ihm vorgeschlagene ökonomische 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 den Generierungsterm kollabieren und macht die übrigen proportional entscheidend: Eine Organisation, die zehnmal schneller generiert, ohne den Rest anzufassen, verschiebt lediglich die Warteschlange. Dies ist die namentlich zitierte Theory of Constraints. Die Erfahrungen von Stripe, Spotify und Amplitude dienen als Material. Sie zeigen vor allem, wo die nächsten Engpässe wieder auftauchen: Umgebung, CI, Review und Governance. Eine dreißigminütige Pipeline, schreibt er, schlägt jedes Modell. Daraus folgt eine Architektur: drei koexistierende Entwicklungsmodi statt einer einzigen Reifekurve; die innere Schleife wandert vom Arbeitsplatz in die Pipeline, näher an das Repository heran, und erzeugt dabei Nachweise; Autonomie wird gesteuert statt gewährt, durch deterministische Gates, Isolation, Policy und Nachweise. Anschließend wird die These des Anbieters dargelegt: Das Modell ist eine austauschbare Ausführungskomponente, nicht die dauerhafte Architektur. Kontext, Identität, Policy, Herkunftsnachweis und organisatorisches Gedächtnis müssen über Modelle und Agenten hinweg bestehen bleiben, was in Richtung einer modell- und cloudneutralen Kontrollebene drängt. Der Text unterscheidet die Markdown-Datei vom steuerbaren Datensatz, argumentiert, dass der Agent dem Kunden gehören sollte, beschreibt einen PDLC, in dem Geschäftssignale zu verifizierter Software werden, und sieht die Population der Builder wachsen. Menschliches Urteilsvermögen wird währenddessen nicht im Überfluss vorhanden – es verschiebt sich nach oben, hin zu Absicht, Architektur und Ausnahmen.

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

Fri, 21 Aug 2026 00:00:00 GMT

Louis Claxton vom Applied-AI-Team von Anthropic veröffentlichte am 21. August 2026 einen Umsetzungsleitfaden für einen „KI-nativen“ Software-Entwicklungszyklus. Ausgangspunkt ist ein Ungleichgewicht: Organisationen schreiben heute Code in einer vor einem Jahr unvorstellbaren Geschwindigkeit, aber die umgebenden Prozesse — Freigabetore, Reviews, Übergaben, Richtlinien — haben sich nicht mitbewegt. Der traditionelle SDLC wurde für eine Welt konzipiert, in der das Schreiben von Code die längste und teuerste Phase war; seine Kontrollen gehen zudem davon aus, dass jede Aktion von einem Menschen ausgeführt wird. Daraus ergeben sich drei Konsequenzen. Der Engpass verschiebt sich auf die Phasen, die weiterhin mit menschlicher Geschwindigkeit ablaufen, vor und nach dem Bau. Kontrollen werden unanwendbar: Jede Zeile zu lesen ergab Sinn, solange eine Person sie geschrieben hatte. Und die Governance-Kosten steigen, da Ausnahmen über periodische Ausschüsse laufen. Die Antwort behält die Kontrollziele bei und ändert ihre Umsetzung. Der Prozess wird zu einer Schleife, mit KI an jedem Punkt eingebettet, gegliedert in sechs Phasen — Plan, Design, Build, Test, Deploy, Maintain —, aufgeteilt in *Plays*, die alle demselben Raster folgen, bis hin zu den Metriken. Der rote Faden ist das committete Artefakt. Die Absicht wird von ihrem ursprünglichen Urheber als `intent.md` festgehalten; Anforderungen und Design verschmelzen zu einer einzigen Session, die `spec.md` erzeugt, eingeschränkt durch die Skills für Marke, Sicherheit, Compliance und UX; der Bau beginnt im Plan-Modus und fixiert `plan.md`, bevor jeglicher Code geschrieben wird. Die Commit-Kette dient als Audit-Trail. Institutionelles Wissen wird zu versionierten Dateien: `CLAUDE.md` für den Repository-Kontext, Skills für übergreifende Richtlinien, `REVIEW.md` für die Review-Doktrin, `bands.yaml` für Produktionsschwellenwerte. Governance gliedert sich in zwei Schichten, wobei der Skill als beratende Kontrolle fungiert und der Hook als deterministische Schicht, die blockiert oder eine Genehmigung anfordert. Ein Beispiel für *managed settings* schlüsselt Feld für Feld auf, was jede Einstellung an Kontrolle bringt, vom Verweigern des Lesens von Secrets bis zur Durchsetzung einer Mindestversionsgrenze. Die Maintain-Phase schließt die Schleife: Ein deterministisches Skript überwacht eine Metrik, und das Überschreiten eines Bands ruft Claude ohne Menschen im Aufrufpfad auf, auf einem durch die Stufe festgelegten Autonomiegrad. Was der Agent findet, wird als `intent.md` neu formuliert und in den Zyklus zurückgespeist. Claude Tag, in öffentlicher Beta auf Slack, erweitert das Muster auf Vorfälle, die per Chat eingehen. Es werden keine quantifizierten Ergebnisse vorgelegt: Der Leitfaden liefert zu messende Metriken und benennt jeweils deren Quelle.

The Claude Code guide for startups

Thu, 20 Aug 2026 00:00:00 GMT

Michael Segner veröffentlicht am 20. August 2026 im Blog von claude.com einen Leitfaden, der aus Interviews mit mehr als einem Dutzend schnell wachsender Startups hervorgeht, fünfzehn davon namentlich genannt, zu deren Nutzung von Claude Code. Das Dokument leitet daraus fünf Betriebsregeln ab und schließt mit einer Checkliste technischer Tipps. Erste Regel, „everyone ships": Agentisches Coding senkt die Einstiegshürde, sodass die Person, die das Problem versteht, die erste Version der Korrektur ausliefern kann. Parahelp berichtet von Beiträgen nicht-technischer Mitarbeiter, Crosby von Anwälten, die die besten Produktintuitionen mitbringen, Heidi vom Verschwinden eines Stille-Post-Effekts, bei dem sich die Idee auf dem Weg vom Urheber zum Product Manager, dann zum Designer, dann zum Ingenieur abschwächte. Der Leitfaden schränkt den Geltungsbereich sofort ein: Die Arbeitsteilung bleibt bestehen, nur der Schritt von null zu eins öffnet sich. Drei Mechanismen machen dies systematisch — die Anbindung des Tools an verlässliche Quellen über MCP oder CLI, die Ritualisierung von Prototyp-Demos, das Teilen von Skills. Zweite Regel, automate the tedium: Agenten übernehmen die mechanischen achtzig Prozent des Zyklus, und Ingenieure behalten die Ermessensentscheidungen. ClickHouse gibt an, fast jeden Schritt in eine autonome Schleife verwandelt zu haben, wobei zwei Single-Purpose-Agenten zum zweit- und drittgrößten Beitragenden seines Repositorys wurden. Bei Anthropic fungiert Claude Tag als Erstreagierer im Bereitschaftsdienst für Fehler in der kontinuierlichen Integration. Dritte Regel, trust but verify: Ein Prozess wird nicht automatisiert, ohne dass es eine zuverlässige Möglichkeit gibt, ihn zu überprüfen. Cainex beschreibt bei der medizinischen Kodierung eine Selbstverbesserungsschleife, bei der Korrekturen der Prüfer in die Anweisungen des Agenten zurückfließen, getestet an einem Golden Set, unter einer einzigen Regel — das Prinzip korrigieren, nicht das Beispiel. Zingage berichtet, anfangs zu viel Autonomie gewährt zu haben und dadurch Code erhalten zu haben, der plausibel war, sich aber von der Architektur entfernte, bevor die eigenen Invarianten schriftlich festgehalten wurden. Der Leitfaden verweist für deterministische Kontrollpunkte auf hooks und betont die Pflege von Evaluationssets. Vierte Regel, build for rebuilding: Die Fähigkeit der Modelle entwickelt sich ständig weiter, sodass wenig als dauerhaft behandelt wird. Commure legt das Abschlusskriterium für einen Neubau fest — wenn der alte Pfad verschwunden ist — und git worktrees machen diese Praxis erschwinglich. Fünfte Regel, prototype, dogfood, productionize: Der mit Claude Code gebaute interne Agent wird, wenn er überzeugt, zu einem kundenseitigen Produkt über die API, das SDK oder Claude Managed Agents. Die vier Kennzahlen bleiben so bestehen, wie sie von den interviewten Unternehmen angegeben wurden, ohne beschriebene Erhebungsmethode.

Designing AI with character: what we learned building Berd

Tue, 18 Aug 2026 00:00:00 GMT

Unternehmensblogbeitrag von **Block** (`block.xyz/inside`), **nicht namentlich gezeichnet**, veröffentlicht am **18. August 2026**, der **die Open-Source-Stellung von Berd** ankündigt und die Designthese darlegt, die sie geleitet hat. **Was Berd ist.** *"Berd is a desktop application our teams use to work with AI agents across projects, skills, tools, and models."* Entstanden aus einem internen Problem: Block hatte Zugang zu leistungsfähigen Agenten — **goose**, **Claude Code**, **Codex** — aber jeder brachte *"different interfaces, configuration systems, and ways of managing context"* mit sich. Die gezogene Schlussfolgerung: *"we didn't need another model or agent harness, **we needed a consistent environment around them**"*. Berd bringt Unterhaltungen, Dateien, Ordner, Anweisungen, Agenten und Skills rund um **persistente Projekte** zusammen, um zu verhindern, dass der Kontext für jede Aufgabe neu aufgebaut werden muss. **Die Designthese.** Agenten **Charakter** verleihen — nicht nur über Rollen, Anweisungen, Skills und Tools, sondern über **eigenständige visuelle Identitäten**, einschließlich einer Sammlung animierter Figuren, der *"Gloopies"*. Das angeführte Problem ist das der leeren Eingabezeile: *"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"*. Der Beitrag stellt den Ansatz in die Tradition von **Square** und **Cash App** — Design dorthin bringen, wo die Kategorie bislang keines hatte. **Doch das genannte Problem ist ein Problem der Konfigurationslesbarkeit, während der Avatar die Unterscheidbarkeit löst**; der Text räumt dies in einem Satz ein, den er nicht weiter ausführt: *"The avatars make the agent recognizable. **Its role, skills, and tools make it useful.**"* **Die Architektur.** Berd stammt von **goose** ab, dem Open-Source-Agenten-Framework, das Block im **Januar 2025** eingeführt hat und das im Dezember 2025 zusammen mit **MCP** und **AGENTS.md** in die **Agentic AI Foundation** (Linux Foundation) eingebracht wurde. Explizite Aufteilung: *"goose remains the open agent framework and runtime. Berd is a desktop application built around it. **Berd connects to goose through the Agent Client Protocol.**"* goose trägt die Agent-Loop, Berd trägt die Erfahrung. **Die Fortsetzung ist Buzz.** Berd diente dazu, **Solo**-Arbeit zu erkunden; *"But work rarely stays private"*. Was Berd gezeigt hat — *"private space, durable context, recognizable agent identities, reusable skills, visible configuration"* — soll in **Buzz** einfließen, den gemeinsamen Raum für Mensch und Agent. *"Start alone, then go multiplayer."* **Vorbehalte.** **Keine Zahlen, keine Nutzertests, keine genannte Lizenz**; eine vereinzelte Übertreibung (*"create custom agents to do any task they want"*); und ein Beitrag, dessen Titel einen Rückblick ankündigt, während das Produkt im Präsens bleibt — **Berd wird nicht als eingestellt erklärt, aber die Roadmap weist auf Buzz**.

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

Tue, 18 Aug 2026 00:00:00 GMT

Sonatype veröffentlicht, verfasst von seiner *technical writer* Aaron Linskens, eine Zusammenfassung einer Längsschnittstudie seiner Research Labs über neunundvierzig Monate, von Juni 2022 bis Juni 2026. Die Methode wird vorab genannt: eine feste Kohorte von Anwendungen wird kontinuierlich verfolgt, sodass die gemessenen Veränderungen die Entwicklung der Softwareflotte widerspiegeln und nicht die des Kundenportfolios. Das zentrale Ergebnis wird als Widerspruch dargestellt: Organisationen beheben Schwachstellen schneller als zuvor, doch ihre Anwendungen häufen mehr Risiko an. Vier Kennzahlen rahmen den Befund. *Critical*- und *High*-Schwachstellen pro Anwendung wurden mit 4,31 multipliziert und stiegen von durchschnittlich 14,14 im Juni 2022 auf 54,3 im Jahr 2026; der Effekt wird nicht allein von Legacy-Anwendungen getrieben, denn ohne kürzlich neu unter Verwaltung gebrachte Legacy-Anwendungen bleibt immer noch ein Faktor von 3,91. Neu betroffene Komponentenversionen schreiten mit dem Sechsundvierzigfachen der Rate vor der KI-Ära voran. Das mediane Alter von Schwachstellen ist seit seinem Höchststand im Januar 2024 um 59 % gesunken. Schließlich wurde die durchschnittliche monatliche Erstellung von Anwendungen mit 4,84 multipliziert, und mit ihr die Abhängigkeitsentscheidungen. Der Fortschritt bei der Behebung ist real: Mehr als die Hälfte der behobenen Verstöße wird in weniger als einem Tag behoben, und das mediane Alter ungelöster *Critical/High*-Schwachstellen sinkt von 228 auf 126 Tage, dann im Mai 2026 auf 103 Tage. Unter Kohorten mit mindestens zwölf Monaten Handlungszeit sind 52,6 % behoben, 44,3 % bleiben offen, und 3,1 % stehen unter Waiver. Die vorgeschlagene Verschiebung betrifft die vorgelagerte Stufe. Die Forscher untersuchten die anfälligen Abhängigkeiten, die in die Anwendungen des Zeitraums eingeflossen sind, und stellten eine einfache Frage: Existierte zum Zeitpunkt der Auswahl bereits eine deutlich weniger riskante Version? Die Antwort lautet Ja in 62,2 % der Fälle bei Maven, 46,9 % bei npm und 34,3 % bei PyPI. Der Text lehnt es ab, dies als Fehler der Entwickler zu deuten: Manche Schwachstellen sind unvermeidlich, andere entstehen aus einer Informationslücke zum Zeitpunkt der Wahl — ein Punkt, der heikel wird, wenn ein KI-Assistent eine Komponente in Sekunden einführen kann, ohne über aktuelle Erkenntnisse zu deren Risiko und zur organisatorischen Richtlinie zu verfügen. Der Beitrag räumt ein, dass KI nicht die alleinige Ursache der wachsenden Schwachstellenlandschaft ist, und nennt vier konkurrierende Faktoren. Er schließt mit Sonatype Guide, das diese Intelligenz an den Punkt der Auswahl bringt, und verweist für die zugrunde liegenden Daten auf den vollständigen Bericht *The AI-Era Software Assembly Line*.

Projects in Buzz

Tue, 18 Aug 2026 00:00:00 GMT

Ankündigungsbeitrag von **Block Engineering**, gezeichnet von **Thomas Petersen** (*Principal Designer & Builder*), veröffentlicht am **18. August 2026**, der **Buzz Projects** vorstellt — den Forge-Baustein von **Buzz**, dem Mensch-und-Agenten-Arbeitsbereich von Block auf Basis von **Nostr**. **Das formulierte Problem.** *« Software development tools are fragmented in ways the work itself is not. »* Der Bug-Report liegt in einem Tool, die Diskussion in einem anderen, der Fix auf einem Branch, CI anderswo, das Review in einem Kommentar-Thread, Release Notes werden im Nachhinein rekonstruiert. **Die These: All dies ist ein einziges Gespräch, und die Historie muss Teil des Projekts sein.** **Was Projects liefert.** Eine **Forge, gehostet auf dem eigenen Relay**: Standard-Git-Repositories, zugänglich via `fetch/clone/pull/push` über **Smart HTTP**, *« with no custom tooling or wrapper CLI required »*; **die clé Nostr als einzige Identität** — *« the same npub that signs your messages signs your pushes »*, ohne separates Token oder GitHub-Konto; **Multi-Repo-Projekte**, die Repositories einschließen können, die man nicht besitzt (*« you just won't have authority over it »*); Issues, Pull Requests, Diffs, Inline-Kommentare, Review und Merge; ein serverweiter **Activity Feed**; sowie die **Verknüpfung eines beliebigen Projekts mit einer beliebigen Anzahl von Channels**, sodass *« the context around a change doesn't disappear the moment agents start writing code »*. Aus einem Channel heraus kann ein Issue an einen Agenten übergeben werden, oder der Agent kann gebeten werden, einen PR zu öffnen, der auf das Gespräch zurückverweist, aus dem er entstanden ist; der Agent wendet sich über die **Inbox** an den Menschen. **Die Doktrin, in zwei Teilen, die der Beitrag nie zusammenführt.** Auf der einen Seite **keine vorherige Einschränkung**: *« No forced guardrails, no limitations on what your agents are allowed to help you with. »* Auf der anderen **ein signierter Nachweis jeder Handlung**: *« Every push, review, approval, and merge is a signed Nostr event »*, mit einer Nachverfolgung, **welcher Agent** einen Patch erzeugt hat und **welcher Mensch** ihn autorisiert hatte. Daher die abschließende Projektion: Die Beitragshistorie wird zu *« more than a set of colored squares on a profile »*, einer **überprüfbaren, an einen Schlüssel gebundenen Historie**, und Block erklärt, **es erkunde *« agent trust protocols informed by past behavior »***. **Vertrauen verschiebt sich von *ex ante*-Autorisierung zu *ex post*-Nachweis.** Die zugehörige Einordnung ist explizit: *« 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. »* **Vorbehalte.** **Keine Zahlen, keine ausgehenden Links, keine Spezifikation** an irgendeiner Stelle des Textes; **CI und Release Notes werden versprochen, fehlen aber im Bestand**; Projects befindet sich unter dem **Experiments-Tab**, und der Beitrag relativiert sich selbst sechsmal — *« Buzz is still in beta and Buzz Projects is still under experiments, so treat it accordingly. »*

The AI Engineering Skills Map

Fri, 14 Aug 2026 00:00:00 GMT

X-Post von **Andrew Ng** vom **14. August 2026**, Wiederaufnahme des "Dear friends"-Briefs aus ***The Batch* #366** (DeepLearning.AI). **Was angekündigt wird.** *The AI Engineering Skills Map*: **vier Skills**, die als die wichtigsten für einen Entwickler dargestellt werden, gestützt auf *« an analysis of more than 10,000 job postings »*, Dutzende strukturierte Interviews mit Experten, Hiring Managern und Recruitern, Umfragen und weitere Online-Daten. Explizit doppeltes Publikum: Entwicklern helfen, **zu priorisieren, was sie lernen**, und Arbeitgebern, **einzustellen**. **Die vier Skills.** **(1) Aufbau und Bereitstellung von KI-Anwendungen** — ihr Unterschied liegt in der **Unvorhersehbarkeit der Ausgaben**; man muss die Bausteine kennen (LLM, context engineering, RAG, agentische Workflows, maschinelles Lernen, Deep Learning) und vor allem die **statistischen Techniken zum Messen, Steuern und Governance**, einschließlich *« disciplined evals and error-analysis loops »*. **(2) Grundlagen der Softwareentwicklung** — deren Verständnis erlaubt es, *« recognize what tradeoffs exist »* (Kosten, Skalierbarkeit, Zuverlässigkeit, Geschwindigkeit, Sicherheit, Datenschutz) und so den Agenten *« in the precise language of software engineering »* zu steuern; der unerfahrene Entwickler, der *vibe coding* betreibt, scheitert, weil *« they don't know what context to give their agent »*. **(3) Einsatz von Coding-Agenten** — ein mentales Modell ihrer Grenzen, Kontextmanagement, Abwägungen zwischen Planung und Ausführung, **Bereitstellung von Verifiern oder Evals, damit der Agent seine Loops selbstständig schließt**, Arbeiten mit einer klaren Spec *« and when not to bother doing so »*, Multi-Agent-Orchestrierung, Guardrails. **(4) *Den Build gestalten*** — da Agenten gegen eine klare Spec gut liefern, verschiebt sich die Arbeit hin zu **der Entscheidung, was die Spec enthalten soll**: Product Sense, Business-Kontext, Projekt-Ownership. **Allen vieren zugrunde liegt: eine Haltung des kontinuierlichen Lernens**, mit *« routines for trying new tools »*. **Die eigentliche These, versteckt in einem Hinweis zur Terminologie.** Ng spricht von **Skills** im AI Engineering und nicht von der **Rolle** "AI Engineer": *« all developers should know how to work with the cloud, only a small number carry the "Cloud engineer" title »*. **AI Engineering wird zur Grundausstattung, nicht zur Spezialisierung** — man stellt nicht ein, man qualifiziert um. **Zwei Vorbehalte.** **Es werden keine numerischen Ergebnisse veröffentlicht**: keine Gewichtung, keine Sub-Skills, ein Clustering, das als *« informal »*-Analogie beschrieben wird, und die detaillierte Map wird auf künftige Beiträge verschoben. **Dies ist die Ankündigung einer Map, nicht die Map selbst.** Und der Autor benennt sein Eigeninteresse: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities

Fri, 14 Aug 2026 00:00:00 GMT

Ankündigungsbeitrag, veröffentlicht am **14. August 2026** im **Z.ai**-Blog (ehemals Zhipu AI), **unsigniert**, zur Einführung von **GLM-5.3**. **Die methodische These.** *« Scaling post-training is all we did for GLM-5.3. »* Dasselbe Basismodell wie GLM-5.2: **der gesamte Gewinn stammt aus dem Post-Training**, aufbauend auf dem Stack des vorherigen Zyklus — **IndexShare** (langer Kontext), **SAO** (Long-Horizon-RL) und **slime** (asynchrones Training, Megatron + SGLang). Der Engpass hat sich vom Modell zur **Umgebung** verlagert: Z.ai beschreibt Pipelines, die Umgebungen und Belohnungssignal **synthetisieren** — ein Judge-Agent verifiziert die Lösbarkeit, **Verifier werden ohne Zugriff auf die Referenzlösung synthetisiert** und erst nach einem Triptychon aus **oracle-/no-op-/unsolved-state**-Kontrollen zugelassen. Die Arbeit bleibt *« human-in-the-loop »*. Der End-to-End-RL-Durchsatz verbesserte sich um **mehr als das 2,3-Fache**. **Die Coding-Ergebnisse.** Terminal-Bench 3.0 steigt von **4,6 auf 28,3**, DeepSWE v1.1 von **46,2 auf 66,9**, Agents' Last Exam von **23,8 auf 28,5**. Auf **Z.ai Code Bench**, einem **internen, privaten** Benchmark, +50 % gegenüber GLM-5.2, bei gleichzeitigem Gewinn an **Token-Effizienz**: 34,5 % bei ~75K Output-Token mit Max-Effort (gegenüber 23,4 % bei 96K für GLM-5.2) und 31,4 % bei ~50K mit High-Effort — vor Claude Opus 4.8 (29,5 % bei 120K). **Claude Fable 5 bleibt mit 39,5 % vorn.** Die Behauptung *« most capable open-weights model for coding »* **ergibt sich nicht aus der Tabelle**: gegenüber **Kimi K3** steht es **3:3 mit einem Unentschieden**. **Die Cyber-Fähigkeit.** Als *« emergent »* dargestellt, wurde sie **gezielt trainiert** — der Beitrag schreibt *« we expected this to make the model better »*. Überraschend waren die **Geschwindigkeit** und der Wechsel von isolierten Schwachstellen zur **vollständigen Exploitation-Kette**. CyberGym **84,5 %** (bester Wert der Tabelle), ExploitBench **54,4 %** (×2,2), ExploitGym **105/130 Aufgaben** (×3,6 gegenüber GLM-5.2, durchsatznormierte Budgets). Schlüsselsatz: ***« Capability is growing fastest exactly where we are furthest behind. »*** **Die schwerwiegendste Zahl.** In Zusammenarbeit mit chinesischen Sicherheitsteams identifizierte das Modell **2.436 Schwachstellen in 269 Open-Source-Projekten** — Kernel, Betriebssysteme, Browser-Engines, Netzwerkprotokolle — die älteste eingeführt **1981**, durchschnittliche Lebensdauer **26,6 Jahre**. Das **Security Disclosure Ledger** zeigt **53 offengelegte** und **2.383 unter Embargo stehende**: **2,2 % veröffentlicht**. **Governance.** Die Gewichte werden angekündigt *« in two weeks, once safety evaluation and hardening are complete »* — **ein Datum, kein Kriterium**: keine Definition von Hardening, keine Bedingung für eine Nicht-Freigabe, kein externer Prüfer. **Sonstiges.** `thinking.type: "disabled"` **wird nicht mehr unterstützt** (Migration erforderlich); GLM Coding Plan-Kontingente in Punkten, **50 % außerhalb von 14:00–18:00 UTC+8**; **nahezu alle Evaluierungen werden in Claude Code 2.1.207 durchgeführt**.

DeepSeek Harness developer preview: Everything is a plugin

Thu, 13 Aug 2026 00:00:00 GMT

Produkt-Launch-Seite, veröffentlicht am **13. August 2026** von **DeepSeek**, **nicht gezeichnet**, zur *Developer-Preview*-Veröffentlichung von **DeepSeek Harness** (`dsh`), einem Coding-Agent-Harness, **Open Source unter der MIT-Lizenz**, dessen Repository am selben Tag eröffnet wurde. **Was die Seite sagt.** Zwei Versprechen, in vierhundert Wörtern und ohne eine einzige Zahl. **« Everything is a plugin »**: jede Fähigkeit — Modelle, Tools, Skills, Sessions, Sandboxes, Storage, Loops, Scheduling, Interface — ist ein Plugin, **austauschbar per Konfiguration, ohne den Quellcode zu ändern**. **« Every run is traceable »**: alles, was das Modell sieht, wird in einem **Append-only-Session-Log** erfasst — System-Prompts, Reasoning, Tool-Aufrufe und -Ergebnisse, Subagent-Scheduling, jede Kontext-Injektion — und *« resume, fork, search and replay all operate on the same event stream »*. Der Kern ist **Cordis**, ein vendortes Drittanbieter-Framework, das in einem externen Paper beschrieben und prominent gewürdigt wird. Vier Ausführungsmodi werden ausgeliefert: **Standard** (vollständiges Tooling), **Code** (Tools, die über ein TypeScript-SDK freigelegt werden, um mehrere Operationen in einem Programm zu kombinieren), **Minimal** (zwei Tools, persistenter Bash und `str_replace_editor`, *« for benchmarking models in a minimal environment »*), und **Creator** (Laufzeitinspektion, In-Memory-Plugin-Tests, Komposition neuer Modi). Einstieg: `npx @deepseek-ai/dsh web`. **Was die Seite nicht sagt.** Die stärkste Aussage steht in `docs/architecture.md`: ***« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it. »*** **Eine zur Laufzeit erzwungene Garantie**, keine Werbeaussage — genau diese Eigenschaft unterscheidet DSH eigentlich, und sie fehlt im Marketingtext. Dasselbe Repository liefert den Widerspruch gleich mit: `SESSION_FORMAT_VERSION` bleibt bei **`0` ohne Kompatibilitätsversprechen**, *« backends reject old on-disk formats »*, und die README warnt in Großbuchstaben, dass es Breaking Changes geben wird. **Nachvollziehbar heute bedeutet nicht archivierbar morgen.** **Das Geschäftsmodell steckt im Zeitplan.** DSH erscheint am Tag der **GA von DeepSeek-V4-Pro** und **drei Tage vor** einem neuen API-Preisplan (16. August, 16:00 UTC; Nebenzeittarife bei **−50 %**). **Harness verschenkt, Inferenz verteuert** — genau umgekehrt zum Modell von Anthropic. **Was sich bestätigt.** Die Austauschbarkeit hält zumindest auf der Modellebene: Neben dem DeepSeek-Adapter macht **`dsh-llm-pi-ai`** jedes OpenAI-kompatible Gateway zugänglich, *« by configuration, not by code change »*. Und mode Minimal liefert den **Benchmarking-Harness** direkt im Produkt mit — ein Versuch, Claude Code die Definitionshoheit über den Benchmark zu entreißen, obwohl DSHs eigenes Repository selbst eine `CLAUDE.md` und ein `.claude/skills` enthält.

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

Wed, 12 Aug 2026 00:00:00 GMT

Interner Rechercheureport vom **12. August 2026**, der den öffentlichen Stand von **Buzz** zusammenfasst, dem Workspace für Menschen+Agenten von **Block**, eingeführt am **21. Juli 2026** unter **Apache 2.0**, zu Präsentationszwecken. Er aggregiert Blocks zwei Engineering-Beiträge, die Unternehmensankündigung, das GitHub-Repository, die Presseberichterstattung, X und **drei unabhängige Auswertungen** — wobei diese letzte Ebene den Großteil des Mehrwerts trägt. **Das Konzept.** Buzz verschmilzt Team-Chat, eine Git-Forge und automatisierte Workflows zu einem einzigen Raum, in dem Agenten **vollwertige Mitglieder, keine Bots** sind. Die These stammt von Tyler Longwell: *„The bottleneck moved from intelligence to coordination.“* Bradley Axen (Head of AI Capabilities) fasst die Marktlage zusammen: *„Every company is going to need a place where humans and agents work together. The question is whether that place is proprietary or open.“* **Die Architektur.** Ein **Rust**-Relay auf **Nostr** (NIP-01/42/98/34, 127 *event kinds*), **Postgres**, **Redis**, **S3/MinIO**, Desktop **Tauri+React**. Jeder Teilnehmer besitzt ein Schlüsselpaar; jede Nachricht, jede Review, jeder Workflow-Schritt und jedes Git-Event wird **signiert** in ein hash-verkettetes Append-only-Audit-Log eingetragen. Ein für ein **v0.4.x/0.5.x** seltenes Maß an Formalismus: Mandanten-Isolation mechanisiert in **TLA+**, in **Tamarin** verifizierte Autorisierungseigenschaften. Die Agentenintegration erfolgt über **`buzz-acp`**, ein **ACP**-Harness, das goose, Codex und Claude Code einbindet und **ACP ↔ MCP übersetzt** — *„They compose through protocols, not imports.“* **Die zentrale Lücke.** Jack Dorsey kündigt *„decentralized, self-sovereign“* an; Blocks `ARCHITECTURE.md` stellt fest: *„The relay is the single source of truth… There is no peer-to-peer event exchange, no gossip, no replication.“* Ein einziger Relay pro Community, somit ein **Single Point of Failure**: Dezentralisierung ist **organisatorische Souveränität**, keine Redundanz. **Die dokumentierten Einschränkungen.** Die Berechtigungseinheit ist die **Kanalmitgliedschaft** — *„channel membership is not fine-grained tool authorization“*; Agenten laufen in **`--dangerously-skip-permissions`**, außerhalb jeder Sandbox; **die Beobachtbarkeit fehlt** (*„It doesn't tell me what happens next“*, stille OOM-Kills). Signierte Events sind *tamper-evident*, nicht *tamper-resistant*: Ein kompromittierter Relay-Betreiber kann sie löschen. Auf dem gehosteten Relay gibt es **keine Ende-zu-Ende-Verschlüsselung**. **Eine Zahlenkorrektur.** Die „+33% more work“ sind das **Verhältnis abgeschlossener Aufgaben (20 gegenüber 15 von 44)**, kein Punktzahlgewinn — diese steigt von 59,1 % auf 71,5 %, also **+12,4 Pkt.** **Rezeption**: ~25.900 GitHub-Stars, ein Dorsey-Tweet mit ~2,3–2,7 Mio. Aufrufen, Zustimmung von Sundar Pichai, sowie Justin Waldrons Formulierung: *„the first proper multiplayer agent harness“*. Eingeräumte Vorbehalte: Benchmarks **von Block selbst evaluiert**, kein veröffentlichter Hosting-Preis, keine Adoptionszahlen.

I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

Wed, 12 Aug 2026 00:00:00 GMT

Erfahrungsbericht, veröffentlicht auf **LinkedIn Pulse** am **12. August 2026** von **Guillaume Dumortier** (Newsletter *Growth Marketing Fit*), über ein internes Marketing-KI-System, gebaut **in Claude** für ein Team von rund sechzig Personen: etwa dreißig Skills, ein Dutzend Truth-Module, **sieben Agenten, von denen sechs nur Arbeit prüfen**, ein Terminal-Plugin, eine Browseranwendung und eine Multi-Asset-Kampagnenorchestrierung. **Die These.** *„I thought I was building a content machine. I was building a trust machine."* Die Qualität eines KI-Outputs entscheidet sich nicht bei der Generierung, sondern durch **das, was das System vorher weiß**, und **das, was anschließend mit dem Entwurf geschieht**. Die Generierung ist der einfache Teil – und der einzige Teil, den die meisten Teams gebaut haben. **Vier Schichten.** *Truth*: Faktendokumente, getrennt von allem, was Content produziert, jedes mit einem Owner, versioniert und datiert. Fakten innerhalb der Skills zu belassen erzeugte **vier Versionen eines Launch-Datums in vier Dateien**, jede für sich plausibel. *Production*: Der Blog-Skill verbrachte Wochen damit, **Beschreibungen von Artikeln** statt Artikel zu schreiben, und bestand jede Prüfung, weil die Prüfung die Struktur kontrollierte. Ab dreißig Skills wird das Problem zum **Routing** – die Hälfte jeder Skill-Beschreibung muss angeben, wofür sie nicht gedacht ist. *Verification*: die Schicht, die eine Demo von einem System unterscheidet. *Internal distribution*: wo Projekte daran sterben, exzellent zu sein und von vier Personen genutzt zu werden. **Die beiden zentralen Fehler.** Ein Fact-Checker erhält eine Behauptung, die keine seiner Quellen abdeckt: Er liefert ein „pass". *„It didn't just miss the error, it certified it."* Lösung: Ein Prüfer ist ein **Closed-World-System**; **es ist ihm untersagt, ein nacktes „pass" zurückzugeben**, und er muss seine Abdeckung offenlegen – wie viele Behauptungen geprüft wurden, wie viele tatsächlich zugeordnet werden konnten, welche außerhalb seiner Zuständigkeit lagen, welche keiner Quelle gehörten. *„An unverifiable claim is a finding, not a silence."* Zweiter Fehler: **Zwei für sich korrekte Assets können sich widersprechen**; die Prüfung pro Asset kann das konstruktionsbedingt nicht erfassen. **Fünf übergreifende Regeln.** Nie ein Modell um etwas bitten, das sich im Code erzwingen lässt. **Stille Fehler** sind das eigentliche Risiko – eine geleerte Konstante entfernte jede Zahl aus jedem Prompt, und dem Modell wurde Halluzination vorgeworfen. Die Pipeline testen, nicht nur den Output. Die eigene Validierung hat dieselben Lücken wie das System. **Dem System das Verweigern beibringen.** **Adoption folgt Vertrauen, nicht Fähigkeit**: Ein Output, der zugibt, wobei er sich unsicher ist, wird genutzt. Schlusssatz: ***„The generation is free. The trust is the product."***

Agent Plugins package your skills, tools, and more

Thu, 06 Aug 2026 00:00:00 GMT

Engineering-Beitrag von **Google** am **6. August 2026**, der ankündigt, dass das Unternehmen als **Core Maintainer** der Spezifikation **Agent Plugins 1.0.0** beitritt — einem offenen, *anbieterneutralen* Packaging-Format für die gemeinsame Verteilung von **Agent Skills** und **MCP servern**. **Zuerst die Governance-Tatsache.** Die Spezifikation wurde von einem TSC aus Core Maintainern von **Amazon, Cursor, Microsoft, OpenAI und Vercel** veröffentlicht. Google tritt ihnen bei, namentlich vertreten durch **Kevin Hou** (Google DeepMind). Sechs Wettbewerber einigen sich auf eine Packaging-Schicht. **Anthropic erscheint nicht auf der Liste der Maintainer**, obwohl die beiden gepackten Bausteine von dort stammen. **Die Diagnose.** Ein Skill ist portabel, ein MCP server ist portabel — *„The core problem isn't the components. It's the manifest.“* Was nie portabel war, ist die Kiste: Verzeichnisstruktur, Manifest-Metadaten, die Form der MCP-Konfiguration und die Transport-Ableitung unterscheiden sich von Client zu Client. Man forkt, pflegt zwei Kopien identischer Komponenten, und sie driften auseinander. **Das Format.** *„A plugin is a directory. That's the whole idea, and the restraint is the point.“* Eine `plugin.json`, reduziert auf `$schema` und `name`; Skills in `skills/`, im Agent-Skills-Format; servers in `mcp.json`, **mit einem expliziten `type`** bei jedem Eintrag (stdio, Streamable HTTP, veraltetes HTTP+SSE). Die Stärke des Designs liegt in dem, was das Manifest **nicht** kann: eine Komponente weder verlagern noch inline deklarieren. Es gibt also keinen zu konfigurierenden Discovery-Pfad, keine zu erlernende Rangfolge. Korollar: **Komponenten scheitern unabhängig voneinander** — ein server, der nicht startet, reißt nicht die Skills mit sich. Ein **Reverse-Domain**-Verzeichnis (`com.example.client/`) dient als proprietärer Erweiterungsraum, der von anderen Clients ignoriert wird: Der portable Kern bleibt klein, weil die nicht-portablen Teile einen Ort haben, an den sie gehören. **Die Grenzen, offen benannt.** Ein ganzer Abschnitt erklärt, **wann man kein Plugin bauen sollte** (ein einzelner MCP server, ein einzelner Skill: unnötig). Ein weiterer listet auf, was v1 ausschließt: **Installation, Distribution, Berechtigungen, Sandboxing, Vertrauens- und Herkunftsprüfung, UX**. Begründung: Die Verpflichtungen einer IDE, einer CLI und einer Enterprise-Plattform unterscheiden sich tatsächlich. **Der Stack.** Finden (**Agentic Resource Discovery**), beschreiben (**AI Catalog**), packen (**Agent Plugins**), ausführen (**MCP + Agent Skills**) — jede Schicht unabhängig adoptierbar. **Bereits verfügbar**: **Agents CLI** (nutzbar aus Antigravity, Gemini CLI, Claude Code oder Cursor) und **Data Agent Kit** (BigQuery, Spanner, Cloud SQL). *„Those skills were already distributable. Now they're distributable in a format that isn't ours alone.“* Schlusssatz: *„Packaging is unglamorous infrastructure,“* und genau das sollte geteilt statt fünfmal neu erfunden werden.

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

Thu, 06 Aug 2026 00:00:00 GMT

Die Website **graphify.net**, aufgerufen am 6. August 2026, offiziell im Besitz von **Safi Shamsi**, dem Schöpfer des Open-Source-graphify-Skills. Die Domain trägt drei Dinge, die sich von der kommerziellen Plattform `graphify.com` und dem GitHub-Repository unterscheiden. **Eine Produktpräsentation**, zunächst: Vorstellung von graphify, Nutzungsanleitungen, CLI-Referenz, Seiten zu tree-sitter und Leiden-Clustering. **Eine Demo-Galerie**, als Nächstes, und sie ist der überzeugendste Teil: **100 bereits graphifizierte GitHub-Trending-Repositories**, insgesamt **854.079 Knoten und 1.932.930 Kanten**, filterbar nach Sprache und Größe, jedes mit Angabe der Knoten-, Kanten- und Community-Zahlen, mit Graph-Vorschau und Detailseite. Das Tool an bekannten Repositories in Aktion zu zeigen, ist mehr wert als ein Pitch, und erzeugt nebenbei einen öffentlichen Datensatz vergleichbarer Graphen. **Ein redaktionelles Verzeichnis**, schließlich, das einen eigenständigen Wert hat, unabhängig vom Produkt, für das es wirbt: **30 AI coding client guides**, verglichen nach Workflow, Agenten, Preisgestaltung, Sicherheit und Eignung für die Auslieferung; ein **MCP-Server-Verzeichnis**, bewertet nach Transport, Laufzeitumgebung, unterstützten Clients, Einrichtungsaufwand und **Zugriffsrisiken**; paarweise Vergleiche nach abgestimmten Feldern. Die Website beansprucht eine Methode — *« source-reviewed »*, offizielle Belege, explizite Unbekannte — und ist in sechs Sprachen verfügbar. **Diese Fiche existiert vor allem, um eine Diskrepanz festzuhalten.** Am selben Tag kündigt die Website **« 3.7k+ GitHub stars »** an, während die API **103.187** zählt; sie gibt **dreimal** eine **MIT**-Lizenz an, während die `LICENSE`-Datei des Repositories **Apache 2.0** lautet; und sie hebt die Behauptung **« 71.5× token reduction »** hervor, die zur README-Generation v1 gehört und in der aktuellen Version zugunsten der LOCOMO- und LongMemEval-Benchmarks verschwunden ist. Die Website beschreibt somit ein um mehrere Generationen veraltetes Produkt. **Der Lizenzfehler ist der schwerwiegendste**: MIT und Apache 2.0 bringen nicht dieselben Verpflichtungen mit sich, insbesondere bei Patenten und der Offenlegung von Änderungen. Eine strategische Beobachtung bleibt: **Ein Tool-Anbieter, der das Verzeichnis seiner eigenen Kategorie aufbaut**, besetzt die Bewertungsanfrage vor seinen Wettbewerbern. Der Neutralitätsanspruch beseitigt den Interessenkonflikt nicht — graphify erscheint unter den vorgestellten Skills der Website. Ein nützlicher Einstiegspunkt, kein Schiedsrichter.

Efficient Tokens & Effective Teams in Buzz

Thu, 06 Aug 2026 00:00:00 GMT

Ein **Block**-Benchmark-Beitrag von **Atish Patel**, veröffentlicht am **6. August 2026**, der an den **Buzz**-Launch anknüpft: Da das Zusammenstellen eines Agententeams dort trivial geworden ist, stellt sich die Frage, *welches das günstigste ist, das zuverlässig erfolgreich ist*. **Erst das Vokabular.** Der Beitrag schlägt vier Stufen vor: **QuickBee** (schnell und günstig – Builds, Screenshots, Tests, Erst-Triage: GPT-5.6 Luna, DeepSeek V4 Flash, lokale Modelle, **mit hohem Aufwand betrieben**), **WorkerBee** (vielseitig, übernimmt unbeaufsichtigt einen vollständigen Teilbereich: GPT-5.6 Terra, Gemini 3.6 Flash, offene Modelle), **SmartBee** (Gesamtbild, Abwägungen, Eskalationen: Claude Opus 5, Kimi K3, GPT-5.6 Sol, **mit *medium*-Aufwand**), sowie der Mensch, *„die teuerste Biene im Team, und die langsamste. Aber immer noch die klügste"*. Zwei Teamformen: die permanente **Hive**, die sich die Präferenzen der Nutzenden merkt, und der einmalige **Swarm**, der sich **das Projekt** merkt und danach verschwindet. **Das Solo-Ergebnis.** Auf **Terminal-Bench 2.1** ist die Erhöhung des Aufwands eines **günstigen Modells** der beste Kauf: Luna steigt von 1,61 $ / 57,3 % (*medium*) auf 4,98 $ / 75,0 % (*high*). Am anderen Ende ist **Opus 5 mit *xhigh*-Aufwand der teuerste Durchlauf (140,63 $) und erreicht nur 75,0 %**, nachdem durch Over-Reasoning **bei 17 von 88 Aufgaben der Timeout erreicht wurde**. Unter den sechs besten Durchläufen: **eine 5,5-fache Preisspanne bei einer Punktzahldifferenz von 8,9 Punkten**. Fazit: *„die Wahl zwischen ihnen ist überhaupt keine Qualitätsentscheidung. Es ist eine Budgetentscheidung."* **Das Teamergebnis, in zwei Akten.** Auf Terminal-Bench 2.1 wurden **zwölf Zusammensetzungen** getestet, und **keine schlug Solo bei gleichen Kosten** – einer kurzen Aufgabe fehlt die Struktur, um sie aufzuteilen. Auf **Long-Horizon Terminal-Bench** (44 mehrstündige Aufgaben, Lead GPT-5.6 Sol, **3-facher Timeout**) zeigt sich die Umkehrung deutlich: Solo **15 Aufgaben / 59,1 %**, +2 WorkerBees **20 / 71,5 %** – **+12,4 Punkte, wovon 11,4 aus zusätzlich abgeschlossenen Aufgaben stammen**. Das Team kostet pro Aufgabe mehr, was sich auszahlt, *„wenn die Alternative ein Mensch ist, der unfertige Arbeit übernehmen muss"*. **Die Betriebsregel.** Eskalationen von Workern werden an einen **SmartBee-Koordinator** geleitet statt an den Menschen: *„jede Unklarheit wird zu einer Benachrichtigung"* ist der eigentliche Fehlermodus. Ein Block-Ingenieur berichtet von **über 2.000 migrierten Apps** mit einem Swarm (Koordinator, 1–10 Migratoren, unabhängiger Verifizierer), wobei der Koordinator menschliche Antworten im Gedächtnis speichert. **Vorbehalte**: n=1 pro Aufgabe, kein Konfidenzintervall, Teamkosten nicht veröffentlicht, sowie ein Eingeständnis – *„das könnte sich ändern, wenn Modelle für bessere Zusammenarbeit trainiert werden."*

graphify — « Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store. »

Thu, 06 Aug 2026 00:00:00 GMT

**graphify** (Safi Shamsi, Graphify Labs, Y Combinator S26) verwandelt ein gesamtes Projekt in einen **abfragbaren Knowledge Graph**, aufgerufen über `/graphify` aus Claude Code, Cursor, Codex, Gemini CLI und rund fünfzehn weiteren Clients. Stand 6. August 2026: **103.187 Stars** für ein am 3. April erstelltes Repository, Apache-2.0, Python. **Drei Designentscheidungen bilden die Grundlage des Projekts.** **Der Code wird lokal** ohne LLM in einen tree-sitter-AST geparst: deterministisch, nichts verlässt die Maschine, für einen reinen Code-Korpus ist kein API-Schlüssel nötig. **Jede Kante trägt ihre Herkunft** — `EXTRACTED`, wenn explizit in der Quelle vorhanden, `INFERRED`, wenn graphify sie aufgelöst hat —, *„so you can tell what was read directly from what was inferred"*. Und das Projekt definiert sich **gegen Vektor-RAG**: *„Not a vector index. No embeddings, no vector store: a real graph you traverse."* **Die Nutzung ersetzt grep.** `query` liefert einen Subgraphen zu einer Frage in natürlicher Sprache, `path A B` verfolgt den Pfad zwischen zwei Entitäten, `explain` entfaltet ein Konzept. Drei Ausgaben: ein interaktiver Graph, ein lesbarer Report (God Nodes, überraschende Verbindungen, vorgeschlagene Fragen) und ein persistentes `graph.json`, Wochen später abfragbar. **Die Abdeckung reicht über Code hinaus**: 36 tree-sitter-Grammatiken, aber auch SQL, Terraform, Apex, **MCP-Konfigurationen**, Paketmanifeste, Office, PDF, Bilder und lokal transkribierte Videos. `# WHY:`-Kommentare und Design-Begründungen werden zu **eigenständigen Knoten, die mit dem von ihnen erläuterten Code verknüpft sind**. **Die Benchmarks verlangen eine sorgfältige Lektüre.** Auf LOCOMO dominiert graphify beim Recall (0,497 gegenüber 0,149 und 0,048), **verliert jedoch bei der QA-Genauigkeit** (45,3 % gegenüber 49,7 %); auf LongMemEval-S **liegt es mit 76 % gleichauf** mit einem dense RAG. Die entscheidende Zeile steht woanders: *„Graph build — LLM credits: 0"*. Das vertretbare Unterscheidungsmerkmal sind **Kosten und Nachvollziehbarkeit, nicht die Antwortqualität**. **Drei Vorbehalte.** Der `main`-Branch trägt ein veraltetes README aus der v1-Ära, das ein anderes Produkt beschreibt: zu lesen ist `v8`. Das PyPI-Paket heißt `graphifyy`, während der Name zurückerobert wird. Und ein **lokales Query-Log** ist standardmäßig aktiv, lässt sich aber über eine Umgebungsvariable deaktivieren. Der Skill dient zudem als Einstiegspunkt zu einer kommerziellen, mit Warteliste versehenen Plattform unter graphify.com, die denselben Ansatz kontinuierlich auf den gesamten Arbeitskontext anwendet.

Introducing Muse Code and Muse Spark 1.2

Wed, 05 Aug 2026 00:00:00 GMT

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

How to use Notion as Code

Mon, 03 Aug 2026 00:00:00 GMT

Dokumentation zu **Notion as Code**, ein Produkt in **Closed Alpha**, abgerufen am 3. August 2026 im Notion-Ambassadors-Workspace — ohne Autor- oder Datumsangabe, mit einem Warnhinweis, der empfiehlt, es zunächst in einem neuen Workspace auszuprobieren, und vor möglichen Breaking Changes warnt. **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 der Endpunkt **`/v1/infra_as_code`** zu dessen Bereitstellung. **Der Mechanismus, der alles trägt**, ist die Indirektion über Bezeichner. Das Skript **enthält keine Notion-ID**: Es deklariert vom Autor gewählte `resourceId`-Werte. Das erste Deployment liefert eine **Zuordnungstabelle** zwischen diesen logischen Bezeichnern und den tatsächlich erstellten Datensätzen zurück; bei nachfolgenden Aufrufen wieder übergeben, stellt sie sicher, dass dieselben Datensätze **aktualisiert statt neu erstellt** werden. **Drei Eigenschaften folgen daraus.** Das Skript wird **idempotent**. Es wird **vom Workspace entkoppelt** — mehrere Zuordnungstabellen erlauben das Deployment **desselben Skripts auf mehrere Workspaces**. Und da es sich um Code handelt, unterstützt es Variablen und Schleifen: Als Beispiel wird der Aufbau von zehn Teams identischer Struktur genannt, bei denen nur einige Substantive geändert werden. **Der API-Vertrag ist asynchron**: Ein `POST` liefert eine `taskId` zurück, die bis zum Abschluss abgefragt wird; die Antwort enthält die zu persistierenden Zuordnungstabellen — das Äquivalent einer State-Datei. **Zwei betriebliche Unterschiede**: Das Produkt erfordert **persönliche Zugriffstoken** anstelle der üblichen Bot-Token, wodurch Aktionen einer Person statt einer Integration zugeschrieben werden; und das **Rate Limit sinkt auf 5 Anfragen pro Minute**, da ein Aufruf nun ein Batch statt einer einzelnen Entität ist. **Das Produkt setzt den Agenten voraus.** Das SDK wird als gebaut *« für Sie oder Ihren Coding Agent »* vorgestellt, und der Onboarding-Pfad besteht darin, einen Agenten die README des SDK lesen zu lassen. Ein typisierter Zustandsdeskriptor ist tatsächlich ein besseres Werkzeug für einen Agenten als eine Folge imperativer Aufrufe: Der Fehler ist dort wiederholbar, nicht kumulativ. **Was fehlt**: keine Erwähnung des Löschens von aus dem Skript entfernten Elementen, kein Vorschaumodus vor der Anwendung, nichts zur Nebenläufigkeit, und kein Datum bei einer Dokumentation, die sich noch ändern wird.

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

Mon, 03 Aug 2026 00:00:00 GMT

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

Agent Client Protocol — Introduction

Sun, 02 Aug 2026 00:00:00 GMT

Einführungsseite der **Agent Client Protocol**-Spezifikation, abgerufen am 2. August 2026. Ein lebendes Artefakt ohne Veröffentlichungsdatum: Die Fiche ist nach ihrem Beobachtungszeitpunkt datiert. **Das Problem.** *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Jeder Editor muss für jeden Agenten, den er unterstützen will, eine eigene Integration bauen, und jeder Agent muss die spezifischen APIs jedes Editors implementieren. Daraus folgen drei unterschiedliche Kosten: **Integrationsaufwand** (jede Agent-Editor-Kombination erfordert spezifische Arbeit), **eingeschränkte Kompatibilität** (ein Agent erreicht nur einen Bruchteil der Editoren) und **Developer-Lock-in** — *« choosing an agent often means accepting their available interfaces »*. **Die Lösung.** ACP standardisiert die Agent-Editor-Kommunikation *« similar to how the Language Server Protocol (LSP) standardized language server integration »*. Der Nutzen ist gegenseitig und hält das Ökosystem zusammen: Ein Agent, der ACP implementiert, funktioniert mit jedem kompatiblen Editor; ein Editor, der ACP unterstützt, erhält Zugang zum gesamten ACP-Agenten-Ökosystem. *« This decoupling allows both sides to innovate independently. »* **Die Architektur.** ACP geht davon aus, dass sich der Nutzer **primär in seinem Editor** befindet und dort für eine bestimmte Aufgabe auf einen Agenten zugreift. Zwei Deployment-Modi: **Lokale** Agenten laufen als Subprozess des Editors und kommunizieren über **JSON-RPC auf stdio**; **Remote**-Agenten, in der Cloud oder auf separater Infrastruktur gehostet, kommunizieren über **HTTP oder WebSocket** — die Unterstützung wird als *« a work in progress »* deklariert, mit aktiver Zusammenarbeit mit agentischen Plattformen. Der zweite Modus wird in der sekundären Berichterstattung regelmäßig ausgelassen, obwohl er die unternehmerische Ausrichtung des Protokolls vorzeichnet. **Die Verbindung zu MCP** ist enger als eine architektonische Komplementarität: ACP *« re-uses the JSON representations used in MCP where possible »* und ergänzt gleichzeitig Typen, die spezifisch für die UX des agentischen Codings sind — die **Diff**-Anzeige wird als Beispiel genannt. Das Standardformat für lesbaren Text ist **Markdown**, gewählt genau deshalb, damit der Editor nicht zum Rendern von HTML gezwungen ist. **Zwei Beobachtungen zur Quelle selbst.** Die Navigation zeigt **v1 (Latest)** und **v2 (Draft)** — nicht die „ACP 1.2“, die andernorts kursiert. Und sie verlinkt **Zed Industries und JetBrains auf derselben Ebene**, neben einer **ACP Registry**, **RFDs**, einem Community-Bereich, Publications, Updates und einer Brand-Seite: die Struktur eines gemeinschaftlich geführten Projekts mit einem Prozess. Offizielle Bibliotheken in Kotlin, Java, Python, Rust und TypeScript.

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

Sun, 02 Aug 2026 00:00:00 GMT

Tech-Watch-Notiz vom **2. August 2026**, entstanden aus der Frage eines Kollegen — *"Was ist ACP?"* —, bei der der Autor zeigt, dass es keine einfache Antwort gibt: **Drei Protokolle konkurrieren um das Akronym**, ohne jede technische Überschneidung. **Agent Client Protocol** verbindet **einen Client mit einem Agenten**. Von **Zed** im August 2025 eingeführt, leistet es für Agenten, was **LSP** für Sprachen leistete: Es entkoppelt den Editor vom Agenten. Zuvor erforderten N Editoren × M Agenten **N×M** maßgeschneiderte Integrationen; danach sprechen alle das Protokoll, und **N+M** genügt. JSON-RPC 2.0 über stdio, Apache-2.0. Die Notiz weist darauf hin, dass das Protokoll die Umlaufbahn seines Schöpfers verlassen hat — eine eigene Organisation, eine Agenten-Registry, eine versionierte Spezifikation, eine JetBrains-Implementierung. **Agentic Commerce Protocol** hat damit nichts zu tun: Es verbindet **einen Agenten mit einem Händler** (Discovery, Warenkorb, Zahlung). Am 29. September 2025 von **OpenAI und Stripe** angekündigt, steht es **Googles** **UCP** (11. Januar 2026) gegenüber, das sich für die Zahlung auf **AP2** stützt. Der Einsatz: die "Visa/Mastercard"-Schicht des Agentic Commerce. **Agent Communication Protocol** (IBM Research / BeeAI), Agent-zu-Agent, rundet das Bild ab und verfälscht Suchen. **Das beobachtete Problem ist dokumentarischer Natur.** Der Autor sucht "ACP" in seiner Tech-Watch-Datenbank: **zwölf Treffer, alle zum Commerce-Protokoll, keiner zu dem von Zed**. Die Indexierungs-Agenten hatten das Akronym verarbeitet, ohne es zu disambiguieren. Daraus die übernommene Regel: ***"ein nacktes Akronym wird nie indexiert"*** — die Entität ist der vollständige Name, das Akronym ist nur ein **Alias**, hier getragen von drei verschiedenen Entitäten. Die Notiz räumt nebenbei mit einer verwandten Verwechslung auf: **MCP** verbindet einen Agenten mit seinen **Tools**, **ACP** verbindet einen **Client** mit einem **Agenten**, und beide **stapeln sich**. **Der konkrete Fall ist Buzz**, von **Block** am 21. Juli 2026 unter Apache-2.0 veröffentlicht: ein selbst hostbarer Arbeitsbereich auf **Nostr**, in dem Menschen und Agenten dieselben Kanäle teilen, wobei jeder Teilnehmer ein **Schlüsselpaar** ist und jedes Ereignis — Nachricht, Workflow-Schritt, Git-Push — in einem Append-only-Log **signiert** wird. Die Agenten-Architektur ist vollständig protokollbasiert (`buzz-acp`, `buzz-agent`, `buzz-dev-mcp`), daher die Agnostizität: **Goose, Claude Code und Codex** über dasselbe Harness, und **Hermes** hat sich verbunden, ohne dass auf Blocks Seite eine einzige Codezeile geschrieben wurde. *"N+M statt N×M, im Produktivbetrieb."* **Die Pointe betrifft das Claude-Abonnement** im Verhältnis zu Drittanbieter-Agenten, nach einem turbulenten Jahr 2026 (OAuth-Blockade, separate Credits angekündigt und dann am Tag ihres Inkrafttretens ausgesetzt). Die gezogene Grenze trennt die **gewöhnliche, individuelle** Nutzung von der **Weiterleitung fremder Anfragen**. Ihre Formulierung gilt über diesen Fall hinaus: *"die Unterscheidung ist nicht rechtlicher, sondern architektonischer Natur: **wer konsumiert, und in wessen Auftrag**"* — eine Frage, die bereits beim Design geklärt werden sollte, statt beim Lesen der Nutzungsbedingungen.

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

Thu, 30 Jul 2026 00:00:00 GMT

Fünfte Episode der SFEIR-Reihe zum erweiterten SDLC, gewidmet der Review-Phase, veröffentlicht am selben Tag wie der LinkedIn-Beitrag von Addy Osmani, den sie in eine Phasenspezifikation überführt. Die Ausgangsbeobachtung: Qualität wurde früher im Code gelesen; Agenten produzieren heute mehr davon, als irgendjemand reviewen kann. Sie hat deshalb **die Adresse gewechselt** — sie lebt jetzt in **dem Ring von Constraints**, der den Agenten umgibt, also im Harness. Sieben Dimensionen bilden diesen Ring (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. Das Korollar stellt die vorherrschende Intuition auf den Kopf: 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." Daraus folgt die zentrale Architekturentscheidung: Im Elf-Phasen-Zyklus ist **Review kein menschliches Gate** — und das ist Absicht. Die drei unantastbaren Gates sind Define, Plan und Ship. Würde Review das Gate tragen, würde menschliche Aufmerksamkeit — eine endliche Ressource — zum Kontrollpunkt einer Generierung, die selbst skaliert: der Hals würde sich nie weiten. **Review instrumentiert, Ship entscheidet**; Review erzeugt einen widerlegbaren Beweiskörper, und die Entscheidung fällt anhand der Evidenz, nicht anhand des vollständigen Diffs. SFEIR übernimmt von Monperrus, dass menschliche Inspektion jedes Diffs der agentischen Geschwindigkeit nicht standhält, lehnt aber seine Schlussfolgerung ab: Abnahme kann nicht delegiert werden. Die operative Übersetzung ist eine Tabelle Dimension für Dimension, die trennt, was mechanisierbar ist, von irreduzibel menschlichem Urteilsvermögen. Die systematisch vergessene Dimension ist die **Verständlichkeit**, „weil sie die CI nicht bricht" — daher die günstigste Abhilfe im Raster: den Agenten protokollieren zu lassen, was er versucht und verworfen hat, denn „Absicht geht nicht verloren, sie wird verworfen." Der benannte Fehlermodus ist die **zirkuläre Validierung**: Der Agent, der den Code schreibt, schreibt auch die Tests, die ihn validieren, die CI ist grün, „man hat einen Spiegel gebaut, keinen Ring." Fünf Gegenmaßnahmen stammen von Anthropic (unabhängige Gates, deterministisch + agentisch, Shadow Mode, risikobasierte Stufung, SIEM-Logging), und Compare the Market warnt, dass ein auf Vektor-RAG aufgebauter Reviewer die Review-Qualität verschlechtert (~70 % bei einem AST-Graphen gegenüber ~58 %). Die eigene Erweiterung der Firma ist **das Ratschenprinzip**, angebunden an Compound-1: Jedes Entkommen wird zum Constraint. Der Ring verdickt sich mit jedem Zyklus — „das einzige Asset in der Kette, das an Wert gewinnt, während die Modelle an Wert verlieren" (−30 % Fix-Iterationen nach zehn Zyklen, interne Messung). Es bleibt nur eine Frage: **Was lässt mein System nicht durch?**

Mon usine logicielle à l'heure de l'IA

Tue, 28 Jul 2026 00:00:00 GMT

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

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

Sun, 26 Jul 2026 00:00:00 GMT

Fünf Tage nach dem Debriefing von Jason Clinton (Anthropics Deputy CISO) zur Absicherung eines Entwicklungszyklus, der KI-nativ geworden ist, veröffentlicht SFEIR eine Dekonstruktion, die nichts bestreitet und keine Tatsache hinzufügt: Sie **verschiebt das Thema**. Der Leser kommt auf der Suche nach Sicherheitskontrollen, und ihm wird gezeigt, dass zuerst ein Zyklus fehlt. Die Darstellung ist getreu. Drei von Anthropic selbst berichtete Eingangsgrößen: ×8 ausgelieferter Code pro Ingenieur und Quartal, ~80 % des gemergten Codes von Claude geschrieben, mehr als die Hälfte von der internen Version von Claude Tag gemergt. Ein Problem, das durch **Amdahls Gesetz** gestellt wird: Wenn Review und Monitoring nicht im gleichen Tempo skalieren wie die Produktion, wird die Beschleunigung zum Engpass. Ein explizites Bedrohungsmodell (kompromittierter oder durch Prompt-Injection manipulierter Agent, Dependency Poisoning, erhöhtes Volumen klassischer Schwachstellen). Dann eine Kontrolle, die pro Phase zugeordnet wird: **PSR** bei Plan, **CLAUDE.md** und **Egress-Allowlist** bei Code, **spezialisierte Review-Agenten** bei Test, **kontinuierliches DAST** bei Deploy, **Triage und SIEM-Routing** bei Monitor. Die These trägt sich in einer vierteiligen Anapher. **Ohne SDLC materialisieren sich keine Gewinne**: Das Achtfachen des Codevolumens vervielfacht nichts, wenn das Review sequenziell bleibt — 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." **Ohne SDLC hat Sicherheit keinen Anker**: Ein Gate ist per Definition eine zwischen zwei Phasen platzierte Kontrolle. **Ohne SDLC lässt sich keine Token-FinOps-Politik formulieren**: Scannen wird nach Verbrauch abgerechnet und wächst mit dem Code-Durchsatz, sodass die **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." **Ohne SDLC gibt es nichts zu messen**: Der Anstieg von 16 % auf 54 % kommentierter PRs setzt eine Phase voraus, an der ein Zähler platziert werden kann; ohne das produziert man nur Nutzungszahlen, die zu Qualität und Risiko schweigen. Zwei Beiträge jenseits der These. Die Lesart des incident agent-à-agent — ein Incident-Response-Agent, der eine andere Claude-Instanz über Slack bittet, einen Fix zu pushen, gestoppt durch ein menschliches Gate: „ein Perimeter, der auf einer Anweisung in einem Prompt beruht, ist kein Perimeter", und der Zugriff eines Agenten auf andere Agenten ist Teil seiner Angriffsfläche. Und ein klarer Vorbehalt: Diese Zahlen stammen vom Anbieter des Modells, auf einer jungen Codebasis ohne Mainframe. **Was sich übertragen lässt, ist die Methode, nicht die Zahlen.**

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

Wed, 22 Jul 2026 00:00:00 GMT

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

How Anthropic secures its AI-native software development lifecycle

Tue, 21 Jul 2026 00:00:00 GMT

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.

Buzz!

Tue, 21 Jul 2026 00:00:00 GMT

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

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

Mon, 20 Jul 2026 00:00:00 GMT

Udit Akhouri veröffentlicht **ADHD** („ein Skill für Agenten“), ein Open-Source-Projekt (MIT, v0.1.4, ca. 1.000 Stars), das die **vorzeitige Konvergenz** autoregressiven Schließens angeht: Ein LLM verankert sich an seiner ersten Idee, und baumbasierte Methoden entkommen dem nicht wirklich — „Tree-of-Thought erweitert die Suche, durchläuft aber einen einzigen gemeinsamen Kontext, sodass die Verankerung über die Zweige hinweg bestehen bleibt.“ Die Position des Projekts: Dies ist ein **Architekturproblem, kein Prompting-Problem**. Die Mechanik besteht aus zwei **wasserdichten** Phasen. *Diverge*: N parallele, **isolierte** Agentenaufrufe — ohne gemeinsamen Kontext —, die das Problem jeweils über einen von **15 kognitiven Frames** erhalten, die bewusst verzerrt sind (mit Auswahllogik und benutzerdefinierten Frames), unter einem System-Prompt, der **das Bewerten verbietet**. *Focus*: Ein **separater** Kritiker, mit einem gegensätzlichen System-Prompt, bewertet die Ideen (Originalität, Machbarkeit, Passung), clustert sie nach zugrunde liegendem Blickwinkel, **markiert die Fallstricke samt Begründung** und vertieft die besten Überlebenden. Die Trennung von Generator und Kritiker ist „mechanisch“: getrennte LLM-Aufrufe, keine innerhalb eines einzigen Kontexts simulierten Rollen — dieselbe Intuition wie beim Adversarial Review mit getrenntem Kontext des Bun-Projekts ([[sumner-bun-rewrite-rust-claude-2026-07-08]]). Die Signature-Demo vergleicht anhand „einer CLI, die ein LLM aufruft und manchmal für 90s einfriert“ die Baseline (4 Lehrbuch-Muster: progressive Timeouts, exponentieller Backoff, Hedged Requests, Streaming — „die Antwort, die ein Senior in 30 Sekunden gibt“) mit ADHD: 30+ Ideen in 6 Clustern, **20 benannte Fallstricke** und eine nicht offensichtliche Wahl — den **„Rage-Quit“**-Button, der sich mit der Wartezeit aufheizt und die Anfrage sofort zu einem schnelleren, günstigeren Modell umleitet, weil „das langsame Modell für diesen Prompt schlicht das falsche Modell sein könnte“. Bei 6 offenen Problemen ergibt die Bewertung des Autors (LLM-Richter) eine Breite von 9,00 vs. 4,83, Neuheit 7,83 vs. 2,67, **Fallstrickerkennung 9,50 vs. 1,83**, Umsetzbarkeit 9,50 vs. 6,50 — selbstberichtete Zahlen, die als Behauptungen zu lesen sind. Die Distribution läuft über das **skills**-Ökosystem (derselbe Kanal wie [[skill-pocock-grill-with-docs-2026-06]]): `npx skills add UditAkhourii/adhd` erkennt automatisch ~50 Agenten (Claude Code, Cursor, Codex, Cline, Gemini CLI, Windsurf…), Aufruf über `/adhd` oder automatische Auslösung bei Ideenfindungs-Intents, eine CLI und eine npm-Bibliothek, alle auf den Claude- und Codex-Agent-SDKs aufgebaut. Die Traktion ist greifbar: ein Feature auf The New Stack, ein Preprint, Übernahme durch repowire (PR #313 gemerged — die Frames werden zu „Peers“ des Mesh-Orchestrators), mstack (`think`-Plugin), zk-flow-oss und ein unabhängiger Forschungsreview (testdouble/han), dessen Erkenntnisse in öffentlichen Issues weiterleben. Fazit: nützliche Divergenz wird nicht promptet, sondern **architektiert** — durch Kontextisolation und die mechanische Generator/Kritiker-Opposition.

Reflecting on a year of Claude Code

Fri, 17 Jul 2026 00:00:00 GMT

Boris Cherny (**Head of Claude Code**) und Cat Wu (**Head of Product, Claude Code**) veröffentlichen auf LinkedIn, via Claude for Business, ein kurzes (~47 s) Video mit dem Titel **„Reflecting on a year of Claude Code“**. Ihre These: im Zeitalter der Coding-Agenten **verschmelzen Produkt- und Engineering-Rollen**. „Is everyone going to be a PM or is everyone going to be an engineer? Everyone's going to be both.“ **Beweis am Beispiel: der interne Fall.** Cherny beschreibt, wie Anthropic als Demonstration operiert: das Produktteam, DevRel und Design **schreiben alle Code**; umgekehrt **liefern** viele Engineers Produkte **End-to-End** — sie haben eine Idee, was zu bauen ist, bauen es, und arbeiten dann mit Legal, Marketing und Security zusammen, um zu kommunizieren und Sicherheit zu gewährleisten. Fazit: KI **begünstigt Profile** mit **Neugier**, **Produktgespür** und einem Faible für **End-to-End-Verantwortung**. **Der eigentliche Inhalt: der Kommentarthread.** Von 55 Kommentaren tragen 28 eine inhaltlich substanzielle Idee bei und bilden ein öffentliches Peer-Review entlang von acht Achsen. Die **dominierende** Neueinordnung: es sind nicht die Rollen, die verschwinden, sondern die **Verkürzung der Feedback-Schleife**. Rehan Nazir — wenn ein PM eine Idee mit einem noch am selben Tag erstellten Prototyp validiert, „hören Organigramme auf, eine Rolle zu spielen“; Noman A. — Ideen werden in Stunden statt Wochen getestet, was verändert, *wie Unternehmen lernen*; Kevin Schoovaerts — Claude Code baut 80 % des Produkts, die eigentliche Kraft liegt in der engen Schleife mit dem Nutzer. Zweite, tiefere Achse: die **knappe Fähigkeit verschiebt sich** von „wissen, wie man baut“ hin zu **Urteilsvermögen** und der **Definition des richtigen Problems** (Omer K., meistgeliketer Kommentar: „choosing the right problems, knowing what NOT to build“; Syed T.; Andrei van Noordt: die knappe Einstellung wird zur Person mit Gespür dafür, *was* gebaut werden soll und die es auch bauen kann; Natasha Newbold: man wird zum **Architekten**, der die Spezifikationen schreibt, die Teams von Agenten ausführen). Sunny Vara verschiebt den entscheidenden Faktor vom Prompt hin zum **Kontext**. **Der Gegenpunkt.** Eine Ebene wirft die Fragen auf, die das Video umgeht: Paul Breuler und Ron H. — die Verantwortung wächst, also wächst auch die **Rechenschaftspflicht**; „wenn jeder bauen kann, muss jemand trotzdem in der Lage sein, Nein zu sagen.“ Mohammadjavad Sayadi — die **Lücke zwischen Demo und Produktion** bleibt in regulierten Bereichen (Gesundheitswesen) erheblich. Die **Skeptiker** (Chris Bounds, Mohamed Anis, Panny Malialis, David H.) warnen davor, eine Startup-typische Arbeitsweise zu verallgemeinern. Schließlich üben zwei **frontale Kritiken** (James Hutchinson, Dewayne J Grunden II) scharfe Kritik am **Diebstahl geistigen Eigentums** und fordern, Modelle als Open Source zu veröffentlichen und Urheber zu entschädigen. In einem Satz: der Konsens bestätigt die These, ordnet sie aber neu ein — **das Ausliefern wird billig**, was den Wert in Richtung **Urteilsvermögen, Produktgespür und das richtige Problem** verschiebt, während Rechenschaftspflicht, Governance und Zuverlässigkeit noch nicht nachgezogen sind.

The Token Manifesto

Fri, 17 Jul 2026 00:00:00 GMT

**Nicolas Martignole** veröffentlicht auf *Le Touilleur Express* **« The Token Manifesto »**, einen kurzen satirischen Text, gemeinsam verfasst mit zwei Modellen (**GLM-5.2** und **MiniMax-M3**). Die Mechanik ist klar: Man übernimmt die exakte Struktur des **Manifeste Agile** von 2001 — seine Präambel, seine vier Werte in der Form „X statt Y“, seine zwölf Prinzipien — und überträgt sie auf die Welt der LLMs, in der die Recheneinheit nicht mehr die Ingenieurstunde, sondern das **Token** ist. Die Präambel gibt den Ton vor: „Wir entdecken bessere Wege, Kontext zu verbrauchen, indem wir es tun … Durch die Arbeit des Erzeugens von Tokens, des Löschens von Tokens und **nervösen Starrens auf eine Nutzungsanzeige** haben wir gelernt zu schätzen … “. **Die vier Werte** skizzieren eine Ästhetik des sparsamen Prompts: *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*. Jeder Wert stellt eine sparsame Praxis (Prägnanz, Beispiel, Iteration, eingeschränktes Format) einer kostspieligen Versuchung gegenüber (Raffinesse, Weitschweifigkeit, ein umfangreiches Lastenheft, eine unbeschränkte Antwort). **Die zwölf Prinzipien** unterlaufen die des Agilen Manifests eines nach dem anderen. Die Priorität wird zur Lieferung „**der Antwort, nicht des Weges zur Antwort**“; das Manifest „begrüßt sich ändernde Anforderungen, selbst spät im Gespräch“; es baut „auf motivierten Individuen mit einem **angemessenen Kontextfenster**“ auf; „funktionierende Prompts messen den Fortschritt **und die Rechnungen**“. Das meistzitierte Prinzip kehrt das berühmte zehnte Prinzip von Agile um: „**Einfachheit — die Kunst, die Menge an Arbeit zu maximieren, die nicht vom Modell erledigt wird**“. Andere zielen auf Kontextschulden („Wiederholungen erkennen und einmal dokumentieren“) und ökonomische Nachhaltigkeit ab („ein Prompting-Tempo, das sich unbegrenzt durchhalten lässt“, „regelmäßige Reflexion **bevor die Monatsrechnungen eintreffen**“). Zwei Pointen beschließen das Manifest und tragen unter dem Humor seine ernsthafte These: **« Du hast kein Prompt-Problem. Du hast ein Kontextfenster-Problem. »** — eine Verlagerung der Aufmerksamkeit vom *Prompt Engineering* hin zur **Ökonomie des Kontextfensters** — und **« Jeder ist ein Prompt Engineer, bis das Monatskontingent aufgebraucht ist. »** — eine ironische Erinnerung daran, dass sich das wahre Können am Nutzungszähler bemisst. Jenseits des Scherzes kristallisiert der Text einen kulturellen Wandel heraus: In der Ära KI-gestützter Entwicklung ist der strukturierende Engpass nicht mehr die **Geschwindigkeit** (die Obsession von Agile), sondern das **Token-Budget** und das Kontextmanagement. Die Ko-Autorschaft von Mensch und Modellen fungiert als Meta-Signatur: ein Plädoyer für Token-Sparsamkeit, verfasst mit Hilfe eben jener Modelle, deren Sparsamkeit es lehrt.

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

Thu, 16 Jul 2026 00:00:00 GMT

Boris Cherny, Creator & Head of Claude Code bei Anthropic, veröffentlicht eine Framework-Tabelle — **« Steps of AI Adoption »** — entstanden aus einer wiederkehrenden Beobachtung: In vielen Unternehmen vervielfacht *eine einzelne* Person ihren Output mit Claude um das Zehnfache, aber der Rest der Organisation zieht nicht nach. Daraus leitet er eine **5-stufige Reifeskala (0→4)** ab, strukturiert um die **Größenordnung der von einem Engineer gesteuerten Agenten** — und die dadurch erzwungene Rollentransformation. **0 — Gated (0 Agenten)**: abgeschotteter Zugang, ältere Modelle, keine MCP-Governance und keine Infrastruktur, um Claudes Code zu hosten; Engpass = veraltete Sicherheits-/Freigabeprozesse und eine Fixierung auf Kosten pro Token. **1 — Assisted (~1)**: „du + ein Agent“, betreutes Pair Programming, synchrone Arbeit; Engpass = deine Aufmerksamkeit, da du ohne Self-Verification alles selbst prüfst. **2 — Parallel (~10)**: du wirst zum **Orchestrator** von 5–10 Agenten auf getrennten Worktrees; Claude verifiziert sich selbst (Tests/Build/Lint/Security), Auto mode und automatisierte Reviews sind Standard; Engpass = das Prüfen mehrerer paralleler Stränge. **3 — Supervised autonomy (~100)**: **Manager of Managers**, Claude schreibt fast alles, Wartung läuft im Hintergrund; Engpass = Vertrauen in die Loop und der Entscheidungsdurchsatz. **4 — AI-native (~1.000+)**: **VP Steering by Intent**, eine geschlossene Loop, in der Claude die meisten Agenten selbst startet, Überwachung nach dem Ausnahmeprinzip. **Zentrale These**: Tokens bringen keinen Stufenaufstieg. Jede Stufe hat ihren eigenen Engpass; Fortschritt entsteht durch **dessen Auflösung** und den **Aufbau des nächsten Satzes an Guardrails**, der den Output vertrauenswürdig macht. Die genannten Hebel: Self-Verification-Loop (Tests + Build + Lint + E2E in einer echten Umgebung), **Auto mode** gegen blockierende Abfragen, **Code-Review + Security-Review als Standard**, Multi-Agenten-Oberflächen (Agent View, Desktop, Mobile, Tag), dann `/loop`, `/batch`, `/goal`, **dynamische Workflows**, **worktree isolation**, **CLAUDE.md + Skills** zur Kodifizierung von Standards, und schließlich das **Claude Agent SDK**, um Agentenflotten programmatisch zu bauen und zu steuern. Zum Thema Steuerung verwirft Cherny die Vanity-Metrik: Nutzung misst **Aktivität, nicht Ertrag**. Die richtige Frage — *hätten wir diesen Aufwand ohnehin investiert, und wie viele **manuelle Engineer-Stunden** hätte es gekostet?* — liefert den wahren ROI. Der entscheidende Gewinn kommt, wenn Fixes/Wartung in den Hintergrund wandern und Teams frei werden, um Dinge zu *bauen*, die zuvor nicht einmal in Reichweite lagen. Ein ehrlicher Maßstab: Anthropic steht auf Stufe 3 und strebt Richtung 4; er selbst habe soeben Stufe 4 erreicht.