Die wichtigen Zeilen schreibst du

Was es ist und warum es zählt

Wenn du deine App mit Claude baust und den Code nicht verstehst, sitzt du fest, sobald etwas kaputtgeht. Du weißt nicht, wo du suchen sollst, und bittest um eine Reparatur für etwas, das du nicht einmal beschreiben kannst. Je größer die App wird, desto mehr wiegt das.

Claude Code hat die Antwort schon eingebaut: Output-Stile. Ein Stil ist eine Reihe von Anweisungen, die für die ganze Sitzung ändert, wie Claude dir antwortet. Neben dem Grundstil namens Default sind vier dabei: Proactive, Concise, Explanatory und Learning. Learning ist der zum Lernen.

Mit Learning erledigt Claude die Routinearbeit weiterhin selbst. Aber wenn es zu einem Teil mit einer echten Entscheidung kommt, lässt es dir ein paar Zeilen zum Schreiben und erklärt nebenbei seine eigenen Entscheidungen. Die App wird trotzdem fertig, aber einige der wichtigen Zeilen hast du selbst geschrieben. Das ist für alle, die allein mit Claude bauen und ihren Code gut genug verstehen wollen, um ihn zu reparieren.

1. So schaltest du ihn ein

Für jeden Ort, an dem du Claude Code nutzt, gibt es einen Weg. Der Befehl und beide Menüs speichern deine Wahl in der Datei .claude/settings.local.json des Projekts: Sie gilt nur in diesem Projekt und nur für dich.

1. Im Terminal: Tipp /output-style learning. Der Befehl ignoriert Groß- und Kleinschreibung. Wenn du nur /output-style tippst, listet er die Stile auf und markiert den aktiven.
2. Ebenfalls im Terminal, über das Menü: Tipp /config und wähl Output style.
3. In der VS-Code-Erweiterung: Tipp / in das Eingabefeld und wähl Output styles.
4. In der Desktop-App: Hier öffnet /config die Einstellungen der App, nicht das Menü. Schreib das Feld outputStyle selbst in die Datei .claude/settings.local.json des Projekts, wie unten gezeigt, und starte dann eine neue Sitzung.

{
  "outputStyle": "Learning"
}

In der Datei zählt der Großbuchstabe: Schreib Learning, nicht learning. Ein falsch geschriebener Name gibt keinen Fehler: Du bleibst ohne Hinweis im Default-Stil. Wenn die Datei schon andere Einstellungen hat, füg nur die Zeile outputStyle in die vorhandenen geschweiften Klammern ein.

Wenn du Learning in allen Projekten willst, setz dasselbe Feld in die Datei deines Benutzers, ~/.claude/settings.json. Aber die Einstellungen eines Projekts haben Vorrang vor denen des Benutzers: Hat ein Projekt ein eigenes outputStyle, gilt dort dieses.

Wenn du den Stil mitten in der Sitzung wechselst, gilt der neue Stil in der neuesten Version von Claude Code ab deiner nächsten Nachricht: Du musst nicht neu anfangen.

2. Was passiert, während es arbeitet

Du gibst ihm wie immer eine Aufgabe. Ab da läuft es so:

1. Die Routinearbeit erledigt es selbst: die Dateien, die angelegt werden müssen, die Verbindungen, die Teile, die man nur auf eine Art schreiben kann.
2. Wenn es zu einem Teil mit einer echten Entscheidung kommt, hält es an. Die Dokumentation nennt drei Beispiele: wie man einen Fehler behandelt, wie man die Daten organisiert, eine Regel deiner App, die sich auf mehr als eine richtige Art schreiben lässt.
3. In der Datei lässt es genau an der richtigen Stelle einen Platzhalter-Kommentar: das englische Wort für „zu erledigen“, gefolgt von (human), also „Mensch“. Um ihn zu finden, such in der Datei nach (human).
4. Es schickt dir eine Learn-by-Doing-Anfrage in drei Teilen: Context, was schon da ist; Your Task, was du wo schreiben sollst; Guidance, worauf du beim Schreiben achten sollst.
5. Dann hält es an und wartet. Du schreibst die paar Zeilen an die Stelle des Platzhalters und sagst ihm, dass du fertig bist.
6. Es liest deinen Code, antwortet mit einem Insight-Kasten zu dem, was du geschrieben hast, und macht mit der Aufgabe weiter.

Nebenbei fügt es vor oder nach dem Code, den es schreibt, Insight-Kästen hinzu: zwei oder drei Punkte dazu, warum es sich so entschieden hat, bezogen auf dein Projekt. Sie bleiben im Gespräch: Sie landen nicht als Kommentare in deinen Dateien.

Eine Sache solltest du gleich wissen: Ein Stil ist eine Anweisung, keine Garantie. Claude entscheidet selbst, welche Teile es dir überlässt, und bei einer Aufgabe ohne echte Entscheidungen überlässt es dir vielleicht gar nichts. Wenn du einen bestimmten Teil willst, bitte darum: Das ist der nächste Abschnitt.

3. Nutz ihn für eine echte Funktion

Bei einer Funktion, die du wirklich brauchst, bringt es mehr als bei einer Übung. Die Zeilen, die du selbst schreiben solltest, sind die Regeln deiner App: Die änderst du, wenn sich die Idee ändert, und die schaust du dir zuerst an, wenn etwas nicht stimmt. Schreib ihm so:

Ich baue gerade diese Funktion ein: [zum Beispiel höchstens 3 Projekte in der Gratisversion]. Den Routineteil schreibst du: Dateien, Verbindungen, Oberfläche. Die Regeln meiner App, also was in jedem Fall passiert und wie Fehler behandelt werden, überlässt du mir mit dem Platzhalter (human), eine nach der anderen. Sag mir bei jeder, in welcher Datei sie steht, was ich bekomme und was ich zurückgeben muss.

Wenn du deine Zeilen geschrieben hast:

Ich bin mit dem Platzhalter (human) in [Dateiname] fertig. Lies meinen Code und sag mir, ob es einen Fall gibt, den ich nicht behandle, ohne ihn selbst umzuschreiben. Dann mach weiter.

4. Wenn du festhängst, frag nach einem Hinweis

Manchmal schaust du auf den Platzhalter und weißt nicht, wo du anfangen sollst. Frag nicht sofort nach der Lösung: Wenn du sie fertig liest, stehst du beim nächsten Mal wieder am selben Punkt. Frag nach einem Hinweis:

Ich hänge beim Platzhalter (human) in [Dateiname] fest. Schreib nicht den Code. Gib mir nur einen Hinweis: das Erste, was ich prüfen sollte, oder die Frage, die ich mir stellen sollte. Wenn ich nach zwei Hinweisen immer noch festhänge, zeig mir ein ähnliches Beispiel, aber nicht dasselbe.

Wenn es gerade wirklich nicht passt, kannst du ihm immer sagen, dass es den Teil selbst schreiben soll. Aber versuch es zuerst mit den Hinweisen: Genau da wird der Code zu deinem.

5. Wenn es eilt, zurück zu Default

Learning bremst dich, und das ist gewollt. Die Antworten sind absichtlich länger als bei Default, also verbrauchst du mehr Ausgabe-Tokens. Wenn du einfach etwas fertig machen musst, geh zurück zum Grundstil:

/output-style default

Default steht mit den anderen Stilen in der Liste, du findest es also auch in /config und im Menü von VS Code. In der Desktop-App nimmst du die Zeile outputStyle aus der Datei. Wenn du wieder Zeit hast, schalt Learning wieder ein.

6. Wenn du nur die Erklärungen willst: Explanatory

Wenn du keine Lust hast, Code zu schreiben, aber verstehen willst, was passiert, gibt es Explanatory. Es arbeitet wie Default und fügt dieselben Insight-Kästen hinzu, mit den Gründen für seine Entscheidungen. Es lässt dir nichts zum Schreiben und hält nicht an, um auf dich zu warten.

Du schaltest es genauso ein: /output-style explanatory im Terminal oder Explanatory in der Datei, mit großem E. Auch hier sind die Antworten länger als bei Default, also mehr Tokens. Explanatory passt, wenn du dich in Code einarbeitest, den du nicht kennst; Learning, wenn du eine Funktion schreibst, die du selbst pflegen musst.

Häufige Fehler

• learning in der Datei kleinschreiben. In die Datei gehört Learning: Mit einem falschen Namen bleibst du in Default, und nichts weist dich darauf hin.
• In jeder Antwort einen Platzhalter (human) erwarten. Claude entscheidet, welche Teile es dir überlässt: Wenn du einen willst, bitte darum.
• Ihn eingeschaltet lassen, wenn es eilt. Lange Antworten verbrauchen mehr Tokens: Geh zurück zu Default und schalt ihn später wieder ein.
• Learning in ~/.claude/settings.json eintragen und nicht verstehen, warum es in einem Projekt nicht greift. Die Projekteinstellungen haben Vorrang: Schau nach, ob dort ein anderes outputStyle steht.
• .claude/settings.local.json von Hand anlegen und es am Ende in git committen. Wenn Claude Code die Datei anlegt, hält es sie selbst aus git heraus; legst du sie selbst an, trag sie in .gitignore ein.

Checkliste

• Learning ist in dem Projekt eingeschaltet, an dem ich arbeite
• Wenn ich es in die Datei geschrieben habe, steht dort Learning mit großem L
• Ich habe es gebeten, mir die Regeln meiner App mit dem Platzhalter (human) zu überlassen
• Ich habe meine Zeilen geschrieben und ihm gesagt, dass ich fertig bin
• Ich habe den Insight zu meinem Code gelesen
• Ich weiß, wie ich zu Default zurückwechsle, wenn es eilt

Häufige Fragen