Claude Code im Webdev-Alltag: Erstes Fazit

Seit ein paar Tagen nutze ich Claude Code in meinem Alltag als Web Developer, vor allem für Kirby und WordPress sowie klassisches Frontend mit JavaScript und CSS. Überraschend schnell fühlt sich Claude für mich wie ein engagierter Junior‑Entwickler an, den ich gerne steuere und der mir viel Arbeit abnimmt.

Ich arbeite in kurzen, iterativen Schleifen quer durch verschiedene Frontend‑ und CMS‑Projekte, vor allem Kirby, WordPress und JavaScript/CSS. Pro Session kommen im Schnitt ungefähr zwölf Nachrichten zusammen. Ich lasse Claude viel mit Bash‑Befehlen und Datei‑Reads arbeiten, übernehme aber aktiv das Korrigieren, wenn etwas in die falsche Richtung läuft.

Ein Beispiel: In einer Session zur Umstellung einer bilingualen Seite auf reines Englisch ist Claude mehrfach in die falsche Richtung gegangen. Es hat unter anderem Übersetzungs‑Calls entfernt und damit Kirbys Mehrsprachigkeits‑Modus kaputtgemacht. Statt abzubrechen habe ich Claude immer wieder zurückgelenkt, bis die Lösung passte. Das beschreibt meinen Stil ganz gut: geduldig, aber klar steuernd.

Ein wiederkehrendes Muster in meiner Arbeit mit Claude ist, dass das Tool falsche Annahmen über meinen Stack trifft. Dazu gehören falsche Tailwind‑Versionen, falsch abgeleitete Schriftgrößen aus Figma oder unpassende Strategien für Kirby‑Content‑Dateien. Ich greife relativ schnell ein und korrigiere.

Ich habe eine ziemlich geringe Toleranz für verschwendete Zeit und mag es nicht, wenn zu viel auf Vermutungen basiert. Als ein Prettier‑Setup einmal meine PHP‑Templates zerlegt hat, habe ich nicht lange analysiert, sondern sofort darum gebeten, alles wieder zurückzudrehen. Trotzdem bin ich mit den Ergebnissen insgesamt sehr zufrieden und erreiche die meisten Ziele. Iteration ist für mich der Plan und nicht der Notfall.

Meistens habe ich nur eine Claude‑Code‑Session gleichzeitig offen und gehe damit Schritt für Schritt durch meine Aufgaben. In letzter Zeit waren das vor allem das Anpassen von Templates und Komponenten in Kirby und WordPress, das Verfeinern von CSS, kleinere Bugfixes und das teilweise Automatisieren von Routinen wie PR‑Erstellung oder Format‑Checks.

Dafür nutze ich zum Beispiel ein kleines PR‑Skill‑Setup in .claude/skills/pr, das Schritte wie git add -A, Commit, Push und das Anlegen eines Pull Requests bündelt. Für die Code‑Qualität setze ich auf einen postEdit‑Hook in .claude/settings.json, der nach Edits automatisch npx prettier --check ausführt, ohne meinen Flow zu blockieren.

Mir ist klar geworden, dass ich Claude mehr Autonomie geben kann, aber nur mit klaren Regeln. In meinen Prompts formuliere ich deshalb oft explizit, dass Claude vor Änderungen zuerst die relevanten Dateien lesen, das aktuelle Verhalten dokumentieren und einen Plan skizzieren soll, den ich abnicken kann, bevor es losgeht.

Ich lasse Claude außerdem die Tech‑Stacks meiner Projekte bewusst aus package.json, composer.json und anderen Config‑Dateien auslesen, statt Versionen raten zu lassen, und mir dann eine strukturierte Übersicht zurückgeben. Für Bugfixes verlange ich einen Ablauf, bei dem Claude erst die Ursache erklärt, dann einen minimalen Fix macht und die Änderung mit einem Request auf die Seite validiert, bevor ich überhaupt etwas reviewe.

Nach ein paar Tagen intensiver Nutzung habe ich das Gefühl, dass Claude Code meinen Alltag als Web Developer deutlich produktiver macht, allerdings nicht, indem ich Aufgaben blind abgebe. Am besten funktioniert für mich die Kombination aus meiner Kontrolle, kurzen Feedback‑Schleifen und klaren "Spielregeln" für Claude.

Ich behandle Claude wie eine fähige, aber manchmal überkonfidente Assistenz, die mit guten Vorgaben und Checks enorm helfen kann, aber immer noch jemanden braucht, der die Richtung vorgibt. In Zukunft möchte ich noch mehr damit experimentieren, zum Beispiel mit automatisierten Validierungsskripten und projektweiten Stack‑Scans, die Claude komplett vorbereiten darf, bevor ich eingreife.