Mit Claude Code gute Ergebnisse erzielen

 (dzombak.com)
45 Punkte von GN⁺ 2025-08-09 | 5 Kommentare | Auf WhatsApp teilen
  • In den letzten Monaten wurden verschiedene LLM-Programmieragenten ausprobiert; dabei war Claude Code das zufriedenstellendste Werkzeug
  • Mit Claude Code wurden in kurzer Zeit rund 12 Programme und Projekte erstellt; auch Arbeiten wurden möglich, die sonst aus Zeitgründen gar nicht begonnen worden wären
  • Für eine erfolgreiche Nutzung sind das Erstellen klarer Spezifikationen, die Bereitstellung einer Dokumentation zu Projektstruktur sowie Build-, Lint- und Testausführung, das Anfordern eines Code-Reviews durch die AI selbst und der Einsatz eines personalisierten globalen Agentenleitfadens entscheidend
  • Da von AI geschriebener Code oft ungenau oder ineffizient sein kann, werden sämtlicher Code und alle Testfälle unbedingt manuell geprüft; fehlende Tests werden entweder selbst ergänzt oder von der AI erstellt und anschließend erneut überprüft
  • Der als Anhang veröffentlichte globale Agentenleitfaden enthält detaillierte Entwicklungsrichtlinien wie schrittweise Implementierungsplanung, testgetriebene Entwicklung, eine Philosophie mit Fokus auf Einfachheit, Klarheit und Pragmatismus, Qualitätskriterien und Problemlösungsprozesse

Erfahrungen mit Claude Code und seine Wirkung

  • In den vergangenen Monaten wurden verschiedene LLM-Programmieragenten getestet, wobei die Erfahrungen mit Claude Code besonders positiv waren
  • Es ist nicht völlig frei von Problemen, dennoch konnten in kurzer Zeit mehr als 12 Programme und Projekte fertiggestellt werden
  • Ohne Claude Code wäre es nahezu unmöglich gewesen, all diese Arbeiten im selben Zeitraum zu erledigen
  • Viele dieser Arbeiten wären wegen des Zeitaufwands vermutlich gar nicht erst versucht worden

Strategien für den Einsatz von Claude Code

  • Klare Spezifikationen erstellen
    • Vor Projektbeginn Anforderungen und Kontext klar dokumentieren und dem Agenten bereitstellen
    • Dadurch werden Richtung und Umfang der Code-Erstellung eindeutig
  • Projektstruktur dokumentieren
    • Eine Dokumentation bereitstellen, die auch beschreibt, wie Build, Lint und Tests ausgeführt werden
    • So kann der Agent die Codebasis effektiver erkunden und bearbeiten
  • Code-Review durch den Agenten anfordern
    • Claude Code den erzeugten Code selbst prüfen lassen, um unerwartete Verbesserungsmöglichkeiten oder Bugs zu finden
  • Persönlichen globalen Leitfaden nutzen
    • Über ~/.claude/CLAUDE.md, das persönliche Regeln wie Problemlösungsansatz, Einsatz von TDD, Wahrung von Einfachheit und Klarheit sowie ein Limit von drei Versuchen enthält, wird ein konsistenter Entwicklungsprozess sichergestellt

Von LLMs geschriebenen Code validieren

  • Von AI erzeugter Code weist häufig Probleme wie logische Fehler, Leistungseinbußen oder unvollständige Tests auf
  • Der Autor prüft sämtlichen Code manuell und kontrolliert dessen Verhalten
    • Fehlende Testfälle werden selbst ergänzt
    • Oder die AI wird gebeten, sie zu schreiben; anschließend werden Code und Tests erneut überprüft
  • In professionellen Umgebungen, so wird betont, liegt die Verantwortung für die Endqualität bei einem selbst, sobald der eigene Name in einem PR steht

Wichtige Inhalte des persönlichen „globalen“ Agentenleitfadens

Dieser Leitfaden wird in der Datei ~/.claude/CLAUDE.md verwaltet

  • Philosophie und Kernprinzipien

    • Schrittweises Vorgehen: Änderungen in kleinen Einheiten, dabei müssen Kompilierung und Tests immer erfolgreich sein
    • Bestehenden Code lernen: Vor der Implementierung Code-Muster analysieren und einen Plan erstellen
    • Pragmatismus vor allem: Ein flexibler Ansatz, angepasst an die jeweilige Projektsituation
    • Klarheit vor allem: Gut lesbarer Code mit klarer Absicht, ohne unnötige Tricks

  • Definition von Einfachheit

    • Funktionen und Klassen haben jeweils nur eine Verantwortung
    • Keine verfrühte Abstraktion
    • Komplexität reduzieren und Code anstreben, der keine Erklärung benötigt

  • Arbeitsprozess

    • 1. Planung und Phaseneinteilung:
      • Komplexe Aufgaben in 3 bis 5 Schritte aufteilen und in IMPLEMENTATION_PLAN.md festhalten
      • Für jede Phase Ziele, Erfolgskriterien, Testfälle und Fortschrittsstatus angeben
    • 2. Implementierungsablauf:
      • Verstehen → Test schreiben (rot) → minimale Implementierung (grün) → Refactoring → Commit
    • 3. Nach drei Versuchen neu bewerten:
      • Bei Fehlschlägen die bisherigen Versuche, Fehler und Ursachen dokumentieren
      • Alternativen erkunden (2–3 Ansätze)
      • Grundlegendes Design und Problemzerlegung erneut überprüfen
      • Andere Muster oder Funktionen ausprobieren

  • Technische Standards

    • Composition zuerst, unter Nutzung von Dependency Injection
    • Interfaces verwenden, um Testbarkeit sicherzustellen
    • Expliziter Datenfluss
    • TDD wird empfohlen, das Deaktivieren von Tests ist verboten

  • Regeln für Code-Qualität

    • Jeder Commit muss erfolgreich kompilieren, alle Tests bestehen, Tests für neue Funktionen enthalten und den Code-Stil einhalten
    • Vor dem Commit Formatter und Linter ausführen, Änderungen selbst reviewen und Commit-Messages schreiben, die das „Warum“ erklären

  • Fehlerbehandlung

    • Schnell fehlschlagen und konkrete Meldungen ausgeben
    • Den für das Debugging nötigen Kontext bereitstellen
    • Ausnahmen auf der passenden Ebene behandeln, Ausnahmen nicht verschleiern

  • Entscheidungskriterien

    • 1. Testbarkeit
    • 2. Lesbarkeit, die auch in 6 Monaten noch verständlich ist
    • 3. Konsistenz mit den Projektmustern
    • 4. Einfachheit
    • 5. Änderbarkeit

  • Projektintegration

    • Mindestens 3 ähnliche Funktionen analysieren
    • Bestehende Muster und Bibliotheken wiederverwenden
    • Dieselben Test-Utilities verwenden
    • Für die Einführung neuer Werkzeuge ist eine starke Begründung nötig

  • Quality Gates

    • Alle Tests bestehen
    • Projektregeln werden eingehalten
    • Keine Linter-Warnungen
    • Commit-Message ist klar
    • Die Implementierung entspricht dem Plan
    • TODOs enthalten eine Issue-Nummer

  • Testleitlinien

    • Tests fokussieren auf Verhalten statt auf Implementierung
    • Wenn möglich nur eine Assertion pro Test
    • Klare Namen, die das Szenario beschreiben
    • Bestehende Test-Utilities wiederverwenden
    • Tests müssen deterministisch sein

  • Absolut verboten

    • Hooks mit --no-verify umgehen
    • Tests deaktivieren
    • Nicht kompilierbaren Code committen
    • Vermutungen ohne Verifikation

  • Muss unbedingt getan werden

    • Schrittweise committen
    • Dokumentation laufend aktualisieren
    • Aus bestehenden Implementierungen lernen
    • Nach drei Fehlschlägen den Ansatz neu bewerten

Mit Claude Code erstellte Open-Source-Projekte

Verwandte Beiträge

5 Kommentare

 
wedding 2025-08-11

Dass gute Ergebnisse herauskommen, bedeutet das dann, dass man den von jemand anderem bereits geschriebenen Code gut referenziert hat?
 
aeolian21 2025-08-11

Was der Autor gemacht hat, haben ohnehin längst schon alle gemacht, also prahl nicht mit Überflüssigem.
Viel sinnvoller wäre ein Beitrag, der begründet, warum du im Vergleich zwischen den LLMs zu dem Schluss gekommen bist, dass Claude am besten war.
Zum Beispiel mit einem Vergleich des tatsächlich erzeugten Codes, der Häufigkeit von Compiler-Fehlern, der Stabilität beim Erfassen des Kontexts usw.
Tatsächlich ist Gemini bei der Fähigkeit, den Kontext zu erfassen, am stärksten (1 Million Token).
 
zxcv123 2025-08-10

Er hat nur völlig nutzlose Dinge gebaut und den Text unnötig lang ausgewalzt.
 
knunu 2025-08-11

Für manche könnte das nützlich sein, haha.
 
GN⁺ 2025-08-09
Hacker-News-Kommentare

  • Heute hatte ich mit Claude und Coding-Agenten zum ersten Mal ein richtiges Erfolgserlebnis. Früher habe ich Cursor ausprobiert, inzwischen teste ich Claude und noch andere Tools parallel. Wie im Artikel erwähnt, ist das Entscheidende, eine klare Spezifikation zu schreiben. Ich habe zwei Stunden lang selbst ein 12-stufiges Dokument geschrieben, die Implementierungsmethode geordnet und auch Hintergrundinformationen ergänzt. Claude hat dann diesen Ablauf befolgt und Schritt für Schritt den Code erzeugt. Meiner Einschätzung nach hat mir das vermutlich 6 bis 10 Stunden gespart. Jetzt werde ich den Code prüfen, testen, schrittweise anpassen und Funktionen ergänzen. Die Grundlage dieses Erfolgs war, dass ich alle Schritte, die Claude ausführen sollte, selbst klar formuliert habe. Anders gesagt: Ich habe den gesamten Ablauf entworfen und Claude hat nur die Anweisungen befolgt. Durch diesen Prozess bin ich überzeugt, dass Entwickler auf mittlerem Niveau und darüber auf absehbare Zeit nicht durch AI ersetzt werden. Trotzdem ist es wirklich faszinierend zu sehen, wie Claude eine Spezifikation komplett liest und sauber dokumentierten Code ausgibt. Beeindruckend ist vor allem, dass ich nicht selbst coden musste.

    • Ich bekomme mit Claude auch ohne so viel Vorbereitung gute Ergebnisse. Ich bitte Claude fast genauso wie beim eigenen Coden um jeweils nur einen Schritt nach dem anderen. Jedes Mal übernehme und committe ich die Änderungen sofort und prüfe dann den Diff. Wenn Claude etwas Merkwürdiges produziert, fordere ich direkt eine Korrektur an. Außerdem nenne ich explizit bestehenden Code oder Funktionsreferenzen, die übernommen werden sollen. So kann man mit deutlich weniger Tipparbeit und Zeitaufwand hervorragende Ergebnisse erzielen.

    • Ich empfehle, Naurs „Programming as Theory Building“ zu lesen. Dadurch habe ich gelernt, wie man ein Problem theoretisch versteht und selbst modelliert. Sonst kann ein LLM seine eigene — womöglich falsche — Theorie erzeugen.
      „Programming as Theory Building“ - Naur lesen

    • Wie im Artikel ist eine klare Spezifikation wirklich wichtig. Ich baue mit Claude gerade eine Programmiersprache und spüre das sehr direkt. Beim Programmieren gibt es unzählige kleine Entscheidungen. Wenn man nicht klar führt, geht das LLM bei den meisten Dingen in den Vermutungsmodus und trifft oft die falsche Wahl. Diese kleinen Fehler können sich aufaddieren und am Ende zu falschen Ergebnissen führen.

    • Falls du ein Beispiel für so ein Spezifikationsdokument teilen könntest, wäre das wirklich großartig. Als jemand, der sich Entwicklung selbst beibringt und mit Claude Code experimentiert, würde mir das sehr helfen zu verstehen, welche Informationen und welche Tiefe tatsächlich nützlich sind.

    • Tatsächlich können ziemlich viele Mid-Level- und Senior-Entwickler auch keine ordentliche Spezifikation schreiben. Dem Grundgedanken stimme ich aber zu.

  • ~/.claude/CLAUDE.md anzulegen und dort Regeln hineinzuschreiben, bringt in der Praxis vermutlich nicht besonders viel. Claude ist kein Mensch und schlussfolgert nicht jede Codezeile sorgfältig einzeln. Subjektive und vage Anweisungen führen nicht dazu, dass sich der Code tatsächlich verändert. Dazu kommt das Problem des „context rot“.
    (Erklärung zu context rot: ein Phänomen, bei dem ein LLM in langen Gesprächen oder während längerer Arbeit den Kontext verliert oder verzerrt; Referenzlink: https://news.ycombinator.com/item?id=44564248)
    Realistisch gesehen ist es unmöglich, alle möglichen Regeln in eine einzige Datei zu packen und zu erwarten, dass die AI sie automatisch einhält. Wenn man das wirklich will, müsste man für jede Regel einen Sub-Agenten bauen und das nicht der AI überlassen, sondern in eine normale Pipeline auslagern. Dann steigen die Kosten allerdings exponentiell.

    • Wenn es um die Kosten geht, kann man nach Stabilisierung des Workflows günstigere LLMs einsetzen (auch wenn der Betrieb an sich teuer bleibt). Mit Fine-Tuning, Prompt-Optimierung, spezialisierten Distillation-Techniken usw. lässt sich viel sparen. In dem Bereich gibt es bereits viel Forschung.

    • Ich frage mich, welche Inhalte sinnvoll in CLAUDE.md aufgenommen werden sollten.

  • Wenn man sich die Beispielprojekte am Ende der Seite anschaut, ist die meiste Software auf einen einzigen sehr spezifischen Zweck optimiert. Ich glaube, dass sich auch Open-Source-Projekte künftig in diese Richtung entwickeln werden — extrem spezialisiert, um die Bedürfnisse einer einzelnen Person zu erfüllen. Solche Software beziehungsweise Utilities werden wohl zu Wegwerfcode, den LLMs in einem Durchgang erzeugen.

  • Mein Ansatz zu Claude Code verändert sich ständig. Es ist mir bisher noch nicht gelungen, mit Claude Code direkt sinnvolle Features für die große Web-App meines Unternehmens beizusteuern. Spezifikationen helfen bis zu einem gewissen Grad, aber am Ende driftet es doch in seltsame Richtungen ab und landet in einer Schleife falscher Entscheidungen. Das kann an den Grenzen von Claude liegen oder daran, dass meine Spezifikation noch nicht präzise genug ist. Ich habe viel experimentiert, aber bei „anspruchsvollen Dingen oder Themen mit viel Domänenwissen“ gab es so viele Fehlschläge, dass ich das nicht mehr weiterverfolge. Stattdessen nutze ich Claude inzwischen auf Empfehlung eines Freundes für Backlog-Arbeiten mit fast keiner mentalen Belastung. Ich habe Claude zum Beispiel Playwright-Tests in einem neuen Workspace erstellen lassen, an denen ich ohnehin nicht besonders hänge. Das war sehr erfolgreich. Ich habe Claude die User Experience beschrieben, als würde ich sie einem Menschen erklären, und den Pfad zum Dev-Server angegeben. Ich habe es angewiesen, mit Playwright MCP herauszufinden, welche Features wie zu verwenden sind, den Ablauf zu dokumentieren, Tests zu schreiben und Fehler zu debuggen. Dazu kam auch die Aufgabe, im UI-Code des Projekts nach data-testid-Selektoren zu suchen und sie hinzuzufügen. Den gesamten Prozess habe ich in einer master task.md festgehalten und zusätzlich anweisen lassen, für jedes Feature eigene Task-Markdown-Dateien anzulegen. Das hat sehr gut funktioniert. Ich habe es sogar bei komplexen Features eingesetzt, bei denen zwei Browser-Nutzer auf nicht intuitive Weise miteinander interagieren. Es war nicht zu 100 % präzise, aber je komplexer es wurde, desto mehr Kontextkorrekturen und Code-Anpassungen waren nötig. Insgesamt hat es trotzdem nervige Arbeit, die sonst mehrere Tage gedauert hätte, auf einen Schlag erledigt.

  • Für CLAUDE.md war es am besten, die Datei so minimal wie möglich und unter 100 Zeilen zu halten.

    • eine Zusammenfassung des wesentlichen Kontexts und Zwecks des Projekts
    • eine minimale Beschreibung der Projektstruktur, damit Typen, Interfaces und Helper auffindbar sind
    • nur die wichtigsten Commands, damit nicht ständig package.json neu geparst werden muss Im Implementierungs-/Test-Workflow habe ich erlebt, dass Claude manchmal alle Tests im Voraus auf einmal schreiben wollte oder nur dann alles implementierte, wenn Imports fehlschlugen (also nicht wirklich im TDD-Stil). Deshalb habe ich einen Hook namens TDD-Guard gebaut, der erzwingt, dass immer nur ein Test auf einmal grün wird, dass Tests aus dem richtigen Grund fehlschlagen und dass nur der minimale Code zum Bestehen des Tests implementiert wird. Die Codequalität habe ich mit husky, lint-staged, commitlint usw. automatisiert und damit sehr gute Ergebnisse erzielt. So bleibt mehr Kontext für wichtigere Informationen frei. Ich stimme zu, dass bei Blockaden in Claude Code letztlich der direkte Eingriff des Entwicklers am besten ist. Etwas unbefriedigend finde ich nur, wenn die Hinweise zu allgemein bleiben.
    • Falls du dich für einen Automatisierungsansatz interessierst:

  • Ich arbeite seit über einem Monat jeden Tag mit Claude Code. Ich habe auch Cursor und Q benutzt, aber Claude Code ist deutlich besser. Viele der im Artikel erwähnten Tipps überschneiden sich mit dem, was ich selbst gelernt habe.
    Ein paar zusätzliche Gedanken:

    • Ich beginne mit Claude im Web-Console immer mit einer Ideensession. Ich erkläre die Ziele des Projekts und skizziere grob Domänenmodellierung und Meilensteine. Bei kleinen Projekten ist das nach ein paar Stunden Hin-und-her-Diskussionen ausgearbeitet. Dort entsteht dann die erste Version von CLAUDE.md.

    • Wenn das eigentliche Projekt startet, liest Claude sowohl meine globale CLAUDE.md als auch die Projekt-CLAUDE.md, und so beginnt jede Session.

    • Während der Arbeit lasse ich Claude Code die Projekt-CLAUDE.md laufend aktualisieren. Es markiert den Fortschritt entlang des Plans und schreibt am Ende einer Session eine Projektzusammenfassung, die Funktionsweise und Hinweise zur Codenavigation hinein. Das dient als eine Art Langzeitgedächtnis. Das hat gut funktioniert.

    • So gut Richtlinien auch sein mögen: Claude hat die Tendenz, vorauseilend zu handeln. Deshalb zerlege ich Aufgaben, an denen ich aktiv beteiligt bin, immer in kleine Inkremente, damit der Fokus Schritt für Schritt erhalten bleibt. Bei One-off-Aufgaben oder Prototypen lasse ich es dagegen einfach frei umsetzen.

      • Ich frage mich, ob das 20-Dollar-Abo im Vergleich zu Cursor ein gutes Preis-Leistungs-Verhältnis hat und ob es den Preis nur dann wert ist, wenn man es täglich nutzt.

  • Die Projekt-CLAUDE.md sollte nicht zu lang sein und knapp bleiben. Detailliertere Inhalte sollten stattdessen in Unterordner verschoben werden. Die oberste Ebene dient dann als eine Art Karte. Immer wenn ein Feature geplant wird, schaut Claude in die passenden Ordner, zieht den nötigen Kontext heran und erstellt einen schrittweisen Implementierungsplan. Nach jedem Schritt lasse ich Claude den Plan mit dem neuen Kontext aktualisieren. So wird der Kontext natürlich in die nächste Phase weitergegeben, und man kann das Fenster zurücksetzen und mit frischem Kopf in den nächsten Schritt gehen.

  • Ich baue mit Claude Code ein ASCII-Spiel im Stil von Factorio. Am Anfang habe ich es fast unbeaufsichtigt coden lassen, und die meisten Hauptfunktionen — Speichern/Laden, Optionen, Debug, Kartengenerierung, Bauen, Förderbänder, Crafting, QoL usw. — wurden in einem Zug umgesetzt. Als ich dann Details korrigieren wollte, ging aber ständig etwas anderes kaputt; änderte man etwa die Bewegung, funktionierten die Förderbänder nicht mehr. Also habe ich Playwright-Automatisierung hinzufügen lassen, aber die Tests waren qualitativ schwach und voller sleep-Aufrufe. Als ich mir den Code genauer ansah, stellte ich fest, dass alles als React-Frontend mit useEffect aufgebaut war und nicht wie eine richtige Game-Engine. Die Hook-Regeln wurden nicht sauber eingehalten, und das Verständnis für Timing war schwach. Deshalb habe ich diesmal eine tick-basierte Game-Engine eingeführt und angefangen, das Ganze von Grund auf neu zu bauen, zusätzlich mit Code-Reviews. Es geht zwar langsamer voran, aber die Entwicklung ist deutlich robuster. Wenn eine gute Demo fertig ist, will ich sie als Show HN veröffentlichen.

    • Solange das grundlegende Gerüst am Anfang noch nicht steht, ist direkter menschlicher Beitrag wirklich enorm wertvoll. Nach einer Refactoring-Runde kann man sich danach etwas entspannen.

  • Falls es noch andere wie mich gibt, die Claude sowohl beruflich als auch privat abonniert haben: Mit etwas wie alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude" kann man sehr einfach zwischen den Accounts wechseln.
    Blog: Mehrere Claude-Accounts effizient nutzen

  • Alle sagen immer, der Schlüssel sei, im Voraus eine klare Spezifikation zu schreiben und so Kontext zu geben. Meiner Erfahrung nach funktioniert das aber nicht immer. Ich habe tatsächlich gemeinsam mit einem echten Experten eine CC-Session mit Opus 4 & Sonnet 4 gemacht. Die andere Person hatte eine wirklich klare Spezifikation vorbereitet, aber die Ergebnisse waren nicht besser als bei meinem Ansatz, bei dem ich Features direkt so anfordere, wie sie mir einfallen, ohne CLAUDE.md, jeweils mit dem aktuellen Kontext. Der spezifikationsbasierte Workflow hat ständig wichtige Dinge vergessen oder Sachen erfunden, die nicht im Kontextdokument standen — sogar Dinge, die ausdrücklich verboten waren. Bei mir funktionierte eher etwas wie: „Füge eine CRUD-Seite für Rechnungen hinzu, analysiere zuerst die Codebasis.“ Das ist natürlich nur anekdotisch, aber nach über 100 Projekten mit Claude kann ich außer separaten Hooks, die Überschreitungen verhindern, nicht mit Sicherheit sagen, dass irgendein bestimmter Ansatz überlegen ist. Auch wenn viele behaupten, „spezifikationsbasiert ist besser“, sieht man bei praktischen Beispielen oft eher, dass extrem viel Zeit dafür draufgeht, offensichtlich falsche Teile immer wieder zu korrigieren. Sogar wenn in CLAUDE.md steht: „Tu so etwas auf keinen Fall“, bestand weiter die Tendenz, genau das trotzdem zu tun.