Arbeit mit KI

GODAV Pro schreibe ich nicht allein. Seit dem ersten Commit Ende Juli 2026 arbeite ich mit Claude Code, dem Programmierassistenten von Anthropic. Die Entscheidungen treffe ich: was gebaut wird, wie es sich verhalten soll, was wegkommt. Claude liest den Code, schlägt vor, schreibt, testet und dokumentiert. Auf dieser Seite beschreibe ich, wie das im Alltag aussieht und welche Regeln dafür sorgen, dass am Ende trotzdem meine Anwendung herauskommt.

Wo ich arbeite: Claude Code in VS Code

Claude Code läuft bei mir als Erweiterung in Visual Studio Code. Das Fenster sitzt neben dem Editor, und jede Änderung landet als Diff direkt in den Dateien, die ich ohnehin offen habe. Ich sehe also nicht nur das Ergebnis, sondern auch den Weg dorthin: welche Dateien gelesen wurden, welche Befehle liefen, wo ein Test rot war.

Das ist mir wichtiger, als es klingt. Ein Werkzeug, das nur fertige Ergebnisse abliefert, müsste ich blind übernehmen. So kann ich jederzeit eingreifen, wenn ein Ansatz in die falsche Richtung läuft.

Die Modelle

Den Großteil der Arbeit erledigt das jeweils größte Claude-Modell: anfangs Claude Opus 4.8, inzwischen Opus 5.5. Daneben setze ich Claude Fable ein für besonders anspruchsvolle Konzepte. Sonnet 5 hilft mir bei Routineaufgaben. Die meiste Zeit arbeite ich im Medium-Effort Mode.

Warum das große Modell? Die typischen Aufträge in GODAV sind lang. Ein Feature berührt Datenbank, Server, gemeinsame Verträge, Oberfläche, zwei Sprachen und Tests — und es muss dabei Dutzende Regeln einhalten, die irgendwo in der Projektdokumentation stehen. Gerade dieses „über viele Dateien hinweg konsequent bleiben” ist der Unterschied, der sich für mich bezahlt macht.

Die Regeln: CLAUDE.md und die Fachakten

Das Wichtigste an der Zusammenarbeit ist keine Funktion, sondern eine Datei: die CLAUDE.md im Projektordner. Vor dem Start habe ich hier besonders viel Zeit investiert um ein Regelwerk festzulegen. Dabei habe ich mir auch Unterstützung von anderen KI-Modellen wie Copilot und ChatGPT geholt. Claude Code liest sie bei jedem Auftrag. Darin steht, wie hier entwickelt wird — und zu jeder Regel der Grund. Ein paar Beispiele:

• TypeScript im strengsten Modus, keine Abkürzungen über any.
• Fachlogik gehört in Services, nie in Controller — maschinell durch den Linter geprüft.
• Jede Oberfläche folgt denselben Farben, Abständen und Icons wie die Referenzentwürfe.
• Vor jedem Auftrag stellt Claude vier Rückfragen zu den Entscheidungen, die ich treffen muss — jeweils mit einer eigenen Empfehlung — und wartet auf meine Antwort.

Die letzte Regel ist aus Erfahrung entstanden. Früher wurden Umfangs- und Modellentscheidungen „nebenbei” getroffen, jede für sich vertretbar, aber keine mit mir abgestimmt. Jetzt kommen immer mindestens vier Fragen zuerst, und meistens genügt ein Klick auf „wie vorgeschlagen”. Ein “Stelle bei Unklarheiten so viele Fragen wie nötig” bei größeren Aufgaben hat schon wahre Wunder bewirkt.

Die Datei CLAUDE.MD wurde irgendwann zu groß. Sie wuchs mit jedem Bereich, bis sie bei jedem Auftrag rund 70 % des verfügbaren Kontexts belegte, bevor überhaupt eine Zeile Code gelesen war. Ich habe sie deshalb geteilt: Die allgemeinen Regeln bleiben in der CLAUDE.md, und jeder fertige Bereich bekommt eine eigene Fachakte, die beschreibt, wie er gebaut ist und warum. Ein Index sagt, welche Akte zu welchem Auftrag gehört. Seitdem sind es noch etwa 7 %.

Dazu kommt ein Gedächtnis über Sitzungen hinweg: kurze Notizen zu Entscheidungen, Vorlieben und Stolperfallen, etwa wie die Entwicklungsumgebung gestartet wird oder welches Projekt in der Testdatenbank niemals angefasst werden darf.

Die Skills

Wiederkehrende Abläufe habe ich als Skills hinterlegt — Anleitungen, die Claude Schritt für Schritt abarbeitet, sobald ich sie aufrufe. Fünf gibt es im Projekt:

Skill	Wofür
update_help	Zieht Neuerungen, Hilfe und Bildschirmfotos gebündelt nach — und legt seit Neuestem einen Entwurf für diesen Blog an
audit	Ein vollständiger technischer Audit in zehn Phasen: Sicherheit, Berechtigungen, Datenbank, Performance, Altlasten; jeder Befund mit Datei und Zeile
linux-installer	Baut aus dem aktuellen Stand ein Installationspaket mit geführtem Installer
helpdesk	Arbeitet gemeldete Fehler der Reihe nach ab — mit Freigabe, Prüfkette und eigenem Commit je Vorgang - Ich benutze mein Tool bereits als Helpdesk
lizenz	Stellt Lizenzdateien für Installationen aus

update_help ist ein gutes Beispiel dafür, warum Skills sich lohnen. Anfangs wurden Neuerungen und Hilfe in jedem Feature-Commit nebenher mitgeschrieben. Das klang ordentlich, führte aber zu vielen kleinen, verstreuten Einträgen, hohem Zeitaufwand und zu Bildschirmfotos, die bei jeder Kleinigkeit neu aufgenommen wurden. Seit September entscheide ich, wann dokumentiert wird: Ein Aufruf sammelt alles seit dem letzten Stand, legt mir eine Übersicht zur Freigabe vor und schreibt dann einen sauberen Stand.

Neben den Skills gibt es einen Hook, also ein Skript, das an einem festen Punkt automatisch läuft: Beim ersten Auftrag des Tages wird die Datenbank gesichert. Der Hook blockiert nie. Schlägt die Sicherung fehl, wird das gemeldet, und die Arbeit läuft weiter.

Mehrere Agenten gleichzeitig

Größere Aufgaben verteilt Claude auf Subagenten, die parallel arbeiten. Für diesen Blog zum Beispiel haben sieben Agenten gleichzeitig die Beiträge zu den bisherigen Versionen geschrieben, während der Hauptagent die Seite selbst gebaut hat. Jeder Agent bekam dasselbe Briefing mit Stilregeln und einer klaren Liste, was nicht in einen öffentlichen Text darf.

Am Ende habe ich trotzdem jedes Bild noch einmal einzeln prüfen lassen. Dabei kam heraus, dass die Entwicklungsdatenbank neben den Demodaten auch echte Daten enthält, die in einigen Bildern noch sichtbar waren. Parallel heißt schneller, aber nicht ungeprüft.

Unterwegs: Remote Control auf dem Smartphone

Viele Aufträge laufen lange: ein Feature über mehrere Schichten, ein Audit, ein Importlauf. Damit ich dafür nicht am Schreibtisch sitzen muss, verbinde ich mich über Remote Control (/remote-control) vom Smartphone aus mit der laufenden Sitzung auf meinem Rechner. Die Arbeit läuft dort weiter, das Handy ist nur das Fenster dazu.

Ich nutze das für vier Dinge:

• Rückfragen beantworten. Die vier Fragen vor einem Auftrag lassen sich unterwegs anklicken, und die Arbeit geht weiter, statt auf mich zu warten.
• Fortschritt verfolgen. Ein kurzer Blick, wo ein langer Auftrag gerade steht.
• Aufträge anstoßen. Ein gemeldeter Fehler kann so bearbeitet werden, bevor ich wieder am Rechner bin.
• Freigaben erteilen. Commits und Berechtigungsanfragen bestätige ich direkt vom Handy.

Was ich daraus gelernt habe

• Regeln brauchen einen Grund. Eine Regel ohne Begründung wird irgendwann umgangen — vom Menschen genauso wie von der KI. Mit Begründung kann Claude auch Fälle richtig entscheiden, die die Regel nicht ausdrücklich nennt.
• Prüfen bleibt Pflicht. Linter, Typprüfung und Tests laufen vor jedem Commit, und jede neue Ansicht wird im Browser angesehen. Ergebnisse werden ehrlich berichtet, auch wenn sie rot sind.
• Fragen sind billiger als Umbauten. Eine Rückfrage kostet eine Minute, eine falsche Architekturentscheidung Tage.
• Ich bleibe verantwortlich. Was in GODAV landet, habe ich entschieden und freigegeben. Claude ist ein sehr schneller und gründlicher Mitentwickler, aber kein Ersatz für jemanden, der weiß, wofür die Anwendung da ist.
• Ich bleibe, kritisch, vorsichtig und aufmerksam Für mein Projekt habe ich mir einen zusätzlichen Laptop angeschafft, auf diesem läuft nichts, außer dem Projekt. Ich beschränke Zugriffe auf Ordner und prüfe regelmäßig was angelegt wurde.
• Ich nutze VS Code So kann ich immer sehen an welchen Objekten Claude Code arbeitet und was geändert wurde.
• Was ich nicht kenne, bringe ich in Erfahrung Macht Claude Code einen technischen Vorschlag und benutzt dabei Begriffe, die ich nicht kenne, dann werden diese direkt nachgeschlagen und ich informiere mich darüber. So baut man sich nebenbei zusätzliches Wissen auf.
• Zwinge dich zu denken Ich schreibe Konzepte zuerst in einem einfachen Editor vor. Dabei versuche ich Abhängigkeiten zu beachten und zu durchdenken und bereits Entscheidungen zu treffen bevor ich die KI frage. Mein Ziel: Claude soll mich möglichst nicht auf einen Punkt hinweisen, den ich nicht beachtet habe. Warum? Wer nicht ins Fitnessstudio geht, verliert seine Muskeln. Mit dem Gehirn verhält es sich genauso. Und das Gehirn ist faul. Es gewöhnt sich wahnsinnig schnell ans Nicht-Denken.
• Betrachte dich als Anfänger Ich betrachte mich selbst immer als Anfänger beim Umgang mit KI. Die Entwicklungen im KI-Bereich sind zu groß und zu schnell, um sich fähig zu fühlen. Wer sich überschätzt macht schwerwiegende Fehler und verpasst tolle Möglichkeiten. Ich habe schon einige Fehler gemacht. Bestimmt auch welche, die ich nicht mal kenne.