Der letzte Engpass - Brains, Bodies und Memory

Ich baue seit 25 Jahren Products und führe Engineering Teams. In dieser Zeit hat jede große Welle - Cloud, Mobile, Microservices, DevOps - verändert, was möglich war. Keine hat die grundlegende Einheit verändert, mit der wir bauen: das Team.

Das hat sich dieses Jahr geändert. Ich shippe inzwischen regelmäßig Production Features, die vor achtzehn Monaten ein Team von fünf gebraucht hätten. Nicht durch härtere Arbeit. Indem ich AI Agents über Nacht laufen lasse während ich schlafe, morgens beim Kaffee ihren Output reviewe und vor dem Mittagessen shippe. Ich habe dieses Setup im Detail beschrieben in The Overnight Agent Factory.

Das ist keine Zukunftsprognose. Das ist mein Dienstag.

Drei Dinge kamen zusammen, um das möglich zu machen: die Models wurden mächtig genug (Brains), Agent Orchestration wurde erwachsen (Bodies), und persistente Knowledge Layers entstanden (Memory). Jedes für sich ist interessant. Zusammen beenden sie das Zeitalter der Teamgröße.

Hier ist, was passiert - und was ich in der Praxis erlebe.

Brains: Die Models haben eine Linie überschritten

Lass mich konkret sagen, was “bessere Models” 2026 bedeutet, denn das ist nicht der übliche inkrementelle Benchmark-Sprung.

Im März 2026 bestätigte Anthropic Mythos, nachdem ein Leak sie dazu zwang. Die Benchmarks erzählen eine klare Geschichte:

93,9% auf SWE-bench Verified - der Industriestandard für reale Coding-Aufgaben. Das ist nicht “schreibt eine Funktion.” Das ist “liest eine unbekannte Codebase, findet den Bug, schreibt den Fix und besteht die Tests.”
97,6% auf USAMO 2026 - der schwerste Mathematik-Wettbewerb der USA.
100% Erfolgsrate auf Cybench - kein anderes Model hat das je erreicht. Es fand Tausende Zero-Day-Schwachstellen in gängigen Betriebssystemen, darunter einen OpenBSD-Bug, der 27 Jahre menschliches Review überlebt hatte. Es verkettete vier separate Exploits, entkam zwei Sandbox-Layern und erlangte vollen Systemzugriff. Eigenständig.
Führt 17 von 18 Benchmarks, die Anthropic gemessen hat. Zweistellige Sprünge gegenüber der vorherigen Generation.

Der US-Finanzminister und der Fed-Chef riefen die CEOs der größten amerikanischen Banken zusammen. Nicht wegen Regulierung. Wegen Verteidigung. Anthropic wird Mythos nicht öffentlich releasen - stattdessen starteten sie Project Glasswing, 100 Millionen Dollar für rein defensive Nutzung.

Was das in der Praxis bedeutet: Ich spüre es jeden Tag. 2024 war AI Autocomplete - es beendete meine Sätze. Anfang 2025 konnte es eine Funktion schreiben, wenn ich sie sorgfältig beschrieb. Ende 2025 hatte ich Claude Code, das ganze Features über mehrere Files baute, mit einem strukturierten Planning-Ansatz. Jetzt dispatche ich Arbeit abends und wache mit Pull Requests auf, die CI bestehen. Die Kurve von “hilfreicher Assistent” zu “autonomer Builder” verlief in 18 Monaten.

Die Obergrenze, die wir annahmen - “AI kann Boilerplate aber kein echtes Engineering” - ist weg. Und Mythos sagt uns, dass wir noch weit von der Spitze entfernt sind.

Bodies: Vom einzelnen Agent zu Agent Teams

Das Problem mit einem brillanten Brain ohne Struktur: teures Chaos.

Ich habe die Evolution selbst durchlebt. Mein Weg über 18 Monate sah so aus:

Single Session - ein Claude Code Chat, ich schaue zu, tippe Prompts. Nützlich aber langsam.
Parallele Agents - mehrere Claude Code Instanzen, jede auf eigenem Git Branch, ich wechsle zwischen ihnen. 3-4x Durchsatz. Die Patterns habe ich beschrieben in Agentic Development Patterns.
Headless Agents - Agents auf einem Remote Server, 24/7, gesteuert vom Handy. Das komplette Setup beschreibe ich in From Terminal to Factory. Das war der Sprung vom “Tool” zur “Belegschaft.”
Strukturierte Agent Teams - Agents mit definierten Rollen (Architect, Implementer, Reviewer, Tester), die einem Skills Framework folgen, das Engineering-Disziplin kodiert. Garry Tans gstack Framework geht noch weiter mit 23 Spezialisten-Rollen.

Bei jedem Schritt war ich der Koordinator. Ich entschied, was wann läuft. Ich löste Konflikte zwischen Agents. Ich war der Manager.

Das änderte sich Anfang 2026.

Paperclip AI knackte 42.000 GitHub Stars innerhalb von Wochen nach dem Launch. Es führt Agents nicht nur aus - es managed sie. Agents bekommen Org Charts, Budgets und Governance. Sie senden Heartbeat Updates. Andere Agents subscriben. Ein Agent, der sein Budget aufbraucht, wird pausiert, nicht gewarnt. Das System erzwingt die Disziplin, die ich manuell gemacht habe.

Ähnlich wie Kubernetes Container-Orchestrierung abstrahierte. Paperclip abstrahiert Agent-Orchestrierung. Es sitzt auf Claude Code, Codex, Cursor - was auch immer deine Agents nutzen - und fügt den Management Layer hinzu.

Aber hier ist der Teil, der am meisten zählt. Dasselbe Muster entsteht mit Menschen, nicht nur mit Maschinen.

Nehmen wir Langfuse, die Open-Source LLM Observability Platform aus Berlin. Fünfzehn Leute. Anfang 2026 von ClickHouse übernommen. Ihr öffentliches Handbook sagt es klar: “80% of work is shipped by a single person without needing to collaborate.” Zwei Meetings pro Woche - ein 15-minütiges Planning und eine 60-minütige Demo. Das war’s. Engineers managen ihre Backlogs, entscheiden selbst woran sie arbeiten, und shippen ohne um Erlaubnis zu fragen. Sie bauen bewusst das, was sie “strong ICs who are autonomous and highly leveraged with AI” nennen.

Langfuse ist kein Einzelfall. Es ist das Signal. Eine wachsende Zahl von Startups nutzt das, was ich das Micro-Founder Model nennen würde: jede Person, die dazukommt, bekommt eine Domain, ein Budget und baut ihren Teil des Produkts autonom. Kein Sprint Planning. Keine Standups. Keine Koordinations-Meetings. Das Unternehmen wächst durch autonome Builder, nicht durch größere Teams.

Ich glaube seit zwanzig Jahren, dass das beste Produkt entsteht, wenn eine Person alle Rollen ausfüllt - mit Kunden spricht, die Lösung designed, den Code schreibt, shipped. Jedes Mal, wenn man eine Idee auf fünf Spezialisten aufteilt und deren Arbeit durch Meetings und Tickets zusammenfügt, wird die ursprüngliche Intention verwässert. Zwanzig Jahre lang war das eine nette Theorie mit einer harten praktischen Grenze: Eine Person konnte nicht alles allein schaffen.

Diese Grenze ist gerade verschwunden.

Memory: Was es zum Compound Effect macht

Brains und Bodies allein erzeugen eine Belegschaft mit Amnesie. Jede Session startet bei Null. Die Arbeit wird erledigt. Das Wissen verschwindet.

Das ist der Teil, den die meisten übersehen - und der, für den ich am meisten Zeit investiert habe, ihn von Hand aufzubauen.

Das Problem ist real. Ich hatte einen Agent, der etwas Brillantes baute, und der nächste Agent auf derselben Codebase hatte null Context darüber, was gebaut wurde oder warum. Ich war das Memory. Jeden Morgen erklärte ich neu die Architektur, die Entscheidungen, die Constraints. Wenn sich das anhört wie jeden Tag einen neuen Freelancer onboarden - genau das war es.

Die Lösung hat zwei Ebenen, und sie passen zu etwas, das Andrej Karpathy 2023 sagte und das sich als prophetisch herausstellte: “The hottest new programming language is English.”

Language-Based Memory (Der menschliche Layer)

Karpathys Satz klang wie ein Witz. Es war eine Vorhersage.

Die besten Knowledge Structures für das AI-Zeitalter sind keine Datenbank-Schemas oder JSON Configs. Es ist einfache Sprache. Markdown Files. Lesbarer Text, den Menschen öffnen und verstehen können, und den Agents lesen, durchdenken und danach handeln können.

Das baue ich täglich:

CLAUDE.md Files geben jedem Agent denselben Projektkontext - Architekturentscheidungen, Coding Standards, Domain-Konventionen. Ich habe einen ausführlichen Guide dazu geschrieben: The Perfect CLAUDE.md. Ein gut geschriebenes CLAUDE.md ist gleichzeitig Dokumentation für Menschen, Context für Agents und institutionelles Memory, das über Sessions hinweg bestehen bleibt.
Obsidian Vaults dienen als mein Second Brain. Einfache .md Files in Ordnern. Kein Lock-in. Kein proprietäres Format. Jede Notiz aus Kundengesprächen, jede Architekturentscheidung, jedes Research Finding - alles in Markdown, das jeder Agent parsen und jeder Mensch lesen kann.
Strukturierte Skill Files kodieren Engineering-Prozesse als lesbare Anweisungen. Das Skills Framework macht Tribal Knowledge zu etwas, dem Agents konsistent folgen können.

Ein Format, drei Zielgruppen: menschlicher Leser, AI Agent, Search Index. Das ist die “Programming Language”, die Karpathy vorhergesagt hat.

Technical Memory (Der Machine Layer)

Der Language Layer deckt ab, was Menschen verstehen müssen. Der Technical Layer skaliert.

Vector Databases wie Pinecone speichern Information nach Bedeutung, nicht nur nach Keywords. Wenn ein Agent “die Diskussion über Retry-Logik von letzter Woche” braucht, sucht er nach semantischer Ähnlichkeit - nicht exakten Dateinamen. Das macht große Knowledge Bases tatsächlich nutzbar.

GBrain, gebaut von Y Combinator CEO Garry Tan, geht weiter. Es ist ein vollständiger Memory Layer, den der Agent selbst installiert und betreibt. E-Mails, Meetings, Notizen, Kalendereinträge - alles in eine lokale Postgres-Datenbank eingebettet, durchsuchbar nach Bedeutung und exakter Übereinstimmung. Siebenunddreißig Operationen, von Import über Embedding bis Query und Sync. Der Agent schließt eine Aufgabe nicht ab und vergisst. Er schreibt zurück, was er gelernt hat.

Der praktische Unterschied: Ohne Memory sind Agents Freelancer, die jeden Tag frisch anfangen. Mit Memory sind sie Kollegen, die institutionelles Wissen aufbauen. Die Qualität ihrer Arbeit wird besser, je länger sie an deinem Projekt arbeiten.

Ich pflege das seit über einem Jahr von Hand - es funktioniert, braucht aber konstanten Aufwand. Tools wie GBrain machen aus dieser manuellen Arbeit Infrastruktur. So wie Docker aus “funktioniert auf meinem Rechner” etwas Reproduzierbares machte.

Mein aktueller Stack

So sieht das in der Praxis aus. Das ist nicht theoretisch - damit shippe ich Software:

Layer	Was ich nutze	Was es tut
Brains	Claude Opus 4.6, Claude Sonnet 4	Die Models, die das eigentliche Engineering machen
Orchestration	Claude Code + Headless Agents	Parallele Workstreams, Overnight Factories, Remote Dispatch
Planning	Ultraplan, Spec-Driven Workflow	Cloud-basiertes Multi-Agent Planning vor der Execution
Discipline	Skills Framework, gstack Roles	Engineering-Prozess als Code, Spezialisten-Rollen
Memory	CLAUDE.md, Obsidian, Project Context	Persistentes Wissen über Sessions hinweg
Architecture	Three-Tier AI Pattern	Rules vs. ML vs. Agents - das richtige Tool für jeden Job
Local Fallback	Gemma 4 auf Apple Silicon	Frontier-Class Local Model, in Claude Code integriert

Jedes Stück verlinkt auf einen Deep-Dive, den ich geschrieben habe. Das ist nicht ein Tool - es ist ein System. Und dieses System produziert mehr funktionierende Software als jedes Team, das ich in 25 Jahren geführt habe.

Was Leadership wird

Wenn eine Person bauen kann, wofür früher ein Team nötig war - was bedeutet Leadership dann?

Ich habe 25 Jahre lang Engineers eingestellt, Org Charts gezeichnet, Standups geleitet, über Sprint Velocity debattiert. Ich war gut darin. Und ich denke jetzt, dass das meiste davon das Management eines Engpasses war, der verschwindet.

Das traditionelle Setup - Product Manager schreiben Requirements, Engineering Manager verteilen Arbeit, Scrum Master moderieren Ceremonies, Tech Leads reviewen Code - existiert, weil Arbeit auf viele Menschen verteilt werden musste, die aligned bleiben mussten. Dieser ganze Management Layer ist Koordinationskosten. Notwendig, wenn zehn Leute eine Sache bauen. Aber Kosten.

In einer Welt von Micro-Foundern mit Agent Teams behält Leadership, was wirklich zählt, und streift alles ab, was nur Kleber war:

Vision wird zum Hauptjob. Nicht die vage Art in einem Deck, das niemand liest. Eine klare, messbare Richtung, der jeder autonome Builder eigenständig folgen kann. Wenn ein Micro-Founder deine Vision nicht lesen und den richtigen Product Call machen kann, ohne dich zu fragen, ist deine Vision nicht gut genug.

Trust ersetzt Control. Du hörst auf, jeden Pull Request zu reviewen. Du definierst, wie Erfolg aussieht - in Zahlen, für Kunden - und vertraust jedem Builder und seinem Agent Team, den besten Weg dorthin zu finden. Der Leader, der nicht loslassen kann, wird zum Engpass in einem Unternehmen, das darauf ausgelegt ist, keinen zu haben.

Judgment wird zum knappsten Skill. Wenn Execution günstig und schnell ist, trennt die richtige Auswahl dessen, was gebaut wird, Gewinner von Unternehmen, die einfach nur viel Code shippen. Welches Kundenproblem lösen. Welchen Markt angehen. Welche Wette eingehen. Welches Feature killen. Kein Agent Framework trifft diese Entscheidungen für dich.

Das ist eine Rückkehr zu dem, was Leadership immer sein sollte. Bevor wir es unter Jira, Velocity Charts und Status Meetings begraben haben.

Was sich für jedes Tech-Unternehmen ändert

Hier geht es nicht um Headcount oder Effizienz. Das ist die langweilige Lesart.

Die spannende Lesart: Was wird möglich, wenn man aufhört, 80% seiner Energie für Koordination auszugeben, und anfängt, sie für das eigentliche Kundenproblem einzusetzen?

Denk darüber nach, was die meisten Product Teams den ganzen Tag tun. Refinement Meetings. Tickets schreiben. Story Points schätzen. Auf Code Review warten. Standups. Prioritäten zwischen Teams verhandeln. Bis sie beim eigentlichen Kundenproblem ankommen, wurde die Lösung sechsmal durch die Übergabekette verwässert, die sie produziert hat.

Jetzt stell dir eine Person vor mit tiefem Kundenverständnis, starkem Product Taste und einem Agent Team - die in Tagen statt Quartalen vom Insight zum fertigen Produkt kommt. Kein Komitee. Keine Verwässerung. Kein “das nehmen wir in den nächsten Sprint.”

Das schaltet diese Konvergenz frei. Nicht billigere Software. Bessere Software. Produkte, die näher an dem sind, was Kunden wirklich brauchen, weil der Builder dieselbe Person ist, die mit dem Kunden gesprochen hat. Produkte, die in Stunden statt Sprints iterieren. Produkte, die schwierigere Probleme lösen, weil der Builder alle Energie auf das Problem konzentrieren kann statt auf den Prozess drumherum.

Langfuse hat mit fünfzehn Leuten eine branchendefinierende Plattform gebaut - weil ihre Struktur jeder Person erlaubt hat, sich auf echte Probleme für echte Entwickler zu konzentrieren, ohne dass der Overhead ihr bestes Denken auffrisst.

Die Unternehmen, die sich zuerst bewegen, werden nicht nur schlanker sein. Sie werden Dinge bauen, die ihre Wettbewerber nicht können. Die Lücke zwischen dem, was möglich ist, und dem, was die meisten Organisationen für möglich halten, war noch nie so groß.

Ich habe zu jedem Teil dieses Stacks detaillierte Guides geschrieben. Wenn du ein Builder bist, der so arbeiten will, starte mit Agentic Development Patterns und The Overnight Agent Factory. Wenn du ein Leader bist, der den Shift verstehen will, lies The Perfect CLAUDE.md - es zeigt, wie Knowledge Transfer zu Agents in der Praxis funktioniert.

Der Engpass waren immer Menschen. Nicht weil Menschen nicht gut genug sind. Weil eine Person nicht skalieren konnte. Jetzt kann sie es.