Der Satz, der alles kaputt macht

Was es ist und warum es zählt

Der Satz, der alles kaputt macht, ist der schnell hingeworfene: „repariere den Login“, „mach die Seite schneller“, „bau die Zahlungen ein“. Claude Code nimmt ihn ernst und tut etwas. Das Problem: Es entscheidet selbst, was „repariert“ heißt, was es anfassen darf und wann es fertig ist.

Das ist kein Fehler der KI. Claude kann nur keine Gedanken lesen. Auch der Prompting-Leitfaden von Anthropic sagt es einfach: Behandle Claude wie einen brillanten Kollegen, der gerade erst angefangen hat und deine Regeln und dein Projekt nicht kennt. Je genauer du sagst, was du willst, desto besser das Ergebnis.

Deshalb fülle ich vor jeder Anfrage eine Vorlage mit drei Zeilen aus: was passieren soll, was sich nicht ändern darf, wie wir es prüfen. Das dauert nicht lange. Es erspart mir den schlimmsten Teil: am Ende festzustellen, dass Claude etwas umgeschrieben hat, das funktioniert hat. Dieselbe KI liefert dir mit einer klaren Anfrage ein anderes Ergebnis. Das ist keine Magie: Es heißt nur, klar zu sein mit jemandem, der keine Gedanken lesen kann.

Die Vorlage in drei Zeilen

Hier ist sie. Kopier sie und füll die Klammern aus. Eine Zeile pro Teil reicht.

Was passieren soll: [das Ergebnis, das du sehen willst, in deinen eigenen Worten]
Was sich nicht ändern darf: [Dateien, Seiten oder Funktionen, die es nicht anfassen darf]
Wie wir es prüfen: [woran du merkst, dass es funktioniert: ein Test, ein Klick, ein Wert, der erscheinen muss]

Was passieren soll

Das Ergebnis, das du sehen willst, nicht der Weg dorthin. Schreib es in deinen eigenen Worten, so wie du es laut sagen würdest. „Wenn ich auf Speichern drücke, erscheint die Notiz in der Liste“ funktioniert besser als „behebe den Speicher-Bug“, weil es sagt, was jemand sieht, der die App benutzt. Wenn du weißt, wo es passiert, also welche Seite, welcher Button, schreib es dazu: Dann muss Claude nicht raten.

Was sich nicht ändern darf

Die Grenzen: Dateien, Seiten oder Funktionen, die so bleiben müssen, wie sie sind. Um eine Sache zu reparieren, „verbessert“ Claude manchmal andere Dinge daneben, um die niemand gebeten hat. Wenn du sagst, wo es die Finger weglassen soll, hat es eine klare Grenze. Das ist die Zeile, die fast alle überspringen, und ich komme weiter unten darauf zurück.

Wie wir es prüfen

Woran du merkst, dass es funktioniert: ein Test, ein Klick, ein Wert, der erscheinen muss. Diese Zeile ist für dich und für Claude. Wenn Claude eine Prüfung hat, die es selbst ausführen kann, etwa einen Test, der besteht oder durchfällt, kann es probieren, das Ergebnis lesen und sich korrigieren, bevor es dir sagt, dass es fertig ist. Ohne sie ist das einzige Signal, dass die Arbeit „fertig aussieht“, und das Prüfen bleibt an dir hängen.

Zwei Beispiele zum Kopieren

Beispiel 1: ein Button, der nicht speichert

Was passieren soll: Wenn ich auf der Seite Notizen auf den Button Speichern drücke, soll eine Zeile in der Notizen-Tabelle der Datenbank angelegt werden.
Was sich nicht ändern darf: Fass den Login nicht an und ändere das Design der Seite nicht.
Wie wir es prüfen: Sag mir genau, wie ich es teste, Schritt für Schritt, und wenn du kannst, schreib einen Test, der es prüft.

Schau dir die dritte Zeile an. Du musst keinen Test schreiben können: Ich bitte Claude, mir zu sagen, wie ich es ausprobiere, und, wenn es geht, den Test selbst zu schreiben. Du musst nicht wissen, wie man es prüft. Du musst nur darauf bestehen, dass es einen Weg gibt.

Beispiel 2: eine langsame Seite

Was passieren soll: Die Preisseite soll sich in weniger als zwei Sekunden öffnen, auch auf dem Handy.
Was sich nicht ändern darf: Preise, Texte und Bezahlung bleiben genau gleich.
Wie wir es prüfen: Miss die Ladezeit vorher und nachher und zeig mir die zwei Zahlen.

Hier ist die Prüfung eine Zahl vorher und eine nachher. Wenn Claude dir sagt „jetzt ist es schneller“, ohne die zwei Zahlen, weißt du nicht, ob es stimmt. Und die mittlere Zeile schützt, was sich beim Optimieren nicht aus Versehen ändern soll: Preise, Texte, Bezahlung.

Drei Tipps, wie du sie in Claude Code nutzt

1. Wenn du nicht weißt, wie du es prüfst, halt an

Wenn du auf „wie prüfen wir es“ keine Antwort hast, weißt du noch nicht, was du willst. Das passiert, und es ist besser, es vorher zu merken als nachher. Statt die Arbeit zu starten, bitte um Hilfe, es herauszufinden:

Hilf mir herauszufinden, wie ich das überprüfen kann, schreib keinen Code.

Für größere Aufgaben nutze ich den Plan-Modus von Claude Code (plan mode). Claude liest die Dateien und schlägt dir einen Plan vor, ändert aber nichts, bis du ihn freigibst. Du kommst hinein, indem du Shift+Tab drückst, bis unten „plan mode on“ erscheint, oder indem du /plan vor deine Nachricht schreibst. Dort füge ich die Vorlage ein und frage:

Lies die Vorlage unten und schlag mir einen Plan vor. Sag mir, welche Dateien du anfassen willst, bestätige, dass du die ausgeschlossenen nicht anfasst, und erklär mir, wie wir die Prüfung aus der letzten Zeile machen.

[hier die ausgefüllte Vorlage einfügen]

Für eine kleine Änderung brauchst du keinen Plan: Wenn du sie in einem Satz beschreiben kannst, etwa einen Tippfehler in einem Text korrigieren, frag einfach direkt danach.

2. Überspring nicht die mittlere Zeile

„Was sich nicht ändern darf“ ist der Teil, den alle überspringen, und genau der rettet dir den Login, die Zahlungen und die echten Daten. Was Claude nie anfassen darf, schreibe ich zusätzlich in die CLAUDE.md, die Datei im Projektordner, die Claude Code zu Beginn jeder Sitzung liest. Zum Beispiel diese Zeile:

Ändere den Login, die Zahlungen und die Nutzerdaten nicht, ohne mich vorher zu fragen.

Aber Vorsicht: Die CLAUDE.md ist eine Anweisung, kein Schloss. Claude behandelt sie als Kontext, nicht als feste Sperre. Deshalb schreibe ich diese Teile trotzdem in die Vorlage, wenn eine Anfrage in ihre Nähe kommt.

3. Frag am Ende nach dem Bericht

Wenn Claude fertig ist, frag immer:

Sag mir, was du geändert hast und was du nicht angefasst hast.

Dann vergleich die Antwort mit der Vorlage. Wenn Claude etwas aus der mittleren Zeile angefasst hat oder die Prüfung aus der dritten Zeile fehlt, siehst du es sofort. Dann mache ich nicht weiter und frage:

Zeig mir den Nachweis für die letzte Zeile der Vorlage: den Test mit dem Ergebnis oder die genauen Schritte, wie ich es selbst ausprobiere.

Häufige Fehler

• Den Code statt des Ergebnisses beschreiben, etwa „ändere diese Funktion“: Schreib, was jemand sieht, der die App benutzt, und überlass Claude das Wie.
• „Was sich nicht ändern darf“ leer lassen, weil es offensichtlich scheint: Schreib mindestens Login, Zahlungen und echte Daten hin, wenn die Arbeit in ihre Nähe kommt.
• Eine vage Prüfung wie „schau, ob es funktioniert“: Verlang etwas, das man sieht oder misst, also einen Test, der besteht, einen Klick, eine Zahl.
• Drei Anfragen in dieselbe Vorlage packen: eine Vorlage, eine Sache, und den Rest fragst du danach, eins nach dem anderen.
• Dem „fertig“ ohne Bericht vertrauen: Frag, was Claude geändert und was es nicht angefasst hat, und vergleich es mit der Vorlage.

Checkliste

• Ich habe das Ergebnis in eigenen Worten geschrieben
• Ich habe aufgeschrieben, was es nicht anfassen darf
• Ich weiß, wie ich prüfe, ob es funktioniert
• Die Vorlage verlangt nur eine Sache
• Bei einer großen Aufgabe habe ich zuerst einen Plan verlangt
• Am Ende habe ich gefragt, was geändert wurde und was nicht

Häufige Fragen