Wie Claude Code in großen Codebasen funktioniert: Best Practices und Einstiegspunkte

• Claude Code liest Live-Codebasen direkt auf dem Rechner des Entwicklers über Dateisystem-Navigation sowie grep und Referenzverfolgung, ohne einen Index hochzuladen
• Die Leistung hängt nicht nur vom Modell ab, sondern stark vom Harness, das aus CLAUDE.md, Hooks, Skills, Plugins und MCP-Servern besteht, sowie von der Reihenfolge des Aufbaus
• In großen Repositories erhöhen ein schlankes, hierarchisches CLAUDE.md, der Start in Unterverzeichnissen, bereichsbezogene Tests und Lints sowie Ausschlussregeln die Effizienz der Navigation
• Die LSP-Integration bietet definitions- und referenzbasierte Verfolgung auf Symbolbasis statt Stringsuche und reduziert so Fehl-Navigation in mehrsprachigen und großen Codebasen
• Für eine erfolgreiche Einführung braucht es alle 3 bis 6 Monate eine Überprüfung der Konfiguration sowie einen DRI oder Agent Manager, der Plugins, Berechtigungen und Regeln verwaltet

---

Wie Claude Code in großen Codebasen navigiert

• Claude Code bewegt sich wie ein Software Engineer durch das Dateisystem, liest Dateien, findet mit grep die nötigen Inhalte und folgt Referenzen durch die gesamte Codebasis
• Es läuft lokal auf dem Rechner des Entwicklers; ein Index der Codebasis muss weder aufgebaut noch gepflegt oder auf einen Server hochgeladen werden
• RAG-basierte AI-Coding-Tools betten die gesamte Codebasis ein und holen zum Zeitpunkt der Abfrage relevante Chunks, doch in großen Umgebungen kann die Embedding-Pipeline mit der hohen Entwicklungsgeschwindigkeit nicht Schritt halten
• Wenn ein Index den Stand von vor Wochen, Tagen oder Stunden widerspiegelt, kann er Funktionen zurückgeben, die bereits umbenannt wurden, oder Module, die im letzten Sprint gelöscht wurden, ohne dass ein Signal vorliegt, dass diese Information veraltet ist
• Die agentische Suche von Claude Code ermöglicht es jeder Entwicklerinstanz, auf Basis der lebenden Codebasis zu arbeiten, ohne Embedding-Pipeline oder zentralen Index
• Es gibt auch einen Nachteil: Claude arbeitet am besten, wenn es genug Startkontext gibt, um zu wissen, wo es suchen soll
• Wenn man verlangt, alle Instanzen eines mehrdeutigen Musters in einer Codebasis mit einer Milliarde Zeilen zu finden, kann man schon vor dem eigentlichen Start an die Grenzen des Kontextfensters stoßen
• Teams erzielen bessere Ergebnisse, wenn sie die Codebasis gut vorbereiten und Kontext mithilfe von CLAUDE.md-Dateien und Skills hierarchisch strukturieren

Das Harness ist so wichtig wie das Modell

• Die Leistung von Claude Code wird stark durch das Harness beeinflusst, das um das Modell herum aufgebaut wird, oft stärker als durch das Modell selbst
• Das Harness besteht aus fünf Erweiterungspunkten: CLAUDE.md, Hooks, Skills, Plugins und MCP-Servern
• Da jede Ebene auf der vorherigen aufbaut, ist auch die Reihenfolge wichtig, in der ein Team sie einführt
• LSP-Integration und Subagents wirken als zusätzliche Fähigkeiten, die dieses Setup ergänzen

• CLAUDE.md-Dateien

  • CLAUDE.md ist eine Kontextdatei, die Claude zu Beginn jeder Sitzung automatisch liest
  • Die Root-Datei enthält das große Ganze, Dateien in Unterverzeichnissen enthalten lokale Regeln
  • Da sie in jede Sitzung geladen wird, sollte sie sich auf breit anwendbare Inhalte konzentrieren, um Leistungseinbußen zu vermeiden

• Hooks

  • Hooks sind nicht nur Skripte, die Fehlverhalten von Claude verhindern; ihr größerer Wert liegt darin, die Konfiguration kontinuierlich zu verbessern
  • Ein Stop-Hook kann reflektieren, was während einer Sitzung passiert ist, und Aktualisierungen an CLAUDE.md vorschlagen, solange der Kontext noch frisch ist
  • Ein Start-Hook kann teamspezifischen Kontext dynamisch laden, sodass Entwickler ohne manuelle Einrichtung die passende Konfiguration für ihr Modul erhalten
  • Automatische Prüfungen wie Linting und Formatting liefern konsistentere Ergebnisse, wenn Hooks die Regeln deterministisch durchsetzen, statt darauf zu setzen, dass Claude sich an Anweisungen erinnert

• Skills

  • Skills ermöglichen es, benötigte Expertise on demand bereitzuhalten, ohne jede Sitzung aufzublähen
  • In großen Codebasen kann es Dutzende Aufgabentypen geben, doch nicht jede Expertise muss in jeder Sitzung vorhanden sein
  • Über progressive disclosure halten Skills spezialisierte Workflows und Domänenwissen außerhalb des Kontextfensters und laden sie nur bei Bedarf
  • So wird etwa ein Security-Review-Skill geladen, wenn Claude Schwachstellen bewertet, und ein Dokumentations-Skill, wenn nach Codeänderungen die Dokumentation aktualisiert werden muss
  • Skills können auf bestimmte Pfade begrenzt werden, sodass der Deployment-Skill eines Payment-Service-Teams nur an dieses Verzeichnis gebunden ist und bei Arbeit in anderen Bereichen des Monorepos nicht automatisch geladen wird

• Plugins

  • Plugins sind ein Weg, funktionierende Konfigurationen zu verteilen, damit sie nicht als stilles Wissen verloren gehen
  • Ein Plugin bündelt Skills, Hooks und MCP-Konfigurationen in einem installierbaren Paket
  • Installiert ein neuer Engineer am ersten Tag das Plugin, erhält er sofort denselben Kontext und dieselben Fähigkeiten wie Personen, die Claude bereits nutzen
  • Plugin-Updates können über managed marketplaces organisationsweit ausgerollt werden
  • Eine große Einzelhandelsorganisation entwickelte einen Skill, der Claude mit ihrer internen Analyseplattform verbindet, damit Business-Analysten Leistungsdaten abrufen können, ohne ihren Workflow zu verlassen, und verteilte ihn vor dem breiten Rollout im Unternehmen als Plugin

• Language Server Protocol-Integration

  • Die Integration des Language Server Protocol (LSP) gibt Claude Code-Navigationsfähigkeiten wie in der IDE des Entwicklers
  • Die meisten IDEs für große Codebasen führen bereits LSP aus, das „go to definition“ und „find all references“ antreibt
  • Wenn Claude darauf zugreifen kann, kann es Funktionsaufrufen bis zur Definition folgen, Referenzen über Dateien hinweg verfolgen und gleichnamige Funktionen in unterschiedlichen Sprachen mit Präzision auf Symbolebene unterscheiden
  • Ohne LSP ist Claude auf textbasiertes Pattern Matching angewiesen und kann beim falschen Symbol landen
  • Ein Enterprise-Software-Unternehmen rollte die LSP-Integration organisationsweit aus, noch bevor Claude Code eingeführt wurde, um die Navigation in C- und C++-Code in großem Maßstab zu stabilisieren
  • Für mehrsprachige Codebasen ist dies eine der wertvollsten Investitionen

• MCP-Server

  • MCP-Server sind die Art, wie Claude mit internen Tools, Datenquellen und APIs verbunden wird, die es nicht direkt erreichen kann
  • Die reifsten Teams bauen MCP-Server, die strukturierte Suche als Werkzeuge bereitstellen, die Claude direkt aufrufen kann
  • Andere Teams verbinden Claude mit interner Dokumentation, Ticket-Systemen und Analyseplattformen

• Subagents

  • Subagents trennen Navigation und Bearbeitung
  • Ein Subagent ist eine isolierte Claude-Instanz mit eigenem Kontextfenster, die eine Aufgabe übernimmt, ausführt und nur das Endergebnis an das übergeordnete System zurückgibt
  • Nachdem das Harness etabliert war, starteten einige Teams schreibgeschützte Subagents, um Subsysteme zu kartieren und die Ergebnisse in Dateien zu schreiben, damit der Hauptagent anschließend auf Basis des Gesamtbilds Änderungen vornehmen konnte

• Rolle der einzelnen Komponenten und typische Verwechslungen

  • CLAUDE.md: eine Kontextdatei, die Claude automatisch liest und die in jede Sitzung geladen wird. Geeignet für projektspezifische Regeln und Wissen über die Codebasis; leicht kann dort wiederverwendbare Expertise landen, die eigentlich in einen Skill gehört
  • Hooks: Skripte, die an zentralen Zeitpunkten laufen und durch Events ausgelöst werden. Geeignet für die Automatisierung konsistenten Verhaltens und das Erfassen von Lerneffekten aus Sitzungen; leicht behandelt man per Prompt Dinge, die automatisch laufen sollten
  • Skills: paketierte Anweisungen für bestimmte Aufgabentypen, die on demand geladen werden, wenn sie relevant sind. Geeignet für Expertise, die über Sitzungen und Projekte hinweg wiederverwendet wird; leicht landet alles in CLAUDE.md
  • Plugins: Bundles aus Skills, Hooks und MCP-Konfigurationen, die nach der Einrichtung immer verfügbar sind. Geeignet, um funktionierende Setups organisationsweit auszurollen; leicht bleiben gute Konfigurationen stilles Wissen
  • LSP: Code Intelligence in Echtzeit über sprachspezifische Server, die nach der Einrichtung immer verfügbar ist. Geeignet für Navigation auf Symbolebene in typisierten Sprachen und automatische Fehlererkennung; leicht nimmt man an, dass es ohnehin automatisch funktioniert
  • MCP-Server: Verbindungen zu externen Tools und Daten, die nach der Einrichtung immer verfügbar sind. Geeignet für den Zugriff auf interne Werkzeuge, auf die Claude nicht direkt zugreifen kann; leicht baut man zuerst MCP-Verbindungen, bevor die Grundlagen funktionieren
  • Subagents: separate Claude-Instanzen für bestimmte Aufgaben, die bei Aufruf ausgeführt werden. Geeignet für die Trennung von Navigation und Bearbeitung sowie parallele Arbeit; leicht erledigt man Navigation und Bearbeitung in derselben Sitzung
  • Auf LSP wird über die Plugin-Ebene zugegriffen, und Subagents sind keine konfigurierte Erweiterungsstelle, sondern eine Delegationsfähigkeit

Drei Konfigurationsmuster, die sich bei erfolgreichen Deployments wiederholt haben

• Die Codebasis auch in großem Maßstab navigierbar machen

  • Wie sehr Claude in großen Codebasen helfen kann, wird durch seine Fähigkeit begrenzt, den richtigen Kontext zu finden
  • Wird in jede Sitzung zu viel Kontext geladen, sinkt die Leistung; wird zu wenig Kontext geladen, navigiert Claude praktisch blind
  • Erfolgreiche Deployments investieren früh darin, die Codebasis für Claude gut lesbar zu machen

  • CLAUDE.md-Dateien schlank und hierarchisch halten

    • Claude lädt CLAUDE.md-Dateien additiv, während es sich durch die Codebasis bewegt
    • Die Root-Datei trägt das große Ganze, Dateien in Unterverzeichnissen enthalten lokale Regeln
    • Die Root-Datei sollte nur Pointer und kritische Hinweise enthalten; alles Weitere wird leicht zu Rauschen

  • Nicht im Repository-Root, sondern in einem Unterverzeichnis starten

    • Claude arbeitet am besten, wenn der Umfang auf den Teil der Codebasis begrenzt ist, der für die Aufgabe tatsächlich relevant ist
    • In Monorepos kann das kontraintuitiv wirken, weil Tools oft Root-Zugriff voraussetzen
    • Claude läuft im Verzeichnisbaum automatisch nach oben und lädt dabei alle gefundenen CLAUDE.md-Dateien, daher geht Kontext auf Root-Ebene nicht verloren

  • Test- und Lint-Befehle auf Unterverzeichnisse eingrenzen

    • Wenn Claude nur einen Service geändert hat, aber die gesamte Test-Suite ausführt, entstehen Timeouts und Kontext wird mit irrelevanter Ausgabe verschwendet
    • CLAUDE.md-Dateien in Unterverzeichnissen sollten die Befehle angeben, die für diesen Teil der Codebasis gelten
    • Das funktioniert gut in serviceorientierten Codebasen, in denen jedes Verzeichnis eigene Test- und Build-Befehle hat
    • In Monorepos kompilierter Sprachen mit tiefen Abhängigkeiten über Verzeichnisse hinweg ist diese Eingrenzung schwieriger und kann projektspezifische Build-Konfigurationen erfordern

  • Generierte Dateien, Build-Artefakte und Third-Party-Code mit .ignore-Dateien ausschließen

    • Werden permissions.deny-Regeln in .claude/settings.json eingecheckt, sind Ausschlussregeln versioniert
    • So erhalten alle Entwickler im Team denselben Effekt der Rauschunterdrückung ohne separate Einrichtung
    • In manchen Codebasen können gerade generierte Dateien selbst Entwicklungsziel sein
    • Entwickler, die mit Code-Generatoren arbeiten, können projektweite Ausschlussregeln in ihrer lokalen Konfiguration überschreiben, ohne den Rest des Teams zu beeinflussen

  • Eine Karte der Codebasis erstellen, wenn die Verzeichnisstruktur nicht ausreicht

    • In Organisationen, in denen der Code nicht in einer üblichen Verzeichnisstruktur zusammengeführt ist, kann eine leichte Markdown-Datei im Root helfen
    • Eine Ein-Zeilen-Beschreibung jedes Top-Level-Ordners und seines Inhalts ergibt ein Inhaltsverzeichnis, das Claude überfliegen kann, bevor es Dateien öffnet
    • Wenn es Hunderte Top-Level-Ordner gibt, funktioniert ein hierarchischer Ansatz am besten: Die Root-Datei beschreibt nur die höchste Ebene, und CLAUDE.md in Unterverzeichnissen liefert die nächste Detailstufe on demand
    • In einfacheren Fällen kann derselbe Zweck erreicht werden, indem bestimmte Dateien oder Verzeichnisse, auf die Claude sich beziehen soll, mit @ erwähnt werden

  • Mit LSP nach Symbolen statt nach Strings suchen

    • Wenn man in einer großen Codebasis mit grep nach einem häufigen Funktionsnamen sucht, erhält man Tausende Treffer, und Claude verbraucht Kontext, indem es Dateien öffnet, um deren Relevanz zu beurteilen
    • LSP gibt nur Referenzen zurück, die auf dasselbe Symbol zeigen; die Filterung geschieht also, bevor Claude überhaupt etwas lesen muss
    • Für die Einrichtung müssen das Code-Intelligence-Plugin für die Sprache und das entsprechende Language-Server-Binary installiert werden
    • Die Claude-Code-Dokumentation enthält verfügbare Plugins und Hinweise zur Fehlerbehebung

  • Ausnahmen

    • Es gibt Edge Cases, in denen selbst der hierarchische CLAUDE.md-Ansatz versagt
    • Dazu zählen Codebasen mit Hunderttausenden Ordnern und Millionen Dateien sowie Legacy-Systeme mit anderer Versionsverwaltung als Git

• CLAUDE.md-Dateien entsprechend Veränderungen der Modellintelligenz pflegen

  • Wenn Modelle besser werden, können Anweisungen, die für das aktuelle Modell geschrieben wurden, für zukünftige Modelle hinderlich sein
  • Regeln in CLAUDE.md, die Claude früher bei schwierigen Mustern geholfen haben, können bei einem neuen Modell unnötig werden oder sogar zur Einschränkung werden
  • Beispielsweise mag eine Regel, jedes Refactoring in Änderungen an nur einer Datei aufzuteilen, älteren Modellen geholfen haben, den Überblick zu behalten, kann aber koordinierte Änderungen über mehrere Dateien blockieren, die neue Modelle gut bewältigen
  • Skills und Hooks, die gebaut wurden, um bestimmte Grenzen der Modelllogik oder der Claude-Code-Tools zu kompensieren, werden zu Overhead, sobald diese Grenzen entfallen
  • Ein Hook, der Schreibzugriffe abfing, um in einer Perforce-Codebasis p4 edit zu erzwingen, wurde überflüssig, nachdem Claude Code einen nativen Perforce-Modus hinzugefügt hatte
  • Teams sollten alle 3 bis 6 Monate mit einer substanziellen Überprüfung ihrer Konfiguration rechnen
  • Auch wenn sich die Leistung nach einem wichtigen Modell-Release stagnierend anfühlt, lohnt sich eine Konfigurationsprüfung

• Eigentümerschaft für Verwaltung und Einführung von Claude Code festlegen

  • Technische Konfiguration allein sorgt nicht für Adoption
  • Die Rollouts, die sich am schnellsten verbreiteten, hatten schon vor breitem Zugang Investitionen in Infrastruktur
  • Ein kleines Team, manchmal nur eine Person, verband die Tools so, dass Claude beim ersten Kontakt für Entwickler bereits zu ihrem Workflow passte
  • In einem Unternehmen baute eine Gruppe von Engineers Plugin- und MCP-Bundles, die vom ersten Tag an nutzbar waren
  • In einem anderen Unternehmen bereitete ein Team, das sich ausschließlich um das Management von AI-Coding-Tools kümmert, die Infrastruktur vor dem Rollout vor
  • Diese Arbeit ist oft in Organisationen für Developer Experience oder Developer Productivity angesiedelt, die sich auch um Onboarding neuer Engineers und Entwicklerwerkzeuge kümmern
  • In mehreren Organisationen entsteht die Rolle eines Agent Managers als hybrider PM-/Engineer-Posten, der das Claude-Code-Ökosystem verwaltet
  • Gibt es kein dediziertes Team, ist die kleinste praktikable Form ein einzelner DRI
  • Dieser DRI sollte Verantwortung für die Claude-Code-Konfiguration, Konfigurationsentscheidungen, Berechtigungspolitiken, den Plugin-Marketplace und die Ownership sowie Aktualität der CLAUDE.md-Regeln tragen
  • Bottom-up-Adoption erzeugt Begeisterung, kann aber ohne jemanden, der funktionierende Lösungen zentralisiert, fragmentieren
  • Es braucht eine Person oder ein Team, das Claude-Code-Konventionen wie standardisierte CLAUDE.md-Hierarchien oder kuratierte Skills und Plugins sammelt und verbreitet
  • Ohne diese Arbeit bleibt Wissen stilles Wissen und die Adoption stagniert

Governance und Rollout

• In großen Organisationen, besonders in regulierten Branchen, tauchen Governance-Fragen früh auf
• Zentrale Streitpunkte sind, wer kontrolliert, welche Skills und Plugins verwendet werden dürfen, wie verhindert wird, dass Tausende Engineers unabhängig dieselben Dinge neu bauen, und wie sichergestellt wird, dass AI-generierter Code denselben Review-Prozess durchläuft wie von Menschen geschriebener Code
• Empfohlen wird, anfangs mit einer definierten Menge genehmigter Skills, einem verpflichtenden Code-Review-Prozess und eingeschränktem Erstzugang zu starten und dann mit wachsendem Vertrauen zu erweitern
• Die reibungslosesten Deployments stammen aus Organisationen, die früh eine funktionsübergreifende Arbeitsgruppe mit Vertretern aus Engineering, Informationssicherheit und Governance gebildet und Anforderungen sowie Rollout-Roadmap gemeinsam definiert haben

Annahmen und Grenzen bei der Anwendung in Organisationen

• Claude Code ist rund um traditionelle Software-Engineering-Umgebungen konzipiert, in denen Engineers die wichtigsten Beitragenden zur Codebasis sind, das Repository Git verwendet und der Code einer Standard-Verzeichnisstruktur folgt
• Die meisten großen Codebasen passen in dieses Schema, aber Game Engines mit großen binären Assets, Umgebungen mit nicht traditioneller Versionsverwaltung und Umgebungen, in denen Nicht-Engineers zur Codebasis beitragen, erfordern zusätzliche Einrichtungsarbeit
• Die vorgestellten Muster setzen ein traditionelles Setup voraus und haben in mehreren Kundenumgebungen funktioniert
• Die verbleibende Komplexität muss anhand der jeweiligen Codebasis, Tools und Organisationsstruktur individuell beurteilt werden
• Das Applied-AI-Team von Anthropic arbeitet direkt mit Engineering-Teams zusammen, um diese Muster auf die konkreten Anforderungen einer Organisation zu übertragen

[GN⁺]

Hacker-News-Kommentare

• Die Formulierung, man navigiere durch eine Codebasis „wie ein Softwareingenieur“, scheint im Widerspruch zur Schlussfolgerung zu stehen
  Autovervollständigung oder LSP nutze ich immer, und das ist nützlich – ist das nicht auch eine Art Index? Ich frage mich auch, warum Claude so etwas nicht nutzen kann
  Softwareingenieure erinnern sich auch an eine Codebasis; das kommt im Grunde RAG nahe, und es gibt viel Muskelgedächtnis dabei, mit automatisch vervollständigtem CMD+P die benötigten Dateien zu finden
  Für die gesamte Codebasis, die von Tausenden Ingenieuren gleichzeitig verändert wird, muss es nicht in Echtzeit sein; es reicht, wenn nur mein aktueller Branch gut betrachtet wird
  Eine Codebasis von Grund auf durch Traversieren des Dateisystems zu erkunden, kommt selten vor; normalerweise nur bei einer neuen Codebasis, und selbst dann würde ich das kaum als optimale Erfahrung bezeichnen

  • Das entspricht genau meiner Arbeitsweise
    Ich habe gelernt, große Codebasen zu erkunden, noch bevor es LSP gab, und habe lange mit vim gearbeitet und mit grep die relevanten Dateien gefunden
    Als ich letztes Jahr Claude Code zum ersten Mal ausprobierte, war mein Eindruck: „Was soll’s, es macht genau das, was ich ohnehin tun wollte“
  • Die Antwort steht in der Einleitung des Artikels
    Claude Code geht von einer Umgebung mit Monorepos in der Größenordnung von Millionen Zeilen, jahrzehntealten Legacy-Systemen und verteilten Architekturen über Dutzende Repositories hinweg aus
    Deshalb ist es auf den allgemeinen Fall robuster Werkzeuge optimiert, die überall funktionieren, besonders in großen, unordentlichen Codebasen
    Der Einwand stimmt aber auch, dass man bei kleinen, gut organisierten Repositories bessere Werkzeuge nutzen kann und sollte
    Zumindest Codex arbeitet so und verwendet zum Beispiel erst go doc, bevor es grep einsetzt
  • In wirklich großen Codebasen bekommen grep und find Timeouts
    Wenn man in dieser Größenordnung arbeitet, merkt man schnell, dass Claude die Werkzeuge, die zum Durchsuchen überhaupt erst bereitgestellt wurden, nicht verwendet
  • In dem kurzen Absatz stehen viele plausibel klingende Formulierungen, aber in Wirklichkeit wirkt es eher wie Wunschdenken
    „Wie ein Softwareingenieur“ stimmt nur teilweise
    Menschen nutzen auch Symbolsuche, aber sie suchen nach Symbolen, an die sie sich im Kontext einer konkreten Aufgabe erinnern
    Die Art, wie Claude Code aktuell Symbole wahllos abgrast, unterscheidet sich davon, wie Ingenieure arbeiten
    Ein einzelner Tippfehler kann den Agenten zu dem Schluss bringen, er müsse etwas neu implementieren, und selbst wenn er zufällig die richtige Datei liest, kann er leicht halluzinieren
    So arbeitet man auch nicht in großen Codebasen
    Besonders die Aussage „mit grep genau das finden, was man braucht“ stört mich
    Um grep einzusetzen, muss man wissen, wonach man grep’en will, und wenn Tausende Ergebnisse zurückkommen, muss man sie alle prüfen
    Wenn so viele Treffer auftauchen, denkt ein Mensch eher darüber nach, wie sich die Ausgabe eingrenzen lässt, statt sie stumpf durchzugehen
    Der Ansatz des Artikels ist eher eine Erklärung zur Rechtfertigung der aktuellen Vorgehensweise als eine belastbare Empfehlung
    Auch die Aussage „Man braucht keinen Codebasis-Index“ ist zwar nicht falsch, heißt aber nur, dass man mit grep-read-grep den Kontext immer weiter aufbläst und irgendwann vielleicht eine Antwort findet
    Es klingt ähnlich wie zu sagen: „Weil ein Entwickler es auch ohne Claude Code selbst umsetzen kann, braucht man Claude Code nicht“
    Diese Botschaft des „nicht nötig“ halte ich für falsch, weil sie der Community eine Entscheidung als absolutes Dogma vermittelt
    Insgesamt ist der Text bezüglich der organisatorischen Kosten ehrlich
    Es heißt, in mehreren Organisationen entstünden bereits Rollen als „Agent Manager“, eine Mischung aus PM und Ingenieur, um das Claude-Code-Ökosystem zu verwalten, und Teams müssten alle 3–6 Monate sinnvolle Konfigurations-Reviews durchführen
    Das zeigt die Realität von Claude Code im großen Maßstab ohne vorgebaute Code-Intelligence-Schicht ziemlich genau
    Die Richtung stimmt, aber nach dem Lesen bleibt ein Nachgeschmack von „Wir haben das Problem nicht gelöst, und hier liegt unsere Grenze“
  • Selbst wenn man einen Teil einer Codebasis von Grund auf erkundet, gibt es Bereiche, die sich nie ändern, und sie jedes Mal erneut zu erkunden ist eine enorme Token-Verschwendung
    Ein häufiger Streitpunkt mit Claude ist auch, es dazu zu bringen, deutlich weniger zu explorieren
    Dinge, die sich fast nie ändern, kenne ich besser und schneller, als sie auf langsame und teure Weise zu durchkämmen
    Trotzdem gerät es jedes Mal wieder in dieselben Kaninchenlöcher

• Als Anekdote: Ich entwarf ein Projekt für LLM-Onboarding und Orchestrierung, und Claude entschied sich, von jeder Datei nur die ersten 40 Zeilen zu lesen
  Später entdeckte Claude in einer anderen Session bei der Suche nach der Ursache der niedrigen Qualität genau diesen Mangel und änderte den Code so, dass eine AST-Analyse mit Dokumentationszeilen und den Ein-/Ausgaben der Funktionssignaturen als Input durchgeführt wurde
  Claudes ursprünglicher Ansatz war wirklich schlecht
  Das lässt mich daran zweifeln, wie viel Nachbesserung und Review Claude Code braucht, um gut zu werden, und ob es überhaupt von vornherein guten Code erzeugen kann
  Allgemeiner gesagt kann Claude lokale und klar identifizierbare schlechte Entscheidungen wie „Lies nur die ersten 40 Zeilen“ korrigieren
  Denn der Defekt ist isoliert und auf ein einzelnes Stück Code zurückzuführen
  Reale Software-Qualitätsprobleme entstehen jedoch oft dadurch, dass viele kleine Entscheidungen, die einzeln vernünftig wirken, zusammen ein schlechtes Ergebnis erzeugen
  Dann ist keines davon offensichtlich ein „Defekt“, weshalb ein Werkzeug, das Stück für Stück Komponenten geringer Qualität erzeugt, möglicherweise nicht zu gutem Code konvergiert, weil jedes Stück für sich betrachtet noch in Ordnung aussieht

  • Es scheint darauf trainiert zu sein, Quellcode durch ein enges Schlüsselloch zu betrachten, um Kontext zu erhalten
    In solchen Fällen könnten Sub-Logik oder vollständige Sub-Agenten gut passen
    Man könnte einem Sub-Agenten zum Beispiel sagen: „Scanne diese Datei und fasse sie zusammen, markiere die Teile, die für X und Y relevant sind. Dann schaue ich sie mir im Hauptkontext an“
    Man könnte ihn auch den Haupt-Workflow periodisch beobachten lassen und eingreifen lassen, wenn er entscheidet, dass etwas in den Dateien, über die er nachdenkt, für die aktuelle Aufgabe relevant ist oder die Richtung ändern könnte

• Wie funktioniert Claude Code in großen Codebasen? Ganz einfach
  Schon in kleinen Projekten frisst es im ersten Prompt 35 % des 5-Stunden-Nutzungslimits auf, und wenn es nicht innerhalb von 5 Minuten schnell antwortet, verfällt der Cache, sodass ich beim nächsten Prompt noch einmal 12–15 % zahle

  • Der verlinkte Artikel erklärt, wie man das vermeidet
    Wenn man es in einer großen Codebasis naiv frei laufen lässt, verbrennt es beim Suchen tatsächlich viele Tokens

• Sollte Claude Code nicht die Codebasis untersuchen und automatisch eine effektive Harness erzeugen?
  Ich habe CLAUDE.md, AGENTS.md, Skills und Plugins definiert, aber nicht annähernd die Wirkung erzielt, von der andere sprechen
  Selbst wenn es etwa ein LSP-Plugin gibt, nutzt Claude Code LSP nicht zum Umbenennen von Symbolen, sondern bearbeitet Dateien langsam einzeln, oder es ruft einen Skill trotz expliziter Vorgabe im Prompt, ihn bei bestimmten Hinweisen aufzurufen, einfach nicht auf
  Benutze ich das falsch? Ich frage mich, ob es robuste Harness-Beispiele gibt, die man einfach kopieren und verwenden kann

  • Das ist seit Jahren ein Schmerzpunkt und bis heute überhaupt nicht gelöst
    Selbst wenn man sagt: „Wenn A, dann mach X. Mach B, C, D. Mach A“, wird X einfach nicht verwendet
    Weil es „vergessen“ wurde
    Man kann nicht darauf vertrauen, dass die Zeit, die man ins Erstellen der Regeln gesteckt hat, sich tatsächlich auszahlt; eher kann man darauf vertrauen, dass es irgendwann scheitern wird
    RAG, Harnesses und Skills haben alle behauptet, das zu beheben, in der Praxis haben sie es aber nicht geschafft
  • Ich habe aufgehört, /init zu verwenden und eine CLAUDE.md- oder AGENTS.md-Datei zur Beschreibung der Codebasis zu pflegen
    Übrig geblieben ist nur noch, wie man die Codebasis erkundet und dass man bei Untersuchungen git log verwenden soll, aber selbst das ist vermutlich redundant
    Ich kenne die Antwort auch nicht
    Die Codebasis, an der ich arbeite, hat ungefähr 100.000 Zeilen; ich weiß nicht, ob das schon als groß gilt, aber für mich ist es persönlich das größte Repository, an dem ich je gearbeitet habe
  • In manchen Fällen scheinen Hooks mit angehängten Skripten wirksam zu sein, indem sie Informationen in das Kontextfenster einspeisen
    Um den Kontext zu begrenzen, musste ich einige unnötige Linter-Meldungen entfernen
    Auch Linter oder sprachspezifische Prüfwerkzeuge, die sich über das Paket-Repository des Betriebssystems installieren und aus Skripten aufrufen lassen, helfen
    Die Kombination aus Modell und Skill-Kontext kann ebenfalls einen Unterschied machen
    Ein Skill, der in 4.6 „funktioniert“ hat, passt in 4.7 möglicherweise nicht mehr gut; 4.7 braucht explizitere Anweisungen, ist dafür aber vergleichsweise stabiler als 4.6
    Es kann auch helfen, den Skill zu aktualisieren, und man sollte Tests und Ausführung davor und danach vergleichen
    Claude Code legt auch unnötige Tool-Aufrufe in den Kontext, daher muss man die Arbeit möglicherweise drosseln, wenn man zum Beispiel beads mag

• Mit der Behauptung über Codebasis-Indizierung bin ich nicht einverstanden
  In PHPStorm oder anderen JetBrains-IDEs funktioniert Indizierung ziemlich gut

  • PHPStorm-Indizierung ist großartig
    Sehr selten war sie mal beschädigt, aber das ließ sich leicht beheben, und ich habe nie veraltete Ergebnisse bekommen
    Wenn man Claudes Suchwerkzeuge benutzt hat, überrascht es einen nicht, dass dieses Team offenbar nichts von Indizierung versteht
    Dass ein Unternehmen, dessen Kernprodukt textbasierter Chat ist, es Nutzern nicht leicht macht, in diesem Chat Text zu durchsuchen, ist für mich unverständlich
  • Claude Code kann diesen Index über MCP von JetBrains nutzen
  • Eine seltsame Behauptung
    Ist das AI-Mülltext? Auch GitHub Copilot hat einen ziemlich guten lokalen Index
    Code in eine Vektor-Datenbank zu stecken, ist kein besonders schwieriges Problem

• Dieser Artikel wurde ganz offensichtlich von Claude geschrieben
  Er ist voller Füllmaterial und enthält wenig Substanz

• Die Formulierung ist merkwürdig, dass auch Sprachen wie C, C++, C#, Java und PHP dazugehören, die Teams nicht immer automatisch mit AI-Coding-Tools verbinden
  Warum sollte man erwarten, dass Claude Code in solchen Sprachen nicht gut funktioniert? An welche Sprachen soll man dann denken – Python und JavaScript?

• In einer Branche, in der sich das Spielfeld nicht nur über Wochen, sondern sogar über Monate verändert, ist es interessant, dass offenbar genug Zeit vergangen ist, damit sich klare Muster zeigen, und dass diese Muster in großen Codebasen erfolgreich gewesen sein sollen
  Was ist denn das Erfolgskriterium? Dass keine Produktionsdatenbank gelöscht wurde, dass Teams schneller wurden, dass die Lebensdauer der Codebasis gestiegen ist oder dass das Ops-Team glücklicher ist?

  • Wenn wegen eines AI-Tools eine Produktionsdatenbank gelöscht wurde, möchte ich weiterhin sagen: Dann ist das ein Versagen von dir und deiner Organisation, weil ihr Entwicklern Produktionsrechte gegeben habt, mit denen sie Betriebsressourcen löschen können
    Ich habe noch nie in einer Firma gearbeitet, die derart unbegrenzte Zugriffsrechte vergeben hat

• Mein ganzer Stress kommt derzeit daher, dass Claude Code Anweisungen nicht befolgt, und je größer die Codebasis wurde, desto schlimmer wurde es
  Nicht missverstehen: Claude ist großartig, und ich mag es
  Aber ich kann keinesfalls nur Claude Code „einstellen“, um eine Codebasis zu warten oder Funktionen hinzuzufügen
  Ich füge ständig neue Memory-Einträge zu vergangenen Fehlern hinzu, aber das Problem, dass wichtige Anweisungen ignoriert werden, tritt immer noch mit etwa 90 % Wahrscheinlichkeit auf
  Der einzige Weg, das zu vermeiden, besteht darin, jede Aufgabe nebenbei zu überwachen und die Ergebnisse massiv zu prüfen
  Claude Code ist hervorragend für Dokumentation oder zum Verständnis großer Codebasen, aber schwach bei Änderungen, für die man das Ganze verstehen muss
  Zum Beispiel gibt es codebasisweit ungefähr 10 Registry-Pattern, die für mehrere Entitäten verwendet werden, und obwohl es die explizite Regel gab, „dieses eine Registry-Pattern zu verwenden“, hat Claude Code stattdessen vier voneinander getrennte Registries pro Entität implementiert
  Ich habe einen halben Tag damit verbracht, Claude Code praktisch anzuschreien, damit es diese einfache Aufgabe richtig macht, und am Ende habe ich es selbst korrigiert, um Stress und Zeit zu sparen

• Es wird nicht einmal in konkreten Begriffen erklärt, was genau in jede CLAUDE.md-Datei hineingehört, daher weiß ich nicht, wie wichtig solche Dateien überhaupt sind

  • Fisch: Hier kann man es lesen https://code.claude.com/docs/en/best-practices#write-an-effe...
    Angelmethode: 1) den offiziellen skill-creator installieren 2) mit dem obigen Link claude-md-improver erstellen 3) den Skill verbessern lassen, indem man ihn das Thema progressive-disclosure aus der offiziellen Dokumentation recherchieren lässt 4) den neuen Skill auf die CLAUDE.md-Datei anwenden und die Änderungen übernehmen