Code w/ Claude London durch die Bitter Lesson

Ich war am 19. Mai bei Code w/ Claude London im Raum. Die Live-Takeaways habe ich noch in derselben Woche auf LinkedIn geschrieben. Dieser Post ist die langsame Version: die Workshop-Notizen, die nach einer Woche überlebt haben, die Eval-Disziplin, die ich gerade in meinen eigenen Production Stack einbaue, und die unbequeme Frage, zu der ich immer wieder zurückgekommen bin — welche der Muster, die ich gerade gelernt habe, wird Claude 6 obsolet machen?

Diese Frage hat einen Namen. Rich Sutton nannte sie The Bitter Lesson in 2019. Es ist ein einseitiger Essay und es ist die nützlichste Linse, die ich gefunden habe, um zu entscheiden, in was man als Agent Engineer in 2026 investieren sollte.

Dieser Post ist in drei Teile gegliedert:

1. Drei Workshop-Takeaways, die nach einer Woche geblieben sind
2. Das größere Muster — eval-driven Agent Development
3. Die Bitter-Lesson-Linse — was sich aufbaut, was gefressen wird

Das Event

Code w/ Claude ist Anthropics Developer-Konferenz. Die 2026er Ausgabe lief in drei Städten: San Francisco am 6. Mai, London am 19. Mai und Tokio am 10. Juni. Die London-Edition war um drei Haupttracks organisiert: Research, Claude Platform und Claude Code. Workshops, Demos, Breakouts, Office Hours mit Anthropic-Engineers und eine parallel laufende Builder Stage mit Founder-Talks.

Die Opening-Keynote hat Boris Cherny mit dem Rest des Anthropic Platform Teams gehalten. Boris hat über seine eigenen Builder-Roots vor Anthropic gesprochen — und dieses Framing trifft anders, wenn du als Softwareengineer im Raum sitzt, der davon lebt. Das ganze Event lehnt sich klar an "Builders building" statt "Vendor pitcht zu Prospects". Das ist die richtige Form für diese Phase des Agent-Ökosystems.

Drei Takeaways, die geblieben sind

Managed Agents — Session State als Default

Isabella Hes Workshop "Ship your first Managed Agent" war das Erste, das mich ein Mental Model umschreiben ließ.

Das Muster, das ich mitgebracht hatte: Ein Agent hat ein Context Window, das Context Window verdampft zwischen Sessions, und ich bin verantwortlich dafür, was überleben soll — Task Board, Zwischenergebnisse, Tool-Call-Historie. Das heißt eine Datenbank. Das heißt Migrations. Das heißt Infrastruktur, die ich für ein System, das noch wöchentlich iteriert, eigentlich nicht selbst besitzen will.

Managed Agents drehen das um. Anthropic positioniert Managed Agents als developer-facing Infrastructure Layer zum Bauen und Betreiben von AI-Agents — Workloads verschieben sich weg von isolierten Inference Calls hin zu koordinierten, stateful Workflows. Session State — Messages, Tool Calls, Results — wird serverseitig von Anthropic persistiert. Clientseitig hältst du eine Session-ID. Die volle Historie spielt sich über sessions.events.list() zurück.

Was sich in der Praxis ändert:

• Kein DB-Schema-Design für Conversation State
• Keine Backup/Restore-Strategie für Agent-Historien
• Full Audit Trail by default — jedes Event ist queryable
• Die Agent Surface und die Storage Surface sind dasselbe

Der Trade-off, den Isabella klar angesprochen hat: Du koppelst dich an Anthropics Persistence Model. Quer durch Claude Code, Claude Platform, Claude Managed Agents, MCP Connectors, Memory Stores, Routines, Subagents, Skills, Managed Settings und Telemetry baut Anthropic mehr von der Agent Control Plane rund um das Modell. Wenn du prototypest oder iterierst, ist das ein fairer Trade gegen die Infrastruktur, die du nicht selbst baust. Wenn du harte Anforderungen an State Portability hast, architekturierst du anders.

Für mich — der multi-tenant Agent-Systeme baut, bei denen der client-facing Value der Output des Agents ist, nicht das Session-Ledger — passt der Trade. Ich investiere die Engineering-Zeit lieber in Tool-Design und Evals.

Memory + Dreaming — Ein Filesystem und ein Kurator

Kevin Chans Workshop zu Memory + Dreaming ist der, zu dem ich immer wieder zurückkomme.

Das Mental Model, mit dem ich reingegangen bin: "Memory" heißt, relevanten Context am Anfang einer Session in den Prompt zu stopfen. Im Grunde RAG, mit hübscherem Namen. Vielleicht eine einzelne memory.md-Datei, die der Agent beim Boot liest.

Das ist auf beiden Achsen falsch. Anthropics Memory Tool speichert Informationen über ein Memory-File-Directory (/memory), das zwischen Sessions persistiert. Der Agent kann Dateien in diesem Memory-File-Directory anlegen, lesen, updaten und löschen.

Ein Memory Store ist ein Filesystem, keine Datei. Jeder Eintrag hat seinen eigenen Pfad (/projects/foo/notes.md), sein eigenes Size Budget und seine eigene Edit-History. Der Agent lädt nicht den ganzen Tree beim Boot — er greppt nach dem Keyword, das er braucht, findet die passende Datei, liest dann nur den passenden Chunk. Selbes Mental Model wie Claude Code in einem lokalen Repo. Das Context Window bleibt klein, auch wenn der Store wächst.

Der zweite Move heißt "Dreaming." Das ist ein async Curator Subagent. Während der Foreground Agent arbeitet — oder zwischen Sessions — läuft ein separater Prozess durch den Memory-Tree und reorganisiert ihn: konsolidiert Duplicates, markiert veraltete Einträge, reichert verwandte Facts an, restrukturiert das Directory-Layout. Der Output ist kein In-Place-Edit. Es ist ein neuer Memory Store, den du in der nächsten Session einswappst.

Das sauberste Framing von Kevin: Memory ist nicht, wo der Agent Antworten speichert. Es ist, wo der Agent Lessons speichert — und Dreaming ist das System, das rohe episodische Notes in eine kuratierte Knowledge Base verwandelt, von selbst, auf einem Cron.

Das Customer Signal hier ist stark. Rakutens long-running Task Agents nutzen Memory, um vergangene Fehler nicht zu wiederholen, und berichten 97 Prozent weniger First-Pass-Errors innerhalb workspace-scoped, observable Boundaries. Das ist die Größenordnung, ab der sich Engineering dafür lohnt, nicht dagegen.

Agent Decomposition — Der harte Teil ist das Interface

William Steuks Workshop zu Agent Decomposition war auf den Slides trügerisch simpel und in der Praxis überhaupt nicht.

Das Muster: Wenn der Tool-Katalog deines Orchestrators zu groß wird, als dass das Modell ihn sauber durchreasonen könnte — meistens irgendwo nördlich von 15-20 Tools, je nach Overlap — dekomponierst du. Gruppiere verwandte Tools zu fokussierten Subagents mit schmalen Tool-Sets. Der Orchestrator ruft Subagents auf statt Tools direkt. Jeder Subagent ist klein, fokussiert und hat eine Tool-Surface, die er tatsächlich navigieren kann.

Der Teil ist offensichtlich, sobald du ihn gespürt hast. Der nicht-offensichtliche Teil ist das, was William als das eigentlich harte Problem markiert hat:

Der harte Teil ist nicht, den Split auszusuchen. Es ist, das Interface zwischen den Layern zu definieren.

Sobald du Orchestrator + Subagents hast, hast du ein Protokoll. Was übergibt der Orchestrator? Was returnt der Subagent? In welchem Format? Auf welche Invarianten verlässt sich der Orchestrator? Was passiert, wenn der Subagent teilweise fehlschlägt? Wenn die Messages zwischen Layern mehrdeutig oder verlustbehaftet sind, degradiert das ganze System — und schlimmer, der Failure Mode ist schwer zu lokalisieren, weil er über die Interface-Boundary verteilt ist.

Das ist dieselbe Lektion, die Distributed-Systems-Leute in den 2010ern gelernt haben: Service Decomposition ist hauptsächlich ein Interface-Design-Problem, das sich als Architektur-Problem verkleidet. Agent Decomposition erbt dieselbe Lektion — und Leute, die Microservice-Systeme verschickt haben, haben hier einen echten Vorsprung, den die Prompt-Engineering-Generation nicht hat.

Ich nutze das als Forcing Function für meinen eigenen multi-tenant SEO-Agent. Aktuell hat er 13 in-process Tools auf einem einzigen Orchestrator. Manche davon clustern natürlich: die GSC-Tools, die Paid-Channel-Audit-Tools, die Content-Brief-Tools, die Webflow-Publishing-Tools. Der Split ist einfach. Der Interface-Contract zwischen einem Orchestrator und einem "Content-Brief Subagent" ist die Arbeit, die ich noch nicht gemacht habe.

Das größere Muster: Hill Climbing auf dem Eval

Die einzelne meistzitierte Zeile aus London in meinen Notes:

Hill Climbing auf dem Eval — climb on them.

— William Steuk (paraphrasiert)

Das ist das Muster, das jeden anderen Workshop miteinander verbunden hat. Es kam in der Decomposition-Session hoch, es kam in der Managed-Agents-Session hoch, und es war der ganze Content des Eval-driven-Agent-Development-Workshops.

Der Frame: Deine Eval-Suite ist eine Landschaft. Jede Prompt-Änderung, jeder Model-Swap, jeder Tool-Tweak, jede Architektur-Entscheidung ist ein Schritt. Du löst Agent-Qualität nicht in einem Schritt. Du wählst den nächsten Schritt, der den Score nach oben bewegt, und wiederholst. Das Eval gibt dir den Gradient. Ohne es bist du nicht engineering — du vibest mit Extra-Schritten.

Ein paar Sachen aus dem Eval-Workshop, die die Woche überlebt haben:

LLMs sind schlecht darin, ihre eigenen Evals zu definieren. Lass das Modell nicht seine eigene Rubric schreiben. Es wird unterspezifizieren, herumwedeln und seinen eigenen Output milde benoten. Das Modell kann eine Rubric anwenden (LLM-as-judge ist okay, mit Vorbehalten). Es kann keine schreiben, gegen die zu optimieren sich lohnt. Die Rubric muss von einem Menschen mit Geschmack in der Domain kommen.

"Gut" zu definieren ist die eigentliche Arbeit. Die Zeile, die mich getroffen hat, war ungefähr: "Manchmal schaust du einen Film und weißt, dass er schlecht ist, kannst aber nicht artikulieren warum." Der Gap zwischen Qualität gefühlt und Qualität artikuliert ist der ganze Job, eine Eval-Rubric zu schreiben. Der Score wird nicht nützlich, bevor jemand im Raum die Failure Modes in Sprache benennen kann. Das ist nicht Engineering. Das ist Knowledge Elicitation. Den meisten Engineers ist das unbequem, weil es kein Code ist.

Woher Rubrics nehmen, wenn du selbst nicht der Experte bist. Scrape Orte, an denen Domain Experts Qualität bereits in Sprache artikulieren — Subreddit-Critiques, Product Reviews, Expert Blogs, Code-Review-Threads, Design Critiques. Die haben die Arbeit, tacit quality in Kriterien zu konvertieren, schon gemacht. Du kannst das minen, um deine Judge Prompts zu seeden. Das war der einzelne actionable-ste Tipp aus dem Workshop.

Zwei Arten von Gradern. Splitte deine Evals in:

• Code Graders — deterministisch, keine LLM-Calls, sofort, gratis. Für meinen SEO-Agent: Hat er einen Output produziert? Liegt der Word Count im Range? Hat er das Target-Keyword im H1 benutzt? Stimmt die Anzahl der Internal Links? Das ist TypeScript über geparsten Output. Läuft auf jedem PR.
• Judge Graders — LLM-as-judge-Calls, strukturierte 0–5-Scores über Schema. Für meinen SEO-Agent: Hookt das Intro? Ist der Ton konsistent zu den Brand-Voice-Beispielen? Matched das H1 die Brief-Intent? Brauchen ein Modell, das lesen kann.

Beide gehen in eine Scorecard. Heatmapped rot/gelb/grün. Deltas gegen eine gespeicherte Baseline. Du schaust auf die Scorecard vor und nach jeder Änderung. Das war's. Das ist der Loop.

Du kannst mehrere Judge-Dimensionen in einem gebatchten Vision-Call laufen lassen. Eine kleine Efficiency-Note, die bei Scale zählt: Feuer nicht einen LLM-as-judge-Call pro Dimension. Memoize einen einzigen Batched Call, der alle Dimensionen auf einmal zurückgibt. Vier Judges, ein Batch.

Optionaler nächster Schritt: den Loop schließen. Das Reference Setup des Workshops ist one-shot — Agent generiert, Graders graden, Scorecard druckt, Mensch iteriert. Du kannst Grader-Scores zurück an den Agent verdrahten (failing Rows in eine zweite Session füttern und ihn bitten, gegen die zu retryen). Die Reference macht das nicht, aber es ist der natürliche nächste Schritt, sobald dein Eval-Set reif genug ist, dass automatisierte Iteration nicht in lokale Minima driftet.

Ich habe London mit dem als meine größte Schuld verlassen. Ich habe keine sauberen Evals auf meinem multi-tenant SEO-Agent. Ich habe Intuition, gebaut aus Monaten Shipping, und Intuition ist okay, bis sie es nicht mehr ist. Ohne Evals kann ich dir nicht sagen, ob ein Model-Swap die Sache besser oder schlechter gemacht hat. Ich kann dir nicht sagen, ob ein Prompt-Tweak tatsächlich eine Verbesserung ist oder nur ein anderer Vibe. Ich fliege auf Gefühl in einem System, das wöchentlich quer durch das Kundenportfolio einer Agentur läuft, und in dem Moment, in dem ich das laut zugebe, wird offensichtlich, dass sich das dieses Quartal ändern muss.

Die Bitter-Lesson-Linse

Jetzt der unbequeme Teil.

The Bitter Lesson sind zwei Seiten. Rich Sutton hat sie 2019 geschrieben. Die These ist einfach und unbequem:

Die größte Lektion, die sich aus 70 Jahren AI-Research lesen lässt, ist, dass generelle Methoden, die Computation hebeln, am Ende die effektivsten sind, und zwar mit großem Abstand.

Das Muster, das Sutton dokumentiert: Jede Generation von AI-Researchern versucht clever zu sein, indem sie ihr Verständnis davon, wie das Problem "funktionieren sollte", encodet — handgemachte Chess-Heuristiken, Phonem-basierte Speech Models, SIFT Features für Vision. Und jede Generation wird, irgendwann, von simpleren Methoden geschlagen, die Compute über Search und Learning skalieren. Die Cleverness plateaut. Die Compute skaliert weiter. Das Bittere ist, dass Researcher wollen, dass ihre Cleverness zählt, und sie tut es nicht.

Das auf Agent Building in 2026 übersetzt:

Der Harness schrumpft, weil das Modell ihn absorbiert. Schau auf die letzten vier Jahre:

• 2022: Prompt Engineering als Handwerk — Magic Phrases, Role Playing, "let's think step by step." Größtenteils weg. Modelle reasonen jetzt nativ.
• 2023: handgemachte Output Parsers, Regex, das JSON aus Completions herauskitzelt. Weg. Structured Outputs und Function Calling sind native.
• 2024: elaborate RAG-Pipelines mit bespoke Chunking und Reranking. Schrumpft. Long Context plus native Retrieval frisst das meiste.
• 2025: handgewartetes Memory, custom Multi-Agent-Orchestration, handgebaute Verification Loops. Schrumpft gerade — Managed Agents, Memory + Dreaming, native Multi-Step Tool Use sind genau die Bitter Lesson in Echtzeit.

Jeder Layer aus menschlicher Cleverness im Harness wird irgendwann gefressen. Das ist kein Versagen der Harness-Arbeit. Sie war nützlich, solange sie nötig war. Es ist nur die Trajektorie.

In was investierst du also wirklich?

Was sich quer durch Modellgenerationen aufbaut (tief bauen):

• Evals und Rubric-Design. Modelle werden besser, aber die Frage "Hat sich mein System auf meiner Domain verbessert?" geht nie weg. Die Rubric ist der Teil, der jeden Model-Swap überlebt.
• General-purpose Tools. Ein Bash Tool plus Code Execution plus Web Access kann fast alles. Das Modell nutzt sie besser, wenn es smarter wird. Fünfzehn schmale spezialisierte Tools sind Harness-Arbeit, die geschluckt wird.
• Production Substrate. Sandboxes, Capability Boundaries, Audit Trails, Distributed Locks, Identity, Permissions, Observability. Das ist keine Cognition. Das ist Systems Engineering. Wird nicht gefressen, weil es nicht das ist, was das Modell tut — es ist das, was das Modell in Production umgibt.
• Domain Knowledge und Integration Surfaces. Zu wissen, was ein bestimmtes CRM in Production tatsächlich tut, was eine Webflow CMS akzeptiert und nicht akzeptiert, was die Industrie deines Clients wertschätzt — das Modell hat das für deine spezifischen Verticals nicht. Bleibt wertvoll.
• Geschmack und Problem-Auswahl. Die Fähigkeit, auf einen Workflow zu schauen und zu wissen, welche Teile zu automatisieren sind, welche menschlich bleiben, wo der Leverage tatsächlich liegt. Das Beständigste auf der Liste.

Was gefressen wird (nutzen, aber so architekturieren, dass du es wegwirfst):

• Das meiste Prompt Engineering jenseits eines klaren, minimalen System Prompts
• Handgemachte Memory Schemes (Memory + Dreaming ist das Writing on the Wall)
• Bespoke Multi-Agent-Orchestration-Patterns (Managed Agents kommen dafür)
• Custom Verification Harnesses für Sachen, die Modelle eventuell selbst verifizieren werden
• Schmale spezialisierte Tools, wo ein General Tool reicht

Die one-line Operational-Version: Encode deinen Geschmack als Evals, nicht als Rules. Rules constrainen das Modell. Rules werden gefressen, sobald das Modell smarter wird. Evals lassen das Modell sich gegen die Sache verbessern, die dir tatsächlich wichtig ist. Evals bauen sich auf.

Das ist der Move, der Suttons 2019er Essay mit Williams "Hill Climb on the Eval" in 2026 verbindet. Evals sind nicht nur Measurement-Infrastruktur. Sie sind das langlebige Scaffolding rund um ein zunehmend fähiges Modell. Du baust keine Cleverness mehr. Du baust das Gradient-Signal, das die Cleverness von selbst passieren lässt.

Was ich in meinem eigenen Stack ändere

Drei konkrete Dinge aus London, die in den nächsten Monat in meiner Arbeit landen:

1. Echte Evals für den multi-tenant SEO-Agent. Embarrassend klein anfangen: 10–20 Inputs per Hand picken, für jeden definieren, was "gut" heißt, vor und nach jeder relevanten Änderung laufen lassen. Code Graders und Judge Graders dazuschichten, sobald die Rubric reift. Aufhören, auf Vibes Hill Climbing zu machen.
2. Die 13 in-process Tools auditen. Für jedes fragen: Ist das hier, weil es in Production load-bearing ist (deterministic Safety, Idempotency, Audit Trail), oder weil heutige Modelle nicht zuverlässig genug sind, um mit einer generelleren Primitive vertraut zu werden? Alles im zweiten Bucket steht auf einer 12–18-Monats-Uhr.
3. Interface Contracts definieren, bevor ich den Orchestrator splitte. Wenn ich den SEO-Agent in einen Content-Brief-Subagent, einen Audit-Subagent und einen Publishing-Subagent dekomponiere, ist das Protokoll dazwischen die Arbeit. Diesen Contract zu designen ist wichtiger als auszusuchen, welche Tools wohin gehen.

Schlusswort

The Bitter Lesson ist unbequem, weil sie dir sagt, dass das meiste der cleveren Harness-Arbeit, die du gerade machst, in 18 Monaten obsolet sein wird. Sie ist auch befreiend, weil sie dir genau sagt, wo du deine Zeit hinstecken solltest: auf die Teile, die sich quer durch Modellgenerationen aufbauen. Evals. Substrate. Domain Knowledge. Geschmack.

Code w/ Claude London war das erste Event, auf dem ich die ganze Industrie sich leise um genau das herum ausrichten gesehen habe. Managed Agents ist Suttons Lektion angewandt auf Session State. Memory + Dreaming ist Suttons Lektion angewandt auf long-running Context. Eval-driven Development ist Suttons Lektion angewandt darauf, wie du tatsächlich iterierst.

Der Takeaway ist nicht "nutze die neuen Anthropic Features". Der Takeaway ist: Bau die Disziplin, die jede Feature-Iteration überlebt.

Danke an Anthropic für die Einladung, an Boris, Isabella, Kevin und William für die Workshops, bei denen es sich gelohnt hat, mitzuschreiben.

Wenn du auch in London warst oder an Agent Harnesses in Production arbeitest, würde ich gern hören, wie du die Eval-Disziplin-Frage angehst — schreib mir.

Weiterführend

• The Bitter Lesson — Rich Sutton, 2019. Zwei Seiten. Lies sie heute Abend.
• Code w/ Claude — die Konferenz selbst, Recordings landen auf Anthropics YouTube Channel.
• Anthropic Managed Agents — der Platform Layer, auf dem die London Workshops aufbauten.
• Mein LinkedIn-Recap von Code w/ Claude London — die kürzere Live-Version dieser Notes.