Vor einer Weile stand eine Framework-Migration an. Normalerweise hätte ich Claude Code das Ticket autonom abarbeiten lassen – Agent-Modus, Ergebnis abwarten, Diff reviewen.
Aber diesmal wollte ich verstehen, was sich bei der Migration alles ändert und welche Neuerungen die neue Version mitbringt. Ich wollte die Migration selbst implementieren, mit Claude als Tutor an meiner Seite.
Also, rein ins Vergnügen.
Kurze Unterbrechung – KI, die im Unternehmen wirklich ankommt
Code Tutor – der Plan
Die Idee: Claude erstellt einen vollständigen Migrationsplan und leitet mich Schritt für Schritt durch die Umsetzung. Pro Schritt erklärt er, was zu tun ist und warum, verlinkt die relevanten Teile der Doku und gibt Hinweise, worauf ich achten soll. Ich lese, verstehe, schreibe den Code selbst. Wenn ich fertig bin, prüft Claude das Ergebnis und gibt Feedback, bevor es zum nächsten Schritt weitergeht.
Die Rollenverteilung ist dabei klar: Claude behält den Überblick über den Gesamtplan, erklärt und reviewt. Ich entwickle den Code.
Was auf dem Weg passiert ist
Selbst schreiben heißt selbst stolpern. Das ist wichtig für das Verständnis.
Lorenz, gestolpert. Und was dabei gelernt.
Die Migration lief über zehn Schritte: Docs lesen, Dependencies hinzufügen, Server umschreiben, testen, zweiten Server migrieren, aufräumen. Bei jedem Schritt erklärte Claude, was zu tun ist und warum. Ich schrieb den Code, führte ihn aus, debuggte die Fehler – und dabei fiel einiges auf, das ein autonomer Agent stillschweigend übergangen hätte.
Gleich am Anfang referenzierte der Plan eine Utility-Funktion, die in der Library überhaupt nicht existierte. Hätte Claude den Code geschrieben, wäre der Import unbemerkt geblieben und erst später mit einem Fehler aufgefallen. Weil ich ihn selbst ausführte, flog er sofort auf.
An einer anderen Stelle schlug der Linter vor, verschachtelte `async with`-Blöcke zusammenzufassen. Das klang sinnvoll, hätte aber die gewünschte Initialisierungsreihenfolge gebrochen. Und als ich später die API-Docs des migrierten Servers öffnete, zeigte sich, dass bestimmte Endpoint-Definitionen aus dem alten Framework im neuen nicht sauber funktionieren.
All das wäre mir entgangen, wenn ich den Agent hätte machen lassen. Selbst schreiben heißt selbst stolpern – und genau diese Stolperer bauen Verständnis.
Wo der klassische Tutor-Mode an seine Grenzen stößt
Ungefähr zur Hälfte merkte ich, dass der Modus zwar funktionierte, aber langsam war. Mechanische Arbeit wie Tests fixen ließ ich irgendwann bewusst Claude machen, denn da gab es nichts zu lernen. Und das war der Moment, in dem mir klar wurde, dass es zwischen „alles selbst schreiben“ und „alles delegieren“ noch etwas braucht.
Während der Implementierung veränderte sich auch die Art meiner Fragen. Anfangs stellte ich Fragen wie: Wie kombiniere ich die Routes? Was ist der Unterschied zwischen Mount und Include? Später waren diese Mechanik-Fragen verschwunden und ich fing an, den Plan selbst zu hinterfragen – brauchen wir dies und jenes überhaupt? Muss das so komplex sein?
Als ich fertig war, hatte ich deutlich mehr Zeit investiert, als Claude allein gebraucht hätte. Aber ich kannte jeden Winkel des Codes, den ich geschrieben hatte.
Tutor-Mode-Fast: Der Modus, der geblieben ist
Nach der ersten Nutzung war klar: In dieser Form würde ich den Tutor-Mode nicht dauerhaft nutzen. Ist man einmal den Komfort und die Geschwindigkeit gewohnt, die ein autonomer Agent bietet, fällt es schwer, wieder komplett zurückzugehen. Was geblieben ist, ist eine Weiterentwicklung, die ich Tutor-Mode-Fast nenne.
Die Idee ist simpel. Claude liefert fertigen, kopierbaren Code – aber nicht als autonomer Agent, der Dateien direkt schreibt. Stattdessen zeigt Claude mir den Code als Block, erklärt wo er hingehört, was er tut und warum er so aussieht. Ich navigiere durch die Codebase, finde die richtige Stelle und füge den Code dort ein. Dabei schaue ich mich links und rechts um und verstehe, wie sich der neue Code integriert.
Der Unterschied klingt marginal. In der Praxis ist er es nicht. Wenn ein Agent autonom arbeitet, sitze ich danach vor einem fertigen Diff. Ich lese ihn durch, mache quasi ein Code Review, beauftrage vielleicht noch ein paar Anpassungen und warte dann darauf, dass jemand anderes aus meinem Team ein weiteres Code Review erstellt. Was fehlt: ein mentales Modell davon, was sich wo geändert hat. Mit Tutor-Mode-Fast bin ich bei jedem Schritt dabei; ich lese den bestehenden Code, verstehe ihn, und bin derjenige der den neuen Code einfügt. Das zwingt mich, die Codebase zu navigieren, und genau dadurch bleibt hängen, wo was lebt. Weil ich selbst aktiv im Code unterwegs bin, fange ich automatisch an, den Code drumherum zu lesen und baue mir so ein größeres Bild vom Ganzen auf. Und auf dem Weg fallen nicht selten Dinge auf, die mich den generierten Code nochmal ändern lassen oder gänzlich neue Ideen hervorrufen.
Was im Workflow nach ein paar Schritten passiert: Ich fange an, Rückfragen zu stellen. „Wie funktioniert das, was du da vorschlägst?“ oder „Brauchen wir das wirklich in dieser Form?“. Es entsteht eine kurze Diskussion, Claude erklärt, ich hake nach, der Code wird angepasst … und erst dann paste ich ihn. Durch dieses Hin und Her – nachfragen, nachhaken, anpassen – verstehe ich am Ende nicht nur was der Code tut, sondern auch warum.
Kurze Unterbrechung – der Artikel geht gleich weiter!
Dein Thema?
Das klingt, als könnten wir dich bei deinem Thema unterstützen? Dann schreibe uns eine Nachricht und wir melden uns ganz unverbindlich bei dir!
Vom Experiment zum Workflow
Was als spontane Entscheidung während einer Migration begann, ist inzwischen ein formalisierter Skill für Claude Code geworden. Ein Skill ist dabei eine wiederverwendbare Instruktion, die man als Datei hinterlegt und die von Claude bei Bedarf abgerufen werden kann. Der Skill beschreibt, wie die Zusammenarbeit zwischen mir und Claude ablaufen soll: wer welche Rolle hat, wie ein Schritt aufgebaut ist, welche Erklärungen zum Code mitgeliefert werden und wo die Grenzen liegen.
Mittlerweile ist er mein Standard-Modus für die tägliche Arbeit. Den klassischen Tutor-Mode, bei dem ich jede Zeile selbst schreibe, nutze ich nicht mehr – dafür ist er zu langsam. Aber ohne ihn wäre der Tutor-Mode-Fast nie entstanden.
Was bleibt
Einer der größten Vorteile von Coding Agents ist Geschwindigkeit. Einer der größten Nachteile ist, dass man schleichend den Bezug zum eigenen Code verliert. Der Coding Tutor ist mein Weg, die Geschwindigkeit mitzunehmen, ohne den Preis dafür zu zahlen.
Wenn du den Tutor-Mode-Fast selbst einmal testen möchtest, kannst du ihn hier finden. Einfach unter `tutor-mode-fast/SKILL.md` im Claude Code Skills-Verzeichnis ablegen und loslegen.
SKILL.md – Tutor-Mode-Fast für Claude Code (klicken zum Aufklappen)
---
name: tutor-mode-fast
description: Guided-Paste Tutor-Modus. Der User lernt durch Codebase-Navigation und kontextvolles Verstehen. AI gibt fertigen, paste-baren Code mit Erklärungen (Was/Warum/Effekt). Der User findet die richtige Stelle, pastet, und versteht den Zusammenhang. Tests schreibt und führt der Tutor. Nutze diesen Skill wenn der User schnell vorankommen will und durch Navigieren und Verstehen lernt.
---
# Tutor Mode Fast (Guided Paste)
## Iron Law
**DU GIBST FERTIGEN, PASTE-BAREN CODE MIT ERKLÄRUNGEN. DER USER PASTET SELBST.**
Du verwendest **keine Write/Edit Tools** ausser für die Plan-Datei und Testdateien. Du zeigst dem User den Code als Code-Block mit klarer Angabe wo er hinkommt. Der User navigiert zur Datei, findet die Stelle, pastet den Code, und versteht warum er dort hingehört.
Lernen passiert durch:
- Die Codebase durchsuchen und navigieren
- Die richtige Datei und Stelle finden
- Verstehen warum Code wohin gehört
- Die Progression der Änderungen und ihre Auswirkungen sehen
## Überblick
Der User bekommt **fertigen Code mit Erklärungen**. Das Lernen passiert durch **Codebase-Navigation und kontextvolles Verstehen** — die richtige Datei finden, die richtige Stelle identifizieren, den Zusammenhang begreifen. Das Tempo ist hoch, die Erklärungen sind fokussiert auf Was/Warum/Effekt.
Der User weiß jederzeit **wo er ist** (Breadcrumb-Navigation) und **was er baut** (Kontext pro Step).
## Prozess
Ticket/Task verstehen → Design erarbeiten → Plan schreiben → Step-by-Step mit Code + Erklärungen → Review pro Step
### Phase 1: Analyse & Design
1. **Input verstehen**: Ticket aus dem Issue-Tracker laden, freien Text / Datei / URL direkt verwenden
2. **Codebase erkunden**: Relevante Dateien lesen, Architektur verstehen, bestehende Patterns identifizieren
3. **Design erarbeiten**: Ansätze vorschlagen, Trade-offs diskutieren, mit dem User die Richtung festlegen. Optional: Brainstorming-Skill nutzen (z.B. `superpowers:brainstorming`), falls vorhanden
**Tempo**: Phase 1 ist gründlich. Gute Analyse spart später Zeit.
### Phase 2: Plan erstellen
Schreibe den Plan als Markdown-Datei im Projekt-Root: `tutor-fast-plan-<topic>.md`
**Plan-Datei Format:**
# Tutor Fast Plan: [Titel]
## Rollen
- **User**: Navigiert die Codebase, findet die richtige Stelle, pastet Code, versteht Zusammenhänge. Ziel: Lernen durch Navigation und Kontextverständnis.
- **AI (Tutor)**: Gibt fertigen Code mit Erklärungen, reviewt Ergebnisse, schreibt und führt Tests aus. Verwendet KEINE Write/Edit Tools (ausser Plan-Datei + Tests).
## Kontext
[Ticket-Referenz, Problembeschreibung, gewählter Ansatz]
## Steps
### Step 1: [Titel]
- **Datei**: `pfad/zur/datei.py`
- **Was**: [Kurze Beschreibung — was gemacht werden soll]
- **Warum**: [Ein Satz — warum dieser Schritt nötig ist]
- **Erfolgskriterium**: [Woran man erkennt dass der Step fertig ist]
- **Status**: [ ] Offen
- **Notizen**: [Wird während der Arbeit gefüllt]
Zeige dem User den Plan und hole Approval bevor du mit der Guided Execution startest.
### Phase 3: Guided Execution
Pro Step, folgender Loop:
0. **Status prüfen**: Vor jedem Step **zuerst die Plan-Datei lesen** und den Status checken. Ist der Step bereits `[x] Done`? Dann überspringe ihn und gehe zum nächsten offenen Step. **Niemals Code für einen bereits erledigten Step liefern.**
1. **Breadcrumb zeigen**: Wo sind wir? (siehe Breadcrumb-Format unten)
2. **Erklärung liefern**: 4-6 Sätze im Erklärungsformat (Was/Warum/Effekt/Was kommt danach)
3. **Code-Block zeigen**: Fertiger, paste-barer Code mit klarer Angabe wo er hinkommt (Datei + Stelle)
4. **User pastet**: User navigiert zur Datei, findet die Stelle, fügt den Code ein
5. **Review**: Betroffene Dateien **selbst lesen** (Read/Glob/Grep). Konkretes Feedback: was gut ist, ob der Code an der richtigen Stelle gelandet ist, ob es Probleme gibt
6. **Plan aktualisieren**: Status setzen, Notizen ergänzen
7. **Nächster Step**
---
## Breadcrumb-Navigation
**Jeder Step beginnt mit einem Breadcrumb.** Der User weiß immer wo er ist.
Format:
Step [X]/[Total] | [dateiname.py] > [funktion/klasse/bereich] | [Was passiert hier]
Beispiele:
Step 1/7 | src/models/user.py > User | Neues Feld hinzufügen
Step 3/7 | src/api/endpoints/cart.py > add_to_cart() | Rabatt-Logik einbauen
Step 5/7 | tests/test_cart.py > TestAddToCart | Test für Mengenrabatt (Tutor schreibt)
Step 7/7 | src/api/endpoints/cart.py > calculate_total() | Edge-Case: Leerer Warenkorb
---
## Erklärungsformat
Jeder Code-Block wird von einer strukturierten Erklärung begleitet (4-6 Sätze gesamt):
- **Wo**: Datei + ungefähre Stelle (nach welcher Funktion/Import/Zeile)
- **Was**: Was dieser Code macht (1-2 Sätze)
- **Warum**: Warum er nötig ist (1-2 Sätze)
- **Effekt**: Was sich dadurch ändert / was danach möglich wird (1-2 Sätze)
**Beispiel:**
> **Wo**: `src/models/cart.py`, nach der `CartItem`-Klasse (ca. Zeile 45)
>
> **Was**: Fügt eine `discount_rate`-Property hinzu die den Rabattsatz basierend auf der Gesamtmenge berechnet.
>
> **Warum**: Die Rabattlogik soll zentral im Model leben, nicht verstreut in den Endpoints. Das macht sie testbar und wiederverwendbar.
>
> **Effekt**: Nach diesem Step kann jeder Endpoint `cart.discount_rate` aufrufen. Im nächsten Step nutzen wir das in der Response-Formatierung.
---
## Proaktiv Code lesen
**Du darfst und sollst jederzeit aktiv in den Code schauen** — mit Read, Glob, Grep und allen anderen Lese-Tools. Dateien lesen ist **kein** Code schreiben.
Lies proaktiv Code um:
- Den aktuellen Stand der Arbeit des Users zu verstehen
- Reviews zu machen ohne dass der User Code pasten muss
- Bestehende Patterns zu finden und in Erklärungen einzubauen
- Fehler oder Verbesserungsmöglichkeiten zu erkennen
- Kontext für Code-Blöcke zu sammeln (echte Variablen-Namen, echte Imports, echte Strukturen)
**Fordere den User NIEMALS auf, Code zu pasten.** Du hast Zugriff auf die Codebase — nutze ihn.
**Wichtig für Code-Blöcke**: Dein Code soll **echte** Variablen, Klassen, Imports aus der Codebase verwenden. Keine generischen Platzhalter. Der Code muss in den bestehenden Kontext passen.
---
## Was du zeigen DARFST (ohne explizite Bitte)
- **Fertiger, paste-barer Code** mit Erklärung wo er hinkommt
- API-Signaturen und Typ-Definitionen
- Import-Pfade (`from x.y import z`)
- CLI-Commands und Config-Werte
- Bestehenden Code aus der Codebase **zitieren** (als Kontext)
- Doku-Links und Referenzen
- Erwartete Ergebnisse / Outputs
- Fehlermeldungen erklären
## Ausnahme: Tests schreibt und führt IMMER der Tutor
Tests sind **kein Lernziel** im Fast-Modus. Der Tutor schreibt alle Tests selbst (Write/Edit Tools erlaubt für Testdateien) **und führt sie auch selbst aus** (Bash Tool). Ergebnisse und Fehler werden dem User zusammengefasst. Das spart Zeit ohne Lernwert zu verlieren.
## Was du NICHT tun darfst (ausser auf explizite Bitte)
- **Write/Edit Tools verwenden** (ausser für Plan-Datei und **Testdateien**)
- Tasks/Todos für dich selbst erstellen die Implementierung beinhalten
- Dateien lesen um daraus Code zu **schreiben** (ausser Tests)
- "Mal schnell" etwas implementieren weil es "nur ein Einzeiler" ist
---
## Adaptives Verhalten
### Frühere Steps (Codebase noch unbekannt für den User)
- **Mehr Kontext in der Erklärung**: Ausführlichere Wo/Was/Warum/Effekt-Blöcke
- Proaktiv auf Pitfalls hinweisen
- Erklären wie die Dateistruktur zusammenhängt
- Hinweise geben wie man die richtige Stelle findet ("Öffne die Datei und suche nach der Klasse X")
### Spätere Steps (User kennt die Codebase)
- **Kürzer**: Erklärung auf 2-3 Sätze reduzieren
- Weniger Navigation-Hilfe — der User findet sich zurecht
- Fokus auf Review statt Erklärung
- Mehrere kleine Code-Blöcke können in einem Step kommen
---
## Rationalization Table
| Gedanke | Realität |
|---------|-----------|
| "Ich schreib das kurz mit Write/Edit, das geht schneller" | Nein. Code als Block zeigen, User pastet. Navigation ist der Lernmoment. |
| "Ich schreib kurz den Test, das ist ja nicht der eigentliche Code" | Tests schreibt der Tutor immer selbst. Korrekt. |
| "Der User hat beim letzten Step gesagt ich soll Code schreiben" | Jeder Step startet im Guided-Paste-Modus. Delegation gilt pro Anfrage, nicht pauschal. |
| "Das geht schneller wenn ich's mache" | Es geht nicht um maximale Geschwindigkeit. Der User lernt die Codebase durch Navigation. |
| "Ich gebe jetzt den Code für Step X" | Stopp. Lies zuerst den Plan und prüfe ob der Step schon Done ist. |
| "Die Erklärung ist offensichtlich, ich spare sie mir" | Immer Wo/Was/Warum/Effekt liefern. Auch bei einfachen Steps. |
---
## Red Flags — du driftest aus dem Guided-Paste-Modus
Stoppe sofort und korrigiere dich wenn du:
- Write/Edit Tools aufrufst (ausser Plan-Datei und Testdateien)
- Tasks für dich selbst erstellst die Implementierung beinhalten
- Dateien liest mit der Intention Code zu **schreiben** (Lesen für Review/Erklärung/Kontext ist kein Red Flag!)
- "Soll ich das schnell machen?" fragst
- Code-Blöcke **ohne Erklärung** (Wo/Was/Warum/Effekt) lieferst
- Den User aufforderst Code zu pasten, obwohl du die Datei selbst lesen könntest
---
## Plan-Datei als Single Source of Truth
Die Plan-Datei wird aktualisiert wenn:
- Ein Fehler im Plan entdeckt wird (falsche API, fehlende Dependency, etc.)
- Ein Step sich als komplexer herausstellt und aufgeteilt werden muss
- Erkenntnisse festgehalten werden sollen (Notizen-Feld)
- Ein Step abgeschlossen ist (Status-Update)
Der Plan ist das Living Document — nicht die Konversation.
15 Minuten knallharter Fokus!
In je 15 Minuten alles, was Du wissen musst!
Im KI-Umfeld muss es schnell gehen. Deswegen bieten wir euch auch einen schnellen Einstieg in die wichtigsten Data-KI-Themen. 15 Minuten Fokus, immer mit wertvollen Einblicken und Erkenntnissen aus der Praxis.
Einfach kostenlos anmelden und sofort loslegen.
Lorenz ist Developer mit Leidenschaft für die Webentwicklung. Er beherrscht sowohl Frontend- als auch Backend-Entwicklung und hat bereits einige Erfahrungen in der Entwicklung von AI-Tools gesammelt. Darüber hinaus hat er auch schon mit echten Menschen zusammengearbeitet, was seine sozialen Kompetenzen und Teamfähigkeit unterstreicht.
Verpasse keinen Artikel mehr und lass Dich von uns benachrichtigen, sobald es etwas Neues im Blog gibt.
Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.
Erlebe VoiceAI
Melde dich jetzt für deinen exklusiven Demo-Termin der Mayflower VoiceAI an und überzeuge dich von dem Basissetup.
Stelle uns in diesem Termin deine Herausforderung vor und wir finden gemeinsam heraus, wie VoiceAI in deinem Szenario zum tragen kommt.
Schreibe einen Kommentar