Engineering-Beitrag von **Anthropic**, veröffentlicht am **14. September 2026** auf claude.com/blog (~1.400 Wörter, fünf Abschnitte), verfasst von **Sachin Malhotra**. Er schildert die Skalierung des **Test-Impact-Analyse**-Dienstes — der Auswahl, welche Tests bei welcher Änderung laufen — unter dem Druck des agentischen Codings. Die Ausgangszahlen und ihre Kausalkette: Die Entwickler liefern im Schnitt **8×** mehr Code pro Quartal als 2021–2025, **Claude schreibt 80 % davon** und trägt auch bei PR-Review und -Freigabe erheblich bei; die Anzahl der Tests wurde bei annähernd konstanter Teamgröße mit **10** multipliziert; daraus folgen **25× CI-Jobs in sechs Monaten**. **(A)** Die v0-Architektur beruht auf zwei Komponenten, die synchron bleiben müssen — einem *Listener*, der die Ergebnisse jedes Laufs erfasst, und einem *Selector*, der entscheidet, welche Tests bei jedem PR laufen —, jedoch als **einziger Prozess**, mit einer Pro-Test-Historie, die einen einzigen Writer voraussetzt. **(B)** Der Fehlermodus besteht darin, dass der Listener hinter die PR-Warteschlange zurückfällt: *« 20 Minuten Listener-Verzögerung können bedeuten, dass Zehntausende Testaktualisierungen nicht übernommen werden »*, mit drei benannten Folgen — verschwendete Untersuchungen, *flaky reds*, die Merges blockieren, ein behobener oder hinzugefügter Test, der nicht läuft. **(C)** Drei Patches, deren Lebensdauer einbricht — **70 Tage, 29 Tage, weniger als ein Tag**: eine größere Maschine, Sharding nach Package, tägliche Neustarts. Dann die Grundüberarbeitung: ein **arbeitsspeicherbasiertes** magasin de données en mémoire, **zustandslose** *Listener*-Worker, die dadurch horizontal skalierbar sind, ein alle paar Sekunden aggregiertes Log. **Drei Wochen für einen Entwickler; ein Jahr zuvor ein Quartal.** Erweitert die 80 % aus [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] auf die Infrastruktur.
#Continuous Integration#CI#Test-Impact-Analyse
Sachin Malhotra (ingénieur, Anthropic) · sur le blog claude.com.
Produktankündigung von **Block Engineering**, gezeichnet von **Thomas Petersen** (*Principal Designer & Builder*), veröffentlicht am **18. August 2026**, ~1.800 Wörter in dreizehn kurzen Abschnitten, die **Buzz Projects** vorstellt — eine **Software-Forge, gehostet auf dem eigenen Relay**: Git-Repositories, Branches, Pull Requests, Issues, Review und Merge, Multi-Repo-Projekte, ein Activity Feed, alles verknüpft mit Conversation-Channels. Vorspann und These des Beitrags: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Drei Beiträge. **(A) Eine Vertrauensdoktrin, die auf *ex post*-Nachweis statt auf *ex ante*-Autorisierung beruht**: auf der einen Seite *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, auf der anderen *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; der Abschnitt schließt mit einer angekündigten Richtung — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Git-Interoperabilität ohne proprietäres Tooling**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, wobei die clé Nostr als einzige Identität dient — *« The same npub that signs your messages signs your pushes. »* **(C) Eine Unterscheidung zwischen Ausführungsfläche und Netzwerkpräsenz**: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* Der Beitrag liefert keine Zahlen und enthält keine ausgehenden Links; er qualifiziert sich sechsmal selbst als vorläufig (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), und Projects befindet sich unter dem Tab **Experiments** von Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
SFEIRs Dekonstruktion (Unternehmensstimme) des fünf Tage zuvor veröffentlichten Debriefings von Jason Clinton (Deputy CISO, Anthropic) — bereits dokumentiert in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **Der Mehrwert liegt nicht in den Fakten, sondern in der These, die sie neu liest**: Wenn Anthropics Kontrollen greifen, dann weil **ein Zyklus mit benannten Phasen existiert, an dem sie sich festmachen lassen** — „der SDLC ist das Fundament, keine Formalität." Die Beweisführung geht vor, indem sie zunächst das Mapping nachliest (**PSR bei Plan, CLAUDE.md + Egress-Allowlist bei Code, Review-Agenten bei Test, kontinuierliches DAST bei Deploy, Triage + SIEM-Routing bei Monitor**), und dann eine **vierteilige Anapher** entfaltet: (1) *ohne SDLC materialisieren sich keine Produktivitätsgewinne* — Clinton zitiert **Amdahls Gesetz**: Das Achtfachen des Codevolumens vervielfacht nichts, wenn das Review sequenziell und menschlich bleibt, und Anthropic hat seine Gewinne nicht durch die Verteilung von Agenten erzielt, sondern indem es **die blockierende Phase (Test) identifiziert und neu aufgebaut hat** — „man optimiert keinen Engpass, den man nicht kartiert hat" (ein Echo des **Spiegeleffekts** aus DORA 2025); (2) *ohne SDLC hat Sicherheit keinen Ankerpunkt* — ein **Gate ist per Definition eine zwischen zwei Phasen platzierte Kontrolle**, und Clintons drei Bedrohungen werden an unterschiedlichen Zeitpunkten adressiert; (3) *ohne SDLC lässt sich keine **Token-FinOps**-Politik formulieren* — agentisches Scannen wird nach Verbrauch abgerechnet und wächst mit dem Code-Durchsatz, sodass **risikobasierte Stufung DIE FinOps-Politik IST** (sie entscheidet, wo drei Agenten-Durchläufe bezahlt werden und wo ein SAST genügt), andernfalls wird „der Token-Verbrauch nicht gesteuert, sondern erst am Monatsende entdeckt"; (4) *ohne SDLC gibt es nichts zu messen* — die Indikatoren (16 % → 54 % kommentierte PRs, ein Drittel der vergangenen Vorfälle abgefangen) existieren nur, weil es Phasen gibt, an denen ein Zähler platziert werden kann; ohne das produziert man nur **Nutzungszahlen** (Lizenzen, Token), die nichts über Qualität oder Risiko aussagen. Zwei starke Punkte jenseits der These: die Lesart des **incident agent-à-agent** („ein Sicherheitsperimeter, der auf einer Anweisung in einem Prompt beruht, ist kein Perimeter"; **der Zugriff eines Agenten auf andere Agenten ist Teil seiner Angriffsfläche**) und ein **expliziter methodischer Vorbehalt** — Anthropics Zahlen über Anthropic, ungeprüft, veröffentlicht vom Anbieter des beschriebenen Modells, im Kontext einer jungen Codebasis ohne Mainframe: **was sich übertragen lässt, ist die Methode, nicht die Zahlen**.
#SDLC#KI-nativer SDLC#Entwicklungszyklus
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)