Künstliche Intelligenz

Künstliche Intelligenz hat die Softwareentwicklung innerhalb kürzester Zeit grundlegend verändert. Was vor wenigen Jahren noch als Experiment galt, ist heute für viele Entwickler ein fester Bestandteil des Arbeitsalltags. Neben klassischen Chatbots haben sich spezialisierte Werkzeuge etabliert, die direkt beim Programmieren unterstützen. Eines davon ist Claude Code.

Nachdem ich in den vergangenen Monaten intensiv mit Claude Code gearbeitet habe, haben sich einige Arbeitsweisen herauskristallisiert, die nicht nur die Qualität der Ergebnisse verbessern, sondern gleichzeitig den Tokenverbrauch erheblich reduzieren. Gerade bei größeren Projekten kann ein ineffizienter Umgang mit Tokens schnell teuer werden oder dazu führen, dass der verfügbare Kontext unnötig ausgeschöpft wird.

In diesem Artikel möchte ich keine allgemeine Einführung in Claude Code geben, sondern meine persönlichen Erfahrungen schildern. Viele der folgenden Punkte habe ich erst nach zahlreichen Projekten gelernt. Sie haben meinen Workflow nachhaltig verändert und ermöglichen deutlich effizienteres Arbeiten.

Claude Code ist mehr als ein Chatbot

Viele Anwender behandeln Claude Code anfangs wie einen gewöhnlichen Chatbot. Man beschreibt eine Aufgabe, erhält eine Antwort und führt anschließend weitere Korrekturen durch. Bei kleinen Projekten funktioniert dieses Vorgehen durchaus.

Bei umfangreichen Softwareprojekten zeigt sich jedoch schnell, dass Claude Code anders genutzt werden sollte. Das Modell arbeitet besonders effektiv, wenn es den Aufbau des Projektes versteht und wiederkehrende Regeln kennt. Gleichzeitig sollte man vermeiden, bei jeder Anfrage dieselben Informationen erneut zu übermitteln.

Genau an dieser Stelle beginnt ein effizienter Workflow.

Tokens sind die eigentliche Ressource

Wer regelmäßig mit Claude Code arbeitet, merkt schnell, dass nicht die Anzahl der Anfragen entscheidend ist, sondern der Verbrauch an Tokens.

Jede Eingabe besteht aus Tokens. Ebenso jede Antwort. Hinzu kommt der Kontext, den Claude bei jeder weiteren Unterhaltung erneut berücksichtigen muss.

Das bedeutet:

• jede unnötige Erklärung kostet Tokens
• jede wiederholte Anweisung kostet Tokens
• jeder unnötig geöffnete Quellcode kostet Tokens
• jede allgemeine Aufgabenstellung führt häufig zu längeren Antworten

Gerade bei großen Projekten summieren sich diese Kosten erheblich.

Ich habe deshalb begonnen, jede Anfrage unter dem Gesichtspunkt zu betrachten:

Welche Informationen benötigt Claude wirklich, um diese Aufgabe zu lösen?

Diese Frage spart erstaunlich viele Tokens.

Wiederholende Regeln gehören in eine Markdown-Datei

Eine der größten Verbesserungen meines Workflows bestand darin, alle wiederkehrenden Anweisungen in einer Markdown-Datei zu sammeln.

Anfangs schrieb ich dieselben Hinweise immer wieder:

• keine Kommentare im Code
• React Hooks bevorzugen
• TypeScript strict mode
• bestehende Architektur beibehalten
• keine unnötigen Bibliotheken installieren
• bestehendes Styling übernehmen
• Tests aktualisieren
• ESLint-Fehler vermeiden

Diese Hinweise wiederholten sich praktisch in jeder Unterhaltung.

Dadurch entstand nicht nur unnötiger Tokenverbrauch, sondern Claude musste dieselben Informationen immer wieder neu interpretieren.

Heute liegen solche Regeln dauerhaft in einer Markdown-Datei.

Diese Datei beschreibt beispielsweise:

• Coding Style
• Namenskonventionen
• Projektstruktur
• Architektur
• Formatierung
• gewünschte Antwortform
• Umgang mit Tests
• bevorzugte Frameworks
• verbotene Bibliotheken
• allgemeine Entwicklungsregeln

Dadurch muss ich diese Informationen nicht ständig erneut eingeben.

Das spart bei längeren Projekten eine erhebliche Menge an Tokens.

Möglichst präzise angeben, wo Änderungen stattfinden sollen

Ein weiterer wichtiger Punkt betrifft den eigentlichen Quellcode.

Viele Entwickler schreiben beispielsweise:

Ändere bitte den Login.

Oder:

Überarbeite die Navigation.

Für Claude bedeutet das zunächst, herauszufinden, welche Dateien überhaupt betroffen sind.

Je größer das Projekt wird, desto mehr Kontext muss eingelesen werden.

Meine Erfahrung zeigt deshalb:

Je präziser der Ort der Änderung beschrieben wird, desto effizienter arbeitet Claude.

Beispiele:

• Passe ausschließlich die Datei LoginForm.tsx an.
• Ändere nur die Methode validateUser().
• Erweitere lediglich die Komponente UserCard.
• Bearbeite ausschließlich den API-Endpunkt /users/{id}.
• Die Änderung betrifft nur Zeilen innerhalb der Klasse InvoiceService.

Dadurch muss Claude deutlich weniger Dateien analysieren.

Der Tokenverbrauch sinkt spürbar.

Gleichzeitig werden versehentliche Änderungen an anderen Komponenten vermieden.

Nicht das ganze Projekt erklären

Anfangs neigt man dazu, Claude möglichst viele Informationen zu geben.

Ironischerweise führt genau das häufig zu schlechteren Ergebnissen.

Wenn eine Aufgabe lediglich eine kleine React-Komponente betrifft, muss Claude nicht sämtliche Backend-Services kennen.

Ebenso benötigt eine CSS-Anpassung meist keine Beschreibung der Datenbankarchitektur.

Ich habe gelernt, Informationen gezielt zu reduzieren.

Nicht alles, was Claude wissen könnte, muss Claude auch wissen.

Der relevante Kontext ist fast immer wertvoller als möglichst viel Kontext.

Offene Aufgaben liefern oft bessere Lösungen

Eine interessante Beobachtung betrifft die eigentliche Formulierung der Aufgabe.

Früher formulierte ich Anforderungen extrem detailliert.

Zum Beispiel:

• benutze genau diese Schleife
• verwende dieses Interface
• ändere nur diese zwei Zeilen
• schreibe keinen zusätzlichen Code
• benutze keine Helper-Funktionen

Das führte erstaunlich oft zu mittelmäßigen Ergebnissen.

Heute beschreibe ich stattdessen eher das gewünschte Ziel.

Beispielsweise:

Vereinfache diese Komponente, reduziere Duplikate und verbessere gleichzeitig die Lesbarkeit.

Oder:

Optimiere diese Funktion hinsichtlich Wartbarkeit und Performance, ohne das Verhalten zu verändern.

Diese offene Formulierung gibt Claude mehr Freiheit.

Interessanterweise entstehen dadurch häufig deutlich elegantere Lösungen, als ich sie selbst vorgegeben hätte.

Claude erkennt oftmals Zusammenhänge, die ich bei einer stark eingeschränkten Aufgabenstellung gar nicht berücksichtigt hätte.

Offen bedeutet nicht unpräzise

Das klingt zunächst widersprüchlich.

Einerseits sollte die betroffene Stelle möglichst exakt beschrieben werden.

Andererseits sollte die eigentliche Lösungsstrategie möglichst offen bleiben.

Beides ergänzt sich jedoch hervorragend.

Ich definiere daher immer:

• wo gearbeitet werden soll
• welches Ziel erreicht werden soll

Ich definiere hingegen möglichst selten:

• wie Claude das intern lösen soll.

Gerade dieser Unterschied macht in meiner Erfahrung einen erheblichen Qualitätsunterschied aus.

Kleine Aufgaben statt riesiger Änderungen

Ein weiterer Punkt betrifft die Größe der einzelnen Aufgaben.

Natürlich kann Claude große Refactorings durchführen.

In der Praxis arbeite ich jedoch lieber in kleineren Schritten.

Anstatt das gesamte Projekt auf einmal modernisieren zu lassen, teile ich die Arbeit in klar abgegrenzte Aufgaben auf.

Zum Beispiel:

• Navigation verbessern
• Authentifizierung überarbeiten
• API vereinheitlichen
• Tests aktualisieren
• Styling optimieren

Dadurch bleiben Antworten übersichtlich.

Fehler lassen sich schneller erkennen.

Auch der Tokenverbrauch bleibt kontrollierbar.

Kontext wächst schneller als erwartet

Viele Entwickler unterschätzen, wie schnell sich der Kontext einer Unterhaltung vergrößert.

Bereits nach einigen Dutzend Nachrichten enthält der Chat:

• ursprüngliche Aufgaben
• Zwischenlösungen
• Rückfragen
• Fehlermeldungen
• Korrekturen
• neue Anforderungen

Claude muss diesen gesamten Verlauf berücksichtigen.

Selbst wenn eine neue Aufgabe nur wenige Zeilen betrifft, werden oft Tausende Tokens verarbeitet.

Deshalb beginne ich größere Arbeitsschritte regelmäßig in einer neuen Unterhaltung.

Dadurch startet Claude mit einem sauberen Kontext.

Auch dies spart langfristig Tokens.

Gute Prompts bestehen nicht aus vielen Worten

Eine weitere Erfahrung war überraschend.

Lange Prompts sind nicht automatisch gute Prompts.

Ein guter Prompt beantwortet lediglich die wirklich relevanten Fragen:

• Was soll geändert werden?
• Wo soll geändert werden?
• Welches Ziel soll erreicht werden?
• Welche Regeln gelten dauerhaft?

Alles andere ist häufig unnötig.

Dadurch entstehen deutlich kürzere Eingaben bei gleichzeitig besseren Ergebnissen.

Claude denkt häufig weiter als erwartet

Einer der größten Vorteile von Claude Code besteht darin, dass das Modell häufig Zusammenhänge erkennt.

Wenn man ihm genügend Freiraum gibt, schlägt es oftmals Verbesserungen vor, die über die eigentliche Aufgabenstellung hinausgehen.

Dazu gehören beispielsweise:

• Vereinfachungen
• bessere Benennung
• Entfernung redundanter Logik
• robustere Fehlerbehandlung
• klarere Architektur
• besser lesbarer Code

Genau deshalb versuche ich heute, Claude möglichst selten auf einen einzigen Lösungsweg festzulegen.

Die eigentliche Stärke liegt nicht darin, exakt meine Idee umzusetzen.

Die Stärke liegt darin, bessere Lösungen vorzuschlagen.

Claude ist ein Entwicklungspartner

Mit der Zeit hat sich meine Sichtweise verändert.

Ich betrachte Claude Code nicht mehr als Werkzeug zur Codegenerierung.

Ich sehe es eher als Entwicklungspartner.

Der Unterschied ist erheblich.

Ein Generator setzt Anweisungen um.

Ein Entwicklungspartner hinterfragt sie, erkennt Optimierungsmöglichkeiten und entwickelt Lösungen mit.

Genau dadurch entstehen häufig qualitativ bessere Ergebnisse.

Mein persönliches Fazit

Nach vielen Stunden Arbeit mit Claude Code hat sich für mich ein klarer Workflow etabliert.

Ich achte darauf, wiederkehrende Regeln dauerhaft in einer Markdown-Datei abzulegen. Dadurch muss ich sie nicht bei jeder Unterhaltung erneut formulieren und spare eine erhebliche Menge an Tokens.

Ich beschreibe möglichst exakt, an welcher Stelle im Projekt Änderungen vorgenommen werden sollen. Je kleiner der relevante Kontext ist, desto effizienter arbeitet Claude.

Gleichzeitig versuche ich, die eigentliche Lösungsstrategie nicht unnötig einzuschränken. Statt Claude vorzuschreiben, wie ein Problem gelöst werden muss, beschreibe ich das gewünschte Ergebnis und überlasse dem Modell den Weg dorthin. Aus meiner Erfahrung entstehen so häufig elegantere, wartbarere und kreativere Lösungen.

Ebenso wichtig ist für mich ein bewusster Umgang mit dem Kontext. Lange Unterhaltungen führen dazu, dass immer mehr Tokens verarbeitet werden. Deshalb beginne ich größere Entwicklungsschritte regelmäßig in einer neuen Unterhaltung und konzentriere mich jeweils auf einen klar abgegrenzten Aufgabenbereich.

Mein wichtigstes Learning lässt sich in einem Satz zusammenfassen:

Sei präzise beim Ort der Änderung, aber offen bei der Lösung. Lege wiederkehrende Regeln dauerhaft fest und behandle Tokens als wertvolle Ressource.

Dieser Ansatz hat meinen Arbeitsalltag mit Claude Code nachhaltig verbessert. Ich arbeite schneller, erhalte konsistentere Ergebnisse und verbrauche deutlich weniger Tokens. Gerade bei großen Softwareprojekten macht sich dieser Unterschied schon nach kurzer Zeit bemerkbar.