Zwei Wochen, 40 Commits und eine KI, die sich an meine Vorlieben erinnert

Der ehrliche Bericht eines Entwicklers darüber, was tatsächlich passiert, wenn man mit Claude Code echte Arbeit veröffentlicht.

Lesezeit: 12 Minuten | Schwierigkeitsgrad: Mittel

Ich hatte nicht vor, diesen Beitrag zu schreiben. Aber nachdem ich zwei Wochen lang mit Claude Code an mehreren Projekten gearbeitet hatte, schaute ich mir das Git-Log an und stellte etwas Interessantes fest: Das Tool arbeitete immer besser mit mir zusammen – nicht wegen eines Software-Updates, sondern weil es gelernt hatte, wie ich denke.

Dies ist keine Rezension und kein Tutorial. Es ist ein Erfahrungsbericht. Was funktioniert hat, was nicht, was ich anders machen würde und ein paar Tricks, über die ich noch niemanden sprechen gehört habe.

🔷 Wie zwei Wochen echte Arbeit aussehen

In meinen Projekten haben Claude Code und ich während eines zweiwöchigen Sprints etwa 40 Commits veröffentlicht. Sicherheitsoptimierungen. SEO-Korrekturen. Verbesserungen der Barrierefreiheit. Eine umfassende Überarbeitung der Testsuite. Automatisiertes Cross-Posting von Blogbeiträgen. Verbesserungen der Docker-Pipeline. Übersetzungen. Refactoring.

Nichts davon war Greenfield-Arbeit à la „Baue mir eine To-Do-App“. Es waren die chaotischen, kontextbezogenen Aufgaben, an denen die meisten KI-Tools scheitern – das Korrigieren von hreflang-Tags auf einer zweisprachigen Website, das Debuggen, warum Docker immer wieder veraltetes, vorgerendertes HTML auslieferte, das Korrigieren von Content Security Policy-Headern, ohne Analytics-Skripte zu beeinträchtigen.

Mir ist Folgendes aufgefallen: Die ersten paar Sitzungen fühlten sich an wie die Einarbeitung eines neuen Mitarbeiters. Am Ende der zweiten Woche fühlte es sich eher wie Pair Programming mit jemandem an, der mein Playbook gelesen hatte.

🔷 Das Speichersystem verändert alles

Die meisten KI-Codierungsassistenten sind wie Goldfische. Jedes Gespräch beginnt bei Null. Claude Code ist anders – es verfügt über zwei Speichersysteme, die sich im Laufe der Zeit ergänzen.

Dateibasiertes Gedächtnis (projektbezogen)

Jedes Projekt kann eine CLAUDE.md-Datei und einen Satz von Regeln haben. Meine enthalten Vorlieben zum Codestil, den Git-Workflow, Teststandards, Sicherheitsregeln und Architekturprinzipien. Claude Code liest diese zu Beginn jeder Sitzung ein.

Das klingt einfach, aber der ROI ist absurd hoch. Ich habe vielleicht eine Stunde damit verbracht, meine CLAUDE.md- und Regel-Dateien zu schreiben. Seitdem beginnt jede Sitzung damit, dass Claude Code bereits weiß:

• Verwende konventionelle Commits (feat:, fix:, chore:)
• Committe niemals .env-Dateien
• Führe während der Entwicklung einzelne Tests durch, nicht die gesamte Testsuite
• Standardmäßig Server-Komponenten, 'use client' nur bei Bedarf
• Funktionale Komponenten mit benannten Exports

Diese eine Stunde für die Einrichtung hat mir Hunderte von Korrekturen erspart.

Wissensgraph (projektübergreifend)

Die zweite Ebene ist ein gemeinsamer Wissensgraph, auf den über MCP zugegriffen werden kann. Hier wird es interessant – er bleibt projekt- und toolübergreifend bestehen. Wenn ich das Verhalten von Claude Code in einem Projekt korrigiere, wird diese Korrektur auf das nächste übertragen.

Zum Beispiel fiel mir schon früh auf, dass Claude Code in generierten Inhalten Wörter wie „delve“ und „tapestry“ verwendete. Ich habe das einmal korrigiert. Diese Einstellung wurde gespeichert. Jetzt vermeidet es diese Wörter in jedem Projekt, ohne dass ich etwas sagen muss.

Außerdem hat es gelernt:

• Meine Website ist eine Vite + React SPA, nicht Next.js (ein Fehler, den es immer wieder machte, bis ich ihn korrigierte)
• Ich bevorzuge die autonome Ausführung nach der Planfreigabe – bitte nicht bei jeder Teilaufgabe um Erlaubnis fragen
• Meine Berufserfahrung niemals erfinden oder übertreiben
• Qualität vor Geschwindigkeit – lieber langsam und richtig als schnell und falsch

Der Compounding-Effekt

Das ist der Teil, den die meisten Leute übersehen. Jede Korrektur, jede gespeicherte Präferenz, jede geschriebene Regel macht die nächste Sitzung ein kleines bisschen besser. Über zwei Wochen hinweg summieren sich diese kleinen Verbesserungen. Am Ende verbrachte ich fast keine Zeit mehr mit Stilkorrekturen, der Formatierung von Commit-Meldungen oder Meinungsverschiedenheiten bezüglich der Architektur.

Die KI wurde nicht schlauer. Meine Konfiguration wurde besser.

🔷 Muster und Tricks, die tatsächlich funktionieren

Hier sind die Workflow-Muster, die sich herauskristallisiert haben. Einige sind im Nachhinein offensichtlich. Ein paar haben mich überrascht.

1. CLAUDE.md ist deine Datei mit dem höchsten ROI

Ich habe das bereits gesagt, aber es lohnt sich, es zu wiederholen. Die Datei CLAUDE.md und die Projektregeln sind das Einzige, was du tun kannst, um den größten Hebeleffekt zu erzielen. Jede Minute, die du damit verbringst, klare Regeln zu schreiben, spart später fünf Minuten an Korrekturen.

Meine Regeln umfassen:

• Codestil — TypeScript-Strict-Modus, kein any, interface statt type für Objektformen
• Git-Workflow — immer verzweigen, konventionelle Commits, niemals Main-Branch zwangsweise pushen
• Testen — AAA-Muster, nur externe Abhängigkeiten mocken, beschreibende Testnamen
• Sicherheit — keine fest codierten Geheimnisse, parametrisierte Abfragen, Validierung an den Grenzen
• Architektur — Dateien mit weniger als 200 Zeilen, nach Funktionen gruppieren, Dependency Injection zur Verbesserung der Testbarkeit

Das ist alles keine Raketenwissenschaft. Aber ohne diese Regeln würde ich in jeder Sitzung dieselben Fehler korrigieren müssen.

2. Unteragenten für die Erkundung, Hauptkontext für die Implementierung

Ein Muster, das sich ganz natürlich herauskristallisiert hat: Verwende Sub-Agenten (Hintergrundagenten) für Recherche und Erkundung und behalte den Hauptkontext für die eigentliche Implementierung.

Wenn ich verstehen muss, wie etwas in einem mir unbekannten Teil des Code-Basis funktioniert, starte ich einen Sub-Agenten zur Erkundung. Er liest Dateien, verfolgt Abhängigkeiten, bildet die Architektur ab – und meldet sich mit einer Zusammenfassung zurück. Mein Hauptkontextfenster bleibt übersichtlich und auf die Aufgabe fokussiert.

Das ist wichtig, denn der Druck im Kontextfenster ist real. In langen Sitzungen sammeln sich Tool-Ergebnisse, Dateiinhalte und Konversationsverlauf an. Wenn man die gesamte Erkundung in den Hauptthread ablegt, verliert man den Implementierungskontext. Subagenten sind ein Druckventil.

3. Pläne als Dateien, nicht als Chat

Ein weiterer nicht offensichtlicher Trick: Speichere Pläne immer in Dateien, nicht als kurzlebige Chat-Ausgabe. Wenn Claude Code einen Implementierungsplan erstellt, lasse ich ihn den Plan in eine Markdown-Datei schreiben. Warum?

• Pläne überstehen die Kontextkomprimierung (lange Konversationen werden zusammengefasst, wodurch Details verloren gehen)
• Pläne können vor der Implementierung von Unteragenten überprüft werden
• Pläne schaffen Verantwortlichkeit – man kann vergleichen, was geplant war und was tatsächlich erstellt wurde
• Pläne können in einer neuen Sitzung wieder aufgenommen werden, wenn man an Kontextgrenzen stößt

Ich verwende die SPARC-Methodik: Spezifikation, Pseudocode, Architektur, Verfeinerung, Fertigstellung. Jede Phase ist ein Kontrollpunkt, an dem ich überprüfen und umlenken kann, bevor ich mich zur Implementierung verpflichte.

4. Korrigieren Sie die KI, tolerieren Sie sie nicht

Dies ist die wichtigste Erkenntnis zum Verhalten. Die meisten Entwickler reagieren, wenn eine KI leicht fehlerhaften Code generiert, entweder wie folgt:

a) Sie akzeptieren ihn und korrigieren ihn später manuell, oder b) sie generieren ihn neu und hoffen auf ein besseres Ergebnis

Beides ist falsch. Der richtige Schritt ist, die KI explizit zu korrigieren und zu erklären, warum. „Simuliere die Datenbank in diesen Tests nicht – wir haben schlechte Erfahrungen gemacht, als die Simulationen vom tatsächlichen Schema abwichen.“ Dadurch entsteht eine Rückkopplungsschleife. Die Korrektur wird gespeichert. Der Fehler wiederholt sich nicht.

Mittelmäßige Ergebnisse zu tolerieren, lehrt die KI nichts. Sie zu korrigieren, lehrt sie alles.

5. Code-Review durch mehrere Agenten

Eines meiner Lieblingsmuster: Nachdem ich einen Codeabschnitt geschrieben habe, lasse ich mehrere Review-Agenten parallel laufen – für Sicherheit, Architektur, Performance und Code-Vereinfachung. Jeder Agent hat einen engen Aufgabenbereich und erkennt unterschiedliche Dinge.

Ein Sicherheitsagent hat einmal nicht bereinigte Benutzereingaben gemeldet, die direkt im DOM gerendert wurden. Ein Vereinfachungsagent hat erkannt, dass ich eine Abstraktion für etwas erstellt hatte, das genau einmal verwendet wurde. Beides wäre bei einer einmaligen Überprüfung nicht aufgefallen.

Der Trick besteht darin, sie parallel laufen zu lassen. Vier Agenten, die gleichzeitig überprüfen, benötigen genauso viel Zeit wie ein einziger.

6. Auch die Testkultur summiert sich

Bei einem Projekt übernahm ich eine Codebasis mit genau einem Test. Nach mehreren Wochen konsequenter Arbeit – dem Schreiben von Tests für jede Fehlerbehebung, jede neue Funktion – stieg die Anzahl auf über 2.750.

Claude Code ist wirklich gut darin, Tests zu schreiben. Nicht perfekt – gelegentlich schreibt es Tests, die eher die Implementierung als das Verhalten prüfen –, aber mit den richtigen Regeln („teste WAS es tut, nicht WIE“) ist die Qualität der Ergebnisse hoch. Der Schlüssel liegt darin, das Testen in deinen Regeln als unverzichtbar festzulegen, nicht als optional.

7. Git-Worktrees für parallele Feature-Arbeit

Wenn ich an mehreren Funktionen gleichzeitig arbeite, verwende ich git worktree, um separate Arbeitsverzeichnisse zu verwalten. So kann Claude Code an einer Funktion arbeiten, während ich eine andere überprüfe, ohne den Aufwand eines Branch-Wechsels.

In Kombination mit Sub-Agenten entsteht so ein wirklich paralleler Arbeitsablauf: ein Worktree für die aktuelle Funktion, ein Sub-Agent, der die Codebasis in einem anderen Worktree untersucht, und der Hauptthread, der beide koordiniert.

🔷 Wo es hakt

Zeit für Ehrlichkeit. Nicht alles läuft reibungslos.

Übertechnisierung

Claude Code neigt dazu, komplexe Lösungen vorzuschlagen, wenn es einfache gibt. Heute habe ich zum Beispiel gefragt, wie man Blogbeiträge dynamisch aktualisieren kann. Es ging tief in die Laufzeit-Datenbankabfrage, React-Context-Provider und eine komplette Neuprogrammierung des Frontends – dabei lautete die eigentliche Antwort: „Füge einfach Auto-Merge zum bestehenden Veröffentlichungsskript hinzu.“ Zehn Minuten Fragen führten uns zu dieser einfachen Antwort.

Das Gegenmittel: Frage frühzeitig und oft: „Was ist die einfachste Version davon?“

Druck durch das Kontextfenster

Lange Sitzungen (3+ Stunden) fühlen sich zunehmend träge an. Die KI hat zu viele Dateiinhalte und zu viele Tool-Ergebnisse gesehen. Wichtiger Kontext aus den frühen Phasen der Konversation wird komprimiert oder geht verloren.

Meine Lösung: Ich teile große Aufgaben in mehrere Sitzungen auf. Jede Sitzung hat einen klar definierten Umfang. Pläne und Fortschritte werden in Dateien gespeichert, sodass die nächste Sitzung nahtlos daran anknüpfen kann.

Störende Plugins und Hooks

Ich verwende mehrere Plugins und Hooks mit Claude Code. Sie sind leistungsstark, aber störend – manchmal lösen sie irrelevante Skill-Vorschläge aus oder fügen Kontext ein, der nichts mit der aktuellen Aufgabe zu tun hat. Ein Next.js-Skill, der ausgelöst wird, während ich an einem Vite-Projekt arbeite. Eine Vercel-Bereitstellungsanleitung, wenn ich auf Hetzner bereitstelle.

Dies ist ein Problem der Tool-Reife, kein grundlegendes Problem. Aber es sorgt für Reibungsverluste.

Der Permissions-Tanz

Claude Code ist bei destruktiven Operationen eher vorsichtig, was im Allgemeinen gut ist. Aber manchmal fragt es nach Berechtigungen für Dinge, die offensichtlich sicher sind – das Ausführen eines Linters, das Lesen einer Konfigurationsdatei. Die Reibung ist pro Fall gering, summiert sich aber.

Ich habe meine Berechtigungseinstellungen so angepasst, dass gängige Operationen automatisch zugelassen werden. Es lohnt sich, ein paar Minuten in die Konfiguration zu investieren.

🔷 Was ich jemandem raten würde, der gerade erst anfängt

Wenn du Claude Code für echte Arbeit (nicht nur für Spielprojekte) in Betracht ziehst, hier ist, was ich gerne gewusst hätte:

1. Investiere zuerst in CLAUDE.md. Verbringe vor deiner ersten Programmiersitzung 30 Minuten damit, deine Regeln zu schreiben. Code-Stil, Git-Workflow, Teststandards, Sicherheitsregeln. Diese eine Datei bestimmt 80 % der Ausgabequalität.

2. Wehre dich nicht gegen die Planungsphase. Claude Code will vor der Umsetzung planen. Lass es zu. Der „Planen-dann-Umsetzen“-Workflow deckt architektonische Fehler auf, deren Behebung später Stunden kosten würde.

3. Korrigiere aggressiv, nicht passiv. Jedes Mal, wenn die KI etwas tut, das dir nicht gefällt, sag es ausdrücklich. „Tu X nicht, weil Y.“ Die Korrektur wird gespeichert und summiert sich.

4. Verwenden Sie Sub-Agenten für alles, was explorativ ist. Dateisuchen, Erkundung der Codebasis, Abhängigkeitsanalyse – all dies sollte in Sub-Agenten erfolgen, nicht in Ihrem Hauptthread. Schützen Sie Ihr Kontextfenster.

5. Speichern Sie alles Wichtige in Dateien. Pläne, Entscheidungen, Fortschrittsnotizen. Chats sind vergänglich. Dateien überstehen Kontextkomprimierung und Sitzungsgrenzen.

6. Teilen Sie große Aufgaben in Sitzungen auf. Eine 6-stündige Sitzung ist weniger produktiv als drei 2-stündige Sitzungen mit klarem Umfang. Die Kontextqualität verschlechtert sich mit der Zeit.

7. Automatisieren Sie die langweiligen Teile. Richten Sie Hooks für die Formatierung von Commits, Deployment-Prüfungen und Code-Reviews ein. Je weniger Sie manuell auslösen müssen, desto länger bleiben Sie im Flow.

Wenn Sie als technischer Leiter prüfen, wie KI-Assistenten in Ihren Entwicklungs-Workflow passen – sei es für Ihre eigene Produktivität oder für Ihr Team –, helfe ich Startups dabei, dies herauszufinden. Nicht jedes Projekt benötigt KI-Tools, aber wenn sie passen, ist der Synergieeffekt real.

Fazit: Es geht nicht um Geschwindigkeit

Die häufigste Frage, die mir zu KI-Coding-Assistenten gestellt wird, lautet: „Wie viel schneller bist du?“ Das ist die falsche Frage.

Der wahre Wert liegt nicht in der Geschwindigkeit – sondern in der Konsistenz. Claude Code vergisst meine Commit-Konventionen nicht um 23 Uhr. Er überspringt keine Tests, nur weil es Freitag ist. Er führt keine any-Typen ein, nur weil er müde ist. Die Regeln, die ich am ersten Tag geschrieben habe, werden am dreißigsten Tag mit derselben Strenge durchgesetzt.

Der zweite Vorteil ist der Zinseszinseffekt. Zwei Wochen voller Korrekturen und Feinabstimmung der Einstellungen haben einen Assistenten hervorgebracht, der meine technischen Ansichten, meinen Schreibstil und meine Qualitätsstandards versteht. Diese Investition wird nicht zurückgesetzt. Sie wirkt sich nachhaltig aus.

Bin ich schneller? Wahrscheinlich. Aber noch wichtiger ist, dass die Qualitätsschwelle höher liegt. Und die Qualitätsschwelle ist das, was am Ende veröffentlicht wird.