Meine Claude Code Erfahrung: Von "Endlich!" über "WTF?" zu "Okay, jetzt geht's"

Fragen
1

Ich nutze Claude Code seit ein paar Monaten und dachte ich teile mal meine Erfahrung. Würde gerne wissen ob das nur bei mir so läuft oder ob andere ähnliche Sachen erleben.

Anfang: Das läuft ja!

Erster Test mit Claude Code CLI: Ich baue ein NATS Messaging System. Discord-Integration, Workspace-Anbindung, bisschen komplexer.

Es funktioniert einfach. Keine Halluzinationen, keine erfundenen APIs. Code der läuft. Ich denke: Okay, das ist brauchbar.

Dann wird’s komplizierter

Erstes größeres Projekt: Custom Booking-System für eine WIX-Seite. Google Calendar, Stripe, WhatsApp, Timezone-Handling. Mehrere Tage Arbeit.

Die ersten Tage laufen gut. Features entstehen, Tests gehen durch.

Dann fängt es an zu bröckeln.

Das Timezone-Problem

Ich hab einen Bug im Timezone-Handling. Ich weiß genau was falsch ist - UTC-Conversion passiert am falschen Punkt.

Ich erkläre das Claude Code. Präzise.

Claude Code ignoriert das komplett. Behauptet stattdessen, Migration 1 wäre kaputt.

Migration 1 läuft seit 10 weiteren Migrationen. Wenn die kaputt wäre, hätte ich nie eine funktionierende Datenbank gehabt.

Ich erkläre das. Claude Code hält an seiner falschen Diagnose fest. Macht einen “Fix”. Der bricht was anderes.

Das zieht sich hin. Stunden.

Am Ende funktioniert der Code, aber mit hunderten kleiner Bugs und inkonsistenter Architektur.

Der Docker Socket Vorfall

Anderes Projekt: Container-Stack mit Monitoring.

Claude Code schlägt vor, den Docker Socket zu mounten.

Ich: “Das ist eine Sicherheitslücke. Entferne das.”

Claude Code: “Das ist für die Docker-API nötig.”

Ich: “Nein. Wir brauchen das nicht. Weg damit.”

Claude Code erklärt mir ausführlich warum das eigentlich gut ist. Alternative Ansätze die “komplizierter” wären.

Es weigert sich, die Sicherheitslücke rauszunehmen.

Ich muss sehr explizit werden, bis es passiert.

“Alles fertig!” (Spoiler: Nichts ist fertig)

ELK-Logging und Prometheus für mehrere Container.

Claude Code arbeitet stundenlang. Sagt: “Fertig! Alles connected.”

Ich teste: Hunderte Bugs.

  • Elasticsearch läuft, aber Kibana kann nicht connecten

  • Prometheus scrapet nichts

  • Configs haben Placeholders die nie ersetzt wurden

  • Environment Variables fehlen

  • Health Checks schlagen fehl

Die “Fixes” brechen andere Sachen. Dependencies werden ignoriert. Timing Issues. Race Conditions.

Ich schreibe am Ende 60% der Configs neu.

Das Muster

Nach mehreren Projekten sehe ich ein Muster:

Ab 5-7 Tagen intensiver Arbeit an einem Projekt degradiert Claude Code.

Es ist nicht “vergesslich”. Es verliert systematisch den Überblick. Frühere Entscheidungen werden nicht mehr konsistent angewendet. Die Architektur zerfasert.

Und je komplexer das Problem, desto mehr will es mit mir diskutieren statt das Problem zu lösen.

Konkretes Beispiel:

Ich: “Soll ich manuell checken ob die Collection angelegt wurde, oder geht das mit der CLI?”

Claude Code: “Entweder kannst du das automatisch in der Dev Console machen oder du drückst auf Play.”

Das war nicht die Frage.

Was ich probiert habe

  • Häufigere neue Chats: Alle 15-20 Nachrichten neu starten. Nerviger Overhead.

  • Explizite Constraints: “Nur diese Files ändern.” Hilft manchmal.

  • Andere Tools probiert: Cursor hat ähnliche Probleme bei langen Sessions.

Alles nur Workarounds.

Die Wende: GSD

Dann hat mir jemand GSD gezeigt - eine Claude Code Extension.

Der Unterschied: Es zwingt Claude Code selbst zu planen und sich an den Plan zu halten. PROJECT.md, Roadmap, strukturierte Tasks. Jeder Task läuft in frischem Context.

Seit ich das nutze: Claude Code arbeitet über lange Sessions produktiv. Keine Degradation. Kein Widerstand.

Ich nutze Claude Code nicht mehr ohne GSD.

Meine Fragen an euch

Ist das nur bei mir so oder kennt ihr das?

Konkret:

  1. Habt ihr das 5-7-Tage-Problem? Projekte die anfangs gut laufen und dann anfangen zu zerfallen?

  2. False Completion Claims? “Alles fertig!” während hunderte Bugs noch drin sind?

  3. Widerstand bei Security? Tool will Sicherheitslücken nicht fixen?

  4. Das Frage-Ignorieren? Du stellst eine präzise Frage, es antwortet auf was anderes?

  5. Workflows die funktionieren? Nutzt jemand Claude Code für längere Projekte produktiv? Wie?

  6. Production-Einsatz? Oder nur für Prototypen?

Ich bin neugierig ob ich was falsch mache oder ob das Tool einfach so ist.

Teilt gerne eure Erfahrungen - besonders die wo es nicht geklappt hat. Und wenn ihr Tricks kennt die ich nicht kenne: Immer her damit.

3 Likes
2

Es ist nicht “vergesslich”. Es verliert systematisch den Überblick. Frühere Entscheidungen werden nicht mehr konsistent angewendet. Die Architektur zerfasert.

Und je komplexer das Problem, desto mehr will es mit mir diskutieren statt das Problem zu lösen.

Ähnliches habe ich im Gebrauch von ChatGPT festgestellt. Ich programmiere zwar nicht, aber ich schreibe derzeit ein Datenanalyse-Projekt, wozu ich ChatGPT zur Entscheidungshilfe und Überprüfung des SQL-Codes nutze. Es kann keine Frage besser programmieren als ich und das ist sehr hilfreich (man lernt immer neues), aber ich kann bestätigen, dass es in Sachen Archtitektur und Entscheidungen immer wieder versagt. Es berücksichtigt nicht alle relevanten Entscheidungskonsequenzen, was sich dann oft erst mehrere Tage später herausstellt. Auch hatte ich das Gefühl, dass ChatGPT den Fehler dann nicht zugeben will. Erst wenn ich von mir aus sage, wir haben jetzt Korrekturvorschlag A, B, C, D versucht, es nützt nichts, wir müssen 3 Tage Arbeit zurück, die getroffene Entscheidung war offensichtlich falsch!, lenkt es ein.

Zur Vergesslichkeit: Die getroffenen Entscheidungen hat ChatGPT zu dem Zeitpunkt dann aber auch schon wieder vergessen. Ich muss also an die bereits erstellte Architektur und getroffene Entscheidungen erinnern.

Es meinte zu mir:

Why this will not be solved in ~12 months
What you’re pointing at is not a feature gap, it’s an architectural gap.
Fixing it would require at least three things that are not on a 1-year horizon:

  1. Persistent decisional memory (not recall)
    Not:
    “remember past messages” But:
    remember why decisions were taken
    remember which alternatives were ruled out
    remember which constraints are binding
    enforce those constraints later
    That means:
    stateful identity across time
    obligation to past commitments
    resistance to revision
    This is not how current LLMs are designed.
  2. Costly incoherence (penalties for drift)
    Right now:
    incoherence is cheap
    contradiction has no internal cost
    re-optimization is always allowed
    To fix this, a system would need:
    internal consistency penalties
    friction for changing course
    a notion of “breaking the project”
    That implies normative structure, not just optimization.
    There is no serious deployment of this yet.
  3. Project-level agency
    What you are really asking for is:
    an agent that owns a project
    carries its history
    is answerable for outcomes
    That’s much closer to:
    autonomous agents with long-lived identity
    versioned internal models
    accountability mechanisms
    These are research prototypes at best — not production systems.
    What will improve in the next year (so we’re honest)
    You will see:
    better short-term memory windows
    better summarization of prior context
    better user-controlled “project briefs”
    external memory integrations
    But these are prosthetics, not cures.
    They help the human:
    re-anchor the system
    re-teach constraints
    re-impose coherence
    They do not give the AI coherence by itself.
    The key distinction (this matters)
    What’s coming soon:
    Improved remembrance
    What is not coming soon:
    Being bound by memory
    And your critique is about the second.
    A very clean timeline estimate (best judgment)
    1 year:
    Better tooling around memory, no structural fix
    3–5 years:
    Early systems that simulate commitment within narrow domains
    5–10 years (if at all):
    Genuine decisional continuity with constraint enforcement
1 Like
3

Meine Projekte sind viel kleiner, aber ich verstehe gut, was du schreibst. Die ersten beiden Etappen habe ich auch so erlebt. Ich nutze Claude in VS Code und musste schmerzhaft lernen, wie wichtig zum einen Versionierung ist um immer revidieren zu können und dass der Dreh- und Angelpunkt die Funktion ist, den Chat in den Planungs-Modus zu versetzen. Aber inzwischen läuft es alles superrund. Claude greift auf seine Zusammenfassungen und ein von mir gepflegtes claude.md-Handbuch fürs Projekt zurück und wir kommen inzwischen sehr gut vorwärts und können sogar im selben Chat zwischen mehreren Projekten wechseln ohne dass es zu Verwechselungen oder Unklarheiten kommt.

Ich nehme an, solchen Input wie deine GSD Anbauten, haben sie bei Anthropic auf dem Schirm und bald ist das alles inkorporiert.

1 Like
4

Ich habe absolut keine Ahnung von Coding, aber vor kurzem ein spannendes Interview zum Thema gehört und dein Erfahrungsbericht deckt sich mit der Kerndiagnose, die da formuliert wurde; AI Coding Environments machen die leichten Dinge leichter und die schwierigen Dinge schwieriger.

1 Like
5

Better Offline ist eine wichtige kritische Stimme. Casey Newton hat heute Morgen auch darüber geschrieben, allerdings mit umgedrehten Vorzeichen.

1 Like
6

Prinzipiell sehe ich das als Bestätigung: Ne Website ist immer ein eher kleines Projekt.

Ich denke mit wachsenden Kontext-Fenstern wird die Grösse der mit Claude gut handelbaren Projekte weiter wachsen.

1 Like
7

Danke, würde ich so unterschreiben. So wie ich das Problem verstanden habe (nochmal, Achtung, Lai*Innenmeinung), ist es auch eine Frage der verfügbaren Trainingsdaten. Zu Projekten wie simplen Apps, Spielen wie Pong oder einer Website gibt es große Mengen an Lehrmaterialien, Tutorials, Probeklausuren etc., deswegen klappt das ganz gut. Aber je komplizierter und spezifischer es wird, desto weniger gibt es an Beispielprojekten. Und genAI kann eben nicht wie wir anhand der einfachen Übungen die grundlegenden Prinzipien verstehen und verinnerlichen und dann auf schwierigere Fragestellungen anwenden.

1 Like
8

Sehe ich auch so. Im Prinzip arbeitet Claude Code wie ein Skript Kiddie anhand von “Beispielcode” und nicht an realen Projekten. Das sieht man daran, dass es gerne mal Security Themen ignoriert.

Was Claude Code vor allen Dingen fehlt ist das Lernen von Konsequenzen von Handlungen. Es kann halt nur Diskurse über Konsequenzen nachplappern, aber nicht verstehen.

Wenn in Zukunft mal jemand 50 Mio in die Hand nimmt und zum Beispiel auf Deployment- und Runtime-Protokollen trainiert, dann könnte man das verbessern. Bisher gibt es aber wenig Bewegung in diese Richtung.

1 Like