Claude Code für Einsteiger: Die 15-Minuten-Routine für sichere Arbeit am Morgen

Freitagabend habe ich Claude Code zugeworfen: “Bring an diesem Projekt alles in Ordnung, was dir auffällt.” Dann bin ich schlafen gegangen.

Am nächsten Morgen waren 23 Dateien verändert. Manches lief sogar. Aber ich konnte selbst nicht erklären, was davon wirklich repariert war und was ich überhaupt prüfen sollte. Allein das Lesen des Diffs von oben bis unten kostete mich eine Stunde – und am Ende hatte ich solche Angst, dass ich keine einzige Zeile committet habe.

Ich hatte die schlaue KI um etwas Großes gebeten und war danach nicht weiter, sondern weiter zurück. Genau in diese Falle tappen Einsteiger zuerst.

Schuld war nicht die Leistung von Claude Code. Ich hatte nur nicht festgelegt, wie ich eine Aufgabe “abschließe”. Heute gebe ich dir genau die 15-Minuten-Routine, die ich morgens mache, während der Kaffee durchläuft.

Das Wichtigste in Kürze

“Mach alles” ist die Quelle der Unfälle. Mache täglich nur eine einzige kleine Aufgabe, die du in einem Satz festgelegt hast.
Lege den Prüfbefehl, mit dem du das Ergebnis abnimmst, fest, bevor du mit dem Bearbeiten beginnst.
Nach der Arbeit reichen drei Dinge: “geänderte Dateien”, “Ergebnis des Prüfbefehls” und “der nächste Schritt”.
Der KI überlässt du das Hände-Schmutzig-Machen. Den Umfang festlegen und den Veröffentlichen-Knopf drücken bleibt beim Menschen.
Mit dem Skript unten reihst du deine morgendlichen Prüfungen automatisch hintereinander.

Warum “klein abschließen” für Einsteiger funktioniert

Als ich anfing, mit Claude Code zu arbeiten, war mein Ziel jedes Mal schwammig. “Mach es schön.” “Mach es lesbar.” Bei solchen Aufträgen weiß man auch hinterher nicht, was die KI genau und bis wohin gemacht hat.

Bei einem menschlichen Berufsanfänger ist es genauso. Wer den Auftrag bekommt “Mach mit dieser Präsentation irgendwie was Sinnvolles”, steht meist ratlos da. Wer hört “Tausch auf Seite 3 die Zahlen gegen die aktuelle Version aus und prüf, ob die Tabelle nicht verrutscht ist”, kann sofort loslegen – und selbst beurteilen, ob er fertig ist.

Bei einer täglichen Routine kommt es nicht darauf an, eine schlaue Anweisung in einem Wurf zu schreiben. Es kommt darauf an, klein zu zerlegen und es so zu formen, dass du das Ende beurteilen kannst. Wenn das gelingt, kann selbst ein Einsteiger jeden Tag sagen: “Bis hierhin bin ich heute gekommen.”

Übrigens baut dieses Denken auf zwei anderen Artikeln auf: So startest du mit Claude Code und Berechtigungen verwalten – die Grundlagen. Richte zuerst dort deine Umgebung ein, dann legst du diese Gewohnheit obendrauf – so wirkt sie am besten.

In 15 Minuten machst du nur vier Schritte

Was ich jeden Morgen mache, sind genau diese vier Dinge. Die Reihenfolge halte ich jedes Mal gleich. Eine feste Reihenfolge sorgt dafür, dass der Körper losläuft, ohne dass man nachdenken muss.

Schreib die kleinste Aufgabe des Tages in einem Satz. Zum Beispiel “Nur die drei Einleitungszeilen der README neu schreiben” – in einer Körnung, bei der das Ende absehbar ist. Große Aufgaben lässt du heute bewusst liegen.
Lege zuerst den Prüfbefehl fest. “OK, wenn npm run build durchläuft” oder “OK, wenn ein Test grün wird” – die Form des Ziels legst du fest, bevor du mit dem Bearbeiten anfängst.
Arbeite, dann prüf in der Reihenfolge Diff, Build, Live-URL. Veröffentliche nicht sofort, sondern geh von dem aus, was die Maschine eindeutig sagen kann.
Lass für nächstes Mal nur eine Zeile übrig. Notiere “verbleibendes Risiko” und “nächste kleinste Aufgabe”. Das ist dein Start am nächsten Morgen.

Der Knackpunkt ist Schritt 2. Wenn du mit dem Bearbeiten anfängst, ohne vorher den Prüfbefehl festzulegen, landest du wieder bei jenem Freitagabend: “Fühlt sich repariert an, aber ich hab keinen Beweis.” Zieh die Ziellinie, bevor du losläufst. Allein das macht die tägliche Arbeit spürbar leichter.

Was die KI übernimmt und was der Mensch entscheidet

Hier verheddern sich Einsteiger meiner Meinung nach am meisten. Man kann nicht alles blind an die KI abgeben – aber wenn man alles selbst macht, hat das Werkzeug keinen Sinn. Ich habe die Trennlinie in eine Tabelle gepackt.

Situation	Die KI übernimmt	Der Mensch entscheidet / drückt
Umfang festlegen	Vorschläge liefern	Den einen Satz für heute festklopfen
Bearbeiten	Code oder Text schreiben	Die Richtung, was repariert wird
Prüfen	Build und Tests ausführen	Welche Prüfung das Ziel ist
Veröffentlichen	Den Diff zusammenfassen	Den Veröffentlichen-Knopf drücken
Gefährliche Aktionen	Fragen “Darf ich?”	Die finale Entscheidung über Löschen / Produktiv-Deploy

Die Faustregel bei Zweifeln ist einfach: Umkehrbares an die KI, Unumkehrbares an den Menschen. Das Bearbeiten von Dateien kann man beliebig oft rückgängig machen, also überlässt du es ihr. Das Veröffentlichen in Produktion oder das Löschen von Dateien drückst du anfangs immer selbst. Nur Aktionen, die dir vertraut geworden sind, stufst du später Stück für Stück auf “automatisch” hoch. Die Feinheiten der Berechtigungen sind in der offiziellen Claude-Code-Dokumentation zusammengefasst – wenn du bei der Trennlinie unsicher bist, lohnt ein Blick.

Eine Vorlage für deinen Auftrag zum Kopieren

Wer jeden Auftrag bei null neu schreibt, dem verrutscht die Körnung. Ich habe diese Vorlage in einer Notiz-App und fülle sie jeden Morgen aus.

Kleinste Aufgabe heute: (ein Satz. Beispiel: die drei Einleitungszeilen der README neu schreiben)
Erlaubter Bereich: (Beispiel: nur README.md. Andere Dateien dürfen nicht verändert werden)
So wird Abschluss geprüft: (Beispiel: npm run build läuft erfolgreich durch)

Vorgehen:
1. Lies zuerst, ohne etwas zu ändern, den aktuellen Stand und fasse ihn zusammen.
2. Bearbeite nur den oben genannten Bereich. Fass nichts außerhalb davon an.
3. Melde nach dem Bearbeiten die geänderten Dateinamen und das Ergebnis der Prüfung.
4. Falls Löschen, Produktiv-Deploy oder externes Senden nötig wird, führ es nicht aus, sondern frag vorher nach.

Allein die zwei Zeilen “nichts außerhalb des Bereichs anfassen” und “gefährliche Aktionen vorher abklären” sorgen dafür, dass der 23-Dateien-Unfall vom Anfang praktisch nicht mehr passiert. Du gibst der KI keine Freiheit, sondern reichst ihr eine sichere Kiste.

Ein Prüfskript, das sofort läuft

Wenn ich die morgendliche Prüfung von Hand tippe, vergesse ich etwas. Ich lege dieses Skript als morning-check.mjs ab und lasse es laufen, bevor ich den Kaffee aufsetze. Es läuft, sobald Node.js installiert ist.

// morning-check.mjs : reiht die morgendlichen Pruefungen aneinander und fuehrt sie aus
import { execSync } from "node:child_process";

// Befehle, die du pruefen willst, der Reihe nach. Passe sie an dein Projekt an.
const checks = [
  { label: "Geaenderte Dateien", cmd: "git status --short" },
  { label: "Laeuft der Build", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // Gib das Ergebnis direkt aus. Bei einem Fehler geht es ins catch unten.
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(keine Ausgabe)");
  } catch (e) {
    allOk = false;
    console.log("Fehlgeschlagen:", e.message.split("\n")[0]);
  }
}

console.log("\n--- Abschluss fuer heute ---");
console.log(allOk ? "Pruefung OK. Notiere die naechste kleinste Aufgabe in einer Zeile." : "Pruefung gestoppt. Erst reparieren, dann weiter.");

Ausführen ist nur das:

node morning-check.mjs

Der Trick ist, den Inhalt von checks an dein eigenes Projekt anzupassen. Gibt es Tests, häng npm test an; bei einer statischen Seite prüf zusätzlich die Live-URL. Allein dadurch, dass jeden Morgen dieselben Befehle in derselben Reihenfolge durchlaufen, verschwinden vergessene Prüfungen fast vollständig. Ich habe hier noch die Prüfung “Bin ich stehen geblieben, ohne am Ende zu committen?” ergänzt.

Drei Situationen, in denen das wirkt

Beispiel 1: Am ersten Tag nur eine Karte des Repos zeichnen. Du musst nicht sofort Code anfassen. Lass dir von der KI zusammenfassen, “wo die gefährlichen Verzeichnisse liegen” und “wo die Konfigurationsdateien sind”, und lies das nur durch – damit ist der erste Tag ein Erfolg. Die Arbeit ab dem nächsten Tag wird dadurch deutlich schneller.

Beispiel 2: Am zweiten Tag nur einen Absatz der README. Du baust ein kleines Erfolgserlebnis. Schreib die Einleitung in drei Zeilen neu und prüf mit npm run build, ob nichts kaputt ist. Mehr nicht. Wenn du es klein abschließt und sauber bis zur Prüfung durchziehst, bekommst du das Gefühl: “Das kann ich selbst stemmen.”

Beispiel 3: Am dritten Tag eine kleine Verbesserung mit messbarem Effekt. Eine Überschrift im Artikel ändern, einen Test ergänzen, einen kaputten Link reparieren. Wähl eine kleine Verbesserung mit sichtbarem Ergebnis. Entscheidend ist, jeden Tag eine “bis zur Prüfung durchgegangene Änderung” zu stapeln.

Fehlerbeispiele und wie du sie behebst

Ehrlich gesagt bin ich über diese drei Dinge immer wieder gestolpert.

Falle 1: Alles auf einmal machen wollen. “Alles, was auffällt” erzeugt einen riesigen Diff, den du nicht mehr prüfen kannst. Die Behebung ist simpel: beschränk den einen Satz für heute auf genau “einen”. Der Rest wandert in die Notiz für morgen.

Falle 2: Den lokalen Build als Abschluss werten. Auch wenn npm run build durchläuft, heißt das nicht, dass die Live-URL korrekt ausgespielt wird. Mir ist einmal passiert, dass der Build grün war, die veröffentlichte Seite aber alt blieb – und ich es nicht bemerkte. Die Behebung: nach dem Veröffentlichen die tatsächliche URL öffnen und mit eigenen Augen prüfen, ob Überschrift und Anfang des Texts die aktuelle Änderung zeigen.

Falle 3: Eine gefährliche Bestätigung aus dem Reflex abnicken. Wenn ein Bestätigungsdialog erscheint, drücken Einsteiger gern “erst mal Ja”. Kommt die Abfrage zu einem Löschen oder Produktiv-Deploy, halt einmal inne. Bist du dir unsicher, lautet die richtige Antwort: diese Aktion machst du heute nicht. Beim Denken über Berechtigungen hilft auch die Erklärung für Nicht-Entwickler.

Die Form der Notiz für nächstes Mal

Die abschließende Notiz darf kurz sein. Aber leg die Form fest, damit dein Ich am nächsten Morgen nicht dieselbe Entscheidung noch einmal treffen muss.

- Heute gemacht: die drei Einleitungszeilen der README neu geschrieben
- So geprueft: npm run build erfolgreich / Ueberschrift an der Live-URL kontrolliert
- Verbleibendes Risiko: zwei kaputte Bild-Links
- Kleinste Aufgabe morgen: genau einen Bild-Link reparieren

Mit dieser Notiz fällt die Zeit, in der du dich morgens fragst “Womit fange ich an?”, auf null. Seit ich das mache, komme ich gefühlt fünf Minuten schneller in Gang.

Häufige Fragen

F. Ich habe nicht jeden Tag 15 Minuten. Geht es kürzer? Ja. Am Anfang reicht auch nur “die kleinste Aufgabe des Tages in einem Satz schreiben”. Sobald die Gewohnheit sitzt, den Prüfbefehl festzulegen, wird die Arbeitszeit von selbst kürzer.

F. Ich weiß nicht, was mein Prüfbefehl sein soll. Gibt es im Projekt npm run build oder npm test, reicht das fürs Erste. Gibt es nichts davon, ist “die Live-URL öffnen und mit eigenen Augen prüfen” eine vollwertige Prüfung. Anfangs genügt es, eine maschinell überprüfbare Sache festzulegen.

F. Wäre es nicht schneller, alles der KI zu überlassen? Kurzfristig sieht es so aus. Aber eine “Änderung, bei der du nicht erklären kannst, was repariert wurde”, musst du am Ende doch komplett neu durchlesen. Klein abzuschließen ist unterm Strich schneller – das ist meine Erfahrung.

F. Was sollte ein Einsteiger als Allererstes tun? Eine Karte des Repos zeichnen. Bevor du Code anfasst, lass dir von der KI zusammenfassen, wo was liegt, und lies das. Das ist das Fundament, um sicher voranzukommen.

F. Lässt sich diese Routine auch im Team einführen? Ja. Im Team solltest du aber vorab dokumentieren, “wer das Veröffentlichen freigibt” und “welche Prüfung das Ziel ist”. Dann wird aus der persönlichen Gewohnheit direkt eine Team-Regel. Wie man solche Regeln festhält, zeigt der Artikel zu den CLAUDE.md-Best-Practices.

Was dabei herausgekommen ist, als ich es ausprobiert habe

Seit jenem Freitagabend habe ich aufgehört, mich mit der Frage zu quälen, “wie viel ich der KI überlasse”. Stattdessen lege ich jeden Morgen nur zwei Dinge fest: den einen Satz für heute und den Prüfbefehl.

Ich habe morning-check.mjs zwei Wochen laufen lassen, und am stärksten verändert haben sich die vergessenen Prüfungen. Früher habe ich committet im Glauben, der Build sei durch, und später war etwas kaputt – das passierte mehrmals. Seit ich die Prüfung in derselben Reihenfolge von der Maschine durchlaufen lasse, ist das auf null gefallen.

Und die Vier-Zeilen-Notiz jeden Abend. Seit ich das mache, ist das morgendliche “Was war noch mal zu tun?” verschwunden. Statt nach der schlauen Nutzung zu suchen, schließt du klein ab und lässt die Prüfung übrig. Unscheinbar – aber ich glaube, hier entscheidet sich, wie schnell ein Einsteiger vorankommt.

Leg morgen früh einfach nur den einen Satz fest und lass einen Prüfbefehl laufen. Wenn sich dabei mit der Zeit dein eigener Stil herausbildet, kannst du in der Lernmaterial-Übersicht deine Auftragsvorlagen erweitern – das reduziert die Handgriffe pro Tag noch weiter.