thekb.eu — Architektur & Konstruktion

DuckDB and the changing physics of analytics

Wed, 26 Aug 2026 00:00:00 GMT

Andy Warfield, Ingenieur im S3-Team bei AWS, veröffentlichte am 26. August 2026 einen Gastbeitrag auf All Things Distributed, eingeleitet von Werner Vogels. Darin erklärt er, warum eingebettete analytische Engines wie DuckDB an Bedeutung gewinnen, und kündigt an, dass DuckLabs, das Team hinter der Entwicklung von DuckDB, zu AWS stößt. Sein Deutungsraster ist das einer sich verändernden „Physik". Während die Naturwissenschaften Invarianten erforschen, sucht die Systeminformatik den eleganten Kompromiss gegenüber Verhältnissen, die sich verschieben: Speichergeschwindigkeit gegenüber Netzwerkgeschwindigkeit, Reichhaltigkeit der Abstraktionen gegenüber verfügbarer Leistung. Er zitiert drei Momente — das NOW-Projekt in Berkeley, seine eigene Arbeit an Xen sowie die Forschung zu MonetDB und X100 am Amsterdamer CWI, wo sich der Engpass der Abfrageverarbeitung von der Festplatte zur CPU verschoben hatte — und stellt fest, dass diese Beschränkungen zyklisch wiederkehren. Auf Daten angewendet, erklärt dieses Raster die verteilte Verarbeitung. Verarbeitung ist auf einer einzelnen schnellen Maschine immer einfacher und effizienter, aber wenn die Festplatte oder Netzwerkkarte eines Servers das gewünschte Volumen nicht mehr lesen kann, wird partitioniert. Das war die Beschränkung der frühen 2000er-Jahre, die MapReduce und später die RDDs von Spark hervorbrachte. Warfield hebt zwei Eigenschaften dieser Systeme hervor: Sie innovierten stark bei der Entwicklerergonomie und akzeptierten einen festen Kosten für Planung und Verteilung, wobei sie auf den durch das Hinzufügen von Maschinen gewonnenen Durchsatz setzten statt auf Effizienz pro Einheit. Doch die Verhältnisse haben sich verändert. Eine aktuelle Instanz bietet etwa das Fünfzigfache an Speicher, Kernen und Netzwerkbandbreite der größten EC2-Instanz von 2007, während das Wachstum der Datensätze einer Verteilung folgt, deren Extremfälle den Schwanz bilden. Das Paper Scalability! But at what COST? von 2015 hatte bereits gezeigt, dass eine sorgfältig optimierte Einzelthread-Implementierung verteilte Frameworks schlagen konnte, die auf hundertachtundzwanzig Kernen liefen. DuckDB, 2018 von Hannes Mühleisen und Mark Raasveldt lanciert, wendet diese Logik an: eine analytische Bibliotheks-Engine, die prozessintern im Adressraum der Anwendung läuft und dem Vertriebsmodell von SQLite folgt. AWS wurde Kunde von DuckLabs und anschließend Sponsor der Iceberg-Erweiterung, parallel zu seiner Arbeit an S3 Tables; die Erweiterung unterstützt inzwischen Iceberg v2 und v3 und überschreitet 800.000 Downloads pro Woche. Warfield präsentiert das eingebettete Modell nicht als Ersatz: Wenn ein Job tausend Maschinen benötigt, benötigt er sie. Was sich ändere, schreibt er, sei, dass ein Großteil der an Daten geleisteten Arbeit tatsächlich nie einen Cluster benötigt hatte. DuckLabs stößt als Tochtergesellschaft zu AWS, wobei das Projekt unter der MIT-Lizenz und unter der Aufsicht der DuckDB Foundation quelloffen bleibt.

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.

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

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.

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.

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.

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.

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

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.

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Mon, 20 Jul 2026 00:00:00 GMT

Innerhalb von neun Monaten haben Amazon, Microsoft und Google jeweils eine Enterprise-Agentenplattform gestartet oder umbenannt, und **alle drei sind auf dieselbe Architektur konvergiert**: Runtime, Memory, Tool-Gateway, Identität, Observability und Governance finden sich nun in **Bedrock AgentCore**, **Microsoft Foundry** und der **Gemini Enterprise Agent Platform**, unter unterschiedlichen Namen. Was vor 18 Monaten noch eine fragmentierte Sammlung von Bibliotheken war, wird zu einer eigenständigen **Plattformschicht**. Um zu verstehen, wohin das führt, greift Janakiram MSV auf die **PaaS-Wende von 2011–2016** zurück. Zuvor stellten Teams VMs, Load Balancer, Warteschlangen, Secret Stores und Monitoring-Agenten zusammen, jeweils mit eigener API. **Cloud Foundry** und **Heroku** vereinheitlichten diese Bausteine um einen **Anwendungsvertrag**: Die Anwendung deklariert, was sie benötigt, und bleibt agnostisch gegenüber dem Ort ihrer Ausführung. Entscheidend war der **Vertrag, nicht die Implementierung**. Cloud Foundry hat den Markt nicht gewonnen — das tat Kubernetes —, aber seine Prinzipien überlebten (Buildpacks → Cloud Native Buildpacks/CNCF; die Cloud-Foundry-Abstraktion auf K8s neu aufgebaut über Korifi). Das Agenten-Ökosystem nähert sich derselben Wende **ohne einen gleichwertigen Vertrag**, und kein Open-Source-Projekt hat ihn für sich beansprucht. Die Kosten sind konkret: Sitzungszustand, Traces und Identität **landen allesamt bei einem einzigen Anbieter**; einen Agenten ein Jahr später zu verschieben erfordert, **alles neu aufzubauen**. Die Konvergenz ist keine Verschwörung, sondern rationales Verhalten — vertikale Integration, „dort liegt die Marge“ —, dessen Konsequenz auf den Kunden fällt. Der Autor schlägt eine **Abbildung** des Cloud-Foundry-Vertrags auf Agenten vor (App-Quelle → Code+Eval; Buildpack → Packaging; Backing Service → Modell/Memory; Binding → authentifizierte Anbindung; Router → MCP/A2A; Logs → Traces/Kosten/Qualität; Promotion → Eval/Versionierung; Policy → Identität), gefolgt von drei Prinzipien: den Agenten als **eine einzige deploybare Einheit verpacken** (AWS kommt dem mit seinem *harness export* zu Strands-Code nahe, „der richtige Instinkt, gerichtet auf eine einzelne Cloud“), **Fähigkeiten anhängen statt Anbieter einzubetten** (die Lehre aus Twelve-Factor), **die operative Schicht in die Abstraktion integrieren**. Ein Agent ist keine Web-App: probabilistisches Verhalten, delegierte Befugnis, Abhängigkeiten, die das Verhalten ändern, ohne dass ein Deployment stattfindet. LangGraph demonstriert dies im Open Source, doch seine Control Plane sitzt in LangSmith (einem kommerziellen Produkt). Offene Protokolle (MCP, A2A, OpenTelemetry, OCI) liefern nahezu alle Primitiven, aber **nicht den Lebenszyklus**: Versionierung, Promotion, Rollback. Die **Linux Foundation** hat die **Agentic AI Foundation** ins Leben gerufen (Dez. 2025, Gründungsprojekte MCP/goose/AGENTS.md, Hyperscaler als Platin-Mitglieder). Drei Due-Diligence-Fragen bleiben — **Governance, Packaging, Zustand** —, die kein offenes Projekt beantwortet. Wer am Ende die **Agenten-Control-Plane** besitzt, wird definieren, *was ein Agent ist*.

Beyond Zero: Enterprise security for the AI era

Mon, 20 Jul 2026 00:00:00 GMT

Forschungsartikel, veröffentlicht in **ACM Queue** (Bd. 24, Nr. 3 — Themenheft „LLMs") am **20. Juli 2026**, verfasst von **Joseph Valente** (Director of Product Management, Alphabet Security) und **Michal Zalewski** (Distinguished Engineer, Stratege bei Alphabet Security — der *lcamtuf* der Offensivsicherheit). Lizenz **CC BY 4.0**, **29.143 Downloads** in zehn Tagen, **eine einzige bibliografische Referenz**: das BeyondCorp-Whitepaper von 2014. Das ist kein Zufall — der Artikel positioniert sich explizit als **generischer Nachfolger von BeyondCorp** und übernimmt dessen Funktion: *„die Vision veröffentlichen, damit sich die Branche daran ausrichten kann."* **These**: Das **anwendungsbasierte Grenzmodell erreicht das Ende seiner Lebensdauer**. Die drei Annahmen, auf denen BeyondCorp beruhte — *Zugreifende sind Menschen, Aktionen erfolgen in menschlichem Tempo, die Anwendung ist die richtige Vertrauensgrenze* — sind allesamt überholt, seit KI-Agenten mit der **zehnfachen Geschwindigkeit von Menschen** auf Daten zugreifen und über riesige unstrukturierte Korpora räsonieren. **Beyond Zero** verlagert die Vertrauensgrenze daher **von der Anwendung auf die einzelne Aktion an der einzelnen Ressource** und die Untersuchung **von nachträglich auf Echtzeit**. **Vierteilige Architektur, die eine Schleife bildet**: *autonome Governance* (die mit KI ein lebendiges **Unternehmensweltmodell** aufbaut — Wer / Was / Wie —, in expliziter Analogie zum Weltmodell eines selbstfahrenden Autos), *Event Intake* (Server-, Client- und **Agentenaktivitäts**-Signale: Prompts, Ausführungspläne, Tool-Aufrufe), *reasoning engine* (hierarchische KI, **schnell** für ABAC zum Zeitpunkt des Zugriffs und **langsam** für Inferenz über eine Abfolge von Aktionen; Urteil *allow / deny / challenge*) und *Challenge-Infrastruktur* (reversible **Challenges** — Begründung, Tippen auf den Sicherheitsschlüssel, Genehmigung, **Selfie** — gegenüber dauerhaften **Containments**, die mitunter erst aufgehoben werden, nachdem das Sicherheitsteam den Mitarbeitenden und dessen Vorgesetzten befragt hat). **Der zentrale Gestaltungsgriff ist die Boden/Decke-Aufteilung**: **statische Richtlinien** (der Boden, statisch verifizierbar) unter einer **dynamischen reasoning engine** (die Decke) — eine explizite Ablehnung eines *„vollständig dynamischen, statisch kaum verifizierbaren"* Modells. **Der benannte Angriffsvektor**: **Ambient Authority**, bei der der Agent die vollen, oft überprovisionierten Berechtigungen seines Menschen erbt. **Drei festgehaltene Vorbehalte**: Es handelt sich um ein **Visionspapier, keine Kriegsgeschichte** — null Produktionsmetriken, null Falsch-Positiv-Rate, null Bereitstellungsgröße, während [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] zwei Monate zuvor eine P99 < 40 ms und Tausende von Agenten im Produktionseinsatz veröffentlicht hatte; eine **interne Inkonsistenz um Größenordnungen** (Dutzende Millionen Aktionen/s in der Problemstellung gegenüber Tausenden Entscheidungen/s in Abstract und Fazit); sowie ein **gravierender blinder Fleck bei europäischen Belangen** — das beschriebene System ist auch ein Überwachungsapparat für Mitarbeitende (Selfie, clientseitige Signale, Baselining gegenüber der Vergleichsgruppe), ohne eine einzige Zeile zur DSGVO, zur Verhältnismäßigkeit oder zu Arbeitnehmervertretungen.

Gregor Hohpe et le rôle de l'architecte à l'ère de l'IA

Wed, 15 Jul 2026 00:00:00 GMT

Dieser Tech-Watch-Digest fasst aus Primärquellen (Bücher, der Blog architectelevator.com, Konferenz-Abstracts, LinkedIn-Beiträge, Podcasts) die Position von Gregor Hohpe zur Rolle des Architekten im Zeitalter generativer KI zusammen. Zentrale These: KI entwertet den Architekten nicht, sie verschiebt seinen Wert vom Code hin zu dem, was KI nicht leistet — Entscheidungen treffen und verantworten, Kompromisse abwägen, „Optionen verkaufen“ und mit Menschen kommunizieren. Seine schärfste Formulierung (Craft Conference 2026): „developers mainly interact with machines (compilers, interpreters, GenAI); architects, meanwhile, communicate with humans — sponsors, stakeholders, regulators. AI generates code and standard diagrams, but architects rely on powerful abstractions that distill critical decisions, remove uncertainty, and align stakeholders.“ Seine Kernthese — der Architekt muss nicht die klügste Person im Raum sein, sondern soll „alle anderen klüger machen“ (QCon SF 2024), indem er Entscheidungsmodelle teilt und blinde Flecken offenlegt — gewinnt an Gewicht, je reichlicher Code verfügbar wird: Der Vorteil entsteht durch Entscheidungsdisziplin, nicht durch Ausstoßmenge. Auch die „Optionen“-Metapher (2016) gewinnt an Wert: Über eine Black-Scholes-Analogie argumentiert Hohpe, dass mit steigender technologischer Volatilität der Wert der von der Architektur verkauften Optionen steigt — weshalb in Zeiten der Unsicherheit, wie im aktuellen KI-Moment, mehr in Architektur investiert werden sollte. Beim Code bevorzugt Hohpe das „Debuggen“ von Entscheidungen gegenüber dem Produzieren von Zeilen: generierter Code enthält standardmäßig architektonische Entscheidungen, und es ist Aufgabe des Architekten, diese bewusst zu machen. Er warnt, dass „ein KI-getriebener SDLC schlechte Gewohnheiten sehr viel schneller bestraft“: KI verstärkt alles, auch Dysfunktion (Schulden, Inkonsistenzen); die Gewinner werden daran gemessen, wie schnell sie von der Experimentierphase zu einer „kontrollierten Produktion“ übergehen. Nach Rolle: Der Enterprise-Architekt muss vom Kartografen zum Scout werden und „die Illusion der Vorhersagbarkeit“ vermeiden; der Plattform-Architekt muss Abstraktionen statt Illusionen liefern; der Chief Architect ist ein Multiplikator (Kommunikation × Technologie × Organisation). Er setzt auf gezielte Automatisierung (Amazon Q Code Transformation: 1000 Java-8→17-Anwendungen in zwei Tagen migriert) statt auf KI als Entscheidungsorakel und entkräftet Marketingzahlen. Zwei Leitplanken im Digest: Die Formel „Architekten, die KI nutzen, werden diejenigen ersetzen, die es nicht tun“ stammt NICHT von Hohpe; manche LinkedIn-Zitate sind nur als Auszüge zugänglich.

Le Rôle de l'Architecte à l'Ère de l'Intelligence Artificielle

Wed, 15 Jul 2026 00:00:00 GMT

Diese SFEIR-Analysenotiz untersucht den Beruf des Softwarearchitekten im Licht der generativen KI neu und stützt sich dabei auf das konzeptionelle Rahmenwerk von Gregor Hohpe (*The Software Architect Elevator*). Ausgangspunkt ist ein Paradigmenwechsel: Der „Orakel"-Architekt, der über überlegenes Wissen verfügt und starre Regeln vom Elfenbeinturm aus diktiert, ist inzwischen obsolet, da KI Code und Designvorschläge auf Abruf generiert. Der Wert des Architekten liegt nicht mehr darin, Syntax auswendig zu kennen oder „Software-Klempnerarbeit" zu leisten, sondern in einer neuen Rolle als **Intelligenzverstärker (IQ Amplifier)**: Teams mentale Modelle, Unternehmenskontext und Entscheidungsunterstützungswerkzeuge bereitzustellen, um KI bestmöglich zu nutzen und dabei die Gesamtkohärenz des Systems zu gewährleisten. Das Dokument gliedert diese Auswirkung anhand der Metapher des „Architect Elevator", der vom Maschinenraum (technisch) bis zum Penthouse (Strategie) reicht. Der **Enterprise Architect** managt den Hype, entscheidet über Build vs. Buy bei Modellen (proprietär, fine-getuntes Open Source, Drittanbieter-APIs) und strukturiert Ethik und Data Governance. Der **Solution Architect** entwirft „für Unsicherheit" — entkoppelte, modulare Architekturen, die einen Austausch von LLMs ohne Neuschreiben ermöglichen — und „kauft Optionen" über erweiterbare Systeme. Der **Platform Architect** standardisiert KI-Fähigkeiten als robuste, sichere APIs und behandelt die Plattform als Produkt (mit Verweis auf *Platform Engineering is Domain-Driven Design*). Der **Software Architect / Tech Lead** richtet Leitplanken ein (hexagonale/Clean-Architekturen), um zu verhindern, dass generierter Code den fachlichen Kern verunreinigt, und dokumentiert das „Warum" hinter Entscheidungen, da KI nur das „Wie" generiert. Der methodische Kern ist **Domain-Driven Design**, das als das beste Werkzeug zur Steuerung von KI dargestellt wird. Zwei Hebel: die **Ubiquitous Language**, ein eindeutiges, in den Kontext der KI injiziertes Domänenwörterbuch (über `.clinerules` oder Prompt-Vorlagen), das Halluzinationen und fachliche Fehlinterpretationen reduziert; und **Bounded Contexts**, die KI auf einen begrenzten Geltungsbereich beschränken, um die Zuverlässigkeit der Generierung zu maximieren, wobei der Architekt die Schnittstellen und Anti-Corruption-Layer (ACL) entwirft und die Integrations-Klempnerarbeit an die KI delegiert. Abschließend ist KI keine Bedrohung, sondern ein Katalysator: Sie entlastet den Architekten von repetitiver technischer Eingabearbeit und wertet dessen edelste Fähigkeiten auf — Synthese, strategische Vision, Modellierung komplexer Konzepte und menschliche Empathie, um Technologie mit geschäftlichen Bedürfnissen zu verbinden.

Your Browser Does Math Differently on Every OS, and Anti-Bot Systems Read the Bits

Sun, 12 Jul 2026 00:00:00 GMT

Engineering-Artikel, veröffentlicht am **12. Juli 2026** von **Scrapfly Engineering**, über einen wenig bekannten Browser-*Fingerprinting*-Kanal: **die letzten Bits einer Gleitkommazahl verraten das Betriebssystem**. **Der Mechanismus**: IEEE 754 legt fest, wie ein `double` gespeichert wird, verlangt aber **nicht**, dass `sin`, `cos`, `tanh` oder `exp` korrekt gerundet werden; jedes System liefert daher eine eigene **libm**, die einen Bruchteil eines ULP gegen Geschwindigkeit eintauscht, mit eigenen Minimax-Koeffizienten, Tabellen und Reduktionskonstanten. Dadurch liefert `Math.tanh(0.8)` **drei unterschiedliche Werte**, je nach glibc (Linux), libsystem_m (macOS) und UCRT (Windows) — „ein einziger tanh-Aufruf mit dem richtigen Eingabewert ist eine Signatur pro Betriebssystem. Wer macOS behauptet, aber Linux-Rechenbits zurückgibt, widerspricht dem eigenen User-Agent.“ **Das Erkennungsmerkmal ist neu und lässt sich genau datieren**: bis **Chrome 147** berechnete V8 `tanh` mit einem eingebetteten **fdlibm**-Port, überall identisch und ohne jedes Leck; der V8-Commit `c1486295ae5` ersetzte ihn durch `std::tanh`, ausgeliefert in V8 14.8.57, also **Chrome 148** — 148, 149 und 150 lecken, 147 und früher nicht. **Drei Oberflächen bündeln die Lecks**: `Math.tanh` (die **einzige** betroffene `Math.*`-Funktion, da V8 alle übrigen einbettet und statisch verlinkt), **sämtliche CSS-Trigonometriefunktionen** (Blink ruft direkt die libm des Hosts auf, nach einer gradbasierten Winkelreduktion, die keinen Code mit `Math.sin` teilt), und **Web Audio** (wo der Kompressor bei skalarer libsystem_m bleibt, während FFT- und Vektorstufen über **Accelerate** laufen). **Vier Fallen** erschweren die Gegenmaßnahme: Nur manche Funktionen lecken — daher **erzeugt das Fälschen der übrigen eine erkennbare Inkonsistenz**; JavaScript und CSS sind getrennte Codepfade; **macOS enthält zwei Mathematikbibliotheken, die voneinander abweichen** (skalar vs. Accelerate, je nach Funktion bei 10 bis 89 % der Eingabewerte: `cos(0)` liefert auf der einen Seite `1.0`, auf der anderen `0.9999999999999999`); und **auch die Architektur leckt** (FMA und die Vorzeichenweitergabe bei NaN unterscheiden sich zwischen ARM und x86). **Die verworfene und die gewählte Gegenmaßnahme**: Rauschen hinzuzufügen scheitert zweifach — der Wert stimmt mit **keinem** realen Betriebssystem überein, und die fehlende Determinismus pro Aufruf ist selbst ein Erkennungsmerkmal. Der einzige Weg ist die **bitgenaue Reproduktion**: die Koeffizienten der Ziel-libm extrahieren, sie **hexadezimal** transkribieren (eine dezimale Transkription würde anders runden), jede fused multiply-add-Operation explizit als `fma()` schreiben und mit `-ffp-contract=off` kompilieren, damit der Compiler keine davon erfindet oder wegoptimiert. **Bemerkenswerter Hinweis**: Der Herausgeber stellt vorab klar, dass „die Beiträge hier mit KI verfasst werden“, während Mechanismen, Zahlen und Code aus eigener Feder stammen.

New Engineering Disciplines for the AI Era Part 3: KDLC — Knowledge Development Life Cycle

Sun, 28 Jun 2026 00:00:00 GMT

Als dritter Teil der Reihe «New Engineering Disciplines for the AI Era» etabliert dieser Artikel von Ashish Singh **KDLC — Knowledge Development Life Cycle** als eigenständige Ingenieursdisziplin. Seine These kehrt die vorherrschende Diagnose um: Wenn so viele KI-Initiativen in Unternehmen scheitern, dann nicht mangels der Wahl des richtigen Modells oder der Einführung eines RAG-Systems, sondern weil sie **die zugrunde liegende Struktur des Wissens** ignorieren. Der zentrale Satz bringt die Tragweite auf den Punkt: „KI ist nur so wirksam wie das Wissen, das sie entdecken, verstehen, abrufen und dem sie vertrauen kann." Wissen muss folglich als **konstruiertes Gut** behandelt werden, gleichrangig mit Code (SDLC) oder Daten. Der KDLC gliedert diese Arbeit in **acht** aufeinanderfolgende Stufen. **Discovery** lokalisiert Wissen, das über Datenbanken, SharePoint, Wikis, CRM, ERP und technische Artefakte verstreut ist. **Extraction** extrahiert die relevanten Informationen unter Wahrung von Geschäftskontext, Metadaten, Beziehungen und Eigentümerschaft. **Structuring** wandelt Informelles in standardisierte, wiederverwendbare Wissensobjekte um. **Knowledge Graph Creation** bildet die Verknüpfungen zwischen Kunden, Produkten, Projekten, Teams, Regulierungen und Anwendungen ab. **Embedding** erzeugt semantische Repräsentationen, die ein Verständnis nach Bedeutung ermöglichen. **Index Optimization** verfeinert Vektorindizes und Retrieval-Pipelines. **Retrieval Evaluation** misst Relevanz, Präzision, Vollständigkeit und geschäftliche Wirkung. Schließlich hält **Knowledge Refresh** das Ganze angesichts neuer Richtlinien, Regulierungen und Releases auf dem aktuellen Stand. Der argumentative Kern stellt zwei Architekturen gegenüber. **Traditionelles RAG** ruft über schlüsselwortbasierte Suchen isolierte Dokumente ab. Das **Enterprise Knowledge Fabric** — eine Kombination aus Knowledge Graphs, Semantic Search, Vektordatenbanken und Hybrid Search — zielt auf ein vernetztes Verständnis: Statt Dokumente abzurufen, erfassen KI-Agenten „Beziehungen, Kontext und geschäftliche Bedeutung". Eine zweite Trias rahmt die jeweiligen Rollen der Schichten: „Modelle liefern Reasoning. Memory liefert Kontinuität. Wissen liefert Verständnis." Drei branchenspezifische Beispiele machen die Wirkung konkret: ein Assistent für **finanzielle Compliance**, der aktuelle Regulierungen mit internen Richtlinien verknüpft; ein Assistent für **Softwareentwicklung**, der Architektur, API-Verträge, Standards und Vorfälle konsultiert, bevor er eine Empfehlung ausspricht; ein **klinischer** Assistent, der Behandlungsleitlinien, Protokolle, Fachliteratur und Patientenakten abgleicht. Singh schließt, dass Wissensingenieurwesen im Zeitalter agentischer KI ebenso kritisch wird wie Softwareentwicklung und Data Engineering. Die Grenze des Artikels liegt in seiner **konzeptionellen, nicht quantifizierten** Natur: keine Benchmarks oder Kostenzahlen, und die eigentlichen Schmerzpunkte — Governance und laufende Pflege der Refresh-Stufe — bleiben unbehandelt.

Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Tue, 16 Jun 2026 00:00:00 GMT

Dieser SFEIR-Artikel formalisiert einen KI-gesteuerten Softwareentwicklungszyklus in **elf Phasen (0 bis 10)** und argumentiert, dass sich die Branche auf ein solches Modell zubewegt. Ausgangspunkt ist eine Diagnose: 2025 setzten Organisationen KI-Tools ein, ohne ihr Betriebsmodell zu transformieren, was ein Paradox erzeugte, das in dem Satz « alles ändert sich… und nichts ändert sich » zusammengefasst wird — die Ausführungsgeschwindigkeit vervielfacht sich ohne proportionalen Gewinn. Die eigentliche Herausforderung besteht daher nicht darin, die richtigen Tools zu wählen, sondern den Software-Lebenszyklus selbst für die maschinengeführte Ausführung **neu zu denken**. Der SFEIR-Zyklus verkettet: **0 Setup** (Stack-Erkennung, Projektgedächtnis), **1 Define** (Spezifikation — menschliches Gate), **2 Plan** (Architekturentscheidung — menschliches Gate), **3 Build** (Entwicklung durch den Agenten), **4 Verify** (automatisierte Tests und Coverage), **5 Review** (vier parallele Audits: Code, Sicherheit, Tests, Performance), **6 Compound-1** (Erfassung von Erkenntnissen vor der Bereitstellung), **7 Ship** (Produktionsabnahme — menschliches Gate), **8 Ops** (Monitoring und Rollback), **9 Compound-2** (Erkenntnisse aus dem Betrieb) und **10 Deprecation** (Ablösung und Kapitalisierung). Drei **unveränderliche menschliche Gates** — Define, Plan, Ship — rahmen eine Reihe ansonsten automatischer Phasen ein; zwei **Kapitalisierungsmomente** (Compound-1 und Compound-2) wandeln Erkenntnisse in wiederverwendbare Regeln um, die in die nachfolgenden Zyklen einfließen. Drei Prinzipien strukturieren den Ansatz. Erstens: **KI führt aus, sie unterstützt nicht** — Agenten produzieren vollständige Artefakte (Code, Tests, Dokumentation) über ganze Phasen hinweg, und eine **Proof-of-Execution**-Disziplin erfasst die tatsächlichen Ergebnisse — das System vertraut niemals den eigenen Angaben des Agenten. Zweitens: **der Mensch behält über die drei Gates die Kontrolle über die Absicht** — er entscheidet, was gebaut wird, die Maschine optimiert die Ausführung. Drittens: **das System lernt kumulativ**, wobei jeder Zyklus den nächsten bereichert. Die angeführten Ergebnisse stützen diese These: eine Website-Neugestaltung, die von sechs Monaten auf einen Tag verkürzt wurde, **−30 % der Korrekturiterationen nach zehn Zyklen** (ein zweimal gemeldeter Bug wird zu einer automatisierten Regel), Reviews aus vier parallelen Blickwinkeln, Augmentierungskosten von rund 10 €/Stunde und ein Ziel von 850 vollständig KI-augmentierten Consultants bis Ende 2026. Der Artikel behauptet eine **branchenweite Konvergenz** mit dem ADLC (zwei Gates, « die Absicht wird genau zweimal überprüft »), Googles Whitepaper zum neuen SDLC (41 % KI-generierter Code, 85 % der Entwickler nutzen Agenten) und DORA 2025 (KI als « Verstärker »). Abschließend grenzt er geeignete Einsatzbereiche (Back-Offices, APIs, Migrationen, automatisch verifizierbare Ergebnisse) von ungeeigneten (uneingeschränktes neuartiges Design, sicherheitskritische Systeme in Erwartung von Standards, ungovernte Datenumgebungen) ab und empfiehlt, mit einem strengen Spezifikations-Gate und Ausführungsnachweis zu beginnen. Erster Teil einer siebenteiligen Serie.

The End of Code Review: Coding Agents Supersede Human Inspection

Thu, 11 Jun 2026 00:00:00 GMT

In diesem als Position Paper auf arXiv veröffentlichten Artikel (Kategorie Software Engineering) vertritt Martin Monperrus eine These, die einer Grundpraxis des SDLC frontal widerspricht: Coding-Agenten haben ein Fähigkeitsniveau erreicht, bei dem menschliches Code-Review keine notwendige Komponente einer Qualitätspipeline mehr ist. Die Argumentation stützt sich auf zwei Thesen. Erstens eine Parität — oder sogar eine Überlegenheit — der Fähigkeiten: autonome LLM-basierte Systeme erfüllen alle traditionellen Ziele des Reviews (Fehler finden, Qualität verbessern, Compliance sicherstellen, Wissen teilen) bei geringeren Kosten und höherem Durchsatz, ohne menschliche Ermüdung oder Inkonsistenz. Zweitens ein Skalierungsproblem: Das dominierende hybride Modell — der Agent schreibt den Code, der Mensch reviewt ihn — bietet weder eine echte Qualitätssicherung noch die Fähigkeit, mit der KI-gestützten Produktionsgeschwindigkeit Schritt zu halten; vor allem erzeugt es ein trügerisches Sicherheitsgefühl. Monperrus verortet sein Ziel historisch und nimmt die inspection de Fagan (1976) ins Visier; er stützt sich zudem auf die Arbeiten von Bacchelli & Bird, die zeigen, dass Review in der Praxis weniger Bugs findet, als Entwickler annehmen. Benchmarks (SWE-bench, ca. 20-40% gelöste Issues je nach Modell, mit schnellen Fortschrittskurven) dienen als Fähigkeitsnachweis. Anstelle des menschlichen Reviews schlägt er eine multi-agentenbasierte adversarial verification pipeline vor: Ein Agent generiert den Code; ein oder mehrere unabhängige Reviewer-Agenten prüfen ihn (Fehler, Sicherheit, Stil); eine Verifikationsschicht ergänzt automatisierte Tests und formale Methoden; ein Konsensmechanismus lässt mehrere Agenten über Annahme oder Ablehnung abstimmen. Der Flaschenhals eines einzelnen menschlichen Reviewers wird durch eine verteilte, ermüdungsfreie Prüfung ersetzt. Der Mensch verschwindet nicht: Er konzentriert sich auf Spezifikation und übergeordnete Anforderungen, architektonische Trade-offs, die Aufsicht über kritische Domänen, von Agenten ungelöste Grenzfälle und bleibt das finale Freigabe-Gate für sensible Systeme. Der Autor geht explizit auf die Einwände ein — Halluzinationen und Prompt Injection, die Grenzen automatisierter Tests (daher property-based testing), Verlust von Domänenexpertise (ausgeglichen durch Fine-Tuning und RAG) — ohne ihnen auszuweichen. Auf der SDLC-Seite verknüpft er Review mit DORA-Metriken: Eine Beschleunigung des Review-Durchsatzes beschleunigt das Deployment. Seine Empfehlungen sind pragmatisch: zunächst Pilotierung an risikoarmen Komponenten, Beibehaltung eines anfänglichen hybriden Workflows (Agenten markieren, Menschen genehmigen), Messung der Erkennungsraten Agent versus Mensch, explizite Ablehnungsentscheidungen sowie der Aufbau von Feedback-Schleifen. Ein bewusst provokanter Text, aber eine wertvolle Gegenthese zum Dogma des „unantastbaren menschlichen Review-Gates“.

The pattern lineage: Why fifty years of design patterns may hold the key to growing the architects AI cannot replace

Wed, 10 Jun 2026 00:00:00 GMT

Philippe Ensarguet (Orange) geht von einer scheinbar administrativen Frage aus – der Gestaltung eines Weiterbildungspfads hin zur Rolle des Architekten –, um eine tiefere Intuition zu formulieren. Diese Rolle ist entscheidend für die „Plattformisierung" eines Telekommunikationsbetreibers (das Zusammenführen der jahrzehntelang getrennten IT- und Netzwerkwelten in programmierbare Plattformen). Doch sie wird genau in dem Moment kritisch, in dem ihre Ausbildungspipeline zusammenbricht: Die Nachfrage nach Architekten steigt (Plattformisierung, Cloud-Native, IA agentique verlagern die Komplexität von den Komponenten hin zu den Beziehungen zwischen ihnen), während sich die Talent-Lieferkette selbst demontiert. Der traditionelle Weg führte über Jahre des Codeschreibens; KI übernimmt heute einen wachsenden Anteil dieser Arbeit. Wenn die Einstiegsarbeit, die einst Architekten formte, an Maschinen delegiert wird, woher soll dann die nächste Generation kommen? Die Antwort liegt laut Ensarguet seit fünfzig Jahren bereit. Er greift auf die ursprüngliche Bedeutung eines Patterns zurück, wie sie der Gebäudearchitekt Christopher Alexander (1977) definierte: eine benannte, wiederkehrende Lösung für ein Problem in einem bestimmten Kontext, einschließlich der im Spannungsverhältnis stehenden Kräfte und der Konsequenzen. Es ist kein Rezept — es ist vermittelbares Urteilsvermögen. Das Buch der Gang of Four (1994), das aus der von Kent Beck und Grady Booch einberufenen Hillside Group hervorging, gab der Branche ihr erstes gemeinsames Vokabular — sein bleibender Wert liegt im Format (Problem, Kontext, Kräfte, Lösung, Konsequenzen), nicht in den 23 Patterns selbst. Ensarguet zeichnet einen Stammbaum nach: POSA (1996), Fowler (2002), Hohpe & Woolf (2003), Nygard (2007, Circuit Breaker), die Cloud-Kataloge (ab 2012), Microservices und Kubernetes (2018–2019), bis hin zu den sich gerade herausbildenden agentischen Korpora (Anthropics „Building Effective Agents", die vier Patterns von Andrew Ng, das Zwei-Achsen-Framework von Huang & Zhou aus dem Jahr 2026 — ein Echo der zwei Achsen der GoF dreißig Jahre zuvor). Unterhalb der Kataloge bestehen sechs invariante Kräfte fort: Kopplung/Kohäsion, Abstraktionsgrenze, Fehlerisolierung, Zustandsverwaltung, Indirektion, Feedback-Schleife — ergänzt um eine siebte, die von agentischen Systemen eingeführte Nichtdeterminiertheit. Diese „Pattern Literacy" ist die widerstandsfähige Fähigkeit — und die einzige, die IT und Netzwerk endgültig überbrückt (Control Plane / User Plane = Indirektion; Network Slicing = Bulkhead; Intent-Based Networking = Feedback-Schleife). KI wird dadurch zum Verbündeten: von der Implementierung befreit, kann die Ausbildung bewusst gestaltet werden — die Maschine erzeugt Optionen, der Mensch liefert das Urteilsvermögen. Zu vermitteln ist die Grammatik, nicht die Kataloge: Kataloge veralten, die Denkweise, die sie kodieren, nicht. Ensarguet veröffentlicht diese These genau deshalb, um sie im Diskurs auf die Probe zu stellen.

How AI Changes the SDLC: A Six-Stage Guide

Mon, 08 Jun 2026 00:00:00 GMT

Dieser Leitfaden von Augment Code, verfasst von Paula Hingel, schlägt ein **sechsstufiges** Modell vor, um zu verstehen, wie KI-Agenten den Software Development Lifecycle umstrukturieren. Zentrale These: KI verbessert den SDLC nicht gleichmäßig — sie erhöht in manchen Phasen den Durchsatz, während sie in anderen das Instabilitätsrisiko steigert. Dieses Ungleichgewicht ist keine technologische Zwangsläufigkeit, sondern das Symptom einer ungleichmäßigen Adoption, die **ohne Neuziehung der Review-Grenzen** erfolgt. Der Artikel stützt sich auf den **DORA-2025-Bericht**, der eine positive Korrelation zwischen KI-Adoption und Durchsatz/Produktperformance feststellt, jedoch eine **negative Korrelation mit der Delivery-Stabilität**: Die Prozessreife zählt mehr als das Werkzeug. Die sechs Phasen werden unter diesem Blickwinkel neu gelesen. (1) **Requirements & Planning**: Die Spezifikation wird zum Steuerungsmechanismus, der den Agenten lenkt; Menschen konzentrieren sich auf die Qualität der Anforderungen und die Auflösung von Mehrdeutigkeiten. (2) **Design & Architektur**: Mehr Entscheidungen erfordern explizite menschliche Prüfung, um „vibe architecting“ zu vermeiden — Infrastruktur- oder Integrationsentscheidungen, die in Sekunden getroffen werden, schneller als die Governance mithalten kann. (3) **Implementierung**: Der Entwickler verlagert sich vom Schreiben von Code hin zu Orchestrierung, Validierung und Freigabe. (4) **Testing & QA**: Das Kernrisiko ist die **zirkuläre Validierung**, bei der KI-generierte Tests KI-generierten Code bestätigen, anstatt die tatsächliche Anforderung zu prüfen; eine präzise Spezifikation ist die Absicherung. (5) **Deployment**: Durchsatzgewinne erzeugen Stabilitätsrisiken, daher die Notwendigkeit stärkerer Rollback-Kontrollen. (6) **Maintenance & Operations**: Agenten übernehmen Erkennung und Behebung, Menschen managen Ausnahmen und Härtung. Drei strukturelle Risiken werden benannt: **Erosion der Junior-Pipeline** (die Automatisierung grundlegender Aufgaben schneller als die Neugestaltung der Junior-Rollen verringert den künftigen Pool an Senioren), zirkuläre Validierung und Governance-Lücken bei Skalierung. Parallel dazu entstehen drei Rollen: **Intent Engineering** (Übersetzung mehrdeutiger Ziele in testbare Spezifikationen), Agentic DevOps/Infra (Orchestrierung von Agenten) und AI Governance/Assurance. Der Leitfaden stützt sich auf Daten: 70 % der Entwicklerzeit werden für das Verständnis bestehenden Codes aufgewendet, eine CMU-Studie (807 Repositories) zeigt +30 % Static-Analysis-Probleme und +40 % Komplexität, sowie Metas DRS-System (>10.000 Änderungen während eines Code-Freeze eingespielt). Er schließt mit fünf operativen Empfehlungen: eine Phase vor der Skalierung auditieren, Governance einem Stresstest unterziehen, die Spezifikation ins Zentrum stellen, explizite Rollback-Richtlinien definieren und die Junior-Rolle rund um Review neu gestalten.

Solving the Identity Crisis for AI Agents

Thu, 21 May 2026 00:00:00 GMT

Engineering-Artikel, veröffentlicht im **Uber** Engineering-Blog von sechs Ingenieuren (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) am **21. Mai 2026**, der die bei Uber für mehrere Tausend interne Agenten produktiv eingesetzte **Doktrin für Agentenidentität und Zugriffskontrolle bei KI** darlegt. **Kernthese**: Bestehende Identitätsmodelle (Menschen + Workloads) scheitern daran, **Handlungsvollmacht (Agency)** zu beschreiben — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — und verlieren die **Provenienz** über die Hops eines agentischen Workflows hinweg. **Zwei identifizierte operative Probleme**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — Delegation ist der Standardmodus, Workflows sind kompositional (Agenten rufen Agenten auf, die Tools aufrufen), das Verhalten ist dynamisch (Pläne entwickeln sich basierend auf Zwischenergebnissen); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Vorgeschlagene Architektur** als Erweiterung von Ubers Zero-Trust-Architektur: **Agent Registry** (Source of Truth für Agent↔Workload-Zuordnungen) + **AI Agent Mesh** (Datenebene zwischen Agenten) + **STS (Security Token Service)** (Ausstellung kurz begrenzter JWTs) + **MCP Gateway** (Policy-Enforcement-Point für Tool-Aufrufe) + **AI Gateway** (Vermittlung externer LLM-Aufrufe mit Guardrails) + **SPIRE** (Anbieter von Workload-Credentials). **Kryptografische Mechanik**: Workloads beziehen kryptografisch signierte **SVIDs (SPIFFE Verifiable IDs)** von SPIRE → das SDK fordert über die Workload-Identität ein JWT vom STS an → der STS prüft die Autorisierung des Agenten gegen die Agent Registry → ein kurzlebiges Token (TTL in der Größenordnung von Minuten) wird für ein **spezifisches Single-Hop-Ziel** ausgestellt (gezielter `Audience`-Claim). **Kerndoktrin**: ***"Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes."*** **Erhalt der Akteurskette**: ein Multi-Hop-Beispiel mit Bereitschaftsingenieur `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; das finale JWT trägt eine verifizierbare **Akteurskette `[user1, oncall-agent, investigation-agent]`**, die Zugriffsentscheidungen auf Tool-Ebene auf Basis der **vollständigen Historie der Anfrage** ermöglicht. **Standardisierung**: ein **Standardized A2A (Agent-to-Agent) Client**, der STS-Austausche und die Propagierung der Akteurskette automatisiert — *"the secure path is also the easiest path for developers to implement A2A calls"* — mit schrittweiser Migration von Legacy-Agenten. **Produktionskennzahlen**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** Tausende interner Agenten im Einsatz, ein Echtzeit-Observability-Dashboard, das Multi-Agenten-Sitzungen nachverfolgt. **Langfristvision — dreischichtiges Framework**: (1) Identity & Trust Foundation (verifizierbare Agentenidentität + Delegationsketten), (2) Dynamic Access Control (kontextbasierte Berechtigungen + Human-in-the-Loop), (3) Unified Enforcement Plane (zentralisierte, beobachtbare Policy). **Abstimmung mit Standards**: die IETF-**WIMSE**-Arbeitsgruppe + der Entwurf `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, konzeptionell gestützt auf **OAuth 2.0 Token Exchange (RFC 8693)** und **SPIFFE/SPIRE** (CNCF graduated). Die erste Referenzpublikation eines Hyperscalers außerhalb der KI-Labs (Logistik/Mobilität), der Agentensicherheit auf Infrastrukturebene industrialisiert und die doktrinäre Lücke zwischen Skills-/Harness-Frameworks (Vincent, Lattice, PROJ-AI) und Fragen der Unternehmensidentität schließt.

How the X Algorithm Actually Works in 2026 — and What That Means for Growth

Sat, 16 May 2026 00:00:00 GMT

Interner Teardown-Bericht zur Open-Source-Veröffentlichung **`xai-org/x-algorithm`** (15. Mai 2026) — dem **For-You-Feed**-Algorithmus von **X (ehemals Twitter)** im Jahr 2026, mit vier zielgruppenspezifischen Wachstums-Empfehlungssträngen (persönlich/Gründer, Marke/Unternehmen, verallgemeinertes Framework, Kunden-/Beratungs-Deliverable). **Kernthese**: ***« Die berühmte Gewichtstabelle von 2023 — Antworten zählen mit einem großen Multiplikator mehr als Likes — beschreibt ein System, das in dieser Form nicht mehr existiert. »*** Der Algorithmus von 2026 ist ein **Transformer (Phoenix, von Grok-1 abgeleitet)**, der Gewichte aus dem eigenen Engagement-Verlauf lernt und gegen eine **19-dimensionale Multi-Aktions-Oberfläche** bewertet wird, gesteuert durch einen Offline-Dienst zum Content-Verständnis (**Grox**). **Die Form des Scorings zählt heute weit mehr als die Zahlen — und die Zahlen selbst sind nicht Teil der öffentlichen Veröffentlichung**. **Architektur mit 4 Komponenten**: (1) **Home Mixer** (Rust, Orchestrator zur Anfragezeit, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, mit Kafka gespeister In-Memory-Store aktueller Posts, Sub-Millisekunden-Lookups für In-Network-Kandidaten); (3) **Phoenix** (JAX-ML, Two-Tower-Retrieval + Ranking-Transformer, ~von Grok-1 abgeleitet); (4) **Grox** (offline, Spam-/Safety-/PTOS-/Banger-Klassifikatoren + multimodaler v5-Embedder). **Die 19 von Phoenix vorhergesagten Aktionen** (zentrale Änderung gegenüber 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view, durch Mindestdauer gesteuert), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (kontinuierlich). **Endscore** = `Σ (weight × P(action))`, modifiziert durch **3 strukturelle Multiplikatoren**: (a) **OON_WEIGHT_FACTOR < 1** (Out-of-Network-Abschlag), (b) **Author-Diversity-Decay** `(1-floor) × decay_factor^position + floor` (exponentielle Abschwächung wiederholter Posts desselben Autors innerhalb eines einzelnen Renders), (c) **Video-Dauer-Gate** (vqv trägt nur bei, wenn `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Zentraler Vorbehalt**: **kein numerischer Gewichtswert** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) ist in der Veröffentlichung enthalten — alles ist `crate::params::*`, verwaltet von einem internen X-Feature-Switch-Dienst für A/B-Tests. ***« Wer behauptet, ‚Antworten sind 2026 N,N-mal mehr wert als Likes‘, erfindet eine Zahl, die sich aus der OSS-Veröffentlichung nicht ableiten lässt. »*** **Zentrale Unterschiede zu 2023**: (1) Entfernung sämtlicher handgefertigter Features (*« Wir haben jedes einzelne handgefertigte Feature und die meisten Heuristiken aus dem System entfernt »*); (2) ein einzelnes Modell sagt 19 Aktionen voraus statt mehrerer Einzelaktions-Modelle; (3) Grox trennt Content-Verständnis vom Ranking; (4) neue erstklassige Signale (kontinuierliches dwell, gesteuertes vqv, follow_author, 3 Share-Varianten); (5) Two-Tower-OON-Retrieval (statt SimClusters+Heuristiken) mit multimodalen Text+Bild+ASR-Video-Embeddings. **Drei Reichweiten-Schichten** (verallgemeinertes Framework): Eligibility (binär, Grox+Filter) → Retrieval (probabilistisch, Two-Tower-ANN) → Ranking (kontinuierlich, gewichtete Summe + Multiplikatoren). **Zwei Gesetze des mechanischen Wachstums**: (1) In-Network ist multiplikativ, OON ist additiv; (2) Die Aufgabe des Modells ist es, dich vorherzusagen, nicht dich zu belohnen. **Bewusste Ehrlichkeitsgrenze**: veröffentlichter Phoenix-Checkpoint = Mini-Version (2 Layer, 4 Heads, 256-dim, 537K-Sportpost-Korpus), nicht das Produktionsmodell; Thrift-Integrationen sind Stubs (`panic!("Not implemented")` in `candidate_features.rs`); Brand-Safety-Listen, Topic-ID-Zuordnungen, Sprachabschläge und Ad-Blending-Regeln fehlen in der öffentlichen Veröffentlichung.

The Ontology Pipeline™, Refresh: Where We Were, Where We Are, and Where We're Headed

Mon, 04 May 2026 00:00:00 GMT

**Jessica Talisman MLS** (Semantic Engineer + Information Architect, über 25 Jahre Erfahrung, zuvor RDF-Wissensgraphen bei Adobe + zuvor Informationsarchitektur bei Amazon, Gründerin des **Ontology Pipeline Framework** + von **Contextually LLC**) veröffentlicht am **4. Mai 2026** auf **Modern Data 101** (Substack, ~20.000 Mitglieder) eine grundlegende Überarbeitung ihres ursprünglich im Januar 2025 veröffentlichten **Ontology Pipeline™**-Frameworks. **Zentrale These**: Seit November 2022 (ChatGPT) ist die Nachfrage nach *semantischer Infrastruktur* explodiert, hat aber **massive Verwirrung** geschaffen — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. Die ursprüngliche **fünfstufige** Pipeline (kontrolliertes Vokabular → Metadatenstandards → Taxonomie → Thesaurus → Ontologie → Wissensgraph) bleibt gültig, **muss jedoch um 2 kritische Ergänzungen erweitert werden**: **(1) Governance** als fortlaufende Engineering-Praxis (nicht als Dokumentation nach Projektabschluss); **(2) AI Partnership** mit einer klaren Unterscheidung zwischen Unterstützung (augment) und Ersetzung (replace). **Marktdiagnose**: *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, KI-generierte Taxonomien, die als Strategie verkauft werden, Anbieter, die den Begriff *"ontology"* missbrauchen, Einheitslösungen, die als Methodologie präsentiert werden. **Bildungskrise**: Die Nachfrage nach Semantic Engineers übersteigt das Angebot an ausgebildeten Praktikern bei Weitem; die Lücke wird von Personen gefüllt, *"who know vocabulary without methodology"*. **Explizite normative Position**: *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Akzeptable KI-Rollen**: Entitätsextraktion, Lückenanalyse, Entwurf von Kandidaten-Vokabularen zur Überprüfung, Unterstützung bei Befüllung/Validierung. **Inakzeptable KI-Rollen**: *wholesale taxonomy generation without human validation against standards*. **Referenzierte Standards**: SKOS, OWL, RDF, SPARQL. **Glaubwürdigkeit**: Framework validiert an **6 Institutionen über 10 Jahre**. **Empfehlungen für 3 Zielgruppen**: (a) Organisationen — in formale Ausbildung investieren, Wissensinfrastruktur als Rückgrat der KI behandeln, Governance als fortlaufenden Prozess, KI als Beschleuniger, nicht als Ersatz; (b) Praktiker — Kompetenzfragen vor der Modellierung, Validierung gegen SKOS/OWL/RDF, definitorische Schwierigkeiten signalisieren eine Pause, Wartung ist kontinuierlich; (c) Führungskräfte — Weiterbildung der Belegschaft ohne Selbstfinanzierung, Ressourcen für Wissensinfrastruktur als strategische Notwendigkeit bereitstellen, Governance vor der Einführung. **Prägnante Zitate**: *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Hohe Relevanz** für Data Leader / CDOs / Architekten, die die semantischen Grundlagen ihrer KI-Agenten aufbauen. Ergänzend zu lesen: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — ontology as the only moat*; Foundation Capital Context Graphs (2025-12-22); Bain Teil 2/5 *redesign data foundations for agent readiness* (2026-05); DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21); Habert PROJ-AI Sechs-Zonen-Doktrin (2026-05-05). Konvergenz mit dem 2026er-Korpus zu *"data foundations as moat"*.

There is a growing disconnect in the way people think about building AI agents

Fri, 17 Apr 2026 00:00:00 GMT

Tony Seale, The Knowledge Graph Guy, identifiziert eine wachsende Diskrepanz in der Art und Weise, wie die Branche KI-Agenten baut. Einerseits investiert die Branche massiv in Orchestrierungs-Frameworks: LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK — jedes mit eigenen Orchestrierungsgraphen, Zustandsautomaten und Routing-Logik. Andererseits sind führende Praktiker zum Paradigma des „leistungsfähigen Modells in einem leistungsfähigen Harness“ übergegangen (Claude Code, Codex, OpenClaw, Hermes). **Der Kollaps der Frameworks.** Frühe Frameworks waren notwendig, als Modelle mehrstufige Aufgaben nicht allein bewältigen konnten. Anthropic-Zitat: „Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions can quickly go stale as models improve.“ Ein für ein begrenztes Modell gebautes Gerüst behindert ein intelligentes Modell. Es sollte mit der Zeit abnehmen, nicht sich anhäufen. Was übrig bleibt, ist einfach: ein leistungsfähiges Modell in einem leistungsfähigen Harness. Viele, die interagieren, die zusammenarbeiten. Kein Framework erforderlich. **Isolierte Agenten reichen nicht aus.** Zugriff auf den Computer ≠ Verständnis. Gibt man einem Agenten 1000 Dokumente, sucht er, hofft er, rät er. Multipliziert man das mit 50 Agenten ohne gemeinsames Weltmodell, erhält man Intelligenz, die isoliert, aber in der Kombination inkohärent ist. Im Unternehmensmaßstab braucht die Informationsumgebung Struktur — ein gemeinsames Domänenmodell, mit dem Menschen im Loop. **Die Symmetrie.** Die Antwort besteht darin, dieselbe Vereinfachung auf der Datenseite anzuwenden. Das Modell sitzt in einem Harness, der ihm Zugriff auf den Computer gibt; die Daten sitzen in einer Ontologie, die ihnen Struktur und Bedeutung gibt. Die Ontologie definiert, was existiert, ihre Eigenschaften, ihre Beziehungen — die Schnittstelle, durch die Agenten Daten verstehen. Zwei symmetrische Muster: (leistungsfähiges Modell + leistungsfähiger Harness) und (leistungsfähige Daten + leistungsfähige Ontologie). **Der Semantische Agent.** Ihre Kombination erzeugt den Semantic Agent: (Model + Harness) + (Ontology + Data). Er generiert nicht nur, er beginnt zu verstehen. Alles andere ist Gerüst — eine Zeit lang nützlich, aber zum Abbau bestimmt. **Was man besitzt.** Jeder hat Zugang zu denselben Frontier-Modellen; jeder kann ein Harness bauen. Das ist Commodity, und es dünnt sich jeden Tag weiter aus. Was KEINE Commodity ist: die eigene Ontologie, das eigene Domänenmodell, das strukturierte und verknüpfte Wissen, das erfasst, wie die eigene Organisation die Welt versteht. Frameworks sind eine Übergangsphase. Modelle werden gemietet. Das Einzige, was noch zu bauen bleibt — und das man selbst besitzt — ist Wissen.

Building for trillions of agents

Sat, 07 Mar 2026 00:00:00 GMT

Aaron Levie, CEO von Box, veröffentlicht einen strategischen Essay über die fundamentale Transformation von Software in einer Welt, in der KI-Agenten zu den primären Nutzern jeder Anwendung werden. Er stellt fest, dass Agenten seit Ende 2025 eine entscheidende Schwelle überschritten haben: Sie verfügen nun über eine eigene sandboxed Compute-Umgebung, können Code schreiben und ausführen, mit APIs und CLIs interagieren und ihre eigenen Dateien sowie ihr Langzeitgedächtnis verwalten. Diese Architektur, die zunächst von Coding-Agenten (Claude Code, Devin, Codex, Cursor, Replit) definiert wurde, hat sich auf sämtliche Wissensarbeit ausgeweitet, mit Agenten wie Claude Cowork, Perplexity Computer, Manus und OpenClaw, wobei Letzterer 24/7 in einer persistenten Umgebung läuft. Levie prognostiziert, dass jeder Mitarbeiter zahlreiche Agenten haben wird, mit 100- bis 1000-mal mehr Agenten als Menschen innerhalb eines Unternehmens, was global auf Billionen von Agenten hinausläuft. In Anlehnung an Paul Grahams berühmten Ratschlag ("Make something people want") schlägt Levie ein neues Paradigma vor: "Make something agents want". Agenten werden selbst die am besten geeigneten Werkzeuge auswählen, ohne von traditionellem Marketing beeinflusst zu werden. Die wesentliche Konsequenz: Alles muss API-first werden. Ohne API existiert eine Funktion für Agenten nicht. CLIs und MCP-Server werden unverzichtbar. Levie zitiert Jared Friedman von YC, der warnt, dass Tools, die keine Anmeldung über API erlauben, "für Agenten tot" seien. Auch Geschäftsmodelle müssen sich weiterentwickeln: Das Pro-Sitzplatz-Modell reicht nicht mehr aus, wenn ein Agent stundenlange menschliche Arbeit in wenigen Zeilen Text erledigen kann. Es werden Modelle benötigt, die auf Verbrauch und Volumen basieren und potenziell sogar Agenten erlauben, ihre eigenen Zahlungen zu verwalten. Levie beschreibt anschließend das erforderliche Infrastruktur-Ökosystem: Sandbox-Umgebungen (E2B, Daytona, Modal, Cloudflare), Dateiverwaltung (Box), Identität und E-Mail für Agenten (Agentmail), Websuche (Parallel, Exa), Zahlungen (Stripe, Coinbase) und potenziell Mikrotransaktionen. Sicherheit, Compliance und Governance werden zu zentralen Themen, wenn Agenten sensible Daten in regulierten Workflows (Pharma, Banking) verarbeiten. Agenten werden eigene Identitäten mit strikten Kontrollen über ihre Handlungen und ihren Datenzugriff benötigen. Abschließend stellt Levie fest, dass wir in eine neue Ära der Software eintreten, in der Werkzeuge speziell für Agenten konzipiert werden müssen, die in einem bisher unerreichten Umfang operieren.