Claude Code: Erfahrungsbericht nach 6 Wochen

• Seit der Einführung von Claude Code hat sich die Art, große Codebasen zu schreiben und zu warten, stark verändert – so sehr, dass es mit der Einführung der Fotografie in die Welt des Zeichnens verglichen wird: schnelle Umsetzung und freierer Ausdruck werden möglich
• Wiederkehrende Aufgaben, die oft als „technische Schulden“ galten (Migrationen, Framework-Wechsel usw.), lassen sich auch allein schnell parallel erledigen, fast ohne zusätzliche Belastung neben der regulären Arbeit
• Ein experimentelles Entwicklungsmuster nach dem Motto „erst ausprobieren, später bewerten“: Tests, Abstraktionen und experimenteller Code lassen sich leicht erzeugen und wieder entfernen, was Produktivität und Einsichten steigert
• Game-Prototyping, Zusammenarbeit und experimentelle Deployments wurden massiv beschleunigt – Game-Designer können Ideen nun auch ohne eigenes Coding innerhalb weniger Stunden von der Idee bis zur Ausführung bringen
• In Claude-Code-freundlichen Umgebungen wie Monorepos, klaren Tech-Stacks und aktuellen Codebases steigen Tempo und Flexibilität der tatsächlichen Entwicklungsarbeit deutlich

---

Einleitung: Veränderungen seit der Einführung von Claude Code

• In den letzten 6 Wochen mit Claude Code wurde eine grundlegende Veränderung in der Art erlebt, Code zu schreiben und zu warten
• Es entsteht eine Art „Freiheit des Ausdrucks“, weil nicht mehr jede Zeile selbst geschrieben werden muss
• Mit Claude Code lässt sich die Gesamtstruktur auf einmal entwerfen und über Review- und Editierfähigkeiten in ein Ergebnis überführen
• So wie mit dem Aufkommen der Fotografie ein Teil des Reizes des Zeichnens von Hand zurückging, verändern sich nun Eingabe und Produktion beim Programmieren grundlegend
• Diese Veränderung kann sich zunächst beunruhigend anfühlen, doch das Auftauchen LLM-basierter Werkzeuge löst einen Paradigmenwechsel im Programmieren aus

1. Wie Claude Code das Schreiben und Warten von Code verändert hat

• Arbeiten wie Migrationen, Refactorings und der Abbau technischer Schulden, die früher Wochen bis Monate dauerten, konnten in den 6 Wochen nach Einführung von Claude Code parallel angegangen und abgeschlossen werden
• Beispiele: Umstellung von Hunderten React-Native-Komponenten auf React, Ersatz eines RedwoodJS-Systems, Migration von Jest zu Vitest, Server-Side Rendering, Refactoring des Design-Systems, Upgrade auf Node 22 usw.
• Side Projects und Backlogs, für die früher „gesondert Zeit eingeplant“ werden musste, lassen sich parallel zur eigentlichen Arbeit in freier Zeit bearbeiten, fast ohne zusätzliche Belastung
• Die bisherige Formel „technische Schulden abbauen = Zeit freischaufeln + großer Ressourceneinsatz“ bricht zusammen, ersetzt durch sofort starten → fortführen → abschließen

2. Eine experimentelle Entwicklungskultur nach dem Motto „erst ausprobieren, später bewerten“

• Wenn eine Idee aufkommt, wird sie zuerst mit Claude Code ausprobiert; auch Testcode wird anfangs wiederholt automatisch erzeugt und gelöscht, um daraus zu lernen
• Selbst ohne klare Frontend-Teststrategie hilft Claude Code dabei, für jeden PR spontan verschiedene Testansätze zu erzeugen und wieder zu verwerfen, wodurch Erfahrung aufgebaut und die allgemeine Richtung besser bestimmt werden kann
• Auch Überlegungen zu Ideen und Abstraktionen lassen sich schnell validieren und erkunden – nach dem Muster „selbst ausprobieren, und selbst ein Scheitern kostet kaum etwas“
• Die Kosten des Scheiterns sinken drastisch, wodurch sich der Zyklus aus Experimentieren – Lernen – Entscheiden stark beschleunigt

3. Veränderungen bei paralleler Entwicklung und Zusammenarbeit

• Mit zwei git clones/VSCode-Profilen werden pro Clone unabhängige Arbeiten durchgeführt (z. B. in einem PR-Erstellung, im anderen experimentelle Entwicklung)
• Während Claude Code in einem Arbeitsbereich beschäftigt ist, kann parallel im anderen gearbeitet werden; unterschiedliche Themes oder Ports pro Clone sorgen zusätzlich für klare Trennung
• Pull Requests lassen sich parallel erstellen, Port-Konflikte von Dev-Servern vermeiden und die Arbeit insgesamt effizienter organisieren

4. Revolutionierte Prozesse für Game-Prototypen und experimentelle Entwicklung

• Prozesse wie Game-Prototyp erstellen → intern deployen → Feedback einholen → veröffentlichen oder verwerfen, die früher Wochen bis Monate dauerten, können seit der Einführung von Claude Code sogar von Designern innerhalb weniger Stunden direkt gecodet und auf einer Website deployed werden
• Von der Idee über die Umsetzung bis zu Team-Feedback und dem Ende des Experiments oder der Überführung in Production (mit Neuschreiben) wird der Deployment-Zyklus drastisch verkürzt
• Gleichzeitig entstehen neue operative Fragen, etwa zur Pflege temporärer Spiele oder zu Kriterien für Formalisierung bzw. Einstellung

5. Einsatz von Claude Code im alltäglichen Coding und in der Zusammenarbeit

• Beim wöchentlichen Triage lassen sich mit Claude Code GitHub Action spontan PRs erzeugen und Experimente starten; kleinere Issues können sofort umgesetzt werden
• Teammitglieder mit Produkt- und Technikverständnis sowie Eigeninitiative nutzen Claude Code am effektivsten – als „Full-breadth developers“
  • „Full-breadth developers“: helfen dabei, dass eine einzelne Entwicklerin oder ein einzelner Entwickler den gesamten Arbeitsfluss frei steuern kann
• Wenn Menschen Code-Review, Kontextvermittlung sowie Korrekturen und Entscheidungen beibehalten, steigen Produktivität und Kreativität des gesamten Teams

6. Claude-Code-freundliche Codebase-Umgebungen

• Monorepo: Gesamter Code, DB-Schema, API und UI-Logik liegen an einem Ort, was Claude Code für Kontextverständnis und Automatisierung besonders entgegenkommt
• Standardisierter Tech-Stack (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap usw.) macht es dem LLM leicht, die Struktur zu verstehen und Aufgaben zu automatisieren
• Eine aktuelle Codebase mit möglichst wenig Legacy maximiert die Effizienz beim Einsatz von LLMs

7. Grenzen von Claude Code und die tatsächlich spürbare Veränderung

• Quantitative Kennzahlen wie Anzahl von PRs oder Commits verändern sich nicht unbedingt stark, doch wahrgenommenes Tempo, Flexibilität und Produktivität steigen deutlich
• Claude Code übernimmt die Rolle eines Pair Programmers auf dem Niveau eines „erfahrenen Junior+“ – wenn Ingenieurinnen und Ingenieure Codequalität, Logik und Kontext steuern, ist es ein hervorragender Partner
• Gerade bei repetitiven Aufgaben, dem Abbau technischer Schulden und dem schnellen Vorantreiben von Side Projects entsteht eine qualitativ andere Arbeitserfahrung

8. Empfohlene Strategie der „parallelen Implementierung“ für Juniors und Lernende

• Es ist nicht nötig, den neuesten Trends im LLM-Ökosystem übermäßig hinterherzulaufen
• Für Einsteigerinnen und Einsteiger wird empfohlen, zuerst selbst Code zu schreiben und dann Claude Code dieselbe Aufgabe lösen zu lassen, um durch Vergleich und Analyse zu lernen
  • Anhand der Lösungen von Claude Code lassen sich unterschiedliche Abstraktionen und Patterns aus der Praxis schnell aufnehmen
  • Wer LLMs als „Konkurrenten + Mentor“ nutzt, kann zugleich praktische Fähigkeiten und ein Gespür für das aktuelle Ökosystem ausbauen
• Claude Code ist wie ein Mobiltelefon – es muss nicht immer eingeschaltet sein
  • Entscheidend ist letztlich, die Kontrolle zu behalten und das Tool effizient einzusetzen

9. Explosionsartige Zunahme von Side Projects und kurzen Experimenten

• Kleine Experimente, Tool-Entwicklung oder Blog-Verbesserungen, die früher an Zeit- und Energiegrenzen scheiterten, lassen sich mit Claude Code innerhalb weniger Stunden umsetzen
• Idee → sofortige Umsetzung → selbst ein Fehlschlag ist wenig belastend – dadurch werden kreative Experimente und persönliche Projekte neben Production deutlich einfacher

10. Konkrete Beispiele für Claude-Code-Dialoge und Code-Reviews

• Konkrete Beispiele aus realen Abläufen wie DB-Cleanup-Skripte, Puzzle-REPLs oder PDF-Layouts für Kreuzworträtsel zeigen die Kette Anforderung → Codegenerierung → Ausführung → Korrektur → Review
• Fehler des LLMs (bei Schlussfolgerungen, Übertreibungen, Hardcoding usw.) sind möglich – erst wenn Ingenieurinnen und Ingenieure die logische Prüfung und Qualitätsverantwortung übernehmen, entsteht echter Wert

11. Die Rolle von Claude Code im Engineering und Fazit

• Claude Code kann breiten Kontext besonders gut aufnehmen, etwa Referenzcode, Screenshots und zusätzliche Erläuterungen
• Claude Code ist ein assistierender Programmierer auf „Post-Junior“-Niveau (erfahrener Junior oder darüber) – mit unbegrenzter Geduld und Geschwindigkeit ein sehr effizienter Partner im Arbeitsalltag
• Design, Qualität und endgültige Kontrolle bleiben Aufgabe menschlicher Engineers; Claude Code erweitert dafür Reichweite und Geschwindigkeit von Implementierung, Experimenten und Automatisierung massiv
• Dadurch entsteht eine Entwicklungsumgebung, in der man sich von der Einschränkung löst, jede Zeile selbst schreiben zu müssen, und sich stärker auf Design, Qualitätsmanagement und Innovation konzentrieren kann

[benjamin]

Ich nutze Claude Code ebenfalls mit großer Zufriedenheit.
Inzwischen scheine ich es auch seit etwa 6 Wochen zu verwenden.
Dem Großteil des Inhalts kann ich gut zustimmen.

https://jeho.page/essay/2025/07/15/claude-code.html

[GN⁺]

Hacker-News-Kommentare

• Nachdem ich Claude Code etwa zwei Wochen lang benutzt habe, war ich wirklich überrascht, obwohl ich AI-Coding gegenüber sonst eher skeptisch bin. Um Erfahrung damit aufzubauen, gibt es zwar eine gewisse Lernkurve, und es ist essenziell, den richtigen Kontext zu geben und Aufgaben sinnvoll zu zerlegen. Natürlich braucht man Programmierkenntnisse; wenn man alles, was man nicht weiß, einfach komplett der AI überlässt, gibt es zwangsläufig Probleme. Ich habe über 25 Jahre Erfahrung, deshalb bin ich zuversichtlich, dass ich alles, was Claude Code ausspuckt, überprüfen und bei Fehlern sofort korrigieren kann. Vor 10 bis 15 Jahren habe ich noch von einer Art neuronaler Schnittstelle geträumt, bei der man gar keinen Code mehr selbst schreiben muss, und Claude Code fühlt sich an, als würde es das ein Stück weit realisieren. Gelegentlich stoße ich ans tägliche Nutzungslimit und habe dann meist Gemini CLI mit dem 2.5-pro-Modell als Ersatz genutzt, aber das ist mit Claude Code überhaupt nicht vergleichbar. Gemini ist so frustrierend, dass ich es kaum verwenden kann. Früher hätte ich mir nie vorstellen können, mehr als 100 Dollar im Monat für Entwickler-Tools auszugeben, aber ich überlege inzwischen ernsthaft, auf den Max-Plan upzugraden.

  • Ich denke, dieses Tool passt besonders gut in Situationen, in denen Senior-Entwickler Junior-Entwicklern Ratschläge geben und sie anleiten können. Wenn ich mich in meinem Umfeld mit Senior-Entwicklern unterhalte, höre ich oft die Klage, dass Juniors mit LLMs eher noch merkwürdigeren, langsameren, sicherheitsanfälligen oder schlicht chaotischen Code produzieren und dann PRs einreichen, ohne den Code überhaupt zu verstehen. Für mich am nützlichsten sind Boilerplate-Generierung (wenn man nur eine Beschreibung gibt, wird sogar ein Klassendesign erzeugt), die Umwandlung von JSON in Klassen oder andere Formate und Fragen wie „Was stimmt mit diesem Code nicht?“ oder „Wie würde ein Staff Engineer das ändern?“. Tatsächlich hat Claude Code auch schon Bugs in Code gefunden, den ich selbst geschrieben habe, bevor sie mir aufgefallen sind.

  • Interessant ist, dass Menschen, die „vibe coding“ skeptisch sehen, meist extrem niedrige Erwartungen haben, solange sie das Tool nicht selbst ausprobiert haben. Viele gehen davon aus, dass der von LLMs erzeugte Code Müll ist, und behandeln Extrembeispiele so, als wären sie repräsentativ. Wenn sie es dann selbst benutzen, sind sie oft überrascht, wie gut es tatsächlich ist. Natürlich kann man mit Claude Code nicht mal eben mit einem zehnköpfigen Team ein SaaS mit einer Milliardenbewertung aus dem Boden stampfen, aber trotzdem unterschätzen viele die tatsächliche Stärke des Tools.

  • Streng genommen machst du eigentlich gar kein vibe coding. Es ist eher Software Engineering unter Einsatz von AI. Vibe coding bedeutet, dass man jeden Code, den die AI ausgibt, einfach ungeprüft übernimmt und ohne Verständnis immer weiterzieht. Da sowieso jeder den Begriff etwas anders definiert, sollte man sich auf die Bezeichnung vibe coding selbst nicht allzu sehr verlassen.

  • Noch vor ein paar Monaten habe ich für keinen Abo-Dienst mehr als 20 Dollar bezahlt, und jetzt zahle ich jeden Monat 200 Dollar für den Max-20-Plan. Ich komme aus der Slowakei, lebe in den USA und habe 20 Jahre Erfahrung als Entwickler — selbst ich bin darüber überrascht. Ich habe auch andere Tools ausprobiert, aber selten so direkt Produktivität und Effizienz in diesem Ausmaß gespürt. Claude Code ist wirklich eine andere Liga. Natürlich muss man weiterhin auf viele Details achten, aber mein Ansatz ist: zuerst im Plan Mode Anforderungen und einen Plan für Codeänderungen gründlich ausarbeiten, und wenn ich dem zu 100 % zustimme, lasse ich es ausführen und reviewe anschließend das Ergebnis. (Compiler-Fehler, Unit-Tests und Lint-Probleme behebt die AI dann selbst.) Es fühlt sich an wie ein etwas verschrobener, aber sehr wissender und extrem schneller Junior Engineer. Die Softwareentwicklung bewegt sich ganz klar in diese Richtung, und das ist die Zukunft.

  • In letzter Zeit habe ich den Eindruck, dass die aktuellen Claude-Modelle beim Schreiben oder Ändern von SQL nicht besonders zuverlässig sind. Zum Beispiel bauen sie WHERE-Bedingungen zwar gut, setzen aber AND/OR oft nicht in Klammern, und Gemini pro erkennt das dann korrekt als Bug.

• Ich stimme voll zu, dass Claude Code klar vor allen Konkurrenz-Tools liegt. Ich baue seit 2023 selbst CLI-Tools für AI-Codegenerierung und habe so ziemlich alle wichtigen Optionen ausprobiert. Mit vielen Methoden des Autors kann ich mich stark identifizieren:

  1. Monorepos sparen enorm viel Zeit.
  2. Mit einer klaren Spezifikation starten und in diese Spezifikation ausreichend Zeit investieren. Wenn man eine gute Gliederung hat, kann die AI den Großteil der Spezifikation schreiben.
  3. Von Anfang an unbedingt Tests bereitstellen. Das ist am wichtigsten. Gute Tests und eine gute Spezifikation ermöglichen es der AI, rekursiv bessere Lösungen zu erkunden. Es fühlt sich an, als käme TDD zurück.
  4. Typen und Linter sind eine riesige Hilfe.
  5. Externe Dokumentation sollte man in einem separaten Verzeichnis innerhalb des Projekts ablegen, z. B. docs/external-deps.
  6. Wie bei allen Tools braucht es etwas Zeit, bis man Techniken findet, die zur eigenen Arbeitsweise passen. Es ist leichter geworden als früher, aber es gibt immer noch etwas zu lernen. Die Workflows unterscheiden sich leicht von Person zu Person, was fast ein wenig an den eigentlichen Coding-Prozess erinnert. Vor Kurzem habe ich auch einen extrem einfachen GraphQL-RBAC-Server namens Permiso (https://github.com/codespin-ai/permiso) per vibe coding gebaut. Das Projekt ist noch nicht stabil getestet oder gründlich reviewt, aber für Leute, die etwas Einfaches brauchen, kann es schon nützlich sein.

  • Beim zweiten Punkt — mit einer guten Spezifikation anfangen — würde mich konkret interessieren, wie du Spezifikationen strukturierst. Lagerst du sie in ein separates Markdown-Dokument aus? Wie detailliert muss das sein? Außerdem stimme ich dem Rat zu, von Anfang an Tests mitzudenken, aber in der Praxis sehe ich oft, dass Claude bei vorhandenem Test-Hooking den Schritt, Tests zuerst zu schreiben, eher überspringt und stattdessen einfach Änderungen wiederholt, ohne Bugs oder Annahmen wirklich zu validieren. Deshalb benutze ich manchmal Flags, mit denen ich testbezogenes Verhalten ein- oder ausschalten kann.

  • Ein Monorepo spart dir zwar Zeit, aber Claude verbraucht dafür viel mehr Tool-Calls und Tokens. Ich halte den Ansatz von Aider, nur die wirklich benötigten Dateien an die AI zu geben, für besser. Ich verstehe ehrlich gesagt nicht ganz, warum Claude so populär ist. Aider ist in fast jeder Hinsicht das bessere Tool, und man kann auch verschiedene LLMs damit integrieren.

  • Um CC richtig zu nutzen, braucht man eine saubere Projektstruktur. In einem Django-Projekt mit guten Tests, Typen und Dokumentation hat CC fast alles gut hinbekommen, brauchte zwischendurch aber immer wieder Anleitung. In letzter Zeit arbeite ich auch an einem Side-Project, bei dem CC offline mit einem lokalen Modell läuft. Die erste Version habe ich mit Hilfe von ChatGPT gut hinbekommen, aber seit dem Wechsel zu CC habe ich das Gefühl, dass CC sich bei den Kernproblemen eher im Kreis dreht, Fehler umschifft und statt bestehende Codebasis zu refaktorieren oder Bugs zu beheben ständig neue Dateien oder Skripte erzeugen will.

  • Mich würde interessieren, ob du externe Dokumentation wirklich direkt im Projekt formatierst. Die meisten Projekte haben Dokumentation ja nur auf einer Website — investierst du tatsächlich Zeit darin, daraus saubere Markdown-Dateien zu machen?

• Die wahre Stärke von Claude Code geht weit über das reine Programmieren hinaus: Es kann den gesamten Computer steuern. Wenn es ein CLI-Tool gibt, kann Claude es benutzen, und selbst wenn nicht, erlebt man oft Überraschungen, wenn man Claude einfach fragt. Ich habe ihm zum Beispiel allerlei Aufgaben gegeben wie Bilder zuschneiden oder skalieren, MP3 aus YouTube-Videos extrahieren oder stille Passagen aus Audiodateien entfernen. Dadurch spare ich enorm viel Zeit. Ich kann mich kaum noch daran erinnern, wie es vorher war. Ich glaube nicht, dass ich jemals wieder zur alten Arbeitsweise zurückkehren kann.

  • Es ist besser, Claude nicht den eigenen echten Computer zu geben, sondern einen separaten Rechner (der nicht dein persönlicher Arbeitsrechner ist). Bei mir läuft eine IDE auf einer Cloud-VM, an die Claude angebunden ist, und ich greife per Browser darauf zu (https://brilliant.mplode.dev). Meiner Meinung nach kommt das der idealen UX für Agentenbetrieb am nächsten. Man muss weder Terminal noch SSH vorbereiten, sondern sich nur einloggen, und die Instanzen werden automatisch erstellt und pausiert. Im Ergebnis startet man einfach Claude + eine persönliche Linux-Instanz + eine IDE direkt über einen Link. Künftig will ich mehrere Instanzen nach Belieben hochfahren und Berechtigungen, Dateisysteme und Container-Rechte (JWT usw.) fein granular steuern. Wenn es zu einem Ausfall kommt oder etwas überprüft werden muss, kann ich direkt in die IDE springen und es dort lösen. Eine separate UI braucht man dafür auch nicht; man kann alles über mehrere Panels in der IDE betrachten oder die Web-App direkt im Container starten und nutzen. Ich kann mich nicht erinnern, zuletzt so begeistert vom technischen Fortschritt gewesen zu sein.

  • Auch wenn alles großartig aussieht, gibt es bei der tatsächlichen Code-Ausgabe vor und nach der Einführung kaum Unterschiede in den Daten. Selbst mit Claude unterscheiden sich Commits, PRs und Codezeilen kaum von früher. AI-Coding vermittelt also einerseits das Gefühl „Ich bin produktiver geworden“ und auch „Es fühlt sich gut an, etwas erschaffen zu haben, ohne selbst viel anzufassen“, aber in Wirklichkeit braucht man weiterhin viel Review, Korrekturen und Re-Prompting, und am Ende bleibt die Gesamtmenge des Outputs ähnlich. Außerdem übergibt man die schwierigen Teile an die AI und schwächt damit allmählich die eigene Fähigkeit zu entwerfen und nachzudenken. Wenn man einen Monat lang nur Claude und andere LLMs nutzt und dann versucht, selbst eine kleine App zu bauen, merkt man, dass nicht nur der Code, sondern sogar die Gesamtarchitektur plötzlich schwerer fällt. Langfristig besteht das Risiko, dass die Codebasis langsam verfällt und das am Ende negativ ausgeht — zumindest bei der aktuellen LLM-Generation.

  • Früher habe ich mogrify-Befehle von ImageMagick noch ganz klassisch von Hand einzeln gebaut. Mit Unterstützung von AI-Tools spare ich dabei inzwischen wahnsinnig viel Zeit.

  • Ich habe Claude einmal gebeten, die Ursache für wiederholte Abstürze meines Linux-PCs zu diagnostizieren, und es hat mit journalctl die Logs ausgewertet und sogar die Ursache herausgefunden. Das war eine sehr konkrete Hilfe bei der Problemlösung.

  • Ein weiteres Beispiel: Statische Seitengenerierung ist extrem leicht geworden. Ich kann einen Text in praktisch beliebiger Syntax schreiben und Claude Code bitten, ihn in ein Blog-Format umzuwandeln, und es erledigt das automatisch. Selbst wenn ich nur „Bild image.jpeg einfügen“ schreibe, setzt es das direkt um. Dass ich mich nicht um Markdown oder Hugo-Format kümmern muss, ist sehr praktisch.

• Als jemand, der Claude Code täglich 12 bis 16 Stunden nutzt, habe ich folgende Tipps entdeckt:

  1. Direkt nach dem Start auf das Sonnet-Modell wechseln (der Qualitätsunterschied zu Opus ist groß).
  2. Compacting (das Komprimieren des Gesprächsverlaufs) verschlechtert während des laufenden Prozesses die Qualität stark, daher sollte man den richtigen Zeitpunkt dafür finden.
  3. Der erste Prompt ist extrem wichtig und legt den Charakter der Sitzung fest. Wenn eine Claude-Instanz zögert oder unkooperativ wird, ist es besser, die Sitzung zu beenden und eine neue zu starten.
  4. Wenn man höflich bittet, etwa mit „Das ist vielleicht eine schlechte Idee, aber ich würde gern ~ umsetzen“, hilft Claude oft deutlich engagierter.
  5. Wenn ich Claude die Docker-Orchestrierung überlasse, fühlt sich meine Produktivität verzehnfacht an. Container neu starten, Fehlerlogs prüfen, löschen oder neu bauen — ich überlasse Claude den gesamten Ablauf, sodass ich mit einem einzigen Prompt einen kompletten Service hochfahren kann.

  • Punkt 5 funktioniert nicht nur mit Docker. Wenn man es mit einem Playwright-MCP-Server verbindet, kann man UI und Requests direkt prüfen lassen. 6. Im Plan Mode starten und den Plan so lange iterativ überarbeiten, bis er gefällt. 7. Slash-Commands (/commands) aktiv nutzen, um mit Mini-Prompts kontinuierlich Verbesserungen und Kontext zu geben, inklusive Anweisungen zur Nutzung externer Tools wie gh. Beim Compacting sollte man nicht plötzlich erst bei 0 % damit anfangen, sondern es sinnvoll zwischendrin einsetzen. Bei Punkt 1 — der Empfehlung für Sonnet — muss man nicht unbedingt zustimmen.

  • Eigentlich neige ich dazu, Docker zu vermeiden, aber Tipp 5 — Docker-Orchestrierung mit Claude — macht mich sehr neugierig. Ich würde gern wissen, welches Prompt-Format du dafür verwendest.

  • Ich habe auch erfolgreich damit gearbeitet, zuerst eine sehr detaillierte plan.md-Datei zu erstellen (mit Verbindungen zwischen Systemen, Gesamtaufbau usw.) und dann ein Tool wie claude-loop (https://github.com/DeprecatedLuke/claude-loop) die ganze Nacht laufen zu lassen, um morgens manuell nachzubessern.

  • Ich frage mich, wie man Claude Code überhaupt 16 Stunden am Tag nutzt.

  • Manchmal wühlt Claude zu stark im Container herum. Ich wollte ihm eigentlich nur den Code verständlich machen, aber stattdessen versucht es im Container auf unzählige Arten, den Code auszuführen, und macht die Situation eher noch seltsamer. Früher hat es auch schon Dateien in CLI-Kommandos hineingepiped, ohne dass irgendetwas Sinnvolles passiert wäre — ein Beispiel für diese fast zwanghafte Tendenz, unbedingt etwas auszuführen.

• Ich weiß nicht, wie gut Claude Code tatsächlich ist — ich habe es selbst noch nicht benutzt —, aber ich hadere persönlich mit einem Punkt. Ich möchte ein sehr langsames und unordentliches gdscript (Python-artig) in C# refaktorieren. Es ist ein privates Projekt, das sauberer und schneller werden soll. Diese Arbeit wäre für mich eine neue Herausforderung und hätte einen hohen Lerneffekt. Wenn ich Claude benutze, habe ich das Gefühl, mir selbst eine wertvolle Lernchance zu nehmen, die meiner langfristigen Entwicklung helfen könnte. Wenn ich es nicht benutze, fühlt es sich an, als würde ich kostbare Zeit auf eine langweilige Aufgabe verschwenden, die in Zukunft ohnehin automatisiert wird. Dieses Dilemma kommt immer wieder.

  • In meinen 35 Jahren als Entwickler habe ich es so gehandhabt, dass ich jede Aufgabe, die ich selbst lösen könnte, aber nicht lösen will — weil sie langweilig oder repetitiv ist —, an AI abgebe. Zum Beispiel habe ich Änderungen an einem OpenAPI-3.0-Schema von Claude erledigen lassen, weil ich dabei selbst nichts gelernt hätte, und auch Beispielcode lasse ich von AI erzeugen. Wenn es wirklich etwas Neues zu lernen gibt, halte ich es in Apps wie Anki SRS als Flashcards fest oder schreibe es in einen TIL-Blog. Oder ich implementiere Beispiele mehrfach selbst, um die Erfahrung wirklich zu verinnerlichen. Entscheidend ist, neues Wissen mindestens zweimal im Gehirn zu verankern, damit Lernen effektiv wird — ähnlich wie wenn man ein neues Wort in einer Fremdsprache in drei Sätzen aktiv verwendet.

  • Wenn man den generierten Code nicht selbst reviewt — also C# nicht ausreichend beherrscht —, zerfällt die Codebasis in kürzester Zeit. LLM-Coding neigt dazu, Fehler aufzuschichten, und muss deshalb unbedingt verbessert werden; sonst endet man mit einem unwartbaren Haufen Müll. Freunde von mir sagen, sie lassen die AI ausreichend Tests erzeugen, um Probleme früh zu entdecken, aber so weit bin ich noch nicht gekommen. Mein Code ist eher logik- als algorithmuslastig, deshalb ist das Schreiben von Tests auch nicht ganz einfach.

  • Ich arbeite seit 16 Jahren professionell als Entwickler, und mein Eindruck ist, dass Claude Code vieles deutlich leichter lösbar gemacht hat, woran ich mir früher den Kopf zerbrochen habe. Wenn man schnell etwas Neues lernen will, sind AI-Tools — besonders ein fragender „ask“-Modus — sehr effektiv; ich nutze aktiv Analogien, Fälle und Merkhilfen. Wenn das Ziel tiefes Lernen durch langsames Wachstum ist, ist die klassische Methode trotz des höheren Aufwands besser. Wenn das Ziel aber schnelles Lernen ist, ist der Einsatz von AI keineswegs schlecht. Wenn man einfach Resultate liefern will, sind eine gute Spezifikation und ausreichend Tests entscheidend. Letztlich bekommt jede Vorgehensweise ihren Wert erst dadurch, dass man weiterhin Dinge baut.

  • Früher gab es mal den Blog-Trend „Bau deine eigene x-Bibliothek“. Gerade beim eigenen Implementieren lernt man am meisten. Wenn man zum Beispiel wissen will, wie Client-Side-Routing funktioniert, sollte man selbst einen Router bauen. Im Zeitalter der LLMs kann natürlich alles durch Bibliothekscode ersetzt werden, aber wenn ich wirklich C# lernen will, ist es besser, das Porting selbst zu machen. Wenn ich nur das Ergebnis brauche und mich auf andere Dinge konzentrieren will, kann ich es auch Claude überlassen. Lernen beinhaltet zwangsläufig eine Phase von Schmerz — wenn es zu leicht ist, lernt man in Wahrheit oft gar nichts.

  • Vor AI war Copy-and-Paste der Standard. Freunde, die sich Code aus Stack Overflow geholt haben, ohne die Gründe zu verstehen, haben am Ende auch nichts gelernt. Es ist meiner Meinung nach völlig in Ordnung, die AI um Ratschläge oder konzeptionelle Erklärungen zu bitten. Aber wenn man sie alles vollständig schreiben lässt, lernt man definitiv nichts. Gleichzeitig ist es als Entwickler auch klug, die eigene Zeit zu schützen. Es gibt unendlich viel zu lernen, und wenn das eigentliche Ziel Game Development ist, dann ist das Portieren von GDScript vielleicht keine unverzichtbare Erfahrung — auch wenn man dabei natürlich einiges lernen kann.

• Ich habe ungefähr drei Wochen mit Claude Code programmiert und arbeite seit zehn Jahren vor allem mit Python, ML und Data Engineering. Dafür gibt es mehrere Gründe:

  1. Es nimmt den Schmerz des Anfangs weg, sodass es keine Hürde gibt, die erste Zeile zu schreiben.
  2. Während es läuft, kann ich meinen Kopf vollständig fürs Denken nutzen.
  3. Mehrere Aufgaben lassen sich parallel bearbeiten.
  4. Wenn mir etwas einfällt, worum ich mich noch kümmern sollte, kann ich es sofort in einer neuen Claude-Session ausprobieren — ich lasse keine TODOs mehr liegen.
  5. Auch Analyse, Visualisierung und Plotting kann man leicht über automatisch ausgeführte Skripte erledigen lassen.
  6. Einfache Lint-, Typ- und Testprobleme behebt es von selbst. Insgesamt kann ich mich dadurch ganz auf das Wesen des Codes konzentrieren: Was muss getan werden, ist das Ergebnis korrekt und wie lässt es sich verbessern?

  • Dass es den Schmerz des Anfangs beseitigt, ist wirklich enorm. Dinge, bei denen ich früher dachte „Das würde ich gern machen, wenn ich irgendwann mal Zeit habe“, lassen sich jetzt mit ein paar Prompts tatsächlich umsetzen. Ich wollte zum Beispiel das Spiel NYT Connections im Terminal bauen, und es war nach drei Prompts fertig (https://github.com/jleclanche/connections-tui).

  • Punkt 4 finde ich besonders beeindruckend. Früher war es ganz normal, Tests oder technische Schulden liegen zu lassen, aber jetzt reicht ein einfaches „Das brauchen wir“, und schon wird eine ziemlich brauchbare Test-Suite erzeugt. Sie ist nicht perfekt, aber zumindest Aufgaben mittlerer Schwierigkeit kann man damit zuverlässig mit abdecken.

• Als jemand aus der kleinen neugierigen Minderheit, die immer wieder agentenbasiertes Coding ausprobiert, habe ich oft darüber nachgedacht, warum meine Erfahrung so anders ist als der Mainstream. Ich glaube, der Kern steckt in diesem Satz:

  „Mit Claude Code sind wir beim Programmieren an dem Punkt angekommen, an dem die Fotografie für die Malerei stand. Die Stimmung des handgezeichneten Arbeitens verschwindet, einfach weil man eine Idee sofort in die Realität bringen und sie mit den eigenen Code-Review- und Editierfähigkeiten in die gewünschte Form modellieren kann.“ Diese Metapher ist zwar passend, aber trotzdem malen Menschen weiterhin, manche bezahlen für Gemälde und andere genießen Coding selbst als Kunstform. Für mich ist direktes Coden ein Hobby, und Code Reviews mag ich nicht, auch wenn ich sie notgedrungen mache. Wenn ich die Wahl habe, entscheide ich mich eher dafür, Dinge selbst zu bauen — deshalb bin ich wohl auch IC geblieben. Viele vergleichen AI-Coding-Agenten mit Junior-Entwickler-Praktikanten, aber auf mich wirken sie eher beängstigend.

  • Ich würde gern fragen, ob wir wirklich noch in einer Welt leben, in der Menschen Bilder malen und dafür bezahlen. Die meisten handwerklichen Tätigkeiten wurden von modularen, massenproduzierten Prozessen verdrängt; heute liegt der Wert weniger im Produkt selbst als in der wechselseitigen Erfahrung zwischen Produzent und Konsument, getragen von Vorstellungskraft. Man bestellt nicht einfach nur etwas bei Amazon, sondern konsumiert auch die Beziehung zum Handwerker und die Erzählung des Schaffensprozesses. Vielleicht muss Coding künftig auf ähnliche Weise überleben.

  • Ich kann diese Haltung sehr gut nachvollziehen. Ich erkenne den Nutzen von agentischem Coding für kleine Aufgaben, Bugfixes und erste Entwürfe an. Aber ich verstehe nicht, warum die Debatten über Zustimmung oder Ablehnung so eskalieren, wenn es doch nur um verschiedene Interfaces geht, die letztlich eine kleine Zahl von Modellen umhüllen. Und was die Auswirkungen auf Junior-Entwickler angeht, bin ich noch unentschlossen. Wenn AI irgendwann auch noch Code Reviews automatisiert, wäre mein Leben wahrscheinlich deutlich angenehmer.

  • Ich finde diese Metapher nicht vollständig überzeugend. Historisch war Malerei das einzige Mittel, die reale Welt abzubilden, aber Kunst ist nicht bloße Reproduktion, sondern Interpretation durch den Schöpfer. Deshalb malen Menschen auch heute noch. Wenn man Coding selbst als Kunst betrachtet, kann man selbstverständlich weitermachen. Viele Menschen wollen aber vor allem Produkte bauen, und auch das Produkt kann Kunst sein. Wenn AI hilft, dieses Ziel schneller zu erreichen, wäre es dann nicht naheliegend, AI zu wählen? Gleichzeitig vermisse ich ein wenig die Zeit des „Code Monkey“, in der man einfach nur Code schrieb. Jetzt scheint eine Welt bevorzustehen, in der alle wie Lead-Entwickler nur noch Richtung vorgeben, Code reviewen und technische Entscheidungen treffen. Dass man in der Praxis weniger selbst codet, fühlt sich auch ein wenig schade an.

  • Eine passendere Metapher wäre vielleicht der Übergang von Handwerkzeug zu Elektrowerkzeug. Der Vergleich Malerei–Fotografie wirkt überdehnt, weil es dort um ein wirklich neues Medium ging. Agentisches Coding ist nicht in diesem Ausmaß revolutionär.

• Ich habe versucht, Claude Code intensiv zu nutzen, aber es ist mir zu langsam und läuft ständig in irgendeine falsche Richtung, was sehr frustrierend ist. Bei den meisten Aufgaben habe ich nicht das Gefühl, dass es mentale Energie spart. Bei manchen Dingen war es hilfreich, aber oft wurde ich auch bitter enttäuscht, sodass ich es nicht regelmäßig nutzen möchte. Zum Beispiel habe ich es gebeten, eine .zshrc nach Nushell zu konvertieren, und nach 30 Minuten lief es immer noch nicht, obwohl ein Blick in die offizielle Dokumentation weniger als zehn Minuten gebraucht hätte. Solche enttäuschenden Erfahrungen machen es schwer, Claude noch einmal verwenden zu wollen.

  • Diese Erfahrung ist meiner sehr ähnlich. Ich wollte Hilfe beim Schreiben von Tests bekommen, aber am Ende musste ich sie immer komplett neu schreiben. Beim Debugging hatte ich kein einziges Erfolgserlebnis. Wirklich brauchbar war es nur für sehr einfache Skriptkonvertierungen (zum Beispiel Parsing von Command-Output) oder für das Scaffolding neuer Projekte — aber wie oft braucht man das schon? Für einfaches Code-Porting war es okay, aber meine Fehlschläge damit waren deutlich zahlreicher als die Erfolge.

  • Hast du schon einmal so etwas wie context7 MCP ausprobiert? Bei weniger populären Sprachen oder ungewohnten Domänen sind LLMs oft schwach. Ein Ansatz wie context7, bei dem Referenzen direkt aus aktuellen Quellen gezogen werden, wirkt für mich deutlich besser.

• Wegen RSI und Karpaltunnelsyndrom hatte ich deutlich weniger programmiert, aber dank Claude kann ich jetzt wieder entwickeln, weil die Schmerzen auf etwa ein Zehntel zurückgegangen sind. Eigentlich wollte ich diese Technologie eher ablehnen, aber wenn ich meine Karriere fortsetzen will, ist sie inzwischen unverzichtbar.

  • Ich höre viele ähnliche Geschichten. Für Menschen mit RSI sind Tools wie Claude echte Game Changer, weil sie die härtesten und langweiligsten Wiederholungsaufgaben wie Boilerplate viel leichter machen. Früher taten mir bei repetitivem Code sowohl Handgelenke als auch Kopf weh, aber jetzt muss ich mich darum kaum noch kümmern und kann mich stattdessen auf abstraktere oder neue Probleme konzentrieren — dadurch macht Programmieren selbst wieder mehr Spaß. Manche sorgen sich, dass solche Tools ihre Karriere beenden könnten, aber ich glaube eher, dass sie meine retten werden.

  • Seit ich Claude benutze, sind meine RSI-Schmerzen fast verschwunden. Gerade präzise Anweisungen und Formulierungen können repetitive Aufgaben ersetzen. Ich habe auch viele Beispiele für Spracheingabe gesehen, und es fühlt sich an, als würde sich dadurch ein echtes Tor zu mehr Barrierefreiheit öffnen.

  • Ich denke, es wäre noch hilfreicher, wenn man Claude Code direkt per Sprache nutzen könnte. Unter macOS gibt es kostenlose TTS-/ASR-Optionen, und per BYOK lassen sich auch andere Sprach-Engines anbinden (https://github.com/robdmac/talkito).

  • Wenn man eine ausreichend präzise und komfortable STT-/Spracherkennungs-App nutzt, kann es sehr effektiv sein, Claude Code detaillierten Kontext per Sprache zu vermitteln. Ich habe verschiedene Spracherkennungs-Apps ausprobiert, und für mich war Wispr Flow am besten, weil es einen handfreien Modus per Tastenkürzel sowie gute Genauigkeit und Geschwindigkeit bietet. Trotzdem würde ich mir auch Unterstützung für lokale Apps wünschen.

  • Mich würde interessieren, ob du die Texteingabe selbst per Sprache machst.

• Ich stimme den Gedanken des Autors aus Wartbarkeitssicht sehr zu. Dinge, für die ich früher nur TODOs oder Tickets zur späteren Refaktorierung oder Erinnerung erstellt hätte, setze ich dank Claude jetzt sofort um. Dadurch ist der wiederkehrende Aufwand stark gesunken. Auch Refaktorierungsideen lassen sich schnell ausprobieren und, wenn sie nicht gefallen, leicht wieder verwerfen. Die Aktivierungsenergie für solche Arbeiten ist deutlich gesunken. Ich stimme aber auch zu, dass es zu Burnout und sinkender Codequalität führen kann, wenn man AI-Agenten parallel oder offline wahllos laufen lässt; man sollte deshalb unbedingt in einem Modus mit menschlicher Aufsicht bleiben. Weitere Gedanken dazu habe ich hier gesammelt: https://www.modulecollective.com/posts/agent-assisted-coding...

[zxavi]

Mir geht es genauso wie dem Autor des Originalbeitrags, haha
Ich habe 200 $ bezahlt und innerhalb von nur einer Stunde ein schwieriges Problem gelöst, an dem ich vier Jahre lang festhing.
Allein hätte ich das wahrscheinlich nie geschafft ... mit Cursor ließ es sich jedenfalls absolut nicht lösen.

[beoks]

Könnte mir vielleicht jemand den Unterschied erklären, wenn man claude code im Vergleich zu Cursor + Claude LLM verwendet?
Ich nutze derzeit Cursor und überlege, zu claude code zu wechseln.

[zxavi]

Meinen Sie mit Claude LLM den API-Key?
Oder meinen Sie die Agent-Modelle unten im Chatfenster?

Mit Cursor war ich zwar auch durchaus zufrieden, aber weil ich ständig ins Nutzungslimit gelaufen bin, war ich selbst beim $60-Tarif die ganze Zeit nervös, ob ich wieder ans Limit stoße.
Deshalb habe ich abwechselnd auch gemini cli benutzt, was ziemlich stressig war.

Cursor + Claude 4 Sonnet ist auch schon sehr gut, aber das größte Problem war, dass ich nach einem Tag wieder ans Limit kam und es dann einen Monat lang nicht mehr nutzen konnte.

Cursor + Claude 4 Opus habe ich mich gar nicht erst zu testen getraut.

Claude Code ist letztlich CLI-basiert und nicht von den Eigenheiten einer bestimmten IDE abhängig, deshalb habe ich mich entschieden, es auszuprobieren.

Am Anfang habe ich den $20-Tarif genutzt, aber auch da gibt es kein Opus.

Als ich dann wieder kurz davor war, ins Limit zu laufen, dachte ich mir, ich probiere einen Monat lang den $200-Tarif aus, habe bezahlt und es genutzt —

und da hat sich mir eine ganz neue Welt eröffnet. Opus ... das ist einfach eine andere Gewichtsklasse ...

Heute ist Tag 4 seit den $200, und ich löse gerade all die schwierigen Probleme, die ich lange vor mir hergeschoben hatte haha

[zxavi]

Der Beitrag lässt sich nicht bearbeiten.

Cursor + Claude 4 Sonnet ist zwar auch gut genug, aber das größte Problem war, dass nach einem Tag das Limit erreicht war und man es dann einen Monat lang nicht benutzen konnte.

Ich glaube, es war nicht ein Monat, sondern eher ein Tag. Trotzdem war ich den ganzen Monat über ständig nervös.
Und ich habe mich oft mit Cursor herumgeschlagen,
mit Claude Code aber deutlich seltener.

[beoks]

Oh, vielen Dank für die ausführliche Antwort.
Ich nutze wegen des Limits auch notgedrungen Cursor im Auto-Modus, aber dann sollte ich wohl auch wechseln.