Claude Code im Alt-Repo: am ersten Tag die erste Aufgabe sicher wählen

Am dritten Tag im neuen Job bekam ich rund 150 Dateien rund um die Zahlungsabwicklung in die Hand gedrückt. Dokumentation? So gut wie keine. Wen ich auch fragte, die Antwort war immer dieselbe: “Läuft, also fass es lieber nicht an.” Ich tat trotzdem das Naheliegende und bat Claude Code: “Verschaff dir einen Überblick über dieses Repository und korrigier, was dir auffällt.”

Zehn Minuten später meldete sich Claude voller Selbstvertrauen zurück: “20 Dateien aufgeräumt.” Ich öffnete den Diff und mir wurde flau. Die SQL-Dateien der Migrationen umformatiert, die .env.example neu sortiert und die Wartezeit beim Zahlungs-Retry eigenmächtig “optimiert”, also halbiert. Der Code lief, keine Frage. Aber wäre das in die Produktion gegangen, hätte ab dem nächsten Morgen das Telefon wegen Doppelbuchungen nicht mehr stillgestanden.

Das Problem war nicht, dass Claude zu dumm gewesen wäre. Der Bereich, den ich am ersten Tag freigegeben hatte, war schlicht zu breit. Wer fremden, riesigen Code sicher übergeben will, sucht nicht zuerst nach der schlausten KI. Man legt vorher in 30 Minuten fest: Lesereihenfolge, Tabu-Zonen, erste kleine Aufgabe und Prüfweg. Allein das lässt die meisten Unfälle des ersten Tags verschwinden. Heute zeige ich, was in diese 30 Minuten gehört, in einer Form zum Kopieren.

Das Wichtigste in Kürze

Am ersten Tag mit Bestandscode ist “Schau dir alles an und reparier es” das Gefährlichste, weil man mit unklarem Umfang losläuft.
Die ersten 30 Minuten erzeugen kein Architekturdokument, sondern einen einzigen Zettel, mit dem du die erste Aufgabe sicher auswählst.
Auf den Zettel kommen nur vier Dinge: Lesereihenfolge, Tabu-Zonen, erste kleine Aufgabe und der Prüfbefehl, der “fertig” bestätigt.
Die erste Aufgabe bleibt auf “leicht rücknehmbare” Stellen begrenzt: Texte, Button-Beschriftungen, Testnamen passen gut.
Der KI überlässt du nur “recherchieren und entwerfen”. Produktiv-DB, Abrechnung, Löschen und den Veröffentlichen-Button drückt ein Mensch.

Warum die allererste Anweisung am ersten Tag schiefgeht

Claude Code ist schnell. Und gerade weil es schnell ist, baut es bei zu breitem Startauftrag selbst die belanglosesten Diffs mit voller Kraft.

Ein menschlicher Neuzugang würde fragen: “Darf ich das hier überhaupt anfassen?” Die KI fragt nicht. Aus Hilfsbereitschaft weitet sie den Umfang aus. Sagst du “räum auf”, dann räumt sie wirklich bis in den letzten Winkel auf. Das Umformatieren der Migration und das “Optimieren” des Zahlungs-Retries tut sie in bester Absicht.

Die Aufgabe am ersten Tag ist deshalb weder, den Code komplett zu lesen, noch einen schönen Verbesserungsplan zu schreiben. Es geht darum, Grenzen zu ziehen: Wie weit darf die KI eigenständig handeln, ab wo fragt sie einen Menschen? Ziehst du diese Linie vorher, verwandelt sich der Auftrag an Claude von “denk frei nach” in “arbeite in diesem Rahmen und hinterlasse Belege”. Für die Linie brauchst du 30 Minuten. Du musst den Code dafür nicht vollständig verstehen.

Der Zettel des ersten Tags, in 30 Minuten erstellt

Papier oder Notizblock, egal. Fülle nur die folgenden vier Punkte aus. Auch ihre Reihenfolge hat einen Sinn.

Lesereihenfolge eng festlegen. Nicht sofort alle Dateien, sondern nur README und package.json. Daraus erkennst du Sprache, Startbefehl und eingesetzte Werkzeuge. Danach zwei bis drei zentrale Seiten oder Routen. Das reicht.
Tabu-Zonen aufschreiben. Abrechnung, Login-Authentifizierung, Umgebungsvariablen, Datenbank-Migrationen. Hier gilt ausdrücklich: “Lesen erlaubt, aber nicht umschreiben.” Schreibst du das nicht hin, behandelt Claude diese Stellen als ganz normale Bearbeitungsziele.
Eine erste kleine Aufgabe auswählen. Begrenzt auf leicht rücknehmbare Stellen: der Text am Artikelende, eine Button-Beschriftung, ein unverständlicher Testname. Etwas, das du bei Fehlern sofort zurückdrehen kannst.
Den Prüfweg für “fertig” festlegen. Läuft der Build durch, liegt der Diff im erwarteten Rahmen, ist die Ansicht nicht zerbrochen? Entschieden wird nicht nach Gefühl, sondern am Ergebnis eines Befehls.

Sind diese vier ausgefüllt, verschwindet der größte Teil der Unsicherheit des ersten Tags. Denn du weißt nicht mehr, “was Claude anstellen könnte”, sondern “wie weit du Claude betraut hast”.

Was die KI übernimmt, was der Mensch entscheidet

Hältst du die Grenze in Worten fest, zögerst du nicht jedes Mal neu. So teile ich es auf:

Tätigkeit	Claude überlassen	Mensch entscheidet
Code lesen und Struktur zusammenfassen	ja, Entwurf erstellen lassen	endgültiges Verständnis selbst prüfen
Tabu-Zonen vorschlagen	ja, Kandidaten nennen lassen	Abrechnung und Auth bestätigt immer ein Mensch
Texte und Beschriftungen korrigieren	ja, kann übergeben werden	Diff ansehen und freigeben
Schreiben in die Produktiv-DB	nein	Mensch führt es von Hand aus
Löschen, Veröffentlichen, Abrechnung	nein	Mensch drückt den Button

Der Kern ist, gefährliche Operationen von Anfang an komplett auf die Seite “Mensch fragen” zu legen. Erst nachträglich stufst du Operationen, die sich als sicher erwiesen haben, auf “automatisch” hoch. Umgekehrt nie. Zuerst breit freigeben und nach dem Unfall nachziehen, das ist die falsche Reihenfolge.

Wer diese Denkweise gründlicher kennenlernen möchte, liest am besten Claude Code: die ersten Schritte und Claude Code: Checkliste für die ersten 30 Minuten dazu, dann fügen sich die Bewegungen des ersten Tags zusammen.

Kopierbare Auftragsvorlagen

Erster Trick: nicht sofort bearbeiten lassen. Am Anfang bittest du nur um “lesen und in einer Tabelle zusammenfassen”.

Ich öffne dieses Repository zum ersten Mal. Bearbeite noch nichts.
Lies in folgender Reihenfolge und gib das Ergebnis als Tabelle zurück.

1. Lies README und package.json und nenne verwendete Sprache, Startbefehl und zentrale Abhängigkeiten
2. Liste die gefährlichen Stellen (Abrechnung, Auth, Umgebungsvariablen, DB-Migrationen) mit Dateipfaden auf
3. Nenne drei leicht rücknehmbare Kandidaten für die "erste kleine Aufgabe", jeweils mit Begründung
4. Schreibe je Kandidat den Befehl, der den Abschluss bestätigt (Build, Diff-Prüfung usw.)

Ich wiederhole: In dieser Phase kein einziges Zeichen bearbeiten.

Kommt die Tabelle zurück, prüfst du mit eigenen Augen, ob in den “Tabu-Zonen” nichts fehlt. Fehlt etwas, ergänzt du es, und erst dann übergibst du genau eine Aufgabe.

Setze von den vorherigen Kandidaten nur XX um (Textkorrektur am Artikelende).
Abrechnung, Auth, Umgebungsvariablen und Migrationen auf keinen Fall anfassen.
Führe nach der Bearbeitung `npm run build` aus und zeige den Diff per `git diff --stat`.
Falls etwas kaputtgeht, erkläre Ursache und Korrektur in einer Zeile und halte dann an.

Schreibst du die “Tabu-Zonen” von Anfang an in die CLAUDE.md, sparst du dir diesen Hinweis jedes Mal. Wie das geht, steht in CLAUDE.md Best Practices.

Ein kleiner Code, der die Prüfung der Maschine überlässt

Verlässt du dich beim “erst vorbereiten, dann übergeben” auf dein Gedächtnis, vergisst du es an einem hektischen Tag garantiert. Also lässt du eine Maschine entscheiden, ob der Zettel das Minimum erfüllt. Folgender Code läuft so direkt in Node.js.

// Maschinell prüfen, ob der Zettel des ersten Tags "an Claude übergebbar" ist
const repoMap = {
  goal: "eine leicht rücknehmbare erste Aufgabe auswählen",
  readFirst: ["README.md", "package.json", "src/routes/"],
  protectedAreas: [".env", "billing/", "migrations/", "wrangler.toml"],
  firstTask: "Text am Artikelende korrigieren (Zahlungscode nicht anfassen)",
  proofCommands: ["npm run build", "git diff --stat"],
};

function isReady(map) {
  const reasons = [];
  if (map.readFirst.length < 2) reasons.push("Lesereihenfolge zu eng / nicht gesetzt");
  if (map.protectedAreas.length === 0) reasons.push("Tabu-Zonen leer");
  if (!map.proofCommands.some((c) => c.includes("build"))) {
    reasons.push("kein Build-Prüfbefehl vorhanden");
  }
  if (!map.firstTask) reasons.push("erste Aufgabe nicht ausgewählt");
  return { ready: reasons.length === 0, reasons };
}

const result = isReady(repoMap);
console.log(result.ready ? "Übergabe OK" : "Noch nicht übergeben: " + result.reasons.join(", "));

Beim Ausführen sieht das so aus.

node check-repo-map.mjs
# => Übergabe OK

Setzt du testweise protectedAreas auf ein leeres Array, erscheint “Noch nicht übergeben: Tabu-Zonen leer”. Mehr ist es nicht, aber es stoppt vor der Übergabe genau den häufigsten Unfall: “die Tabu-Zonen vergessen aufzuschreiben und trotzdem vollautomatisch loslaufen”. Klebst du diesen Zettel direkt in die CLAUDE.md oder ein Issue, können dein Ich von morgen und deine Kolleginnen dieselbe Entscheidung wiederverwenden.

Drei Situationen, in denen es wirklich half

1. Im Blog-Betrieb die Links der umsatzstarken Artikel schützen Wenn du nur die Verlinkung am Ende eines beliebten Artikels anpassen willst und Claude “verbessere den Text” aufträgst, fummelt es schnell auch an der Produkt-URL herum. Also schließt du den Rahmen: “Den Text darfst du korrigieren, aber an der Ziel-URL kein einziges Zeichen ändern. Zeig nach der Änderung Build und Diff.” So polierst du nur den Text, ohne die umsatzrelevanten Links zu zerstören.

2. Im SaaS nicht an die Abrechnung herankommen Ist der Erklärtext im Einstellungsbildschirm unklar, ist das Ziel allein der angezeigte Text. Die Logik für Abrechnung oder Tarifwechsel bleibt tabu. Steht billing/ in den “Tabu-Zonen” des Zettels, verhinderst du, dass Claude aus Hilfsbereitschaft die Retry-Logik anfasst.

3. Im internen Tool nur die Spaltennamen der Ausgabe ändern Eine Anfrage lautete, die Spaltennamen der CSV-Ausgabe seien unverständlich. Zu ändern ist nur der Text der Spaltennamen, die Aggregationslogik ist eine andere Baustelle. Mit “Nur die angezeigten Spaltennamen. Die Berechnungsformeln nicht anfassen. Zeig die Ausgabe mit Beispieldaten” ist auch die Prüfung im Nu erledigt.

Allen dreien gemeinsam ist nicht ein Mangel an Fähigkeit bei Claude, sondern der eine Punkt: bei dünner Grenze passieren Unfälle. Je klarer du die Grenze schreibst, desto sicherer und schneller arbeitet die KI.

Häufige Stolperfallen und ihre Behebung

Stolperfalle 1: Von Anfang an alle Dateien lesen lassen. Du verbrauchst Zeit und Tokens für unwichtiges Formatieren, und die eigentliche Änderung wird dünn. Behebung: Das Leseziel auf README und package.json plus zwei bis drei zentrale Routen begrenzen. Den Gesamtüberblick weitest du Schritt für Schritt aus, nachdem die erste Aufgabe erledigt ist.

Stolperfalle 2: Tabu-Zonen nicht aufschreiben. Claude behandelt Abrechnung, Auth und Deploy-Einstellungen als ganz normale Bearbeitungsziele. Behebung: Die Schutzliste mit Dateipfaden schreiben und dauerhaft in der CLAUDE.md halten. Mündliche Hinweise werden vergessen, Geschriebenes bleibt.

Stolperfalle 3: Ohne Prüfbefehl dem “fertig” glauben. Du musst jedes Mal raten, ob die Abschlussmeldung stimmt. Behebung: Von Anfang an “bau es und zeig den Diff” in den Auftrag schreiben. HTTP 200 oder eine plausibel klingende Antwort sind kein Beleg für Erfolg. Glaube nur dem Ergebnis eines tatsächlich ausgeführten Laufs.

Häufige Fragen

F. Ist es nicht sicherer, erst das ganze Bestandssystem zu verstehen und dann zu übergeben? Ideal ja, aber das vollständige Verständnis wirst du am ersten Tag nicht fertig. Wartest du darauf, geht nichts voran. Also schließt du zuerst die “Tabu-Zonen” und startest mit einer leicht rücknehmbaren Aufgabe. Verständnis baut sich schneller auf, während du arbeitest.

F. Wie klein sollte die erste Aufgabe sein? Als Richtwert: erledigt mit einer Datei, einem Text, einem Befehl. Beauftragst du groß, weitet Claude hilfsbereit den Umfang aus. Wenn du erst Build und Screenshot prüfst und dann weitergehst, verlierst du kein Tempo und verkürzt die Rückrolldauer.

F. Wo schreibe ich die Tabu-Zonen am besten hin? In die CLAUDE.md zu schreiben hält am längsten durch. Die Methode “jedes Mal in den Prompt kleben” vergisst du an hektischen Tagen. Legst du es als Projektregel an eine Stelle, wirkt es auch bei neuer Arbeit automatisch.

F. Ich habe “nicht anfassen” gesagt, und Claude hat es trotzdem angefasst. Meist endet das Schutzziel beim Dateinamen und du hast nicht das ganze Verzeichnis angegeben. Schreib nicht nur billing.js, sondern als Bereich billing/. Übertritt es die Grenze trotzdem, schiebst du am Anfang des Auftrags ein “Erkläre vor dem Bearbeiten die Zieldateien und fahre dann fort” ein, dann hält es leichter an.

F. Muss ich diesen Zettel jedes Mal neu erstellen? Pro Repository einmal erstellt, danach immer wiederverwendbar. Klebst du ihn in die CLAUDE.md und ein Issue, übernehmen dein Ich von morgen und deine Kolleginnen dieselbe Entscheidung. Findest du ein neues Schutzziel, ergänzt du es einfach.

Was ich tatsächlich ausprobiert habe

Nach dem Zahlungscode-Vorfall vom Anfang probierte ich dasselbe Vorgehen an einem anderen Bestands-Repository. Ich ließ zuerst gar nichts bearbeiten und nur mit dem Auftrag von oben die Tabelle ausgeben. Tatsächlich nannte Claude billing/ und migrations/ korrekt als Schutzkandidaten. Allerdings fehlte die Datei der Umgebungsvariablen, also ergänzte ich .env selbst. Mir wurde erneut klar, wie wichtig es ist, diese Stelle unter der Annahme zu fahren, dass ein Mensch sie prüft.

Die erste Aufgabe begrenzte ich auf eine einzige Textkorrektur am Artikelende und schloss sie ab, geprüft bis npm run build und git diff --stat. Der Diff betrug nur sieben Zeilen, am Zahlungscode war kein einziges Zeichen berührt. Auch den Prüfcode ließ ich tatsächlich laufen und bestätigte: Setzt man protectedAreas leer, stoppt er mit “Noch nicht übergeben”. Statt nach der schlausten KI zu suchen, lieber vorher einen kleinen Bereich festlegen, der sich auch nach einem Sturz sofort zurückdrehen lässt. Das half am ersten Tag mit fremdem Code am meisten.

Wenn du gerade an dem Punkt bist, im Bestandscode deiner Firma ein Team-Vorgehen für Claude Code festzulegen, können wir in der Schulung und Beratung anhand eures echten Repositories gemeinsam sortieren, wie ihr die Grenzen zieht. Als offizielle Grundlage prüfst du am besten zusätzlich Anthropic Claude Code getting started.