Claude Code: Der Framework-Krieg

 (shmck.substack.com)
40 Punkte von GN⁺ 2025-09-08 | 1 Kommentare | Auf WhatsApp teilen
  • Entwickler befinden sich nun in einer Phase, in der sie die Zusammenarbeit mit KI erst lernen, und Claude entfaltet seinen Wert nicht als bloßer Chatbot, sondern dann am stärksten, wenn es als Framework genutzt wird
  • In der Community laufen verschiedenste Versuche dazu, wie man Claude aufbauen und einsetzen kann; die Experimente sind so rege, dass man bereits von den Claude Code Framework Wars spricht
  • Dadurch entsteht ein Trend, Claude in mehreren Rollen einzusetzen, etwa als Projektmanager, Architekt, Entwickler und Reviewer
  • Beim Entwurf eines Frameworks sind 8 zentrale Entscheidungen nötig, darunter Aufgabenverwaltung, Vorgaben, Agenten-Zusammenarbeit, Sitzungsbetrieb, Tool-Zugriff, Code-Entwicklung, Auslieferung und Kontexterhalt
  • Die wichtigste Lehre ist, dass KI Entwickler nicht ersetzt, sondern sich als Kollege etabliert, der mit strukturierten Regeln und Rollen die Produktivität vervielfacht

Einleitung

  • Kernidee: Claude nicht als simples Dialogwerkzeug, sondern als Framework verstehen, das durch klare Regeln und Workflows vorhersehbare und wertvolle Ergebnisse erzeugt
    • Entwickler verlagern sich vom eigentlichen Coden hin zu höherwertigen Rollen wie Projektmanagement, Design und Architektur
    • Claude-Code-Frameworks funktionieren ohne Code zu schreiben über strukturierte Prompts
  • Claude Code Framework Wars: Die Entwickler-Community experimentiert mit unterschiedlichen Ansätzen für einen produktiven KI-Einsatz
    • Dutzende Open-Source-Projekte konkurrieren darum, Workflows und Rollenstrukturen zu definieren
    • Beispiele: Agent OS, Claude-Flow

Wichtige Entscheidungen beim Framework-Design

1. Wo Aufgaben verwaltet werden

  • Es muss eine Aufgabenquelle definiert werden, auf die Claude zugreifen kann
    • Markdown-Backlog: Aufgaben werden als Todo-Liste im Markdown-Format verwaltet
    • Strukturierter Text: Produktspezifikationen werden in Aufgaben umgewandelt
    • Issues/Tickets: Spezifikationen werden in GitHub Issues oder Jira-Tickets gespeichert und mit Code-Reviews verknüpft
  • Kernpunkt: Aufgaben müssen an einem Ort gespeichert sein, der für Claude zugänglich und nachverfolgbar ist

2. Wie Claude angeleitet wird

  • Claude sollte nicht mit vagen Prompts, sondern mit einer klaren Struktur angeleitet werden
    • Befehlsbibliothek: vordefinierte Slash-Befehle wie /create-tasks oder /review
    • Coding-Standards: Technologie-Stack und Coding-Richtlinien werden festgelegt
    • Definition of Done: Kriterien für den Abschluss einer Aufgabe werden kodifiziert
    • Auslöser für Validierungs-Hooks: Linting und Tests werden für jede Änderung erzwungen
    • Claude als Reviewer: Claude übernimmt gleichzeitig Entwicklung und Review
  • Kernpunkt: Klare und wiederholbare Regeln verbessern die Arbeitsqualität von Claude

3. Struktur der Agenten-Zusammenarbeit

  • Beim Einsatz mehrerer Claude-Agenten erfolgt die Koordination über Rollen und Planung
    • Rollensimulation: Die KI übernimmt Rollen wie PM, Architekt, Entwickler und Tester
    • Parallele Schwarmverarbeitung: Mehrere Agenten laufen gleichzeitig in einem strukturierten Ablauf von Spezifikation → Pseudocode → Code → Test
    • Repository-native Artefakte: Aufgaben, Logs und Entscheidungsaufzeichnungen (ADR) werden im Codebestand gespeichert, damit das Gedächtnis erhalten bleibt
  • Kernpunkt: Koordination verhindert Konflikte zwischen mehreren KI-Arbeitern

4. Wie Sitzungen betrieben werden

  • Um Chaos in den KI-Ausgaben zu vermeiden, werden Sitzungen als Arbeitsumgebung eingerichtet
    • Terminal-Orchestrierung: Claude steuert Befehle, Fenster und Logs
    • Parallele Worktrees: Mehrere Branches laufen parallel mit Git Worktrees
    • Parallele Container: Claude läuft in isolierten Containern, um Konflikte zu vermeiden
  • Kernpunkt: Parallele Arbeit maximiert die Produktivität ohne Konflikte

4. Wie Sitzungen ausgeführt werden

  • Um Chaos in den KI-Ausgaben zu vermeiden, werden Sitzungen als Arbeitsumgebung eingerichtet
    • Terminal-Orchestrierung: Claude steuert Befehle, Fenster und Logs
    • Parallele Worktrees: Mehrere Branches laufen parallel mit Git Worktrees
    • Parallele Container: Claude läuft in isolierten Containern, um Konflikte zu vermeiden
  • Kernpunkt: Parallele Arbeit maximiert die Produktivität ohne Konflikte

5. Claudes Tool-Zugriff

  • Claude sollte so eingerichtet werden, dass es sein Wissen über den gesamten Technologie-Stack nutzen kann
    • MCP-Integration: Verbindung zu Browsern, Datenbanken, Test-Runnern und UI-Automation-Frameworks
    • Benutzerdefinierte Tool-Bibliothek: aufgebaut mit Shell-Skripten und Befehlen
    • Datenbankzugriff: leistungsstarke Werkzeuge für den Datenbankzugriff
    • Test- und Validierungs-Hooks: Tests mit Vitest, Jest usw. vor Abschluss der Aufgabe ausführen
  • Kernpunkt: Tool-Integration macht Claude aus einer bloßen Autovervollständigung ein aktives Teammitglied

6. Wie Code entwickelt wird

  • Claude übernimmt je nach Bedarf verschiedene Rollen
    • Projektmanager (PM): wandelt Produktspezifikationen in Aufgaben und Backlogs um
    • Architekt: entwirft die Gesamtstruktur, definiert Schnittstellen und legt Regeln vor dem Coden fest
    • Implementierer: schreibt Code gemäß Tests und Standards
    • QA: prüft Probleme in Aufgaben
    • Reviewer: auditiert PR-Qualität, Lesbarkeit und Risiken
  • Kernpunkt: KI wird über den gesamten Software-Lebenszyklus hinweg eingesetzt

7. Wie Code ausgeliefert wird

  • Es muss definiert werden, wie der Code ins Repository gelangt
    • Kleine Diffs: Die KI bearbeitet Tickets und erzeugt kleine PRs, immer mit Review
    • Experimente: Änderungen werden hinter Feature-Flags ausgerollt
    • Vollständiges App-Scaffolding: Eine komplette App wird aus hochrangigen Prompts erstellt und ausgerollt
  • Kernpunkt: Entweder sichere Iterationen für die Produktion oder Scaffolding für Prototypen wählen

8. Wie Kontext erhalten bleibt

  • Claudes Vergesslichkeit wird durch ein Framework-Gedächtnis adressiert
    • Dokumente und Journale: CLAUDE.md, Architekturmemos und Projektjournale werden aktuell gehalten
    • Persistentes Gedächtnis und Checks: Zusammenfassungen der letzten Arbeit, Projekt-Health-Checks und gespeicherte Entscheidungen
  • Kernpunkt: Ohne Gedächtnis wiederholt die KI Fehler, mit Gedächtnis wird Fortschritt kumulativ

Integrationsansätze

  • Die Optionen sollten als Menü betrachtet werden; nicht alles muss auf einmal eingerichtet werden
    • Einsteiger-Setup: Markdown-Backlog + Ticket-Diffs
    • Strukturiertes Team: Produktspezifikation + Standards + Rollensimulation
    • Experimentfokus: Repository-Artefakte + parallele Sitzungen
    • Prototyping-Modus: App-Builder + Dokument-Scaffolding

Fazit und Implikationen

  • Wichtigste Lehre: Claude liefert in einer strukturierten Umgebung die besten Ergebnisse
    • Es ersetzt nicht die Rolle von Entwicklern, sondern reduziert Boilerplate-Arbeit, sodass mehr Fokus auf Spezifikationsdefinition, Design-Review und Architektur möglich wird
    • Wenn Aufgaben falsch laufen, kann es schnell entgleisen; strukturelles Management ist essenziell
  • Die Entwicklung steckt noch in einem frühen Stadium, doch Frameworks lassen KI nicht als magische Blackbox, sondern als Sammlung steuerbarer Teammitglieder erscheinen
    • Je mehr Struktur bereitgestellt wird, desto größer ist der zurückgegebene Wert
  • Über Open-Source-Projekte experimentiert die Community mit verschiedenen Frameworks und sucht nach produktiven Wegen für den KI-Einsatz
  • Entwickler können Claude systematisch einsetzen, sich auf höherwertige Aufgaben konzentrieren und KI als Teammitglied integrieren, um die Produktivität zu maximieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-08
Hacker-News-Kommentare

  • Ich habe mehrere „Frameworks“ für Claude Code ausprobiert, bin mir aber nicht sicher, ob sich die Leistung objektiv verbessert hat.
    Es wirkt eher wie ein Ritual rund um einen unnötig komplexen Prozess, und ich frage mich, woran das eigentlich liegt.
    Ich habe das Gefühl, dass diese Framework-Ansätze nicht zu dem passen, wofür die Modelle trainiert wurden.
    Im Ergebnis wirft man dem Modell unnötige Informationen hin und verschmutzt den Kontext gewaltsam, damit er zu „dem von mir festgelegten Prozess“ passt.
    Wichtig ist aus meiner Sicht, Kontextverschmutzung zu vermeiden, nur die für die eigentliche Aufgabe nötigen Informationen bereitzustellen und sich dann schrittweise zu verbessern.
    Diese traditionelle Art der Zusammenarbeit passt strukturell besser, wenn sie außerhalb des Kontexts eines Agents mit begrenztem Kontextfenster stattfindet.

    • In diesem Beitrag werden subagents überhaupt nicht erwähnt, daher frage ich mich, wann er geschrieben wurde.
      Ich delegiere Dinge wie „nur die für die aktuelle Aufgabe relevanten Informationen aus der Memory Bank holen“ oder „Tests laufen lassen und nur Fehlschläge sowie Coverage zurückmelden“ an subagents.
      So konnte ich verhindern, dass der Kontext des Haupt-Agents zu schnell voll wird.
      https://docs.anthropic.com/en/docs/claude-code/sub-agents

    • Seit ich einige praktische Vorgehensweisen wie dev containers und worktrees eingeführt habe, ist mein Leben deutlich einfacher geworden.
      Ich habe mir sogar selbst ein kleines Shell-Script-„Framework“ für die Verwaltung von Projektdateien und das Erstellen von worktrees gebaut, und das war in ungefähr zwei Tagen erledigt.
      Es fühlt sich gut an, nicht an ein bestimmtes Tool gebunden zu sein.
      Ich stimme zu, dass Kontextverschmutzung ein reales Problem ist, um das man sich kümmern muss.
      Besonders nachdem ich erlebt habe, dass MCP-Endpunktdefinitionen einen erheblichen Teil meines Kontexts belegen (etwa 20.000 Token), berücksichtige ich bei der Auswahl von MCPs unbedingt auch Kontextfragen.

    • Das fühlte sich einer echten Projektmanager-Situation sehr ähnlich an.

  • Was ich mir wünsche, ist, dass die Erstellung eines Plans mit Claude einen Schritt enthält, in dem zuerst unklare Punkte nachgefragt werden.
    Wenn man einem echten Engineer nur Anforderungen und das erwartete Ergebnis gibt, wird er vor der Umsetzung selbstverständlich Rückfragen stellen, um die Dinge sauber abzugleichen.
    Ich hoffe, dass Claude diesen Abstimmungsprozess ebenfalls automatisieren kann.

    • Es erinnert an OpenAIs deep research tool.
      Ich erlebe oft, dass viele Fehler entstehen, weil unklare Fragestellungen überhaupt nicht berücksichtigt werden.

  • Mich würde interessieren, wie viel Autonomie man bei der Anwendung solcher Frameworks tatsächlich gibt und in welcher Umgebung (greenfield/brownfield) sie eingesetzt werden.
    Ich würde auch gern wissen, ob jemand Claude Code schon in Enterprise-Software eingebunden und damit selbstbewusst Ergebnisse erzielt hat.
    In meinem Unternehmen habe ich relativ freien Zugang zu Claude Code, aber in meiner eigenen Codebasis werden die Ergebnisse wechselhaft, sobald Frontend-UI oder Playwright ins Spiel kommen.
    Mich interessieren praktische Erfahrungen: Wie viel Code-Müll bleibt zurück, wie anstrengend ist die Zusammenarbeit mit Kolleg:innen, wie groß werden die Pull Requests, wie hoch sind die Inferenzkosten und wie verwaltet man das Ganze bei Parallelisierung?
    README-Dokumente wirken oft wie Werbematerial, voll mit systemspezifischer Terminologie, Emojis und übermäßig personalisierten Methoden zur Organisation des eigenen Toolkastens.
    Am Ende werden Anthropic und andere solche Funktionen vermutlich ohnehin in ihre eigene CLI integrieren.
    Ich persönlich lasse ein Reasoning-Modell ein zehnseitiges Spec, strikte lint/type check/formatter/hook-Regeln, eine Aufgaben-Checkliste und sogar red/green TDD abarbeiten, und mit einem einzigen „go“ an GPT-5 werden die nötigen Ergebnisse automatisch erstellt.
    Mit denselben Werkzeugen kann sich letztlich jede Person ihr eigenes System leicht bauen.

    • Ich nutze Claude Code selbst erst seit etwa drei Wochen, habe aber in letzter Zeit in einer großen Elixir/Phoenix-Codebasis mit mehr als 500.000 SLOC beeindruckende Ergebnisse mit einer rollenbasierten Struktur erlebt, die sich an Rollen wie z. B. persona orientiert.
      Ich nutze den 200-Dollar-Max-Plan, daher sind auch die Inferenzkosten fix.
      Vor allem bei greenfield-Situationen wie dem Hinzufügen neuer Funktionen waren die Ergebnisse deutlich sichtbar.
      Bei komplexen Refactorings oder tiefgreifenden Systemänderungen kommt man ebenfalls recht gut voran, sofern gute Designdokumente vorhanden sind, aber in schlecht dokumentierten Bereichen funktioniert es nicht besonders gut.
      Anfangs entstand oft „nicht besonders guter Code“ – Implementierungen mit schwachem Stil oder geringer Wiederverwendbarkeit und Wartbarkeit –, aber nachdem wir die Datei CLAUDE.md ausgebaut und dafür gesorgt haben, dass die Entwickler-persona immer den subagent elixir-code-reviewer verwendet, hat sich die Codequalität spürbar verbessert.
      Unsere Plattform ist Open Source, daher teilen wir unsere aktuelle Konfiguration für Claude-Befehle und subagents hier:
      https://github.com/Simon-Initiative/oli-torus/tree/master/.claude

  • Im Blog war der typische Stil von LLMs deutlich zu spüren.
    Die Informationen sind nützlich, aber es ist interessant, von einer KI über KI zu lernen.

    • So fühlen sich derzeit viele Texte über KI an.
      Tatsächlich muss man Claude Code bei allem, was nicht trivial ist, direkt überwachen und sofort eingreifen, wenn es in die falsche Richtung läuft.
      Aus Sicherheitsgründen darf man ihm nicht zu viele Rechte geben, und man muss prüfen, welche Befehle tatsächlich ausgeführt werden.
      Die heutigen „Frameworks“ haben noch einen langen Weg vor sich; realistischer ist es derzeit, sie als „Junior-Praktikant mit enorm hoher Code-Ausgabegeschwindigkeit“ zu betrachten.

    • Vielleicht hat der Autor das Repo nicht ordentlich geprüft, oder das Ergebnis beruht tatsächlich nur auf begrenzter Recherche.
      Zum Beispiel ist superClaude kein MCP-Server, und metaGPT scheint nicht mit Claude Code kompatibel zu sein.

  • Ich habe mich immer gefragt, warum man Agents – wie Menschen – ihren Kontext nicht selbst verwalten lässt.
    Ich verstehe nicht, warum immer der komplette Verlauf aller vorherigen Arbeiten jedes Mal vollständig mitgegeben wird.
    Wenn man den Agent entscheiden ließe, welcher Kontext erhalten bleiben sollte, und ihn die Vor- und Nachteile des Kontextmanagements selbst lernen ließe, könnte seine Fähigkeit zur Aufgabenerfüllung vermutlich besser werden.

  • Am Ende scheint sich auch hier wieder die textbook-„bitter lesson“ zu wiederholen.
    Die Leute bauen alle möglichen „Frameworks“, aber die nächste Modellgeneration macht sie dann sämtlich überflüssig.
    http://www.incompleteideas.net/IncIdeas/BitterLesson.html

  • Ich war ziemlich überrascht, dass BMAD-method nicht erwähnt wurde.
    Meiner Erfahrung nach ist BMAD-method die beste Ergänzung für Claude Code.

    • Mich würde interessieren, was BMAD-method eigentlich ist.
      Ist das einfach nur eine Art System Prompt, oder was genau macht es so nützlich?
      https://github.com/bmad-code-org/BMAD-METHOD

    • Das BMAD-System sieht dem im Beitrag vorgestellten AgentOS ähnlich.
      Diese Art von Context Engineering hat bei mir gut funktioniert, und ich habe Claude selbst die Commands und Agents erzeugen lassen und sie dann an meine Bedürfnisse angepasst.
      In letzter Zeit nutze ich auch aktiv JSON und Markdown, um Kontext zu teilen.

    • taskmaster gilt wohl genauso, fehlt aber in der Liste.

  • Context-Management fühlt sich für mich fast wie Low-Level-Programmierung an.
    Ich denke dabei an die Notwendigkeit, für die richtigen Operationen exakt die richtigen Werte in CPU-Registern zu haben.
    Der Unterschied ist, dass wir viel weniger Kontrolle darüber haben, welchen Kontext wir für jede Aufgabe hinzufügen oder entfernen dürfen.

  • Ich habe das B-MAD Framework ausprobiert, und der Unterschied in der Wirkung war so groß, dass ich inzwischen ohne dieses Tool nicht mehr arbeiten kann.
    Ich hoffe, dass es in Zukunft noch mehr solcher Frameworks geben wird.

  • Mich würde interessieren, ob jemand solche Frameworks tatsächlich produktiv verwendet hat.
    Bringen sie in der Praxis wirklich Ergebnisse, oder ist das nur mitlaufender Hype?

    • Wenn man sich solche Frameworks gelegentlich genauer ansieht, sind die meisten im Grunde nur aus sich selbst heraus aufgebaut.
      Die Ergebnisse sind entsprechend vorhersehbar: eine Flut an Funktionen ohne jede Validierung, kaum brauchbare Dokumentation und alles voller Claude-isms.
      In der Praxis reicht das meist nur für ein paar wenige Projekte, für die sich die Ersteller ohnehin interessieren.