Code with Claude 2026 — Agents lernen träumen, Limits fallen, Musk liefert Strom

Am 6. Mai hat Anthropic in San Francisco Code with Claude 2026 veranstaltet — die zweite Auflage der Entwicklerkonferenz und zugleich einer der dichtesten Produktrelease-Tage, die Anthropic bisher hatte.

Drei Achsen lohnen den Blick:

Managed-Agents-Features — die erste Achse:

Dreaming ist ein geplanter Hintergrund-Prozess, der zwischen Sessions die bisherigen Agent-Transkripte und den Memory-Store durchgeht. Harvey berichtet aus dem Pilot eine grobe Versechsfachung der Task-Completion-Rate — Anthropics Headline-Zahl, ohne externe Benchmark.

Outcomes legt einen eigenständigen Evaluator-Loop um den Agent: Eine getrennte Claude-Session bewertet den Output gegen ein Bewertungsraster und gibt zurück, was zu fixen ist — auf docx-Tasks +8,4 %, auf pptx +10,1 % Task-Success in Anthropics internen Tests.

Multiagent Orchestration lässt ein Lead-Agent-Modell parallel Subagenten auf einem gemeinsamen Filesystem aufspannen. Netflix nutzt das Pattern, um Build-Logs aus hunderten Quellen parallel zu analysieren.

Rate-Limits und Compute — die zweite Achse:

Die 5-Stunden-Limits in Claude Code wurden permanent verdoppelt für Pro, Max, Team und seat-basierte Enterprise-Pläne; die Peak-Hour-Drosselung, die seit Ende März auf Pro- und Max-Accounts lag, ist weg. API-Rate-Limits für Opus-Modelle wurden „erheblich” angehoben.

Dahinter steht ein Deal, der vor einer Woche noch undenkbar gewesen wäre: Anthropic mietet die gesamte Kapazität von SpaceX’ Colossus-1-Datacenter in Memphis — über 300 Megawatt und mehr als 220.000 Nvidia-GPUs, online innerhalb des Monats.

Warum diese drastische Kehrtwende?

• Rechenkapazitätsengpässe: Anthropic verzeichnete eine massive Nachfrage nach seiner KI, stieß jedoch aufgrund begrenzter Rechenkapazitäten an erhebliche Grenzen.

• Der Überschuss bei SpaceX: Musk hatte für sein eigenes xAI-Projekt überdimensionierte Infrastruktur aufgebaut und verfügte somit über sofort nutzbare Rechenzentrumskapazitäten.

Elon Musk, der Anthropic im Februar noch öffentlich als „evil” bezeichnet hatte, schrieb nach einem Meeting mit Anthropic:

„Everyone I met was highly competent and cared a great deal about doing the right thing. No one set off my evil detector.”

SpaceX habe sich vertraglich das Recht gesichert, Kapazität zurückzuziehen, falls Anthropics AI „Handlungen ausführt, die der Menschheit schaden”.

Claude Code, Code Review, Add-ins — die dritte Achse.

Anthropic stellt Code Review als Research Preview für Team- und Enterprise-Pläne vor: Ein Team von Agenten prüft jeden PR, token-basiert abgerechnet, 15–25 $ pro Review im Schnitt.

Eigener Use-Case-Beleg: Bei Anthropic intern bekamen vor dem Tool nur 16 % der PRs substanzielle Review-Kommentare — nach Rollout 54 %.

Dazu kommen Microsoft-365-Add-ins (Excel, PowerPoint, Word ; Outlook als Preview), Agent-Templates für Financial Services (Pitchbook-Builder, KYC-Screener, Month-End-Closer u. a.), und das Claude Agent SDK ist offiziell für externe Entwickler freigegeben — dasselbe SDK, auf dem IDE und Desktop-App gebaut sind.

Und der Vertikalisierungs-Push läuft direkt weiter.

Am 13. Mai folgt Claude for Small Business — 15 vorgefertigte Workflows, 15 Skills, Connectoren zu QuickBooks, PayPal, HubSpot, Canva, Docusign, Google Workspace und Microsoft 365 — flankiert von einer 10-Städte-Tour (Start in Chicago) mit halbtägigen AI-Fluency-Trainings für je 100 lokale Business-Leader.

Am 14. Mai dann zwei Schwergewichte parallel:

PwC kündigt einen breiten Claude-Einsatz an — für Tech-Entwicklung, Deal-Execution und Enterprise-Transformation.

Und Anthropic kündigt eine 200-Mio.-Dollar-Partnerschaft mit der Gates Foundation über vier Jahre an — Global Health, Bildung und Economic Mobility.

Warum das relevant ist:
Vor einem Monat hat Anthropic Routines vorgestellt; jetzt liefert die Konferenz die Schicht darunter — Dreaming als Memory-Konsolidierung zwischen Läufen, Outcomes als externe Evaluator-Loop, Multi-Agent-Orchestrierung als Lead/Subagent-Pattern.

Das ist nicht zufällig: Es ist exakt der Brain/Hands/Session-Split, den Addy Osmani vor zwei Wochen sortiert hat (siehe #005) — nur jetzt als geliefertes Produkt-Set, nicht mehr als Konvergenz-Beobachtung.

Mercado Libre, das mit 23.000 Engineers auf Code with Claude angekündigt hat, 90 % autonomes Coding bis Q3 2026 als Ziel zu setzen, gibt den Maßstab vor, an dem sich die nächsten Quartale messen lassen.

Und der SpaceX-Deal verschiebt die geopolitische Frage, ob ein einzelner Anbieter sich aus dem Compute-Engpass freikaufen kann, mit einem Schlag in die Gegenwart.

Quellen:

• Anthropic Blog: Code Review for Claude Code

• Anthropic: Agents for financial services

• Simon Willison: Live blog Code w/ Claude 2026

• Let’s Data Science: Dreaming for Claude Managed Agents

• Blake Crosley: Code with Claude SF 2026 Recap

• Capacity Global: Anthropic secures full capacity of SpaceX Colossus 1

• Anthropic: Introducing Claude for Small Business

• Anthropic: $200M Partnership with the Gates Foundation

• Anthropic News: PwC deploying Claude

Claude Code: Die Highlights der Woche

Sieben Releases zwischen 8. und 14. Mai (v2.1.136 bis v2.1.142).

Für alle, die Claude Code täglich nutzen

claude agents — Agent View als CLI-Dashboard (Research Preview) — Eine einzige Übersicht für alle Sessions: laufend, wartend, fertig. Session-ID, Wartet-auf-User-Status, letzte Antwort, Timestamp. Via Linkspfeil aus aktiver Session erreichbar. Für alle, die parallele Worktrees managen, ist das der lange erwartete Supervisions-View.
Mein Fazit: Ich hab’s getestet. Extrem praktisch.

/goal — Completion-Conditions statt nur Prompts — Ein objektiv definiertes Ziel, das Claude über mehrere Turns hinweg verfolgt. Ein separater Evaluator prüft nach jedem Turn die Bedingung; entschieden wird nicht vom Modell, das gerade arbeitet. Funktioniert in Interactive, -p-Flag und Remote Control.

Plugin-Details — claude plugin details <name> listet Token-Kosten und Inventar pro Plugin. Plus: Transkript-Navigation per ?, {, }, v.

Für Hook- und MCP-Workflows

CLAUDE_PROJECT_DIR für MCP-Stdio-Server — Stdio-MCP-Server bekommen den Projekt-Pfad jetzt als Environment-Variable mitgereicht. Wer Server schreibt, die kontextabhängig arbeiten müssen, spart sich den Workaround.

Subagent-Header x-claude-code-agent-id und x-claude-code-parent-agent-id — API-Requests aus Subagents tragen jetzt ihre Identität und die ihres Parent-Agents im Header. Saubere Telemetrie und Audit-Trail über verschachtelte Agent-Bäume — Voraussetzung für Multi-Agent-Debugging, das jenseits eines Levels nicht mehr von Hand geht.

Für Sicherheit und Plattform

Fast Mode läuft jetzt auf Opus 4.7 (v2.1.142, 14. Mai) — Fast Mode in Claude Code nutzt standardmäßig Opus 4.7 statt 4.6; wer beim alten Verhalten bleiben will, setzt CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE=1.

Gleicher Release: acht neue Flags für claude agents (--add-dir, --settings, --mcp-config, --plugin-dir, --permission-mode, --model, --effort, --dangerously-skip-permissions), um die im Hintergrund angestoßenen Sessions zu konfigurieren.

MCP-Hygiene (v2.1.136 und Folge-Releases) — Server verschwinden nicht mehr stillschweigend nach /clear. OAuth-Refresh-Tokens gehen bei parallelen Servern nicht mehr verloren. HTTP/SSE-Server haben kein unbounded Memory-Growth mehr.

Code Review für Team/Enterprise — die größte Neuerung kommt nicht über den CLI-Changelog, sondern als eigenes Produkt: Multi-Agent-PR-Reviews, token-basiert abgerechnet, 15–25 $ pro Review, optimiert auf Tiefe statt Latenz. Direkter Wettbewerber zu Cursors Security Reviewer aus #005.

Quellen:

• Claude Code Changelog

• Anthropic Blog: Agent view in Claude Code

• Claude Code Docs: Keep Claude working toward a goal

• Claude Code v2.1.142 Release Notes

Agentic Coding: Cursor parallelisiert, Codex aufs Handy, xAI tritt in den CLI-Markt ein

Cursor 3.3 (7. Mai) — Drei spürbare Schritte: ein redesignter PR-Review-View mit getrennten Reviews/Commits/Changes-Tabs, Build in Parallel (async Subagenten arbeiten gleichzeitig an unabhängigen Plan-Slices) und PR-Splitting über den Chat-Kontext. Cursor kopiert hier nicht den Anthropic-Push, sondern parallelisiert primär die Ausführung — die Antwort eines IDE-zentrierten Hosts auf die Lead/Subagent-Konvergenz.

Cursor in Microsoft Teams (11. Mai) — @Cursor in jedem Teams-Channel: delegierter Cloud-Agent oder Pull aus Cursor in Teams. Repository- und Modellwahl automatisch. Liest den ganzen Thread für Kontext, erstellt einen PR zur Review. Damit ist Cursor der erste Coding-Agent-Host, der nativ in der primären Enterprise-Kollaborationsschicht sitzt.

Cursor Bugbot mit Effort-Levels (11. Mai) — Default/High/Custom für PR-Reviews, Usage-basierte Abrechnung. Bekanntes Muster: Tiefere Reviews kosten mehr, billigere reichen für offensichtliche Issues.

OpenAI Codex CLI v0.130.0 (8. Mai) — codex remote-control als simpler Entry-Point für einen headless app-server, der von anderen Prozessen aus gesteuert wird. v0.131.0 läuft seit 9. Mai in Alpha mit mehreren Builds pro Tag — Codex zieht bei Headless-Architektur sichtbar nach.

Codex in der ChatGPT Mobile App (14. Mai) — OpenAI bringt Codex in der ChatGPT-App auf iOS und Android, „in Preview, jetzt für alle Pläne”. Vom Handy aus alle Threads sehen, Outputs prüfen, Commands genehmigen, Modelle wechseln, Neues anstoßen. Mobile als Approval-Surface ist die Antwort auf die Lead/Subagent-Realität: Wer den ganzen Tag an verteilten Hintergrund-Agenten arbeitet, will nicht für jeden Approval ans Notebook.

xAI Grok Build — erster CLI-Coding-Agent von xAI (15. Mai, Beta) — Damit ist xAI der dritte Frontier-Lab-Player im Terminal-CLI-Markt nach Anthropic (Claude Code) und OpenAI (Codex CLI). Plan Mode mit Step-by-Step-Approval und Diffs vor jeder Änderung, parallele Sub-Agents für größere Tasks, Headless Mode (-p) für Skripte, Support für AGENTS.md, Plugins, Hooks und MCP-Server, /feedback-Command. Beta zunächst exklusiv für SuperGrok-Heavy-Abos. Inhaltlich keine Überraschung — die Konvergenz auf das Claude-Code-/Codex-Pattern ist bemerkenswert deutlich.

GitHub Copilot — vier Updates 14./15. Mai — Der Cloud-Agent unterstützt Auto-Modell-Auswahl (kein manuelles Vorgeben mehr), Team-Level-Usage-Metrics sind über die API verfügbar (Org-Visibility), die Copilot-Desktop-App geht in Tech Preview (Copilot löst sich aus der IDE), und Memory respektiert nun User-Preferences für Pro/Pro+. Plus weiterhin gültig aus #005-Linie: Cloud-Agent-Secrets auf Org-Ebene (8. Mai) — Geteilte Secrets und Variablen für Agents-Workflows, getrennt von normalen Actions-Secrets.

Quellen:

• Cursor Changelog

• OpenAI Codex Releases (GitHub)

• TechCrunch: OpenAI says Codex is coming to your phone

• The Decoder: xAI plays catch-up with Grok Build

• GitHub Changelog

Trend der Woche

„Act 2” — GitLab restrukturiert sich um Agents, und der nächste Org-Umbau steht an

Am 11. Mai hat GitLab unter dem Titel „GitLab Act 2” einen Komplettumbau angekündigt: Verkleinerung des Country-Footprints um bis zu 30 %, Abbau von bis zu drei Management-Layern, Reorganisation in rund 60 kleinere R&D-Teams mit End-to-End-Ownership — plus eine Workforce-Reduktion, deren finaler Umfang erst auf dem Earnings-Call am 2. Juni bekanntgegeben wird (Bloomberg und mehrere Outlets berichten unter Verweis auf das SEC-8-K-Filing von rund 7 Prozent).

CEO Bill Staples begründet das nicht mit makroökonomischem Druck, sondern explizit mit „der agentischen Ära”: Interne Reviews, Approvals und Handoffs sollen durch AI-Agents ersetzt, Rollen entsprechend zugeschnitten werden. Die Aktie verlor nach Bekanntgabe knapp zehn Prozent.

Das ist die erste börsennotierte Devtools-Firma, die ihre Restrukturierung offen als „Wir bauen uns um Agents herum neu” begründet — und es ist erst der Anfang.

Cloudflares interner Engineering-Stack aus #004, Anthropics Sprung der substanziellen PR-Review-Quote von 16 auf 54 Prozent, Mercado Libres 90-Prozent-Autonomous-Coding-Ziel — sie alle deuten in dieselbe Richtung: Es geht nicht mehr um „AI als Tool für bestehende Workflows”, sondern um die Frage, wie sich Org-Designs verändern, wenn weite Teile der Software-Wertschöpfungskette von Agents getragen werden.

Die unbequeme Seite ist ebenso wichtig. GitLab erntet bereits den Vorwurf des „AI Washings” — Layoffs in agentischer Sprache verpackt. Ob die 60 autonomen R&D-Teams in zwölf Monaten schneller liefern oder ob die Restrukturierung primär eine Margen-Story für Anleger ist, lässt sich heute nicht beantworten. Worauf Teams jetzt achten sollten: Welche Aufgaben automatisieren sich tatsächlich agentisch, welche bekommen nur einen neuen Namen — und welche Restrukturierung ist eigentlich nur eine herkömmliche Kostenkürzung mit Hochglanz-Vokabular.

Quellen:

• GitLab Blog: GitLab Act 2

• Bloomberg: GitLab to Cut Jobs, Reinvest in AI Agent Growth Strategy

• TheNextWeb: GitLab layoffs and the agentic era

Tipp der Woche

„Deliberate Skill Development” — gegen die Fluency-Illusion beim AI-Coding

Cat Hicks (Psychological Scientist mit Fokus auf Software-Teams) und Michael Mullarkey haben einen Skill für Claude Code und Codex veröffentlicht: learning-opportunities auf GitHub. Idee: während des AI-assisted Codings schiebt der Skill kurze, an Lerntheorie orientierte Übungen ein — Prediction, Retrieval Practice, Spaced Repetition. Optional als learning-opportunities-auto mit automatischem Trigger.

Warum das hier steht: Sauber generierter Code wird leicht als verstandener Code wahrgenommen — die klassische fluency illusion. Wer den ganzen Tag mit Coding-Agents arbeitet, baut sich darüber unbemerkt Wissenslücken in genau den Stellen, die später das Debug-Limit setzen. Das Skill ist die seltene Spezies eines AI-Tools, das nicht mehr Output verspricht, sondern verlangsamt — und das ist der Punkt.

Kurz notiert

• Anthropic in Gesprächen über 30-Mrd.-Runde bei 900-Mrd.-Bewertung (12. Mai) — Frühe Investorengespräche, Abschluss möglicherweise noch im Mai. Die Vorrunde im Februar lag bei 350 Mrd. — eine knappe Verdreifachung in drei Monaten. Bloomberg

• Akamai-Compute-Deal über 1,8 Mrd. $ (Bloomberg, 8. Mai) — Sieben Jahre, laut Akamai der größte Vertrag in Firmengeschichte. Akamai-Aktie sprang um 27 % auf 148 $. Revenue beginnt im Q4 2026 mit 20–25 Mio. $ anzulaufen. Bloomberg

• Claude Platform auf AWS (13. Mai, GA) — Erster Cloud-Provider mit nativem Zugriff auf Anthropics Platform-Stack: Managed Agents (Beta), Skills (Beta), MCP-Connector, Files API, prompt caching — alles via AWS-IAM und CloudTrail-Audit. Verfügbar in acht Regionen inklusive Frankfurt, Dublin und London. AWS Machine Learning Blog

• Simon Willison über Shopify River (11. Mai) — Internes Coding-Agent-Tool, das ausschließlich in öffentlichen Slack-Channels operiert; auf Direktnachrichten antwortet River mit dem Vorschlag, einen Channel zu erstellen. Such- und Lernbarkeit by design. Lesenswertes Gegenmodell zu „Agent läuft im stillen DM”. simonwillison.net

• Anthropic Engineering: „How Claude Code works in large codebases” (14. Mai) — Best-Practices-Post zu Multi-Million-Line-Monorepos: CLAUDE.md-Hierarchie, .ignore-Files, permissions.deny, fünf Extension-Points (CLAUDE.md, Hooks, Skills, Plugins, MCP-Server) plus LSP-Integration und Subagents. Kernsatz: „The harness matters as much as the model” — und: RAG-basierte Coding-Tools skalieren in großen Monorepos schlecht, weil die Embedding-Pipelines mit aktiven Engineering-Teams nicht mithalten. claude.com/blog

• Microsoft schiebt Engineers von Claude Code zu GitHub Copilot CLI (14. Mai) — Tom Warren (The Verge) berichtet, dass Microsoft seine Entwickler von Claude Code auf die hauseigene GitHub Copilot CLI umzieht — Claude Code hatte intern hohe Verbreitung gefunden und untergrub den eigenen Tool-Push. Frist und betroffene Microsoft-Gruppe siehe Verge-Original; finanzielle Motivation laut Reporting. Kontrapunkt zur Code-with-Claude-Welle: Plattform-Politik schlägt Tool-Ergonomie. Windows Central

Bisher erschein der ‚Agentic Weekly‘ donnerstags. Ich bin am Überlegen, ob es besser wäre, ihn am Wochenende zu veröffentlichen.

Feedback? Einfach kommentieren/antworten.

7.Mai 2026 — Lesezeit: ~6 Min.

Die große Nachricht der Woche

Long-running Agents bekommen ihre Architektur — Brain, Hands, Session

Am 30. April hat Addy Osmani in einem Long-Read sortiert, was unter „long-running agents” eigentlich gemeint ist — und dabei die Architektur sichtbar gemacht, auf die unabhängig voneinander Anthropic, Cursor und Google zulaufen. Drei verschiedene Bedeutungen, sauber getrennt: Long-horizon reasoning (Modellqualität — die METR-Metrik fürs erfolgreich abgeschlossene Task-Horizon verdoppelt sich seit 2019 alle ~7 Monate, das jüngste TH1.1-Update hat die Anzahl der 8-Stunden-plus-Tasks im Eval-Set verdoppelt), long-running execution (das Modell wird hundert- bis tausendfach über die Laufzeit aufgerufen) und persistent agency (Identität über Tasks hinweg).

Drei Wände, an die jeder Agent läuft: endlicher Context plus „context rot” (Degradation lange vor dem harten Limit), kein persistenter State (Anthropics eigenes Bild: „Engineers, die in Schichten arbeiten — jeder neue ohne Erinnerung an die vorige Schicht”) und keine verlässliche Self-Verification (Modelle bewerten ihre eigene Arbeit konsistent zu positiv).

Spannender als die Wände ist die Konvergenz: Anthropics Brain / Hands / Session-Split, Cursors Planner / Worker / Judge und Googles Agent Runtime / Agent Sandbox / Agent Sessions sind drei Namen für dasselbe Muster. Brain = Modell plus Harness-Loop. Hands = sandboxed, ephemere Execution-Umgebungen. Session = append-only Event-Log, das den Lauf rekonstruierbar macht. Praktisch heißt das: State wandert aus dem Modell-Context heraus ins Filesystem oder in eine Datenbank — die Ralph Loop von Geoffrey Huntley und Ryan Carson zeigt das in 30 Zeilen Bash mit prd.json, progress.txt, AGENTS.md. Anthropic berichtet aus internen Tests von 30+ Stunden autonomem Coding, ein Lauf produzierte einen 11.000-Zeilen-Slack-Klon.

Warum das relevant ist: Wer Agents jenseits der Stundenmarke baut, kommt um diesen Split nicht herum. Osmanis Test ist ehrlich: „If you can’t reconstruct what the agent did in the last 24 hours from durable storage, what you have is a long-running shell script that happens to call an LLM, not a long-running agent.” — Eine Ebene weiter raus zoomt Jack Clark, Anthropic-Mitgründer, in Import AI #455 (4. Mai): Er taxiert die Wahrscheinlichkeit auf 60+ %, dass AI-Systeme bis Ende 2028 autonom R&D betreiben und ihre Nachfolger trainieren. SWE-Bench-Progression von ~2 % (Claude 2, Ende 2023) auf 93,9 % (Claude Mythos Preview); Task-Horizon von ~30 Sekunden 2022 auf ~12 Stunden 2026, Forecaster Ajeya Cotra projiziert ~100 Stunden bis Jahresende. Wer die Architektur-Arbeit dieser Woche zusammen mit Clarks Kurve liest, sieht, warum die Anthropic-Köpfe die Zeitachse für eng halten.

Quellen:

• Addy Osmani: Long-running agents — building the architecture for agents that work for hours, days, and weeks

• Jack Clark / Import AI #455: AI systems are about to start building themselves

Claude Code: Die Highlights der Woche

Vier Releases in einer ruhigeren Woche: v2.1.126, v2.1.128, v2.1.129, v2.1.131. Schwerpunkt: Plugin-Distribution, OAuth-Polish, eine Reihe handfester Subprozess- und Cache-Fixes.

Für alle, die Claude Code täglich nutzen

claude project purge ist da — v2.1.126 räumt alle Claude-Code-Spuren aus einem Projekt: Transcripts, Tasks, File-History, Config. Mit --dry-run, --interactive, --all für mehrere Projekte. Vorher musste man drei Verzeichnisse von Hand kennen.

/context verschwendet keine Tokens mehr — v2.1.129 fixt einen alten Ärger: Der ASCII-Visualisierungs-Block landete bisher in der Konversation und kostete pro Aufruf rund 1.600 Tokens.

/model zeigt nur noch ein Opus-Eintrag — Die Doppelung „Opus 4.7” und „Opus” im Picker ist weg, der aktuelle Opus heißt jetzt schlicht „Opus” (v2.1.128).

Für Plugin- und MCP-Workflows

--plugin-url und --plugin-dir mit Zip — v2.1.128/129 erlauben das Laden von Plugin-Archiven direkt aus URL oder lokaler .zip. Saubere Lösung für Air-Gapped-Setups und ad-hoc-Tests, ohne Marketplace-Eintrag.

MCP-Reconnects fluten die Konversation nicht mehr — v2.1.128: Wenn ein Server seine Tools re-announced, kommt nur noch eine Server-Prefix-Zusammenfassung statt der vollen Tool-Liste. Wer mit fünf+ MCP-Servern arbeitet, merkt das sofort.

/mcp zeigt Tool-Counts — v2.1.128 markiert Server mit 0 Tools — ein simpler Blick reicht jetzt, um stille Misskonfigurationen zu sehen.

Für Performance und Plattform

Subagent-Summaries nutzen wieder Prompt-Cache — v2.1.128 fixt eine Regression, die cache_creation ungefähr verdreifacht hatte. Wer Subagents heavy nutzt, sollte den Token-Verbrauch nach dem Update direkt vergleichen.

Parallel Tool-Calls brechen sich nicht mehr gegenseitig ab — Ein fehlgeschlagener Read-Only-Befehl (grep, git diff, ls) cancelte bisher die Geschwister-Calls. Behoben in v2.1.128.

OAuth härtet sich — Eine Race Condition zwischen Wake-from-Sleep und Token-Refresh, die laufende Sessions ausloggte, ist gefixt (v2.1.129). Außerdem: claude auth login akzeptiert jetzt einen OAuth-Code per Paste, wenn der Browser-Callback localhost nicht erreicht (v2.1.126) — endlich sauber für WSL2, SSH-Sessions, DevContainer.

Quellen:

• Claude Code Changelog

• Releasebot: Claude Code Mai 2026

Agentic Coding: Cursor mit eigenem SDK und Security-Review, Codex baut Plugin-Disziplin aus

Cursor SDK (29. April) — Cursor öffnet seine Agent-Plattform für programmatischen Zugriff: TypeScript-SDK, lokal oder gegen Cursors Cloud-VMs ausführbar, freie Modellwahl. Dazu reworked Cloud-Agents-API mit SSE-Streaming und expliziten Lifecycle-Controls. Damit ist Cursor das nächste Tool nach Claude Code, das nicht nur als IDE/Terminal, sondern als API für Agent-Pipelines auftritt.

Cursor Security Review (30. April, Beta für Teams/Enterprise) — Zwei Always-On-Agenten: ein Security Reviewer, der jede PR auf Security-Vulnerabilities, Auth-Regressionen und Privacy-/Data-Handling-Risiken prüft, plus ein Vulnerability Scanner mit geplanten Codebase-Scans gegen bekannte Vulnerabilities und veraltete Dependencies. Direkter Konkurrent zu Claude Codes /security-review-Skill — und ein klares Signal, dass Review-Workloads in Pull Requests die nächste Schicht sind, in der die Agent-Hosts gegeneinander antreten.

Cursor Spend Management (4. Mai) — Granulare Allow-/Blocklists pro Modell und Provider, Soft-Spend-Limits mit Alerts bei 50/80/100 %. Liest sich wie eine direkte Antwort auf das Engineering-Budget-Problem, das diese Woche separat dokumentiert wurde (siehe Trend unten).

OpenAI Codex CLI legt zweimal nach: 0.128.0 (30. April) bringt Goals-Workflows, Permission Profiles, Plugin-Management und Support für externe Agent-Sessions. 0.129.0 (7. Mai) folgt mit TUI-Polish: redesigned Resume/Fork Picker, workspace-aware /diff, Plugin-Workspace-Sharing und Lifecycle-Hooks. Damit zieht Codex bei Plugin-Disziplin und Session-Handling sichtbar nach.

Quellen:

• Cursor Changelog: SDK · Security Review · Spend Management

• Codex Changelog (OpenAI Developers)

Trend der Woche

Token-Spend bricht Engineering-Budgets — und die Strategie spaltet sich

Gergely Orosz hat für The Pragmatic Engineer (30. April) 15 Firmen zwischen Seed-Stage und 10.000+ Mitarbeiter anonym befragt. Das Bild ist eindeutig und unbequem: Bei einem AI-Infra-Startup stieg Token-Spend pro Entwickler in sechs Monaten von $200 auf $3.000 pro Monat — 15-fach. Bei einem Healthcare-Konzern verbrauchte ein einzelner Engineer in einer Claude-Code-Session $1.400. In einem US-/EU-Fintech laufen Heavy-User auf Claude Code bei $500 pro Tag. Bei einem E-Commerce-Konzern mit ~2.000 Devs ist nur Opus 4.7 zum Coden zugelassen: „leichte Fehler in Produktion kosten Stunden”. Vendor-Verhandlungen klaffen weit auseinander: Cursor gewährt Rabatte ab ~$1 Mio. Spend, Anthropic auch bei $5 Mio.+ pro Jahr nicht.

Die Firmen teilen sich grob 50/50 in zwei Lager: „Let it rip and start measuring” (laufen lassen, Impact messen) und „Curb spending” (Default auf billigere Modelle, Caps, Consent-Gates). Ein Engineering Manager im Healthcare-Sektor mit fünfzehn Jahren Branchenerfahrung sagt, einen so dramatischen Wandel habe er noch nie erlebt — vergleichbar nur mit dem Sprung zu höheren Programmiersprachen.

Das Bemerkenswerte ist, wie schnell die Tools darauf antworten: Cursors Spend-Management dieser Woche ist genau die Telemetrie, die in den befragten Firmen bisher gefehlt hat. Wer 2026 ernsthaft Agentic Engineering betreibt, braucht eine Antwort auf die Kostenseite — nicht in zwölf Monaten, sondern für den nächsten Sprint.

Quellen:

• Pragmatic Engineer: Token spend breaks budgets

Kurz notiert

• Background Agents Summit (6./7. Mai, virtuell) — Ona richtet das nach eigener Beschreibung erste Event aus, das ausschließlich Background Agents gewidmet ist; Sprecher unter anderem von Stripe, Harvey, Uber, Monzo, AWS und WorkOS. Wer in den nächsten Monaten selbst eine Background-Agent-Infrastruktur aufbauen will, bekommt hier kompakt das, was sonst über mehrere Engineering-Blogs verteilt ist. background-agents.com/summit

• Sierra holt $950 Mio. (4. Mai) — Bret Taylors Agent-Plattform für Enterprise-Customer-Service ist nach der von Tiger Global und GV angeführten Runde mit über $15 Mrd. bewertet. Das Rennen um Enterprise-Agents wird teurer, je breiter die Anwendungsfelder werden. TechCrunch

• OpenAI: „Automated AI research intern bis September 2026” — Jack Clark zitiert dieses öffentlich kommunizierte Ziel von OpenAI in Import AI #455. Recursive Superintelligence (Startup) hat $500 Mio. spezifisch für AI-R&D-Automatisierung eingesammelt. Import AI #455

Nächste Ausgabe: Donnerstag, 14. Mai 2026

Feedback? Einfach kommentieren/antworten.

Die große Nachricht der Woche

Anthropic legt offen, was Claude Code kaputt gemacht hat

Am 23. April hat Anthropic einen detaillierten Postmortem veröffentlicht — und damit beendet, was seit Februar Foren, Substacks und Tech-Presse beschäftigt hat: die Frage, ob Claude „dümmer” geworden ist.

Antwort: ja, aber nicht weil Anthropic das Modell absichtlich heruntergedreht hätte, sondern weil drei separate Bugs sich zeitlich überlappten und sich gegenseitig verschleierten.

1. Reasoning-Effort-Downgrade (4. März → zurückgenommen am 7. April): Default für Opus 4.6 und Sonnet 4.6 von high auf medium gesenkt — als Reaktion auf User-Beschwerden über lange Latenzen. Falscher Trade-off, wie sich herausstellte.

2. Caching-Bug (26. März → gefixt 10. April): Eine Optimierung sollte alte Thinking-Blöcke nach >1h Idle entfernen. Ein Bug ließ sie bei jedem Turn entfernen — Ergebnis: Cache-Misses, vermeintliches „Vergessen”, schneller verbrauchte Limits.

3. Verbosity-Prompt (16. April → zurückgenommen am 20. April): Eine System-Prompt-Anweisung sollte die Verbosity zwischen Tool-Calls reduzieren. In Kombination mit anderen Änderungen: 3 Prozent Performance-Drop bei Opus 4.6 und 4.7 in Ablation-Tests (Sonnet 4.6 ebenfalls betroffen), nicht in den ursprünglichen Evals erkannt.

Alle drei Issues sind seit v2.1.116 (20. April) behoben. Anthropic hat zusätzlich Usage Limits aller Subscriber zurückgesetzt und Default-Effort auf xhigh (Opus 4.7) bzw. high (alle anderen) angehoben. Die API war nicht betroffen — nur Claude Code.

Warum das relevant ist:

Das ist die transparenteste öffentliche Aufarbeitung, die ein Frontier-Lab bislang zu einem Quality-Drop geliefert hat.

Drei wichtige Lehren stecken drin:

1. Evaluation-Suiten erkennen interagierende Regressionen schlecht — keine der drei Änderungen war für sich genommen problematisch.

2. Caching- und Harness-Verhalten sind genauso modellrelevant wie Gewichte; wer Coding-Agents baut, muss das mitmessen.

3. Vertrauen kommt zurück, wenn Postmortems so detailliert sind wie dieses — und nicht, wenn man stillschweigend zurückrollt.

Der Wermutstropfen: Sechs Wochen Schaden waren entstanden, bevor die Aufklärung kam.

Quellen:

• Anthropic: An update on recent Claude Code quality reports

• VentureBeat: Anthropic reveals harness changes likely caused degradation

• The Register: Anthropic admits it dumbed down Claude with ‘upgrades’

• Stack Futures: Three Overlapping Changes, Six Weeks of Degradation

• Machine Learning at Scale: Three regressions and the evals that didn’t catch them

Claude Code: Die Highlights der Woche

Sieben Releases in sieben Tagen: v2.1.117 bis v2.1.123. Schwerpunkt diesmal: Polishing, Memory-Hygiene und Vim-Power-User-Features.

Für alle, die Claude Code täglich nutzen

Vim Visual Mode endlich da — v2.1.118 bringt vollwertige Visual-Selection (v) und Visual-Line (V) inklusive Operatoren. Wer Claude Code aus Vim-Reflex bedient, hatte bisher nur einen Krüppelmodus. Jetzt: voller Selection-Workflow, Operator-Pending, visuelles Feedback.

/cost und /stats werden zu /usage — Konsolidierter Tabbed-View mit Billing und Verbrauch in einem Command. Kleines Detail, aber spart die ständige „welcher Command war’s nochmal?”-Frage.

Custom Themes — Per /theme benannte Themes anlegen oder direkt JSON in ~/.claude/themes/ editieren. Plugins können Themes über ein themes/-Verzeichnis ausliefern. Endlich konfigurierbar ohne Hack.

/resume aus PR-URL — v2.1.122: PR-URL aus GitHub, GitHub Enterprise, GitLab oder Bitbucket in die /resume-Suche pasten und die Session finden, die diesen PR erzeugt hat. Wer mit vielen parallelen Worktrees jongliert: Game-Changer.

Für Multi-Agent- und Plugin-Workflows

alwaysLoad für MCP-Tools — MCP-Server können einzelne Tools aus dem Tool-Search-Deferral ausschließen. Wer Latenz-kritische Tools hat, sollte das setzen.

PostToolUse-Hooks dürfen Tool-Output ersetzen — Bisher nur für MCP-Tools möglich, jetzt für alle Tools via hookSpecificOutput.updatedToolOutput. Eröffnet sauberere Output-Sanitizer und Redaction-Pipelines.

Hooks können MCP-Tools aufrufen — v2.1.118 erlaubt type: "mcp_tool" direkt aus Hook-Konfiguration. Neue Komposition: Lifecycle-Events lösen Tool-Aufrufe ohne Wrapper-Skript aus.

claude plugin prune und tag — Verwaiste auto-installierte Dependencies entfernen; Release-Tags mit Versionsvalidierung erzeugen. Plugin-Hygiene wird langsam zu echtem Package-Management.

Für CI/CD und Automation

claude ultrareview [target] — /ultrareview jetzt non-interaktiv aus CI/Skripten. Damit ist Cloud-basierter Tiefen-Review als Pipeline-Step nutzbar, nicht nur als interaktiver Slash-Command.

AI_AGENT Environment Variable — Wird für Subprozesse gesetzt; GitHub und andere Hosts können damit Agent-Attribution korrekt taggen. Ein kleiner, aber wichtiger Baustein für saubere Audit-Trails.

Windows ohne Git Bash — v2.1.120 nutzt PowerShell als Default-Shell, wenn Git for Windows fehlt. PowerShell-Tool-Permissions können auto-genehmigt werden. Schluss mit dem Workaround-Setup für Windows-only-Teams.

Performance und Plattform

Memory-Leaks gefixt — v2.1.121 schließt mehrere Speicherlecks: Multi-GB-RSS bei vielen Bildern, ~2 GB Leak in /usage bei großen Transcripts, Leaks in long-running Tools. Wer Sessions tagelang offen lässt, merkt das sofort.

Skill-Suche und Effort-Placeholder — Filter-Suchbox in /skills, Skills können ${CLAUDE_EFFORT} referenzieren. Die Skill-Plattform reift in kleinen, nützlichen Schritten.

Quellen:

• Claude Code Changelog

• Releasebot: Claude Code April 2026

• Ton Technotes: v2.1.115–119 Polish Inside

Agentic Coding: Cursor 3.1, Copilot Inline-Agent und der Stack-Mix wird Standard

Cursor 3.1 (Nachtrag, Mitte April: 3.1 am 13. April, Interactive Canvases am 15.) ergänzt das Agents-Window aus 3.0 um Interactive Canvases: durable Side-Panel-Artefakte mit Tabellen, Diagrammen, Diffs und Custom-Components. Cursor antwortet jetzt nicht mehr nur mit Text und Code, sondern baut Dashboards und Mini-Interfaces, die neben Terminal und Browser im Side-Panel persistent leben. Das ist die richtige Antwort auf eine Beobachtung, die mehrere Hosts gerade machen: Der Output eines längeren Agent-Laufs verträgt mehr als nur Markdown.

GitHub Copilot Inline Agent Mode (24. April) — Public Preview für JetBrains-IDEs. Agent-Capabilities aus dem Inline-Chat heraus, ohne in das Chat-Panel zu wechseln. Copilot positioniert sich klar in der „im IDE bleiben”-Ecke, während Claude Code Terminal-first und Cursor IDE-Rebuilt fährt.

The New Stack berichtet, dass Teams zunehmend alle drei parallel nutzen — Cursor für IDE-native Edits, Claude Code für Terminal-Workflows und Headless-Routinen, Codex für Browser- und Computer-Use. Das ist neu: Vor sechs Monaten war die Tooling-Frage „wer gewinnt?”. Jetzt ist sie „wie kombiniere ich?”.

Warum das relevant ist: Wer noch versucht, ein Tool für alles zu wählen, optimiert in die falsche Richtung. Die spannenden Setups bauen jetzt portable Skills, Hooks und Routines, die zwischen Hosts wandern können — genau dort, wo gh skill (siehe #003) ansetzt.

Quellen:

• Cursor Release Notes

• GitHub Changelog: Inline agent mode in JetBrains

• The New Stack: Cursor, Claude Code, Codex are merging into one stack

• DevTool Picks: Cursor 3 Review

Trend der Woche

Big Tech doppelt nach: Googles 40-Milliarden-Wette auf Anthropic

Am 24. April hat Google bis zu 40 Mrd. $ Investment in Anthropic angekündigt — 10 Mrd. $ jetzt cash bei einer 350-Mrd.-$-Bewertung, weitere 30 Mrd. $ an Performance-Targets gekoppelt. Dazu: 5 Gigawatt Compute über fünf Jahre via Google Cloud, mit Option auf weitere Gigawatt. Das passiert nur vier Tage, nachdem Amazon zusätzliche bis zu 25 Mrd. $ committet hatte (5 Mrd. cash, 20 Mrd. an Milestones gekoppelt).

Die Choreographie ist bemerkenswert: Anthropic und Google sind gleichzeitig Partner und Konkurrenten — Gemini 3.1 Pro misst sich offen an Opus 4.7. Trotzdem zieht Google nach. Der Grund: Wer in der Coding-Agent-Schicht des Stacks führend bleiben will, muss die Compute-Allokation für die Modelle sichern, die Entwickler tatsächlich täglich benutzen. Anthropic ist genau das geworden — auch dank Claude Code.

Parallel hat Anthropic in der Woche drei weitere Expansionssignale gesetzt: Sydney als vierter APAC-Standort (27. April, Theo Hourmouzis von Snowflake als ANZ-GM), eine NEC-Partnerschaft in Japan mit Rollout an 30.000 Mitarbeiter und Aufbau einer der größten AI-native Engineering-Organisationen Japans (24. April), sowie Memorandum mit der australischen Regierung. Das zusammen mit den Investments ergibt das Bild: Anthropic positioniert sich für IPO als globale Plattform, nicht nur als Modell-Anbieter.

Quellen:

• Bloomberg: Google plans up to $40B in Anthropic

• TechCrunch: Google to invest up to $40B in cash and compute

• Axios: Google’s $40B Anthropic move is Big Tech’s latest huge bet

• Anthropic: Theo Hourmouzis als General Manager Australia & New Zealand

• Anthropic + NEC: Building Japan’s largest AI engineering workforce

Kurz notiert

• Google Cloud Next 2026 (22. April) — Konferenz unter dem Banner „Agentic Era”. Kevin Ichhpurani (President Global Partner Ecosystem) kündigt 750 Mio. $ für das 120k-Partner-Ökosystem an, um agentische Use-Cases zu beschleunigen. Google Cloud Press · BizTech

• Cloudflare Agents Week (Nachtrag, 12.–20. April) — Vollständiger Stack-Push: Workers AI, AI Gateway, MCP-Hosting, Browser-Rendering. Im internen Engineering-Stack laufen pro Monat 241 Mrd. Tokens und 20 Mio. AI-Gateway-Requests durch die eigenen Produkte — gebaut auf dem, was sie auch verkaufen. Plattform-Konkurrenz für Anthropic und Google bekommt eine Edge-native Variante. Cloudflare Blog · Internal Stack-Daten

• MIT Technology Review zu Agent Orchestration — Lesenswerter Überblick: Multi-Agent-Systeme als „Fließband-Moment” für White-Collar-Arbeit. Konkret namentlich erwähnt sind Claude Code (mit „a couple of dozen subagents” im Einsatz) und Claude Cowork (in zehn Tagen gebaut). Hauptsorge: unvorhersehbares LLM-Verhalten, sobald die Agenten aus dem Browser-Fenster heraus mit der echten Welt interagieren. MIT Tech Review

• Simon Willison über Qwen3.6-27B — Alibabas neues 27-Mrd.-Dense-Modell erreicht Flagship-Coding-Performance lokal und schlägt das vorherige Open-Source-Flaggschiff Qwen3.5-397B-A17B. Open-Weight-Druck auf die Frontier-Labs steigt weiter. simonwillison.net

Nächste Ausgabe: Donnerstag, 7. Mai 2026

Feedback? Einfach kommentieren/antworten.

Die große Nachricht der Woche

Claude Opus 4.7: Der erste klare Sprung über 60 % auf SWE-bench Pro

Am 16. April hat Anthropic Claude Opus 4.7 general-available gemacht. Das eigentliche Signal ist weniger ein weiterer Benchmark-Gewinn als der Sprung auf SWE-bench Pro 53,4 → 64,3 % — also auf dem härteren Engineering-Benchmark, der längere, realistischere Software-Aufgaben abbildet. Dazu SWE-bench Verified 80,8 → 87,6 %, Terminal-Bench 2.0 65,4 → 69,4 %, CursorBench 58 → 70 %. Auf SWE-bench Pro liegt Opus 4.7 vor GPT-5.4 (57,7 %) und Gemini 3.1 Pro (54,2 %). Dazu High-Res-Vision bis 3,75 Megapixel (3× Opus 4.6) und Pricing unverändert bei 5 $ / 25 $ pro Million In-/Output-Tokens.

Die Reaktionen darauf sind trotzdem nicht einhellig. In der Community gab es Berichte über einen höheren Tokenverbrauch bei vergleichbaren Prompts — wichtig, weil ein stärkeres Modell in der Praxis nur dann ein klarer Gewinn ist, wenn die realen Kosten im eigenen Workflow mitziehen. Ein feststehendes Faktum ist das noch nicht, aber ein Community-Signal, das Teams in eigenen Läufen messen sollten. Anthropic hat zeitgleich an den Effort-Defaults gedreht: high ist jetzt Default für Opus 4.6 und Sonnet 4.6 bei Pro- und Max-Subscribern (vorher medium); xhigh steht als neue Stufe exklusiv für Opus 4.7 bereit. Direkte Antwort auf die Nerfing-Debatte der Vorwoche.

Warum das relevant ist: Opus 4.7 ist der erste allgemein verfügbare Release, der auf SWE-bench Pro sichtbar Abstand gewinnt. Das macht ihn nicht automatisch zum Gewinner in jedem Stack, verschiebt aber die Messlatte für längere agentische Coding-Läufe, Review-Workloads und komplexere Tool-Use-Szenarien. Wer Opus im Stack hat, sollte die Upgrade-Prüfung jetzt machen — inklusive echter Token- und Laufzeitmessung im eigenen Kontext.

Quellen:

• Anthropic: Introducing Claude Opus 4.7

• VentureBeat: Opus 4.7 narrowly retakes the lead

• Vellum: Opus 4.7 Benchmarks Explained

• TheNextWeb: Opus 4.7 Agentic Benchmarks

• GitHub Changelog: Opus 4.7 GA

Die unbequeme Debatte: Claude Code und die Pro-Verwirrung

Am 21. April tauchte Claude Code auf öffentlichen Anthropic-Seiten zeitweise nicht mehr im 20-$-Pro-Plan auf; Support-Dokumente sprachen nur noch von Max. Kritik auf X und Reddit folgte unmittelbar, ein paar Stunden später war die Darstellung wieder korrigiert. Anthropics Amol Avasare klärte auf: „a small test on ~2 % of new prosumer signups” — bestehende Abonnenten seien nicht betroffen, die öffentlichen Seiten „versehentlich” aktualisiert. Das Experiment läuft unter der Haube weiter.

Simon Willison ordnet nüchtern ein: Vertrauensverlust durch die intransparente Änderung, strategisches Fragezeichen (Codex kostet weiterhin weniger), und die Frage, ob man Lehrmaterial um ein Tool baut, das sich Leser nicht leisten können. Die eigentliche Story ist deshalb weniger „Claude Code ist raus”, sondern eher: Schon kleine, intransparente Änderungen an Limits und Zugängen erzeugen sofort Vertrauensverlust.

Warum das relevant ist: Derselbe Reflex wie bei der Effort-Debatte — still an wirtschaftlichen Stellschrauben drehen, erst kommunizieren, wenn die Community rebelliert. Wer Claude Code in Team-Workflows oder Trainingsmaterial einplant, sollte nicht nur auf Modellleistung schauen, sondern auch auf die Frage: Bleibt das Setup für Leser, Teilnehmer oder Teams bezahlbar und stabil erreichbar?

Quellen:

• Where’s Your Ed At: Anthropic (Briefly) Removes Claude Code From Pro

• The Register: Anthropic tests reaction to yanking Claude Code from Pro

• Simon Willison: Is Claude Code going to cost $100/month?

• The New Stack: Claude Code Limits

Claude Code: Die Highlights der Woche

Sieben Releases in sieben Tagen: v2.1.111 bis v2.1.117. Neben Opus-4.7-Support bringt die Woche einen Architekturwechsel.

Für alle, die Claude Code täglich nutzen

Native Binary statt bundled JavaScript — v2.1.113 schaltet auf macOS und Linux auf einen nativen Claude-Code-Binary um. Glob und Grep laufen über eingebettetes bfs und ugrep via Bash. Spürbar schnellere Kaltstarts, weniger Node-Overhead, weniger Abhängigkeit von globalem npm.

/ultrareview — Seit v2.1.111, in v2.1.113 parallelisiert mit Diffstat-Ausgabe: umfassende Code-Reviews in der Cloud. Für PR-Prüfungen, die lokal zu lange dauern, wird das der neue Default.

Opus 4.7 xhigh-Effort und interaktiver Effort-Slider — Neue Stufe zwischen high und max, exklusiv für Opus 4.7. /effort ohne Argument öffnet jetzt einen Slider — endlich ein Interface für den Trade-off zwischen Geschwindigkeit und Tiefe.

Für Multi-Agent- und Plugin-Workflows

Agent-Frontmatter endlich vollständig — mcpServers und hooks aus dem Agent-Frontmatter werden jetzt auch für Main-Thread-Sessions geladen, wenn per --agent gestartet wird. Kleines Detail, großer Effekt für alle, die Agents als First-Class in Workflows behandeln.

Plugin-Dependencies auto-resolved — plugin install, /reload-plugins und Auto-Update lösen fehlende Abhängigkeiten eigenständig auf. blockedMarketplaces und strictKnownMarketplaces werden durchgesetzt — Enterprise-Admins bekommen ihre Plugin-Kontrolle zurück.

/fewer-permission-prompts-Skill — Scannt Transcripts nach häufigen read-only Bash- und MCP-Calls und schlägt eine priorisierte Allow-List für .claude/settings.json vor. Der Endgegner der ständigen Permission-Dialoge.

Für CI/CD und Sicherheit

Sandbox-Härtung — sandbox.network.deniedDomains blockt Domains auch innerhalb weit gefasster Allow-Patterns. Deny-Rules greifen jetzt bei env-, sudo-, watch-, ionice- und setsid-gewrappten Kommandos; find:*-Allow-Regeln lassen nicht mehr automatisch -exec/-delete durch. Dazu ein gefixter Edge-Case, in dem dangerouslyDisableSandbox Kommandos ohne Sandbox und ohne Permission-Prompt laufen ließ. Wer ältere 2.1er in Pipelines hat: jetzt updaten.

Performance und Plattform

/resume bis zu 67 % schneller auf Sessions >40 MB (v2.1.116), parallelisierter MCP-Startup (v2.1.117), PowerShell-Tool progressiv auf Windows via CLAUDE_CODE_USE_POWERSHELL_TOOL. OpenTelemetry bekommt effort-Attribute auf Cost-, Token- und API-Metriken — Billing-Analysen nach Effort-Level werden endlich möglich.

Quellen:

• Claude Code Changelog

• Releasebot: Claude Code April 2026

• GitHub: Claude Code Releases

Agentic Coding: Codex öffnet den Mac — und GitHub standardisiert Skills

OpenAI Codex „for (almost) everything” (16. April): Computer Use auf dem Mac, ein In-App-Browser mit Kommentar-Funktion direkt auf Webseiten, 90+ neue Plugins (Atlassian Rovo, CircleCI, CodeRabbit, GitLab Issues, Microsoft Suite, Neon, Render u. a.), Memory und proaktive Task-Vorschläge. Parallele Agents drängen sich nicht ins Foreground-Fenster. OpenAI nennt 3 Mio. weekly active Developer, npm-Downloads wuchsen von 82k (April 2025) auf 14,5 Mio. (März 2026). Die Bewegung spiegelt Anthropics Desktop-Routines aus #002 — Codex holt strategisch auf.

gh skill Public Preview (16. April, GitHub CLI v2.90.0): Ein einziger Befehl, um Agent Skills über alle großen Agent-Hosts hinweg zu installieren, zu versionieren, zu suchen und zu publizieren — Claude Code, Copilot, Cursor, Codex, Gemini. Skills folgen einer offenen Spezifikation, jede Installation trägt die Git-Tree-SHA ihres Source-Verzeichnisses, Updates vergleichen echte Content-Änderungen. Das ist im Stillen der größte Schritt in Richtung Interoperabilität, den das Ökosystem seit MCP gesehen hat.

Warum das relevant ist: Die Frontline verschiebt sich. Codex schließt den Desktop-Gap zu Claude Code, GitHub liefert das fehlende Paketformat über alle Hosts hinweg. Wer Tooling-Entscheidungen trifft, sollte ab jetzt davon ausgehen, dass Skills portabel sind — und Lock-in auf einzelne Agent-Hosts wird zur strategischen Altlast.

Quellen:

• OpenAI: Codex for (almost) everything

• MacRumors: Codex Mac Update

• GitHub Changelog: gh skill

• Groundy: gh skill command analysis

Trend der Woche

Agent Skills werden zum neuen npm

Drei Bewegungen zeigen in dieselbe Richtung: gh skill macht Skills portabel über Hosts, Claude Code v2.1.111 erlaubt, built-in Slash-Commands (/init, /review, /security-review) via Skill-Tool zu discovern, und OpenAI Codex baut rund um Skills, Plugins und MCP-Server ein modulareres Ökosystem aus. Noch ist das kein vollständig konsolidierter Standard — aber es ist gut möglich, dass wir gerade den Moment sehen, in dem „Skill” vom Prompt-Schnipsel zum versionierten, signierten, cross-kompatiblen Artefakt wird. Wer Agentic Engineering ernsthaft baut, sollte aufhören, Wissen in Prompts und Repo-Wikis zu verstreuen, und Skills als First-Class-Artefakt versionieren. Genau dort dürfte sich in den nächsten Monaten entscheiden, welche Teams nur mit Agenten experimentieren — und welche daraus echte Produktivität ziehen.

Quellen:

• GitHub: Manage agent skills with GitHub CLI

• Anthropic Claude Code: Skills in changelog

• Big Hat Group: gh skill Deep Dive

Kurz notiert

• Claude Design (17. April) — Anthropic Labs launcht Research Preview für Prototypen, Slides, One-Pager. Powered by Opus 4.7, liest Codebase und Design-Systeme, Export zu Canva, PDF, PPTX oder als Handoff-Bundle an Claude Code. Figmas Aktie reagierte sofort negativ. Anthropic · TechCrunch

• Mythos-Leak-Report — TechCrunch berichtete am 21. April, eine unautorisierte Gruppe habe Zugriff auf Anthropics exklusives Cyber-Modell Mythos erlangt. Das Modell war nur im Rahmen von Project Glasswing an AWS, Apple, Google, JPMorgan, Microsoft und Nvidia verteilt. Anthropic hat bislang nicht offiziell kommentiert. TechCrunch

• Simon Willison zur Agent-Definition — Nach monatelangem Herumschlagen gibt es jetzt eine konsensfähige: „An LLM agent runs tools in a loop to achieve a goal.” simonw.substack.com

• GitHub Copilot Individual Plan-Änderungen — Am selben Tag wie das Anthropic-Pricing-Drama kündigt GitHub Usage-basierte Limits für Copilot-Agenten-Workflows an. Agentic Coding knirscht an den Rändern der alten Flatrate-Modelle. simonwillison.net

Nächste Ausgabe: Donnerstag, 30. April 2026

Feedback? Einfach kommentieren/antworten.

Die große Nachricht der Woche

Claude Code Desktop bekommt Routines — und wird zur Agent-Plattform

Am 14. April hat Anthropic die Claude Code Desktop App von Grund auf neu gebaut. Das ist kein kosmetisches Update, sondern ein Architekturwechsel: Die App ist jetzt um parallele Sessions herum organisiert, mit einer Sidebar zum Managen mehrerer gleichzeitiger Agent-Läufe, Drag-and-Drop-Layout, integriertem Terminal und File-Editor.

Das eigentliche Highlight heißt Routines — eine neue Automatisierungsschicht, die Claude Code ohne aktive Session laufen lässt. Eine Routine bündelt Prompt, Repository und Connectors in eine Konfiguration, die auf drei Arten triggern kann: nach Zeitplan, per API-Call oder durch ein GitHub-Event (z.B. neuer Pull Request). Routines laufen auf Anthropics Web-Infrastruktur, nicht lokal. Daily Caps nach Plan: Pro 5, Max 15, Team/Enterprise 25 (weitere zukaufbar).

Dazu kommt: Claude Code kann jetzt den Mac fernsteuern — wenn kein direkter Connector existiert (Slack, Google Calendar), navigiert Claude über den Bildschirm wie ein Mensch. Drei View Modes (Verbose, Normal, Summary) lassen Nutzer steuern, wie viel von Claudes Tool-Aktivität sie sehen wollen.

Warum das relevant ist: Wer letzte Woche das Conway-Leak verfolgt hat (immer noch unbestätigt), sieht hier die offizielle Version: Claude bewegt sich von einem reaktiven Tool zu einem persistent laufenden, event-gesteuerten Agent. Routines sind der erste produktionsreife Schritt dahin.

Quellen:

• MacRumors: Anthropic Rebuilds Claude Code Desktop

• VentureBeat: Routines Hands-On

• 9to5Mac: Routines Feature

• SiliconANGLE: Routines & Desktop Makeover

Die unbequeme Debatte: Wird Claude schlechter?

Es ist das Thema der Woche in der Community: Eine wachsende Zahl von Power-Usern beklagt, dass Claude — insbesondere Opus 4.6 — seit Februar spürbar schwächer geworden ist. Weniger gründliche Analysen, mehr Abkürzungen, häufigeres vorzeitiges Abbrechen.

Die Ursache ist bekannt: Anthropic hat das Default-Effort-Level von Opus 4.6 am 9. Februar auf Adaptive Thinking umgestellt und am 3. März auf Medium Effort (Level 85) gesenkt. Weniger Tokens pro Anfrage, schnellere Antworten — aber auch weniger Tiefe.

Stella Laurenzo, Senior Director bei AMDs AI-Gruppe, hat die Debatte mit einer datengestützten Analyse auf GitHub befeuert: 6.852 Sessions, 17.871 Thinking Blocks, 234.760 Tool Calls. Ihr Befund: Die Reasoning-Tiefe fiel ab Februar messbar, während „Simplest Fix”-Verhalten, Premature Stopping und Edit-first statt Research-first zunahmen.

Die Community-Reaktion ist deutlich. Fortune, VentureBeat, Axios und The Register haben berichtet. Der Vorwurf: Anthropic habe die Änderung nicht transparent genug kommuniziert — sie stand im Changelog, wurde aber nicht prominent angekündigt. Die Spekulation, dass Anthropic unter Compute-Knappheit leidet, hält sich hartnäckig.

Anthropics Antwort: Teams und Enterprise-Nutzer sollen künftig standardmäßig auf High Effort laufen, auch wenn das mehr Tokens und Latenz kostet. Für alle anderen bleibt /effort max der Workaround.

Quellen:

• Fortune: Anthropic Performance Backlash

• Axios: Anthropic’s AI Downgrade Stings Power Users

• VentureBeat: Is Anthropic ‘Nerfing’ Claude?

• The Register: Claude Is Getting Worse, According to Claude

• Stella Laurenzo: 6,852 Sessions Analysis

Claude Code CLI: Die Highlights der Woche

Sieben Releases in sieben Tagen — von v2.1.96 bis v2.1.108. Hier die Highlights, sortiert danach, wen sie betreffen:

Für alle, die Claude Code täglich nutzen

/recap — Beim Zurückkehren in eine Session liefert Claude jetzt automatisch einen Kontext-Überblick. Konfigurierbar in /config, manuell aufrufbar mit /recap. Wer viele parallele Sessions jongliert und nach einem Kontextwechsel erst mal „Wo war ich?” denkt, spart damit spürbar Zeit.

Prompt Caching wird steuerbar — Zwei neue Environment-Variablen: ENABLE_PROMPT_CACHING_1H für eine einstündige Cache-TTL, FORCE_PROMPT_CACHING_5M für fünf Minuten. Relevant für alle, die ihre API-Kosten optimieren oder auf langsamen Backends arbeiten. Ein Bug, bei dem Subscriber mit DISABLE_TELEMETRY auf 5 Minuten statt 1 Stunde zurückfielen, wurde gefixt.

Für Multi-Agent- und MCP-Workflows

Background Monitors — Plugins können jetzt über den monitors Manifest-Key automatisch mit der Session starten. Wer Monitoring-Tools für Builds, Tests oder Deployments als Plugin betreibt, bekommt damit eine hands-off Lösung. Dazu: /reload-plugins erkennt neue Skills ohne Neustart.

PreCompact Hook — Hooks können Compaction blockieren (Exit-Code 2 oder {"decision":"block"}). Nützlich für Agents, die mitten in einer langen Analyse stecken und ihren Kontext nicht verlieren dürfen.

Für CI/CD und Automation

Security-Fixes — Mehrere Bash-Tool-Permission-Bypasses gefixt in v2.1.97/98: Backslash-Escaping umging Auto-Allow-Regeln, Redirects über /dev/tcp und /dev/udp wurden nicht abgefangen, Env-Var-Prefixes tricksten die Permission-Prüfung aus. Wer ältere Versionen in Pipelines nutzt: jetzt updaten.

Enterprise und Plattform

Google Vertex AI Setup Wizard — Interaktiver Wizard für GCP-Authentifizierung, Projekt- und Regionskonfiguration, direkt vom Login-Screen aus. OS-CA-Zertifikate werden jetzt standardmäßig vertraut — Schluss mit manueller Zertifikats-Konfiguration für Enterprise-TLS-Proxies. Dazu PID Namespace Isolation für Subprocess-Sandboxing auf Linux und ein neuer /team-onboarding-Command, der Onboarding-Guides für Teammitglieder aus der eigenen Claude-Code-Nutzung generiert.

Quellen:

• Claude Code Changelog

• Releasebot: Claude Code

• GitHub: Claude Code Releases

Agentic Coding: Cursor 3 und der Drei-Wege-Kampf

Cursor 3 markiert einen Paradigmenwechsel: Das Interface wurde komplett um die Idee herum neu gebaut, dass der Großteil des Codes von AI Agents geschrieben wird. Highlights: Agents Window, Design Mode, Cloud Agents. Composer 2 erreicht 61,3 auf CursorBench (+37 %) und 73,7 auf SWE-bench Multilingual. Anysphere hat über 3 Milliarden Dollar eingesammelt bei einer ARR von 2 Milliarden.

Der Markt teilt sich in drei Philosophien: Cursor setzt auf IDE-native Deep Integration, GitHub Copilot auf Reichweite und Enterprise (Agent Mode GA, agentic Code Review seit März), Claude Code auf Terminal-first mit Routines und maximaler Flexibilität. Die Wahl des Stacks ist jetzt eine Architekturentscheidung.

Quellen:

• DEV Community: Cursor 3 Launch

• NxCode: Cursor vs Claude Code vs Copilot

Trend der Woche

Anthropic auf dem Weg zum Börsengang — die 800-Milliarden-Frage

Anthropic zieht Investoren-Angebote an, die das Unternehmen mit bis zu 800 Milliarden Dollar bewerten — mehr als das Doppelte der Bewertung von 380 Milliarden aus dem Februar. Annualisierte Revenue: über 30 Milliarden Dollar. IPO wird für Oktober 2026 erwartet.

Vas Narasimhan, CEO von Novartis, wurde am 14. April in den Board berufen — erstes Pharma-Schwergewicht, klares Signal Richtung Healthcare. Trust-berufene Direktoren stellen jetzt die Board-Mehrheit. Ein IPO-bereites Anthropic wird Claude Code aggressiver kommerzialisieren — die Enterprise-Features und Routines der letzten Woche passen ins Bild.

Quellen:

• Bloomberg: Anthropic $800B Valuation

• Anthropic: Narasimhan Board

• Benzinga: Anthropic IPO

Kurz notiert

• Conway-Leak — Anfang April tauchten 512.000 Zeilen Claude-Code-Quellcode auf, darin Details zu einer Always-On-Agent-Plattform namens Conway. Anthropic hat weder bestätigt noch dementiert. Routines könnten die offizielle Antwort sein. MindStudio

• Claude-Outage am 15. April — Erhebliche Störung bei Claude.ai, API und Claude Code von ~10:53 bis 13:42 ET. Wer Production-Workloads laufen hat: Redundanz einplanen. CNBC

• Simon Willison über Cybersecurity als „Proof of Work” — AI-Modelle wie Mythos verändern Vulnerability Research fundamental. simonwillison.net

• Anthropic Agentic Coding Trends Report 2026 — Umfassender Bericht darüber, wie Coding Agents Workflows verändern. Pflichtlektüre. Anthropic Resources

• ICSE 2026: Workshop Agentic Engineering — Die führende Software-Engineering-Konferenz widmet dem Thema erstmals einen eigenen Workshop. ICSE 2026

Nächste Ausgabe: Donnerstag, 23. April 2026

Die große Nachricht der Woche

Anthropic stellt Claude Mythos vor — und sperrt das Modell sofort weg

Am Montag hat Anthropic mit Claude Mythos Preview ein neues Frontier-Modell vorgestellt, das vor allem durch eine Fähigkeit auffällt: Es findet und exploitet Zero-Day-Schwachstellen in allen großen Betriebssystemen und Browsern. In internen Tests identifizierte Mythos tausende bisher unbekannte Sicherheitslücken, viele davon in Code, der ein bis zwei Jahrzehnte alt ist.

Der Clou: Anthropic veröffentlicht das Modell nicht frei, sondern nur über Project Glasswing — eine neue Initiative für defensive Cybersecurity. Zwölf Launch-Partner, darunter AWS, Apple, Google, Microsoft, CrowdStrike und die Linux Foundation, erhalten kontrollierten Zugang. Anthropic stellt dafür bis zu 100 Millionen Dollar an Usage Credits und 4 Millionen Dollar an Direktspenden für Open-Source-Security bereit.

Simon Willison kommentierte treffend: Die Entscheidung, ein derart mächtiges Modell zunächst nur für Sicherheitsforscher zugänglich zu machen, sei „notwendig”. Platformer berichtet gleichzeitig, dass einige Security-Experten beunruhigt sind — die Frage, wie lange der Vorsprung der Verteidiger hält, steht im Raum.

Warum das relevant ist: Agentic Security ist der logische nächste Schritt — wenn AI Agents Code schreiben, müssen andere AI Agents ihn absichern. Mythos zeigt, wohin die Reise geht.

Quellen:

• Anthropic: Project Glasswing

• TechCrunch: Anthropic Mythos Preview

• Simon Willison’s Take

• The Hacker News: Zero-Day Findings

Claude Code: Die Highlights der Woche

Die Versionen v2.1.89 bis v2.1.92 brachten eine dichte Folge an Updates — hier die Highlights, sortiert danach, wen sie betreffen:

Für alle, die Claude Code täglich nutzen

Flicker-free Rendering — Mit CLAUDE_CODE_NO_FLICKER=1 gibt es eine Alt-Screen-Rendering-Option mit virtualisiertem Scrollback. Wer längere Agent-Sessions laufen lässt und vom Flackern bei schnellen Ausgaben genervt war, bekommt endlich eine saubere Terminal-Erfahrung.

/powerup Command — Interaktive Lektionen mit animierten Demos, die Claude-Code-Features Schritt für Schritt erklären. Besonders nützlich für Einsteiger, aber auch für erfahrene Nutzer, die versteckte Features entdecken wollen.

Bessere /cost-Transparenz — Per-Model- und Cache-Hit-Aufschlüsselung zeigt jetzt genau, wohin das Budget fließt. Relevant für alle, die ihre API-Kosten im Blick behalten müssen.

Für Multi-Agent- und MCP-Workflows

MCP 500K — Die maximale Tool-Result-Größe springt auf 500.000 Zeichen. Wer MCP-Server baut, die große Datenmengen zurückgeben — etwa Datenbank-Dumps, lange Logs oder umfangreiche API-Responses — ist damit nicht mehr so schnell am Limit.

Named Subagents — Subagents tauchen namentlich in den @-Mention-Vorschlägen auf. Für Teams, die mit spezialisierten Agents arbeiten (z.B. ein Test-Agent, ein Review-Agent, ein Deploy-Agent), wird die Orchestrierung damit deutlich intuitiver.

Für CI/CD und Automation

Permission Deferral für Headless Mode — PreToolUse Hooks können Sessions jetzt pausieren und extern wieder aufnehmen. Der Use Case: Ein Agent in einer CI-Pipeline stößt auf eine Aktion, die menschliche Freigabe braucht — statt abzubrechen, wartet er, bis jemand grünes Licht gibt.

PermissionDenied Hook — Neuer Hook, der nach Ablehnungen durch den Auto-Mode-Classifier feuert. Mit {retry: true} kann der Agent automatisch einen alternativen Weg einschlagen. Nützlich für robustere autonome Workflows, die nicht beim ersten „Nein” aufgeben sollen.

Performance und Plattform

Schnellere Write-Tool-Diffs für große Dateien (60 % schneller, besonders bei Dateien mit Tabs und Sonderzeichen), SSE-Transport jetzt in O(n) statt O(n²) — spürbar bei langen Sessions mit vielen Tool-Calls. Dazu ein interaktiver Bedrock Setup Wizard für AWS-Nutzer und eine Windows PowerShell Preview für das wachsende Windows-Lager.

Quellen:

• Claude Code Changelog

• GitHub Releases

• Releasebot: Claude Code

Agentic Coding: Die Branche sortiert sich

Cursor launcht Agent Experience — Cursor hat eine neue Agent-Erfahrung vorgestellt, die explizit gegen Claude Code und Codex positioniert ist. Der Agent kann Dateien lesen/schreiben, Tests im Terminal ausführen, Fehler iterativ beheben und das gesamte Repository per RAG indexieren.

GitHub Copilot trainiert auf euren Daten — Ab dem 24. April nutzt GitHub Interaktionsdaten von Free-, Pro- und Pro+-Nutzern zum Modelltraining — inklusive Code-Snippets, Dateinamen und Repository-Strukturen. Opt-out ist möglich, aber nicht der Default. Business- und Enterprise-Kunden sind ausgenommen. Die Community-Reaktion ist eindeutig: 59 Thumbs-down, 3 Rockets. Wer nicht mitmachen will, sollte jetzt unter /settings/copilot/features die Option deaktivieren.

GitHub Agent HQ — Claude und OpenAI Codex sind jetzt als wählbare Agents in Public Preview verfügbar — direkt in GitHub, GitHub Mobile und VS Code. Die Multi-Agent-Zukunft wird konkret: Man wählt seinen Agent je nach Task.

CodeSignal: Agentic Coding Assessments — CodeSignal hat eine neue Kategorie technischer Assessments eingeführt, die misst, wie gut Entwickler mit AI-Agents arbeiten. Laut deren Umfrage nutzen bereits 91 % der befragten US-Entwickler Agentic-AI-Tools bei der Arbeit, 75 % haben in den letzten sechs Monaten zumindest teilweise AI-generierten Code in Production deployed.

Quellen:

• Cursor Agent Experience

• GitHub Blog: Copilot Data Policy

• GitHub Blog: Agent HQ

• The Register: GitHub Training

• CodeSignal: Agentic Assessments

Trend der Woche

Von Vibe Coding zu Agentic Engineering — die Reifephase

Das Buzzword „Vibe Coding” aus 2025 — locker prompten und schauen, was passiert — weicht einer strukturierteren Disziplin. Medium-Autor ESA Engineering beschreibt den Übergang treffend: Agentic Coding ist für Produktions-CI/CD-Pipelines und große Refactors gebaut, Vibe Coding für Hackathon-Prototypen.

Gartner prognostiziert, dass 40 % der Enterprise-Anwendungen bis Ende 2026 aufgabenspezifische AI-Agents enthalten werden (2025: unter 5 %). Anfragen zu Multi-Agent-Systemen stiegen um 1.445 % von Q1 2024 bis Q2 2025. Multi-Model-Routing wird dabei zur Pflicht: Das Plan-and-Execute-Pattern — ein starkes Modell plant, günstigere Modelle führen aus — senkt die Kosten um bis zu 90 %.

Gleichzeitig wächst die Skepsis: 80 % der Entwickler nutzen AI Coding Agents, aber das Vertrauen in deren Accuracy ist von 40 % auf 29 % gefallen. Die zentrale Herausforderung 2026: Agents, denen man vertrauen kann — nicht nur welche, die beeindruckend aussehen. Die Branche konsolidiert sich um das Muster human-prompted → agent-executed → human-reviewed.

Quellen:

• Medium: From Vibe to Agentic

• Gartner’s Multi-Agent Systems Boom

• The New Stack: 5 Key Trends

• Let’s Data Science: Developer Trust

Kurz notiert

• Anthropic sichert sich 3,5 GW Compute — Neuer Deal mit Google und Broadcom, TPU-Kapazität ab 2027. Run-Rate-Revenue liegt bei über 30 Mrd. Dollar. TechCrunch · CNBC

• 1M-Token-Context-Beta wird eingestellt — Ab 30. April hat der context-1m-2025-08-07 Beta-Header keine Wirkung mehr für Sonnet 4.5 und Sonnet 4. Anthropic Release Notes

• OpenAI, Anthropic und Google gegen Model-Distillation — Die drei arbeiten über das Frontier Model Forum zusammen, um adversariale Distillationsversuche aus China zu erkennen. Bloomberg

• Xcode 26.3 mit Agentic Coding — Apple integriert Claude Agent und OpenAI Codex über MCP in Xcode. Apple Newsroom

• Coefficient Bio Akquisition — Anthropic kauft AI-Biotech-Startup für ~400M Dollar, Team geht in die Healthcare & Life Sciences Gruppe.

• Claude-Ausfälle — Am 6. und 8. April gab es Outages bei Claude — relevant für alle, die Production Workloads darauf laufen haben. TechRadar

Nächste Ausgabe: Mittwoch, 15. April 2026
Feedback? Einfach antworten — ich justiere gerne Fokus, Tiefe und Quellen.

“If Claude decides to delete all my files: no big deal — but only inside an isolated VM.”

Anyone who uses Claude Code in the terminal with default settings knows the drill: many commands require approval before Claude Code executes them. You constantly have to weigh whether a given command is safe or not.

“Allow this? Allow once? Allow always?”

You keep checking: is this harmless, or could this command cause problems? Cognitive load from reading command lines.

There are essentially two extremes: either you review every single permission request yourself, or you use the --dangerously-skip-permissions option, which allows everything. In between, there are many gradations. You can define your permissions with fine granularity, but that’s almost as much effort.

How nice would it be if you could simply allow everything while still being certain that nothing unwanted happens on your machine. Then agentic coding could proceed unhindered and you’d get results fast.

That’s exactly what an isolated system promises — one that runs shielded from your actual computer. Such an isolated system reduces the blast radius — the maximum damage a misguided command can cause — immensely. If something goes wrong, you simply restart and return to the last stable state. There are many ways to implement this.

One of them is the /sandbox command built into Claude Code. It activates a sandbox that restricts Claude Code at the OS level — file access and networking. You can let commands run automatically without confirming each one, because the sandbox limits what can happen. But how secure is it really?

And then there’s Cowork in the desktop version of the Claude app. Cowork is aimed more at knowledge workers than developers. It can access folders, create and modify files, install packages — all autonomously. At first glance, it’s not obvious how the protection works. There’s no /sandbox command you’d need to activate. The isolation happens in the background.

I was curious about both: how does the sandbox work in Claude Code? And how does Cowork protect me from unwanted changes on my machine?

I didn’t want to rely on the documentation alone — instead, I examined both systems from the inside. Here’s what I found.

Two Products, Two Audiences, Two Security Models

Before I dive into the technical details, an important distinction:

Claude Code is a terminal tool for developers. It executes commands on your machine — in the same context where you work. The sandbox must be manually activated (/sandbox), making it opt-in. That makes sense: developers need as few restrictions as possible to be productive. They want to run commands that a restrictive sandbox would block. But with great power comes great responsibility. You need to understand what you’re approving.

Cowork is part of the Claude Desktop app and is aimed at users who don’t want to deal with the command line. When someone asks Claude to create an Excel spreadsheet from five PDFs, they expect a result — not a discussion about file permissions. Cowork therefore needs to provide stronger protection, without requiring the user to configure anything.

The result: two different isolation models for two different risk profiles.

Let’s get into the details.

Cowork: A Linux Inside Your Mac

Cowork launches a lightweight Linux VM via Apple’s Virtualization.framework. Not a container, but a real virtual machine with its own kernel.

What does the VM say about itself?

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"

$ uname -r
6.8.0-94-generic

$ uname -m
aarch64

$ nproc
4

$ free -h
              total    used    free
Mem:          3.8Gi   564Mi   1.8Gi
Swap:            0B      0B      0B

$ df -h /
Filesystem      Size  Used Avail Use%
/dev/nvme0n1p1  9.6G  7.2G  2.4G  75%

Ubuntu 22.04 on ARM64, 4 cores, 3.8 GB RAM, a 10 GB disk. No swap. Lean enough for document processing and scripts, but not meant for machine learning training.

On the macOS host, the VM files live at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/. The root image (rootfs.img) is 10 GB as a sparse file but only occupies about 7.5 GB on disk.

Alongside it sits a compressed backup (rootfs.img.zst, ~2 GB) and a few configuration files: efivars.fd, macAddress, machineIdentifier.

How Three Layers Work Together to Secure the Isolation

The VM alone would already be a solid boundary. But Anthropic stacks three layers on top of each other.

Layer 1: The VM

Apple’s Virtualization.framework provides hardware isolation. The guest has its own kernel. Even an rm -rf / inside the VM leaves the host untouched.

Layer 2: bubblewrap + seccomp

Inside the VM, Claude doesn’t run directly — first comes bubblewrap (short: bwrap). Bubblewrap is a sandboxing tool that uses Linux namespaces to isolate processes from each other — similar to what containers do, but more lightweight.

It restricts what a process can see and do: which files, which network interfaces, which other processes.

In the Cowork VM, bubblewrap is PID 1 — the very first process:

$ cat /proc/1/status | head -2
Name:   bwrap
State:  S (sleeping)

The bwrap command line (readable via /proc/1/cmdline) shows the key restrictions at a glance:

• --unshare-net — separate network namespace, no direct network access

• --unshare-pid — separate PID namespace, other processes invisible

• --ro-bind / / — root filesystem mounted read-only

• --die-with-parent — if the parent process dies, the sandbox dies with it

• --tmpfs /etc/ssh/ssh_config.d — SSH configuration overlaid with an empty tmpfs

Additionally, a seccomp filter is loaded. Seccomp (Secure Computing Mode) is a Linux kernel mechanism that determines which system calls a process is allowed to make. System calls are the interface between a program and the operating system — opening files, establishing network connections, starting processes.

A seccomp filter can selectively block individual system calls, drastically limiting a process’s radius of action.

$ grep Seccomp /proc/self/status
Seccomp:         2
Seccomp_filters: 2

Seccomp: 2 means filter mode — there’s an active allowlist for permitted syscalls. The filter file is called unix-block.bpf and is loaded via a dedicated binary (apply-seccomp).

Layer 3: Network Isolation

No process in the sandbox has direct internet access. All traffic goes through a local proxy:

$ env | grep HTTP_PROXY
HTTP_PROXY=http://localhost:3128

$ env | grep ALL_PROXY
ALL_PROXY=socks5h://localhost:1080

The proxy runs via socat, which tunnels TCP connections into Unix sockets that lead out of the VM. On the host side, an allowlist decides which domains may pass through.

I tested it:

$ curl -s -o /dev/null -w "%{http_code}" https://registry.npmjs.org
200

$ curl -s -o /dev/null -w "%{http_code}" https://pypi.org
200

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "HTTP/1.1"
< HTTP/1.1 403 Forbidden

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "X-Proxy"
< X-Proxy-Error: blocked-by-allowlist

npm and PyPI get through. Everything else receives a 403 Forbidden with the header X-Proxy-Error: blocked-by-allowlist. Direct DNS lookups also fail:

$ nslookup google.com
socket(): Operation not permitted
;; no servers could be reached

This is consistent: even if a prompt injection attack were to trick Claude into sending data to an external server — the proxy would block it.

Which Files Does the VM See?

Files enter the VM via VirtioFS — a filesystem protocol designed specifically for communication between a VM and its host. Instead of simulating real hardware, host and guest cooperate deliberately (paravirtualization). This makes file access fast and low-overhead.

$ mount | grep virtiofs
/mnt/.virtiofs-root/shared/Work/.../Marketing on
  /sessions/elegant-adoring-brown/mnt/Marketing type fuse (rw,...)

Only the folder I selected in the Desktop app is mounted. Not my home directory, not my Desktop, not my Downloads — just the one folder I explicitly shared.

Plugins and Skills are additionally mounted via bindfs. Bindfs is a FUSE filesystem that remounts an existing folder at a different location — similar to a symlink, but with the ability to change permissions. This way, Skills can be mounted read-only even though they’re writable on the host. Uploads also land in a separate, read-only mount.

One detail reveals that the VM serves multiple conversations simultaneously: the /sessions/ directory contains different sessions side by side:

$ ls -la /sessions/
drwxr-x--- elegant-adoring-brown  elegant-adoring-brown  ...
drwxr-x--- nobody                 nogroup                awesome-epic-mccarthy
drwxr-x--- nobody                 nogroup                dazzling-vibrant-carson

Each session gets its own Linux user with its own UID. My user is called elegant-adoring-brown (uid 1005). The other sessions are listed under nobody — I can’t read their files.

How Does Claude Code Protect Without a VM?

Claude Code in the terminal uses a different approach on macOS: Apple’s Seatbelt (also known as sandbox-exec). Instead of a VM, a dynamically generated sandbox profile restricts the process at the OS level. Important: the sandbox must be manually activated with /sandbox — without this step, Claude Code runs without OS-level isolation.

The profile starts with (deny default) — everything is forbidden unless explicitly allowed. The sandbox runtime is open source and available on GitHub. I downloaded the npm package @anthropic-ai/sandbox-runtime and analyzed the macos-sandbox-utils.js:

• 59 sysctl entries are made readable (hardware info like CPU count, memory size)

• 14 Mach IPC services on the whitelist (Fonts, Logging, Security Server)

• Mandatory denies for .env, .ssh, .aws, .git/hooks, .git/config — even when the working directory has write access

• Move blocking: file-write-rename and file-write-unlink are blocked for protected paths, preventing circumvention of the denies via mv

The network isolation works the same way as with Cowork: all traffic goes through the same proxy with an allowlist. The difference: with Seatbelt, this happens at the process level (same kernel); with Cowork, at the VM level (separate kernel).

Why Two Models?

Claude Code is aimed at developers who need fast feedback in the terminal. The Seatbelt overhead is in the low single-digit millisecond range — I measured it on the host, no perceptible difference from a command without sandbox. Developers can selectively activate the sandbox when they want to give an agent more autonomy without having to approve every command.

Cowork gives Claude significantly more autonomy: it runs longer, creates files independently, installs packages. And it’s aimed at users who can’t assess (and don’t need to assess) which commands are being executed at the operating system level. The potential damage from an agent with local file access, code generation, and network egress is greater — and users are less able to evaluate it. Full VM isolation is appropriate here.

What I Take Away From This

The isolation is real. Not just on paper, but verifiable.

Three things convinced me in particular:

First, the proxy allowlist with the explicit X-Proxy-Error: blocked-by-allowlist header. This isn’t a silent error message but a deliberate architectural decision. You can immediately see why a connection fails.

Second, the layering. The VM alone would be good. With bubblewrap and seccomp, it gets better. All three together make it significantly harder to break out of the sandbox. An exploit would have to simultaneously bypass the seccomp filter, escape the bwrap namespace, and then break out of the VM — on a system with no direct network access.

Third, the transparency. The sandbox runtime is open source. I downloaded the macos-sandbox-utils.js code — the 59 sysctl entries, the 14 Mach services, and the mandatory denies for .env, .ssh, and .aws are all there in black and white. The Seatbelt profile is dynamically generated, but the generating code is inspectable. The VM architecture can be examined from the inside. You don’t have to take anyone’s word for it — you can look for yourself.

If you want to look for yourself: the sandbox runtime is on GitHub. An npm pack and a look at macos-sandbox-utils.js is all it takes to understand the Seatbelt profile.

What You Can Do Now

If you’re using Claude Code and haven’t tried the sandbox yet: start a session and type /sandbox. That alone significantly reduces the effort of approving commands one by one. For everyday use, that’s often enough.

If you want to go deeper:

• Inspect the sandbox runtime: npm pack @anthropic-ai/sandbox-runtime, unpack, read macos-sandbox-utils.js. There you’ll see exactly what’s allowed and what’s blocked.

• Examine Cowork from the inside: Launch Cowork and ask it to run cat /proc/1/cmdline | tr '\0' '\n'. The bubblewrap flags reveal the isolation in detail.

• Test the network: A curl https://evil-exfiltration-test.example.org inside the sandbox immediately shows you whether the allowlist is working.

What’s Next?

The current state is clear. But one question remains: will it stay this way? Claude Code and Cowork already share the agentic architecture — and there are concrete signals that the security models are converging as well:

• Docker is delivering MicroVM sandboxes with docker-model-runner, specifically designed for AI agents.

• Apple is bringing its own Containerization framework with macOS 26 — native container support on the Mac for the first time.

• Anthropic documents DevContainers as the official path toward stronger isolation in Claude Code.

Three players, three approaches, one goal: agents should be able to do more without being able to cause more damage. In the next article, I’ll examine the pros and cons of each path — and why I consider one of them the most likely.

If you want to be notified when the next article is published:

Jetzt abonnieren

Subscribe to my Substack — free, no spam, just substance.

Sources

• Sandboxing — Claude Code Docs

• sandbox-runtime (GitHub)

• Inside Claude Cowork (Pedro José Pereira Vieito) — Reverse engineering analysis of the VM architecture

• Apple Virtualization Framework

KI-Agenten führen Befehle auf deinem Rechner aus — aber wie gut schützen dich die Sandboxes von Claude Code und Cowork? Beide versprechen Isolation, setzen aber auf unterschiedliche Mechanismen. Ich habe nicht nur die Dokumentation gelesen, sondern beide Systeme mit Linux-Tools von innen untersucht. Das Ergebnis: Die Isolation ist real, nachprüfbar und überraschend durchdacht.

„Falls sich Claude entscheidet, alle meine Dateien zu löschen: Halb so wild. Aber bitte nur innerhalb einer isolierten VM !“

Wer Claude Code im Terminal mit den Standardeinstellungen nutzt, kennt das: Viele Befehle benötigen eine Freigabe, bevor Claude Code sie ausführt.

Immer wieder muss man abwägen, ob der jeweilige Befehl in Ordnung geht oder nicht:

„Allow this? Allow once? Allow always?“

Ständig prüft man: Ist das ungefährlich oder könnte dieser Befehl zu Problemen führen? Cognitive Load durch Kommandozeilen lesen.

Im Grunde gibt es zwei extreme Ansätze: Entweder man prüft jede einzelne Freigabeanfrage selbst oder setzt auf die Option --dangerously-skip-permissions, wodurch alles erlaubt ist. Dazwischen gibt es viele Abstufungen. Man kann seine Permissions feingranular definieren, aber das ist fast genauso aufwendig.

Wie schön wäre es, wenn man einfach alles erlauben könnte und dennoch sicher sein könnte, dass nichts Unerwünschtes auf dem eigenen Rechner passiert. Dann könnte Agentic Coding ungebremst stattfinden und man käme schnell zu Ergebnissen.

Genau das verspricht ein isoliertes System, das abgeschirmt vom eigenen Computer läuft. So ein isoliertes System verringert den Blast Radius — also den Schaden, den ein fehlgeleiteter Befehl maximal anrichten kann — immens. Wenn etwas schief geht, startet man einfach neu und geht zum letzten stabilen Ausgangszustand zurück. Es gibt viele Möglichkeiten, das umzusetzen.

Eine davon ist der in Claude Code eingebaute /sandbox-Befehl. Er aktiviert eine Sandbox, die Claude Code auf OS-Ebene einschränkt — Dateizugriffe und Netzwerk. Man kann Commands automatisch laufen lassen, ohne jedes Mal zu bestätigen, weil die Sandbox begrenzt, was passieren kann. Aber wie sicher ist das wirklich?

Und dann gibt es noch Cowork in der Desktop-Variante der Claude-App. Cowork richtet sich eher an Wissensarbeiter, nicht direkt an Entwickler. Es darf auf Ordner zugreifen, Dateien erstellen und verändern, Pakete installieren — und das alles autonom. Auf den ersten Blick ist dabei nicht ersichtlich, wie die Absicherung funktioniert. Es gibt keinen /sandbox-Befehl, den man aktivieren müsste. Die Isolation passiert im Hintergrund.

Mich hat beides interessiert: Wie funktioniert die Sandbox in Claude Code? Und wie schützt mich Cowork davor, dass ungewollte Änderungen auf meinem Rechner passieren?

Dabei wollte ich mich nicht nur auf die Dokumentation verlassen, sondern ich habe beide Systeme von innen untersucht. Hier ist, was ich gefunden habe.

Zwei Produkte, zwei Zielgruppen, zwei Sicherheitsmodelle

Bevor ich in die Technik gehe, ein wichtiger Unterschied:

Claude Code ist ein Terminal-Tool für Entwickler. Es führt Befehle auf deinem Rechner aus — im selben Kontext, in dem du arbeitest. Die Sandbox muss manuell aktiviert werden (/sandbox), ist opt-in. Das ergibt Sinn: Entwickler brauchen möglichst wenig Einschränkungen, um produktiv zu sein. Sie wollen Befehle ausführen können, die eine restriktive Sandbox behindern würde. Aber mit vielen Rechten kommt viel Verantwortung. Man muss verstehen, was man abnickt.

Cowork ist Teil der Claude Desktop-App und richtet sich an Nutzer, die sich nicht mit der Kommandozeile auseinander setzen wollen. Wenn jemand Claude bittet, eine Excel-Tabelle aus fünf PDFs zu erstellen, erwartet er ein Ergebnis — nicht eine Diskussion über Dateiberechtigungen. Cowork muss daher stärker absichern, und zwar ohne dass der Nutzer das konfigurieren muss.

Das Ergebnis: Zwei unterschiedliche Isolationsmodelle für zwei unterschiedliche Risikoprofile.

Lass uns in die Details gehen.

Cowork: Ein Linux in deinem Mac

Cowork startet eine leichtgewichtige Linux-VM über Apples Virtualization.framework. Kein Container, sondern eine echte virtuelle Maschine mit eigenem Kernel.

Was sagt die VM über sich?

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"

$ uname -r
6.8.0-94-generic

$ uname -m
aarch64

$ nproc
4

$ free -h
              total    used    free
Mem:          3.8Gi   564Mi   1.8Gi
Swap:            0B      0B      0B

$ df -h /
Filesystem      Size  Used Avail Use%
/dev/nvme0n1p1  9.6G  7.2G  2.4G  75%

Ubuntu 22.04 auf ARM64, 4 Kerne, 3,8 GB RAM, eine 10-GB-Disk. Kein Swap. Schlank genug für Dokumentenverarbeitung und Skripte, aber nicht für Machine-Learning-Training gedacht.

Auf dem macOS-Host finden sich die VM-Dateien unter ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/. Das Root-Image (rootfs.img) ist 10 GB groß als Sparse-Datei, belegt aber nur etwa 7,5 GB on-disk.

Daneben liegt ein komprimiertes Backup (rootfs.img.zst, ~2 GB) und ein paar Konfigurationsdateien: efivars.fd, macAddress, machineIdentifier.

Wie drei Schichten zusammen die Isolation absichern

Die VM allein wäre schon eine solide Grenze. Aber Anthropic stapelt drei Schichten übereinander.

Schicht 1: Die VM

Apples Virtualization.framework stellt Hardware-Isolation bereit. Der Gast hat seinen eigenen Kernel. Selbst ein rm -rf / in der VM lässt den Host unberührt.

Schicht 2: bubblewrap + seccomp

Innerhalb der VM läuft nicht direkt Claude, sondern erst bubblewrap (kurz: bwrap). Bubblewrap ist ein Sandboxing-Tool, das Linux-Namespaces nutzt, um Prozesse voneinander zu isolieren — ähnlich wie Container es tun, aber leichtgewichtiger.

Es schränkt ein, was ein Prozess sehen und tun darf: welche Dateien, welche Netzwerkschnittstellen, welche anderen Prozesse.

In der Cowork-VM ist bubblewrap PID 1, also der allererste Prozess:

$ cat /proc/1/status | head -2
Name:   bwrap
State:  S (sleeping)

Die bwrap-Kommandozeile (über /proc/1/cmdline auslesbar) zeigt die wichtigsten Einschränkungen im Überblick:

• --unshare-net — eigener Netzwerk-Namespace, kein direkter Netzzugang

• --unshare-pid — eigener PID-Namespace, andere Prozesse unsichtbar

• --ro-bind / / — Root-Dateisystem read-only eingebunden

• --die-with-parent — stirbt der Elternprozess, stirbt die Sandbox mit

• --tmpfs /etc/ssh/ssh_config.d — SSH-Konfiguration wird mit einem leeren tmpfs überdeckt

Zusätzlich wird ein seccomp-Filter geladen. Seccomp (Secure Computing Mode) ist ein Mechanismus im Linux-Kernel, der festlegt, welche Systemaufrufe ein Prozess machen darf. Systemaufrufe sind die Schnittstelle zwischen einem Programm und dem Betriebssystem — Dateien öffnen, Netzwerkverbindungen herstellen, Prozesse starten.

Ein seccomp-Filter kann gezielt einzelne Systemaufrufe blockieren und damit den Aktionsradius eines Prozesses stark einschränken.

$ grep Seccomp /proc/self/status
Seccomp:         2
Seccomp_filters: 2

Seccomp: 2 bedeutet Filter-Modus — es gibt eine aktive Allowlist für erlaubte Syscalls. Die Filterdatei heißt unix-block.bpf und wird über eine eigene Binary (apply-seccomp) geladen.

Schicht 3: Netzwerk-Isolation

Kein Prozess in der Sandbox hat direkten Internetzugang. Aller Traffic geht durch einen lokalen Proxy:

$ env | grep HTTP_PROXY
HTTP_PROXY=http://localhost:3128

$ env | grep ALL_PROXY
ALL_PROXY=socks5h://localhost:1080

Der Proxy läuft über socat, das TCP-Verbindungen in Unix-Sockets tunnelt, die aus der VM herausführen. Auf der Host-Seite entscheidet eine Allowlist, welche Domains passieren dürfen.

Ich habe es getestet:

$ curl -s -o /dev/null -w "%{http_code}" https://registry.npmjs.org
200

$ curl -s -o /dev/null -w "%{http_code}" https://pypi.org
200

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "HTTP/1.1"
< HTTP/1.1 403 Forbidden

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "X-Proxy"
< X-Proxy-Error: blocked-by-allowlist

npm und PyPI kommen durch. Alles andere bekommt ein 403 Forbidden mit dem Header X-Proxy-Error: blocked-by-allowlist. Auch direkte DNS-Lookups scheitern:

$ nslookup google.com
socket(): Operation not permitted
;; no servers could be reached

Das ist konsequent: Selbst wenn ein Prompt-Injection-Angriff Claude dazu bringen würde, Daten an einen externen Server zu senden — der Proxy würde es blockieren.

Welche Dateien sieht die VM?

Dateien kommen über VirtioFS in die VM — ein Dateisystem-Protokoll, das speziell für die Kommunikation zwischen VM und Host entwickelt wurde. Statt echte Hardware zu simulieren, arbeiten Host und Guest bewusst zusammen (Paravirtualisierung). Das macht den Dateizugriff schnell und mit wenig Overhead möglich.

$ mount | grep virtiofs
/mnt/.virtiofs-root/shared/Work/.../Marketing on
  /sessions/elegant-adoring-brown/mnt/Marketing type fuse (rw,...)

Nur der Ordner, den ich in der Desktop-App ausgewählt habe, wird gemountet. Nicht mein Home-Verzeichnis, nicht mein Desktop, nicht meine Downloads — nur der eine Ordner, den ich explizit freigegeben habe.

Plugins und Skills werden über bindfs zusätzlich eingebunden. Bindfs ist ein FUSE-Dateisystem, das einen vorhandenen Ordner an einer anderen Stelle nochmal einbindet — ähnlich wie ein Symlink, aber mit der Möglichkeit, die Berechtigungen zu ändern. So können Skills zum Beispiel read-only eingebunden werden, obwohl sie auf dem Host beschreibbar sind. Uploads landen ebenfalls in einem separaten, schreibgeschützten Mount.

Ein Detail verrät, dass die VM mehrere Conversations gleichzeitig bedient: Im /sessions/-Verzeichnis sitzen verschiedene Sessions nebeneinander:

$ ls -la /sessions/
drwxr-x--- elegant-adoring-brown  elegant-adoring-brown  ...
drwxr-x--- nobody                 nogroup                awesome-epic-mccarthy
drwxr-x--- nobody                 nogroup                dazzling-vibrant-carson

Jede Session bekommt einen eigenen Linux-User mit eigener UID. Mein User heißt elegant-adoring-brown (uid 1005). Die anderen Sessions sind unter nobody gelistet — ich kann ihre Dateien nicht lesen.

Wie schützt Claude Code ohne VM?

Claude Code im Terminal nutzt auf macOS einen anderen Ansatz: Apples Seatbelt (auch bekannt als sandbox-exec). Statt einer VM wird ein dynamisch generiertes Sandbox-Profil erstellt, das den Prozess auf OS-Ebene einschränkt. Wichtig: Die Sandbox muss manuell mit /sandbox aktiviert werden — ohne diesen Schritt läuft Claude Code ohne OS-Level-Isolation.

Das Profil startet mit (deny default) — alles ist verboten, außer es wird explizit erlaubt. Die Sandbox-Runtime ist Open Source und auf GitHub einsehbar. Ich habe das npm-Paket @anthropic-ai/sandbox-runtime heruntergeladen und die macos-sandbox-utils.js analysiert:

• 59 sysctl-Einträge werden zum Lesen freigegeben (Hardware-Info wie CPU-Anzahl, Speichergröße)

• 14 Mach-IPC-Services auf der Whitelist (Fonts, Logging, Security Server)

• Mandatory Denies für .env, .ssh, .aws, .git/hooks, .git/config — auch wenn das Arbeitsverzeichnis Schreibzugriff hat

• Move-Blocking: file-write-rename und file-write-unlink werden für geschützte Pfade blockiert, damit man die Denies nicht per mv umgehen kann

Die Netzwerk-Isolation funktioniert genauso wie bei Cowork: Aller Traffic geht durch denselben Proxy mit Allowlist. Der Unterschied: Bei Seatbelt passiert das auf Prozess-Ebene (gleicher Kernel), bei Cowork auf VM-Ebene (eigener Kernel).

Warum zwei Modelle?

Claude Code richtet sich an Entwickler, die im Terminal schnelles Feedback brauchen. Der Seatbelt-Overhead liegt im niedrigen einstelligen Millisekundenbereich — ich habe es auf dem Host gemessen, kein spürbarer Unterschied zu einem Befehl ohne Sandbox. Entwickler können die Sandbox gezielt aktivieren, wenn sie einem Agenten mehr Autonomie geben wollen, ohne jeden Befehl freigeben zu müssen.

Cowork gibt Claude deutlich mehr Autonomie: Es läuft länger, erstellt eigenständig Dateien, installiert Pakete. Und es richtet sich an Nutzer, die nicht einschätzen können (und nicht einschätzen müssen), welche Befehle auf Betriebssystemebene ausgeführt werden. Der mögliche Schaden eines Agenten mit lokalem Dateizugriff, Codegenerierung und Netzwerk-Egress ist größer — und die Nutzer können ihn schlechter einschätzen. Die volle VM-Isolation ist hier angemessen.

Was ich daraus mitnehme

Die Isolation ist real. Nicht nur auf dem Papier, sondern nachprüfbar.

Drei Dinge haben mich besonders überzeugt:

Erstens die Proxy-Allowlist mit dem expliziten X-Proxy-Error: blocked-by-allowlist Header. Das ist keine stille Fehlermeldung, sondern eine bewusste Architekturentscheidung. Man sieht sofort, warum eine Verbindung scheitert.

Zweitens die Schichtung. VM allein wäre gut. Mit bubblewrap und seccomp wird’s besser. Alle drei zusammen machen es deutlich schwieriger, aus der Sandbox auszubrechen. Ein Exploit müsste gleichzeitig den seccomp-Filter umgehen, aus dem bwrap-Namespace ausbrechen und dann noch aus der VM raus — auf einem System, das keinen direkten Netzzugang hat.

Drittens die Transparenz. Die Sandbox-Runtime ist Open Source. Ich habe den Code der macos-sandbox-utils.js heruntergeladen — dort stehen die 59 sysctl-Einträge, die 14 Mach-Services und die Mandatory Denies für .env, .ssh und .aws schwarz auf weiß. Das Seatbelt-Profil wird dynamisch generiert, aber der generierende Code ist einsehbar. Die VM-Architektur lässt sich von innen inspizieren. Man muss niemandem glauben — man kann nachschauen.

Wer selbst nachschauen will: Die Sandbox-Runtime liegt auf GitHub. Ein npm pack und ein Blick in macos-sandbox-utils.js reichen, um das Seatbelt-Profil zu verstehen.

Was du jetzt tun kannst

Wenn du Claude Code nutzt und die Sandbox noch nicht ausprobiert hast: Starte eine Session und tippe /sandbox. Allein das reduziert den Aufwand, Befehle einzeln freizugeben, erheblich. Für den Alltag reicht das oft schon.

Wenn du tiefer einsteigen willst:

• Sandbox-Runtime inspizieren: npm pack @anthropic-ai/sandbox-runtime, entpacken, macos-sandbox-utils.js lesen. Dort siehst du exakt, was erlaubt und was blockiert wird.

• Cowork von innen ansehen: Starte Cowork und bitte es cat /proc/1/cmdline | tr '\0' '\n' auszuführen. Die bubblewrap-Flags verraten dir die Isolation im Detail.

• Netzwerk testen: Ein curl https://evil-exfiltration-test.example.org in der Sandbox zeigt dir sofort, ob die Allowlist greift.

Wie geht es weiter?

Damit ist der Ist-Zustand klar. Aber eine Frage bleibt: Wird das so bleiben? Claude Code und Cowork teilen sich bereits die agentic Architektur — und es gibt konkrete Signale, dass auch die Sicherheitsmodelle zusammenwachsen:

• Docker liefert mit docker-model-runner MicroVM-Sandboxes, die speziell für KI-Agenten gedacht sind.

• Apple bringt mit macOS 26 ein eigenes Containerization-Framework — erstmals native Container-Unterstützung auf dem Mac.

• Anthropic dokumentiert DevContainer als offiziellen Weg für stärkere Isolation in Claude Code.

Drei Player, drei Ansätze, ein Ziel: Agenten sollen mehr dürfen, ohne mehr Schaden anrichten zu können. Im nächsten Artikel werde ich mir anschauen, was für und gegen jeden dieser Pfade spricht — und warum ich einen davon für den wahrscheinlichsten halte.

Wenn du benachrichtigt werden willst, wenn der nächste Artikel veröffentlich ist:

Jetzt abonnieren

Quellen

• Sandboxing — Claude Code Docs

• sandbox-runtime (GitHub)

• Inside Claude Cowork (Pedro José Pereira Vieito) — Reverse-Engineering-Analyse der VM-Architektur

• Apple Virtualization Framework

Die AI-Diskussion in der Softwareentwicklung dreht sich fast ausschließlich um eine Frage: Wie generieren wir Code schneller? Das ist verständlich – aber es lenkt von dem ab, was gerade wirklich passiert.

Das Bottleneck hat sich verschoben

Vor einem Jahr war “Code schreiben” noch ein limitierender Faktor. Heute kann ein einzelner Entwickler mit den richtigen Agents an einem Tag produzieren, wofür früher eine Woche nötig war.

Klingt nach Fortschritt. Ist es auch – bis man fragt: Wer reviewt das alles? Wer versteht es? Wer verantwortet es?

Die Velocity-Metriken sehen fantastisch aus. Aber die Engpässe sind nicht verschwunden. Sie haben sich verschoben – zum Menschen.

Fünf Fragen, auf die niemand gute Antworten hat

1. Wie bewertest du Arbeit, die du nicht mehr selbst machst?

Engineering Leads haben jahrelang Code-Reviews gemacht. Sie wussten, worauf sie achten mussten, weil sie selbst im Code steckten. Wenn Agents den Großteil des Codes produzieren und Engineers zu “Orchestratoren” werden – nach welchen Kriterien bewerten wir dann? Wie unterscheidest du guten von schlechtem Output, wenn du selbst nicht mehr Zeile für Zeile durchgehst?

2. Wer übernimmt die Verantwortung?

Agent generiert Code. Engineer gibt ihn frei. QA testet. Alles grün. Drei Monate später: Security-Problem, das niemand gesehen hat.

Wer ist verantwortlich? Der Engineer, der den Code freigegeben hat, ohne ihn wirklich zu verstehen? Das Team, das die Guardrails definiert hat? Die Organisation, die keine besseren Review-Prozesse etabliert hat?

In klassischen Strukturen war Verantwortung an Wissen gekoppelt: Wer den Code geschrieben hat, verstand ihn und verantwortete ihn. Diese Kopplung löst sich gerade auf.

3. Wie befähigst du Menschen, Verantwortung zu übernehmen, die sie nicht tragen können?

“Human in the Loop” klingt beruhigend. Aber was bedeutet das konkret?

Ein Mensch, der zehnmal so viel Output überprüfen muss wie vorher, prüft nicht gründlicher – er prüft oberflächlicher. Oder er wird zum Bottleneck, der die gesamte AI-Velocity wieder zunichtemacht.

Wir verlangen von Menschen, dass sie Arbeit verantworten, für die wir sie weder ausgebildet noch ausgestattet haben.

4. Was genau wird verifiziert – und was nicht?

Tests laufen durch. Linting ist sauber. Der Code funktioniert.

Aber: Ist die Architektur-Entscheidung richtig? Passt die Lösung ins Gesamtsystem? Entsteht gerade technische Schuld, die erst in zwei Jahren sichtbar wird?

Agents optimieren lokal. Sie lösen die Aufgabe, die vor ihnen liegt. Die systemischen Auswirkungen sieht niemand – bis es zu spät ist.

5. Was passiert mit den Bereichen, die nicht Engineering heißen?

Code-Generierung ist nur ein Teil des Delivery-Systems. Was ist mit Produktentscheidungen, die jetzt schneller technisch umsetzbar sind – aber nicht schneller durchdacht? Was ist mit Dokumentation, die niemand mehr schreibt, weil der Code sich zu schnell ändert? Mit Onboarding neuer Teammitglieder in eine Codebase, die niemand im Team mehr wirklich versteht?

Wenn Engineering plötzlich zehnmal schneller liefern kann, verschiebt sich der Druck auf Product, Design, QA. Die Friction wandert – sie verschwindet nicht.

Das eigentliche Problem

Wir haben das Code-Schreiben beschleunigt. Aber die Arbeit, die sich nicht beschleunigen lässt – verstehen, bewerten, entscheiden, verantworten – ist immer noch da. Und unsere Organisationen sind nicht dafür gebaut.

Die meisten Unternehmen behandeln AI wie ein Upgrade ihrer Werkzeuge. Schnellere IDE, besserer Copilot, mehr Output pro Kopf.

Aber das Werkzeug hat sich fundamental verändert. Es trifft jetzt eigene Entscheidungen. Und wir haben keine Strukturen, Prozesse oder Rollenbilder, die damit umgehen können.

Kleine AI-native Teams bauen gerade ihre Strukturen um diese Realität herum. Große Organisationen diskutieren noch, welchen Copilot sie lizenzieren. Die Frage ist nicht, ob sich das rächt – sondern wann.

„Ich schreibe kaum noch Code. Und trotzdem baue ich mehr Software als je zuvor.“

Als ich das kürzlich auf LinkedIn schrieb, kam:

„Naja, und wer kontrolliert die Agenten? Wer räumt die technischen Schulden, die sie produzieren, wieder auf?”

Eine Frage, eine berechtigte Frage, mit der ich mich ebenfalls schon beschäftigt hatte.

Eine Frage, die ich nicht mit einem Zweizeiler beantworten kann.

Die Frage hinter der Frage

Wer so fragt, will wissen:

Kannst du dem Output überhaupt vertrauen?

Oder baust du dir gerade ein Kartenhaus, das beim ersten echten Problem zusammenfällt?

Meine Antwort ist unbefriedigend für alle, die ein klares Ja oder Nein wollen: Es kommt darauf an. Und genau dieses „es kommt darauf an” ist der eigentliche Skill, den ich in den letzten Monaten entwickelt habe.

Nicht alles ist gleich kritisch

Der erste Schritt war eine simple Erkenntnis: Nicht jeder Bereich meiner Software verdient dieselbe Aufmerksamkeit.

Ich unterscheide grob nach zwei Kriterien:

1. Wie schnell sehe ich, wenn etwas nicht funktioniert?

2. Wie groß ist der potenzielle Schaden?

Kritische Bereiche sind für mich zum Beispiel:

• Authentifizierung und Login-Flows

• Autorisierungslogik – wer darf was sehen und tun

• Datenbankdesign, insbesondere das Datenmodell

• Row Level Security für Datenbanken

• Alles, was mit Zahlungen oder sensiblen Nutzerdaten zu tun hat

• Alles, von dem viel abhängt

Diese Bereiche haben zwei Eigenschaften gemeinsam:

• Fehler sind nicht sofort sichtbar, und

• wenn sie auftreten, ist der Schaden potenziell groß.

Eine kaputte Authentifizierung merkst du nicht, wenn du die Anwendung durchklickst. Du merkst sie, wenn jemand anderes sie ausnutzt.

Unkritische Bereiche sind für mich:

• Frontend-Darstellung und UI-Komponenten

• Styling und Layout

• Nicht-sicherheitsrelevante Formularvalidierungen

• Hilfsfunktionen und Utilities

Das heisst nicht, dass sie unwichtig sind. Aber wenn hier etwas nicht funktioniert, sehe ich es schnell. Ein Button, der nicht reagiert, eine Liste, die nicht rendert – das fällt beim Testen auf. Und selbst wenn es durchrutscht: Der Schaden ist begrenzt. Kein Nutzer verliert Geld oder Daten, weil ein Schatten an der falschen Stelle sitzt.

Wie ich Agenten einsetze

Für meine Projekte habe ich spezialisierte Subagents aufgebaut, die auf definierte Aufgaben zugeschnitten sind. Manche habe ich selbst konfiguriert, bei anderen greife ich auf vorgefertigte Lösungen zurück. Entscheidend ist nicht das einzelne Tool, sondern wie sie zusammenarbeiten.

Mein Workflow folgt einem Muster, das menschliche Review-Prozesse nachbildet:

Stufe 1: Entwurf. Ein Agent erstellt einen ersten Vorschlag – sei es Code, eine Architekturentscheidung oder ein Datenbankschema.

Stufe 2: Ausarbeitung. Ein anderer Agent nimmt den Entwurf und arbeitet die Details aus. Er kennt den Kontext, aber er hat eine andere Perspektive.

Stufe 3: Prüfung. Ein dritter Agent überprüft das Ergebnis. Er fragt: Was könnte man aus Sicherheitsperspektive verbessern? Wo sind potenzielle Schwachstellen?

Das klingt aufwendiger, als es ist. In der Praxis läuft vieles davon automatisiert. Ich stoße den Prozess an und bekomme am Ende einen Report, den ich durchgehe.

Der entscheidende Unterschied: Wo ich selbst hinschaue

Bei unkritischen Bereichen reicht mir, was die spezialisierten Agenten identifizieren.

Bei kritischen Bereichen ist das Agenten-Review nur die erste Runde. Die zweite Runde mache ich selbst.

Das bedeutet konkret: Ich lese den Code. Ich hinterfrage die Architekturentscheidungen. Ich überlege, welche Edge Cases nicht abgedeckt sind. Ich gleiche ab, ob das, was da steht, zu meinem mentalen Modell des Systems passt.

Das ist der Human-in-the-Loop, von dem alle reden. Nur dass er eben nicht bei jeder Zeile Code greift, sondern gezielt dort, wo es darauf ankommt.

Vorgaben von Anfang an

Ein Bereich, in dem sich der agentenbasierte Ansatz besonders bewährt. Statt Anforderungen nachträglich zu prüfen, bette ich sie von Anfang an in den Entwicklungsprozess ein.

Das funktioniert über Guidelines – Markdown-Dateien, die beschreiben, welche Regeln gelten. Diese Guidelines fließen in die Spezifikations- und Planungsphase ein. Die Agenten kennen sie und berücksichtigen sie.

Anschließend lasse ich spezialisierte Agenten Reviews durchführen und Reports erstellen. Diese Reports gehe ich durch, hinterfrage kritisch, führe meine eigene Analyse durch und gleiche ab. Wenn Probleme auftauchen, lasse ich sie durch die Agenten beheben und stoße dann ein erneutes Review an.

Es ist ein iterativer Prozess. Aber einer, der Compliance by Design ermöglicht, statt sie als nachträglichen Kontrollschritt zu behandeln.

Die Bilanz: Ähnliche Probleme, andere Dynamik

Produzieren Agenten mehr technische Schulden als Menschen? Nach meiner Erfahrung: Nein. Es sind dieselben Probleme – nur schneller sichtbar.

Wenn eine Codebasis wächst, entsteht duplizierter Code. Nicht, weil die Agenten schlecht arbeiten, sondern weil ihnen der Gesamtüberblick fehlt. Ein erfahrener Entwickler, der seit Monaten an einem Projekt arbeitet, weiß implizit, dass es schon eine Utility-Funktion für diesen Fall gibt. Ein Agent sieht nur den aktuellen Kontext.

Das ist kein Argument gegen Agenten. Es ist ein Argument für iterative Zyklen.

Mein Vorgehen: Erst die Funktionalität, dann das Aufräumen. Ich lasse entwickeln, schaue, dass es funktioniert, und starte dann eine neue Runde, in der ich gezielt auf Code-Qualität achte. Dafür nutze ich einen Subagent, der sich auf Refactorings spezialisiert hat – er analysiert, identifiziert Duplikate, schlägt Zusammenführungen vor.

Dieses Vorgehen ist nicht neu. Es ist das, was erfahrene Entwickler schon immer gemacht haben: Erst zum Laufen bringen, dann aufräumen. Wer versucht, von Anfang an hundertprozentig sauberen Code zu schreiben, verzettelt sich und blockiert sich selbst.

Der Unterschied: Mit Agenten passiert beides schneller. Die technischen Schulden entstehen schneller – aber sie werden auch schneller sichtbar und schneller abgebaut.

Was Agenten gut können – und was nicht

Nach Monaten intensiver Arbeit mit diesem Setup habe ich ein klareres Bild davon, wo die Stärken und Grenzen liegen.

Agenten schreiben exzellenten Code im Kleinen. Eine einzelne Funktion, ein Modul, eine Komponente – das bekommen sie auf dem Niveau eines erfahrenen Entwicklers hin. Saubere Struktur, gute Benennung, Best Practices.

Was ihnen fehlt, ist der Systemüberblick. Sie sehen nicht, wie die Teile zusammenhängen. Sie wissen nicht, dass die Entscheidung in Modul A Auswirkungen auf Modul B hat, wenn das nicht explizit im Kontext steht.

Das liegt in der Natur der Sache: Eine KI kann nur aus dem verstehen, was ihr als Kontext gegeben wird. Ein erfahrener Entwickler hat das Gesamtsystem im Kopf – auch die Teile, die er nie explizit aufgeschrieben hat.

Der Skill-Shift

Diese Erkenntnis hat Konsequenzen für die Art, wie ich arbeite.

Früher konnte vieles implizit bleiben. Ich wusste, wie das System funktioniert, und musste es niemandem erklären. Jetzt muss ich es externalisieren – durch Spezifikationen, Guidelines, Architektur-Dokumentation. Was früher im Kopf bleiben konnte, muss jetzt explizit werden.

Das ist mehr Arbeit. Aber es ist bessere Arbeit. Denn was ich für die Agenten aufschreibe, hilft auch anderen Teammitgliedern. Also den Menschen1. Es zwingt mich, meine Entscheidungen zu artikulieren, statt sie vorauszusetzen.

Der Shift, den ich beobachte, ist real:

Weniger „wie schreibe ich diesen Code”, mehr „wie lenke ich die Agenten”. Das bedeutet nicht, dass Programmierkenntnisse unwichtig werden. Es bedeutet, dass sie nicht mehr ausreichen.

Was jetzt zählt:

• Systemdesign auf höherer Ebene: Architektur, Schnittstellen, Datenmodelle

• Sicherheitsdenken: Wo sind die Angriffsflächen, was muss besonders geschützt werden

• Agenten-Orchestrierung: Wie koordiniere ich verschiedene spezialisierte Agenten, wie definiere ich Richtlinien, wie behalte ich die Kontrolle

• Kritisches Prüfen: Wann vertraue ich dem Output, wann schaue ich selbst hin

Die Antwort auf die ursprüngliche Frage

Wer kontrolliert die Agenten? Ich. Aber nicht bei jeder Zeile Code.

Ich kontrolliere durch Struktur: spezialisierte Agenten, die sich gegenseitig prüfen. Ich kontrolliere durch Fokus: menschliche Reviews dort, wo der Schaden am größten wäre. Ich kontrolliere durch Iteration: Entwickeln, prüfen, aufräumen, wiederholen.

Und ich kontrolliere durch Akzeptanz: Die Einsicht, dass kein Prozess perfekt ist – weder mit Agenten noch ohne. Dass technische Schulden entstehen und abgebaut werden müssen. Dass Fehler passieren und gefunden werden müssen.

Der Unterschied ist nicht, dass Agenten fehlerfreien Code produzieren. Der Unterschied ist, dass ich mehr produziere und schneller iteriere. Und dass ich meine Zeit dort einsetze, wo sie den größten Unterschied macht: bei den Entscheidungen, die ein System sicher oder unsicher, wartbar oder unwartbar machen.

Das ist keine Zukunftsvision. Das ist mein Alltag seit Monaten. Und bisher funktioniert es.

Deshalb ist es so spannend sich gegenseitig auszutauschen und zu hören, wie andere konzeptionell an die KI-gestützte Softwareentwicklung herangehen.

Denn letztendlich war es schon immer der richtige Lösungsansatz, der den eigentlichen Mehrwert liefert. Wenn man weiß, wie man ein Problem lösen kann, ist die anschließende Umsetzung fast trivial.

Zudem wird immer deutlicher, dass testgetriebene Entwicklung wichtiger denn je ist:

1. Tests dienen als Leitplanken, die eine Beschreibung des Ziels liefern.

2. Tests dienen als Feedback-Schleife. Agenten können sie eigenständig ausführen und erhalten dadurch Feedback, wie gut sie ihre Aufgaben erfüllt haben.

→ Agenten können autonom und iterativ weiterarbeiten, bis das Ergebnis die Erfolgskriterien erfüllt.

3. Und wie sonst will man bei jeder Iteration die Korrektheit von so viel Code prüfen?

The discussion about agentic coding fluctuates between two extremes: “AI will solve everything” on the one hand, “It’s all just hype” on the other.

Both positions fall short. After months of intensive work with coding agents, I would like to share with you what I have learned in the process – and how my way of working has changed.

The current state of affairs: 7 theses

Before I get to my own specific experiences, here are 7 core theses written by Simon Wardley, which I have supplemented with my own perspective:

Development is not yet engineering. While testing has become a systematic discipline through practices such as TDD, development remains largely intuition-driven. There are patterns, but no consistent system. Agentic coding could be a catalyst for this transformation, if we approach it correctly.

Small, contextual tools beat monoliths with LLM on top. The prevailing approach of simply enriching existing systems with LLM capabilities does not exploit the potential. More effective are combinable tools with clear inputs, outputs, and specific application contexts.

LLMs are coherence machines, not truth machines. They optimize for plausibility, not correctness. This makes them valuable for drafting and exploration, but unreliable for final decisions without human validation.

Code is more than functionality – structure is the real decision. Architectural decisions manifest themselves in code. LLMs can generate functionality, but structural decisions require an understanding of the system.

The key question: Where do humans stand in the decision-making process? It’s not about whether AI is used, but where human judgment remains indispensable. This boundary must be drawn consciously.

Practices are still evolving. What is considered state of the art today may be obsolete tomorrow. Beware of hasty best practices.

Experimentation is fine, but with an awareness of the terrain. Speed without direction is just getting lost quickly.

My approach today

These theories align well with my experiences. However, theory is one thing and daily practice is another. Here’s what works for me.

A deliberately modular setup

I don’t like working with fully integrated solutions. Not on principle, but because they don’t work optimally for my workflow.

My setup consists of three components:

1. An IDE, such as IntelliJ IDEA, which allows me to keep track of the code. I can quickly check where everything is located. Git integration is extremely important here — it makes changes traceable and reversible. IntelliJ can do almost everything I need, including inspecting databases. Unfortunately, with power comes complexity. For smaller projects, I prefer the ZED editor because it’s more streamlined and intuitive.

2. I use the terminal (preferably Ghostty) with my coding agent, which is currently mainly Claude Code. There, I give instructions, observe, and control.

3. I use an LLM chat window for conceptual work. At the beginning of a project, I use it to work through ideas and organize them in a document before writing code.

This three-way split is no coincidence. It corresponds to the principle of specialized tools: each component has its strengths, none tries to be everything.

I use other specialized tools here and there, such as the GitHub Desktop app. But at its core, these three tools are the ones I use.

Sub-agents as the key

Perhaps the most important lesson learned in recent months is that specialized sub-agents deliver significantly better results than general-purpose agents. The reason is simple—the tailored context makes all the difference.

Two examples from my experience:

Quality assurance: A sub-agent exclusively responsible for quality assurance checks against specified guidelines and documentation. It does not advise; it validates. This is essentially TDD thinking at the agent level — explicit standards instead of intuition.

UI design: I achieve significantly better results when designing user interfaces with a specialized design sub-agent. I specify the direction the design should take and which design principles apply. The agent generates designs within these guidelines instead of working in a vacuum.

In both cases, the lever is the specialized context and the focused system prompt of the sub-agent, not the general intelligence of the model.

Validating coherence

Yes, LLM output has misled me before. In fact, it was precisely because it sounded plausible. The coherence was there, but the truth was not.

My validation process is two-stage. First, I verify what I can myself. For everything else, I use specialized sub-agents with internet access that can verify facts. However, it’s crucial to note that ultimately, humans remain responsible. The sub-agents are tools, not decision-makers.

Hallucinations don’t like to stay alone. Where one thing is wrong, other things are often invalid.

Keeping an eye on structure

When does generated code become problematic? Most obviously, when source code files become too large. There are too many lines. Too much functionality in individual functions.

My approach: I let almost everything be generated. If I want to make changes, I let the agent adapt and then check it. Experience shows that this is faster than writing it myself, unless the changes are minor restructuring or corrections. In that case, I intervene directly.

However, I am responsible for the structure. I decide when a file becomes too large, when functionality needs to be split up, and what the architecture and refactorings should look like. I usually define the architecture before coding begins and document it in Markdown files.

The real problem is communication

Ultimately, humans must decide if what has been generated is good enough. Human judgment is indispensable because only humans can determine if they have received what they wanted.

Here lies an uncomfortable truth: Even with AI, the problem is often communication. The question is not “Can AI do that?” but “Can I articulate what I want?” This is not a new insight—anyone who has ever written requirements knows this. But with Agentic Coding, it becomes immediately apparent.

Not balance, but a pendulum

Is there a perfect balance between trying things out quickly and understanding what I’m doing? I don’t think so. It’s more like swinging back and forth.

I try out ideas to see if they lead to reasonable results. At the latest, I need to understand what I’m doing when I’m convinced of the direction and want to check its viability for the future.

That’s more honest than any best practice. Practices are still evolving. Anyone who claims to have found the optimal workflow today will be working differently in six months.

The open question

The core architectural question of our time remains: Where do we place people in the decision-making process?

This is not a technical question. It is a question of organization, responsibility, and design. Every organization must answer it for itself—consciously, rather than implicitly through tool adoption.

As of today, my answer is: People decide on the structure, validate the results, and take responsibility. Agents generate, specialize, and accelerate. The boundary is not fixed; it shifts with every learning experience.

That is precisely what makes this such an interesting time.

Die Diskussion um Agentic Coding schwankt zwischen zwei Extremen: “AI wird alles lösen” auf der einen Seite, “Alles nur Hype” auf der anderen.

Beide Positionen greifen zu kurz. Nach Monaten intensiver Arbeit mit Coding-Agents möchte ich mit euch teilen, was ich dabei gelernt habe – und wie sich meine Arbeitsweise verändert hat.

Der aktuelle Stand: 7 Thesen

Bevor ich zu meinen konkreten, eigenen Erfahrungen komme, hier 7 Kernthesen, zu denen Simon Wardley geschrieben hat und die ich durch meine Perspektive ergänzt habe:

Entwicklung ist noch kein Engineering. Während Testing durch Praktiken wie TDD zu einer systematischen Disziplin geworden ist, bleibt die Entwicklung zum größten Teil intuitions-getrieben. Es gibt Patterns, aber keine durchgängige Systematik. Agentic Coding könnte ein Katalysator für diese Transformation sein – wenn wir es richtig angehen.

Kleine, kontextuelle Tools schlagen Monolithen mit aufgesetztem LLM. Der vorherrschende Ansatz, bestehende Systeme einfach mit LLM-Fähigkeiten anzureichern, nutzt das Potenzial nicht aus. Effektiver sind kombinierbare Tools mit klaren Inputs, Outputs und spezifischem Anwendungskontext.

LLMs sind Kohärenz-Maschinen, keine Wahrheits-Maschinen. Sie optimieren auf Plausibilität, nicht auf Korrektheit. Das macht sie wertvoll für Entwürfe und Exploration, aber unzuverlässig für finale Entscheidungen ohne menschliche Validierung.

Code ist mehr als Funktionalität – Struktur ist die eigentliche Entscheidung. Architektonische Entscheidungen manifestieren sich im Code. LLMs können Funktionalität generieren, aber strukturelle Entscheidungen erfordern Systemverständnis.

Die Kernfrage: Wo stehen Menschen im Entscheidungsprozess? Es geht nicht darum, ob AI eingesetzt wird, sondern wo menschliches Urteil unverzichtbar bleibt. Diese Grenzziehung muss bewusst getroffen werden.

Die Praktiken sind noch im Entstehen. Was heute als State of the Art gilt, kann morgen überholt sein. Vorsicht vor vorschnellen Best Practices.

Experimentieren ja, aber mit Bewusstsein für das Terrain. Geschwindigkeit ohne Richtung ist nur schnelles Verirren.

Wie ich es heute angehe

Diese Thesen decken sich gut mit meinen Erfahrungen. Aber Theorie ist das eine, die tägliche Praxis das andere. Hier ist, was bei mir funktioniert.

Ein bewusst modulares Setup

Ich arbeite ungern mit komplett integrierten Lösungen. Nicht aus Prinzip, sondern weil sie nicht optimal für meinen Workflow funktionieren.

Mein Setup besteht aus drei Komponenten:

1. Eine IDE wie IntelliJ IDEA, weil ich hier den Überblick über den Code behalten kann. Schnell prüfen, wo was untergebracht ist. Die Git-Integration ist dabei eminent wichtig – sie macht Änderungen nachvollziehbar und reversibel. IntelliJ kann nahezu alles (inkl. Datenbanken inspizieren), was ich brauche. Leider kommt mit Mächtigkeit eine gewisse Unübersichtlichkeit. Für kleinere Projekte nutze ich gerne den ZED-Editor, der schlanker und übersichtlicher ist.

2. Das Terminal (am liebsten Ghostty) mit meinem Coding-Agent, aktuell hauptsächlich Claude Code. Hier gebe ich Anweisungen, beobachte und steuere.

3. Ein LLM-Chat-Fenster für die konzeptionelle Arbeit. Gerade am Anfang eines Projekts nutze ich es, um Ideen durchzuarbeiten und in ein Dokument zu bringen, bevor Code entsteht.

Diese Dreiteilung ist kein Zufall. Sie entspricht dem Prinzip der spezialisierten Tools: Jede Komponente hat ihre Stärke, keine versucht alles zu sein.

Hier und da nutze ich noch andere spezialisierte Tools, wie die GitHub Desktop App. Aber im Kern sind es diese drei, die ich benutze.

Sub-Agents als Schlüssel

Das vielleicht wichtigste Learning der letzten Monate: Spezialisierte Sub-Agents liefern deutlich bessere Ergebnisse als ein General-Purpose-Agent für alle Aufgaben. Der Grund ist simpel – der zugeschnittene Kontext macht den Unterschied.

Zwei Beispiele aus meiner Praxis:

Qualitätssicherung: Ein Sub-Agent, der ausschließlich für QA zuständig ist, prüft gegen vorgegebene Richtlinien und Dokumentationen. Er rät nicht, er validiert. Das ist im Grunde TDD-Denken auf Agent-Ebene – explizite Standards statt Intuition.

UI-Design: Bei der Gestaltung von Benutzeroberflächen erziele ich mit einem spezialisierten Design-Sub-Agent wesentlich bessere Ergebnisse. Ich kann Vorgaben machen, in welche Richtung das Design gehen soll, welche Designprinzipien gelten. Der Agent generiert innerhalb dieser Leitplanken, statt im luftleeren Raum zu arbeiten.

In beiden Fällen ist der spezialisierte Kontext und der fokussierte Systemprompt des Sub-Agents der Hebel, nicht die allgemeine Intelligenz des Modells.

Kohärenz validieren

Ja, LLM-Output hat mich schon in die Irre geführt. Tatsächlich gerade weil er plausibel klang. Die Kohärenz war da, die Wahrheit nicht.

Meine Validierung läuft zweistufig: Ich prüfe erst einmal selbst, was ich prüfen kann. Für alles andere nutze ich spezialisierte Sub-Agents mit Internetzugriff, die Fakten verifizieren können. Aber – und das ist entscheidend – schlussendlich bleibt der Mensch verantwortlich. Die Sub-Agents sind Hilfsmittel, keine Entscheider.

Und Halluzinationen bleiben nicht gerne allein. Da, wo eine Sache nicht stimmt, sind oft andere Dinge nicht valide.

Struktur im Blick behalten

Wann wird generierter Code zum Problem? Am offensichtlichsten, wenn Source-Code-Files einfach zu groß werden. Zu viele Zeilen. Zu viel Funktionalität in einzelnen Funktionen.

Mein Ansatz: Ich lasse fast alles generieren. Wenn ich Änderungen will, lasse ich die Agent anpassen und überprüfe anschließend. Die Erfahrung zeigt, dass das schneller geht als selbst zu schreiben – es sei denn, es sind kleinere Umstrukturierungen oder Korrekturen. Da greife ich direkt ein.

Die Struktur aber bleibt meine Verantwortung. Ich entscheide, wann ein File zu groß wird, wann Funktionalität aufgeteilt werden muss, wie Refactorings aussehen sollen und die Architektur sein soll. Gerade die Architektur lege ich meist fest, bevor das Codieren beginnt, und dokumentiere sie in Markdown-Dateien.

Das eigentliche Problem ist Kommunikation

Schlussendlich muss der Mensch die Entscheidung treffen, ob das Generierte gut genug ist. Das menschliche Urteil bleibt unverzichtbar, weil nur der Mensch beurteilen kann, ob er bekommen hat, was er wollte.

Und hier liegt eine unbequeme Wahrheit: Auch mit KI ist das Problem häufig die Kommunikation. Nicht “kann die KI das?”, sondern “kann ich artikulieren, was ich will?”. Das ist keine neue Erkenntnis – jeder, der je Requirements geschrieben hat, kennt das. Aber mit Agentic Coding wird es unmittelbar spürbar.

Keine Balance, sondern ein Pendel

Gibt es eine perfekte Balance zwischen schnell ausprobieren und verstehen, was ich tue? Ich glaube nicht. Es ist eher ein Hin- und Herschwingen.

Manche Ideen probiere ich einfach aus, um zu sehen, ob sie zu einem vernünftigen Ergebnis führen. Verstehen, was ich tue, muss ich spätestens dann, wenn ich von der Richtung überzeugt bin – und prüfen will, ob sie tragfähig für die Zukunft ist.

Das ist ehrlicher als jede Best Practice. Die Praktiken entwickeln sich noch. Wer heute behauptet, den optimalen Workflow gefunden zu haben, wird in sechs Monaten anders arbeiten.

Die offene Frage

Die architektonische Kernfrage unserer Zeit bleibt: Wo platzieren wir Menschen im Entscheidungsprozess?

Das ist keine technische Frage. Es ist eine Frage der Organisation, der Verantwortung, des Designs. Jede Organisation muss sie für sich beantworten – bewusst, nicht durch Tool-Adoption implizit.

Meine Antwort, Stand heute: Der Mensch entscheidet über Struktur, validiert Ergebnisse, trägt Verantwortung. Die Agents generieren, spezialisieren, beschleunigen. Die Grenze ist nicht fix, sie verschiebt sich mit jedem Learning.

Und genau das macht diese Zeit so interessant.

Dann dreht er sich zur Kamera.

Kein Augenkontakt – nur ein schwarzes Antlitz mit ein paar blinkenden Lichtern. Keine Mimik, kein Lächeln, keine Unsicherheit. Nur Absicht.

Ich denke an C-3PO. An seine zappeligen, fast schusseligen Bewegungen, die ihn harmlos machten. An R2-D2, der piepste und gegen Wände fuhr. Figure 03 macht nichts davon. Er ist kompetent. Präzise. Und genau das, gerade das, fühlt sich falsch an.

Faszinierend. Beeindruckend. Und trotzdem irgendwie ... unheimlich. Vielleicht habe ich zu viele dystopische Filme gesehen. Oder mein Instinkt sagt mir etwas, das ich ernst nehmen sollte.

Denn Figure 03 ist nicht der erste humanoide Roboter. Aber er ist der erste, der explizit dafür gebaut wurde, in meinem Zuhause herumzulaufen. Und das macht einen Unterschied.

Der Unterschied: Verletzlichkeit

Warum fühlt sich Figure 03 anders an als all die anderen smarten Geräte, mit denen wir längst leben?

Alexa und Siri hören zu. Sie sammeln Daten, analysieren unsere Gewohnheiten, kennen unsere Stimmen. Aber sie stehen in einer Ecke. Wir wissen, wo sie sind. Wir haben gelernt, damit zu leben — oder es zu verdrängen.

Staubsauger-Roboter bewegen sich durch unsere Wohnungen, tauchen unter Sofas, kartografieren unsere Räume. Aber sie sind offensichtlich dumm. Sie sind simpel und vorhersehbar. Wenn sie gegen die Wand fahren, lachen wir. Keine Bedrohung, weil sie so eindeutig Maschine sind.

Figure 03 ist anders. Er ist autonom und entscheidet selbst, wohin er geht. Er kann eigenständig handeln: Türen öffnen, Dinge greifen, die Umgebung aktiv verändern. Und er ist allgegenwärtig. Er ist nicht nur für das Wohnzimmer gedacht, sondern für alle Räume: Küche, Schlafzimmer, Bad. Dort, wo wir am verletzlichsten sind.

Das Problem ist nicht die Technologie. Das Problem ist, dass Figure 03 in Räumen agiert, in denen wir am verletzlichsten sind: während wir schlafen, streiten, weinen, nackt durchs Bad laufen.

Wir haben keine evolutionären Instinkte dafür, wie man mit einem autonomen, beobachtenden, handlungsfähigen Ding im eigenen Schlafzimmer umgeht.

Wir haben gelernt, damit zu leben, dass Google mehr über uns weiß als unsere Mutter. Dass Social-Media-Plattformen unsere Stimmungen erkennen, bevor wir sie selbst bemerken. Aber das passiert irgendwo da draußen, in der Cloud, abstrakt.

Figure 03 ist nicht abstrakt. Er steht neben deinem Bett. Mit seinem schwarzen Antlitz. Keine Seele dahinter. Und er geht langsam, sehr langsam, zur Tür.

Das eigentlich Beunruhigende

Aber hier kommt das eigentlich Beunruhigende: In fünf, vielleicht zehn Jahren wird das alles normal sein. Figure 03, oder sein Nachfolger, wird so selbstverständlich sein wie heute ein Smartphone. Und genau das sollte uns mehr zu denken geben als die Technologie selbst.

Die Entwicklung beschleunigt sich rasant. Figure 01, 02, 03 – innerhalb kürzester Zeit. Parallel dazu die Sprünge bei Large Language Models: GPT-3, GPT-4 und -5, Claude, Gemini.

Wir haben uns so an exponentiellen Fortschritt gewöhnt, dass wir bereits enttäuscht sind, wenn die nächste Verbesserung ein paar Monate länger braucht oder nicht sofort offensichtlich ist. Die Science Fiction von vor zehn Jahren ist heute Produktankündigung. Und wir zucken kaum noch.

Vor 20 Jahren hätten wir es für absurd gehalten, dass Konzerne unsere Bewegungsprofile haben. Dass sie vorhersagen können, wann wir schwanger sind, depressiv werden oder den Job wechseln.

Heute? Achselzucken: “Was soll man machen?”

Gewöhnung ist jedoch kein neutraler Prozess. Wenn wir uns an Technologie gewöhnen, verlieren wir die Fähigkeit, die grundlegende Frage zu stellen:
„Will ich das wirklich?”

Stattdessen wird die Frage lauten: „Warum hast du noch keinen?”

In zehn Jahren wird jemand, der Figure 03 ablehnt, vielleicht klingen wie jemand, der heute „kein Internet” will – weltfremd, rückständig, irrational.

Es geht nicht nur um Technologie. Es geht um die Frage:

• Wohin wollen wir als Menschen?

• Welche Art von Zuhause wollen wir haben?

• Welche Art von Beziehungen – zu uns selbst, zu anderen Menschen, zu den Dingen, die uns umgeben?

Diese Fragen werden nicht durch Produktankündigungen beantwortet, sondern durch unsere Entscheidungen. Aber nur, wenn wir sie noch stellen, bevor sie irrelevant werden.

Der Hersteller weiß das. Figure 03 hat waschbare Kleidung, sanfte Materialien, wireless charging. Die Design-Entscheidungen sind nicht zufällig. Sie wollen, dass wir ihn als Mitbewohner und nicht als Maschine sehen. Und die Chancen dafür stehen gut, denn der Nutzen ist groß.

Die Frage bleibt

Würde ich Figure 03 in mein Zuhause lassen?

Ehrlich gesagt, weiß ich es nicht.

Die Technologie ist beeindruckend. Die Möglichkeiten sind verlockend. Vielleicht ist mein Unbehagen aber auch nur eine irrationale Reaktion auf zu viele dystopische Filme.

Aber vielleicht ist es auch das Letzte, was uns noch sagt:
„Halt. Warte. Denk nochmal nach.”

Bevor wir es normalisieren. Bevor die Frage nicht mehr lautet, ob wir es wollen, sondern warum wir es nicht haben.

Frag mich in fünf Jahren nochmal – vielleicht finde ich die Frage dann absurd. Vielleicht habe ich mich dann daran gewöhnt, in dieses schwarze Antlitz zu schauen.

Oder es ist längst ein Gesicht. Und das wäre vielleicht noch unheimlicher.

Quelle des Videos: Introducing Figure 03 https://www.figure.ai/news/introducing-figure-03

Verteilung der Arbeitszeit

• Aktives Codieren: Laut einer Analyse von Software.com verbringen Entwickler im Durchschnitt nur etwa 52 Minuten pro Tag mit aktivem Codieren, was etwa 10 % ihrer Arbeitszeit entspricht .

• Anwendungsentwicklung: Eine IDC-Studie aus dem Jahr 2024 ergab, dass Entwickler etwa 16 % ihrer Zeit mit der Entwicklung von Anwendungen verbringen. Der Großteil ihrer Zeit fließt in operative und unterstützende Aufgaben wie CI/CD-Prozesse, Sicherheitsmaßnahmen und Performance-Monitoring .

• Meetings: Eine Studie von Clockwise zeigt, dass Entwickler durchschnittlich ein Drittel ihrer Arbeitszeit in Meetings verbringen. Zusätzlich fallen etwa 6,3 Stunden pro Woche auf fragmentierte Zeit, in der keine konzentrierte Arbeit möglich ist .

• Code-Wartung: Laut einer Umfrage von Tidelift verbringen Entwickler durchschnittlich 30 % ihrer Zeit mit der Wartung von Code, einschließlich der Pflege von Open-Source-Komponenten .

Weitere Tätigkeiten

Neben dem Codieren sind Entwickler mit einer Vielzahl anderer Aufgaben beschäftigt, darunter:

• Debugging: Embedded-Entwickler verbringen etwa 40 % ihrer Zeit mit dem Debuggen von Code .

• Kommunikation: Studien zeigen, dass Entwickler mehr als 50 % ihrer Zeit mit Kommunikation verbringen, während das eigentliche Programmieren nur etwa 10 % bis 15 % ihrer Zeit ausmacht .

• Anwendungsprobleme: Eine Studie von Cisco ergab, dass Entwickler über die Hälfte ihrer Arbeitszeit (57 %) mit der Behebung von Performance-Problemen in bestehenden Anwendungen verbringen .

Fazit

Die Vorstellung, dass Entwickler den Großteil ihrer Zeit mit dem Schreiben von Code verbringen, entspricht nicht der Realität. Vielmehr sind sie in zahlreiche andere Aufgaben eingebunden, die für den Entwicklungsprozess ebenso entscheidend sind. Dies unterstreicht die Bedeutung eines ganzheitlichen Verständnisses von Entwicklerproduktivität, das über das reine Codieren hinausgeht.

Quellen:

• https://www.software.com/reports/code-time-report

• https://www.infoworld.com/article/3831759/developers-spend-most-of-their-time-not-coding-idc-report.html

• https://www.heise.de/news/Softwareentwickler-verbringen-ein-Drittel-ihrer-Arbeitszeit-in-Meetings-7236712.html

• https://www.sonarsource.com/blog/developers-spend-30-of-their-time-on-code-maintenance-our-latest-survey-results-part-3/

• https://en.wikipedia.org/wiki/Software_Peter_principle

• https://ap-verlag.de/entwickler-verbraten-ueber-die-haelfte-ihrer-arbeitszeit-fuer-das-beheben-von-anwendungsproblemen/88394/

Wenn du Verantwortung trägst – als Führungskraft, Designer:in, Produktmensch oder Engineer – und wissen willst, wo es bei euch wirklich klemmt, dann lade ich dich ein:

Mach statt Retro mal ein Value Stream Mapping.

PS: Vielleicht fragt sich jetzt der eine oder andere: "Aber wie genau funktioniert dieses Value Stream Mapping bei Software-Teams?"

Im Kern geht es darum, den kompletten Weg einer Anforderung - vom ersten Gedanken bis zur Nutzung durch den Kunden - zu visualisieren.

Das Besondere: Wir messen nicht nur die aktive Arbeitszeit, sondern auch die Wartezeit zwischen den Schritten.

Bei einem Team zeigte sich: Von 21 Tagen Durchlaufzeit waren nur 3 Tage tatsächliche Arbeitszeit. Der Rest? Warten und Blockaden.

Diese Transparenz verändert vieles.

In diesem 15-minütigen Deep Dive1 geht es darum,

1. welche Probleme die Produktivität in der Softwareentwicklung ausbremsen und

2. was Sie dagegen tun können.

Der Dialog zeigt auf, welche konkreten Schritte Sie unternehmen können, um Herausforderungen wie diesen zu begegnen:

1. Kommunikation & Zusammenarbeit: warum selbst erfahrene Teams in Silos arbeiten

• Silo-Denken zwischen Entwicklung und Operations

• Teams arbeiten in "getrennten Welten"

• Mangelnde Kommunikation führt zu Missverständnissen

• Konflikte zwischen Teams

2. Kultur & Mindset: wie eine Kultur der Schuldzuweisung echtes Lernen und ‘Continuous Improvement’ verhindert und

• Angst vor Fehlern

• Kultur der Schuldzuweisung statt Lernkultur

• Widerstände gegen Veränderungen

• Klammern an alten Gewohnheiten

3. Führung & Kontrolle: warum zu viel Kontrolle die Leistung senkt

• Angst der Führungskräfte vor Kontrollverlust

• Zu viele detaillierte Anweisungen von oben

• Mangelnde Autonomie der Teams

• Fehlendes Vertrauen in Team-Fähigkeiten

4. Performance & Effizienz:

• Langsame Release-Zyklen

• Verzögerungen in der Entwicklung

• Qualitätsprobleme in der Software

• Leistung bleibt hinter Erwartungen zurück

Hören Sie, wie DevOps Coaching diese Herausforderungen angeht - als nachhaltiger Weg zu besserer Zusammenarbeit und besseren Ergebnissen.

Für alle, die verstehen wollen, warum es nichts bringt, einfach nur neue Tools einzuführen, um eine bessere Teamleistung zu erreichen.

A distinction is often not made in everyday language:

This is a complex problem.

It's a complicated system.

Some people use complex as the intensified form of complicated. A complex problem would then be a more complicated problem.

A fundamental difference

The difference between a complex system and a complicated system is of a fundamental nature.

It is not a quantitative difference, but a qualitative one. This is because they behave differently. The complicated system is predictable, the complex system is unpredictable and reacts unexpectedly to changes.

What is complicated?

Complicated is a system that is difficult to get an overview of. Nevertheless, the complicated system can be understood by analyzing the individual parts.

For example, a mixing console is not immediately obvious to the layman. But with the help of a specialist or an instruction manual, you can learn to understand the functions.

Photo by chuttersnap

Complicated therefore has something to do with not knowing and a lack of comprehensibility.

Complexity is the measure of our ignorance. A problem (or: "unignorable event") is complicated because we do not understand it. Because we lack knowledge. This can be remedied by cramming or acquiring knowledge.

Roberto Poli writes:

„Complicated problems originate from causes that can be individually distinguished; they can be addressed piece­-by-­piece; for each input to the system there is a proportionate output; the relevant systems can be controlled and the problems they present admit permanent solutions.“

Solutions can be found for complicated systems that will work again and again and deliver the same effect. The solutions are reproducible.

Teilen

Complex

Complexity means unpredictability. Complexity is the measure of the number of surprises you have to reckon with.

There is no simple cause-and-effect relationship. The influencing factors can influence or even reverse each other through interactions and feedback effects.

Complex means:

Outputs are not proportional or linear to inputs; small changes in one part of the system can cause unexpected outputs in other parts of the system or a system-wide reorganization.

Photo by H Shaw

Complex systems such as organizations can behave completely differently despite the same measures. The same solution that worked for one system may fail completely elsewhere. Solutions are not transferable.

Complexity is like the weather. There is nothing wrong with it. It's just bad not to be prepared for it. — »Komplexithoden«

Examples for complex systems:

• the earth's global climate

• social and economic organizations (such as companies and cities)

• Ecosystems

Roberto Poli adds:

„Complex problems and systems result from networks of multiple interacting causes that cannot be individually distinguished; must be addressed as entire systems, that is they cannot be addressed in a piecemeal way; they are such that small inputs may result in disproportionate effects; the problems they present cannot be solved once and for ever, but require to be systematically managed and typically any intervention merges into new problems as a result of the interventions dealing with them.“

Surprisingly, most systems are complex in nature. Only complicated systems are the exception.

Various solution approaches

The solution to a complex problem cannot be approached in the same way as the solution to a complicated problem. They require different solution strategies.

Complicated systems can be analyzed and predictions can be made about the behavior of the system. Experts can help with this. Solutions can be reused.

Complex systems, on the other hand, defy an understanding of the overall relationships, as the factors influence each other.

„The distinction between complicated and complex systems is of immense importance, yet it is often overlooked. Decision-makers commonly mistake complex systems for simply complicated ones and look for solutions without realizing that ‘learning to dance’ with a complex system is definitely different from ‘solving’ the problems arising from it.“

If you handle complex things as if they were complicated, you are doomed to failure.

Complexity means that there can be a certain degree of control; but it is not complete control, the situation is not fully controllable. By recognizing patterns, some relationships can be understood.

In a complex environment, you cannot expect a comprehensive plan or strategy to work as intended. An approach of trying, learning and adapting is more likely to get you further. Mistakes can be made and risks can be taken.

However, you shouldn't make big bets on large projects or invest too much in comprehensive plans, but instead constantly learn in small steps and make appropriate adjustments.

Jetzt abonnieren

— Martin Gross

Ich habe es definitiv.

Doch die Animation von Beau Janzen zeigt, dass es tatsächlich geht und ist beeindruckend. Ich konnte mir vorher nicht vorstellen, wie das gehen könnte.

Aber schaut erst einmal selbst:

@reason4mathDrilling a triangular hole. Yes, I know there logistical issues is making this work, but this is intended as a fun geometric breakdown. I’m creating all this work on my own, so if you like my content and would like to see more, I’d appreciate your support. In my bio, you can leave a tip in my Linktree. Thanks! #drill #triangle #hole #geometry #geometryart #math #maths #engineering #satisfying #satisfyingvideo #originalanimation #mathtok #stemtok

Tiktok failed to load.

Enable 3rd party cookies or use another browser

Um besser zu verstehen, warum diese Animation — neben der Tatsache, dass sie das Bohren eines dreieckigen Lochs zeigt — so faszinierend ist, habe ich sie mir mehrfach angeschaut.

3 Dinge wurden mir erneut bewusst.
3 Dinge, die ich in Zukunft mehr in meine Tätigkeit integrieren möchte:

1. Wir beschränken unser Denken auf das Vertraute, das wir kennen und täglich sehen. Bis uns jemand etwas unvorhergesehenes Neues zeigt. Und dass das, was wir für unmöglich hielten, doch möglich ist.

2. Gute Visualisierungen sind ein hervorragendes Mittel, um neue Problemlösungsansätze für jedermann verständlich zu machen.

3. Anstatt nur die endgültige Lösung zu präsentieren, ist es viel besser, die Menschen von der Machbarkeit einer Lösung zu überzeugen, indem man ihnen den Denkprozess zeigt, der zu dieser Lösung führt.

Lasst euch inspirieren:
Welche 'unmöglichen' Probleme begegnen euch in eurem Alltag oder Beruf?

Wie wäre es, wenn ihr euch heute die Zeit nehmt, eines davon aus einer völlig neuen Perspektive zu betrachten. Zeichnet es auf, diskutiert es mit anderen oder sucht nach unkonventionellen Lösungsansätzen im Internet.

Vielleicht findet ihr euer eigenes 'dreieckiges Loch' und beweist, dass das, was unmöglich erschien doch möglich ist.

Teilt gerne eure Erkenntnisse in den Kommentaren und inspiriert uns, über den Tellerrand zu schauen.

Denn manchmal ist die kreativste Lösung nur einen ungewöhnlichen Ansatz entfernt.

Einen Kommentar hinterlassen