Weiterlernen, während Claude Code Ihre Software schreibt

Stellen Sie sich einen Entwickler vor, der PHP 5 Jahre vor dem Aufkommen von KI-Assistenten gelernt hat. Ein vergessenes Semikolon konnte ein paar Minuten kosten oder einen ganzen Nachmittag, den man mit der Suche nach der einen fehlerhaften Zeile verbrachte. Eine dynamische Website dauerte Wochen: Schema-Design, Codestruktur, das ganze Projekt im Voraus planen. Jede Phase davon war befriedigend, von der Planung bis zur Umsetzung, und die Belohnung war echt. Man hatte nach einigem Ringen etwas mit eigenen Händen gebaut und wusste danach mehr als vorher.

Vergleichen Sie das mit heute. 2025 kam Claude Code, und Entwickler begannen, ihm immer mehr ihrer täglichen Arbeit zu überlassen. Ein Jahr später öffnen viele kaum noch Stack Overflow, skizzieren seltener auf Whiteboards oder Papier, bevor sie ein Feature entwerfen, und reden weniger mit Kollegen, weil der Großteil ihrer Gespräche mit Claude stattfindet. Das Tempo ist echt, und wer es einmal erlebt hat, will es nicht mehr hergeben. Aber es hat einen Preis. Ein großes Stück des klassischen Prozesses, der aus Juniors ganz nebenbei Seniors macht, geht verloren.

Das ist keine Klage, kein Aufruf, alles von Hand zu programmieren, und keine Rebellion gegen KI. Es ist eine Sorge um eine ganz bestimmte Sache. Viele wählen diesen Beruf auch deshalb, weil sie ständig dazulernen wollen, und dieses Lernen verblasst, wenn ein Modell das ganze Denken übernimmt.

Was die Forschung sagt

Anthropic, das Unternehmen hinter Claude Code, hat eine Studie darüber veröffentlicht, wie KI-Unterstützung den Aufbau von Programmierfähigkeiten beeinflusst. Sie verweist auf ein Paradox: Produktivitätsgewinne durch KI können mit langsamerem Kompetenzaufbau einhergehen, besonders bei Einsteigern. Der Rat, der daraus folgt, deckt sich mit dem, was viele Entwickler intuitiv spüren. Geistige Anstrengung, auch das zeitweilige Feststecken, bleibt nötig, wenn man etwas wirklich beherrschen will.

Die Frage lautet also: Wie lernt man weiter, wenn Claude Code alles erledigt?

Die Reibung, die verloren ging

Benennen wir zuerst, was der alte Arbeitsablauf einem abverlangte:

• Dinge ausprobieren, bis etwas funktioniert
• Dokumentation lesen und noch einmal lesen
• Den eigenen Code erneut durchgehen
• Nachverfolgen, wie ein Feature abläuft und in welcher Reihenfolge seine Funktionen laufen
• Minuten, Stunden oder gelegentlich Tage debuggen

Das waren keine Hindernisse beim Lernen. Das waren seine Voraussetzungen. Künftige Generationen werden von dieser Ära hören wie von den Geschichten über den Schulweg, der bei jedem Wetter zehn Kilometer bergauf führte.

Mit dieser Reibung ist auch das verschwunden, was die Studie kognitive Anstrengung nennt: die Lücke zwischen dem Schreiben von Code und dem Verstehen dessen, was man geschrieben hat. Wenn die Arbeit selbst keine Reibung mehr liefert, muss man sie bewusst zurückholen.

Das Werkzeug zum Lehrer machen

Ein guter Ausgangspunkt ist, Claude als Werkzeug zu betrachten, als bemerkenswertes, aber eben als Werkzeug, das den Entwickler nicht ersetzen sollte. Es sollte die Arbeit erleichtern und dem Entwickler beim Wachsen helfen. Das alte Sprichwort sagt: Wer nur einen Hammer hat, für den sieht jedes Problem wie ein Nagel aus. Ein Entwickler hat es aber auch mit Schrauben, Bolzen und Dübeln zu tun, und genau dort steckt das Können.

Statt gegen den Assistenten anzukämpfen, lassen Sie ihn Ihnen den Umgang mit den anderen Werkzeugen beibringen. Wenn Claude aus einem einzigen erklärenden Prompt ein ganzes Feature schreiben kann, kann es auch Fragen zu dem stellen, was es tut. Die Idee ist also, bewusst Reibung in die Sessions einzubauen. Nicht, um Claude bei der Arbeit zu bremsen, und nicht, um wieder alles von Hand zu schreiben. Mitten in der Arbeit hält es gelegentlich inne und fragt Sie etwas, etwa warum Sie sich für einen bestimmten Ansatz entschieden haben.

Typische Fragen sehen so aus:

• Warum verhält sich diese Funktion so, wie sie es tut?
• Was passiert, wenn dieser Aufruf fehlschlägt?
• Ist diese Zeile notwendig?
• Können Sie diese Funktion fertig schreiben?
• Warum diese Architektur und keine andere?

Das Ziel ist einfach: Claude macht seine Arbeit, während Sie weiterlernen und nebenbei den Überblick darüber behalten, was es produziert.

Wie ein Lernmodus funktionieren könnte

Das lässt sich als Claude-Code-Skill mit ein paar Hooks bauen. Einmal installiert, steht es auf Ihrem Rechner in jeder Session zur Verfügung. Nach einer Änderung schaut sich Claude den Diff an, sucht eine interessante Stelle im Code aus und bittet Sie, sie zu erklären. Eine Frage könnte so aussehen:

🎓 Learner — src/auth/session.ts
You modified `refreshSession()` to delete the old session line before inserting the new one.
Why use this order rather than “insert then delete,” and what does a caller see if the insert fails after the delete has been committed?

Claude fragt und macht dann mit seiner Arbeit weiter. Antworten Sie mit skip, geht es weiter, ohne nachzuhaken.

Die interessanteste Variante nimmt eine kurze Funktion, die Sie gerade geändert haben, holt die korrekte Version aus Git und schneidet Teile aus der echten Datei auf der Festplatte heraus. Die Häufigkeit steuert ein kleiner Shell-Helfer, der eine Einstellung auf eine Zahl abbildet:

learner_synthesis_n() {
  case "${1:-}" in
    off)   printf '0' ;;
    rare)  printf '8' ;;
    often) printf '2' ;;
    # LEARNER-TODO Complete this part of code
    *)     printf '4' ;;
  esac
}

Dann bittet Claude Sie, die Lücke zu füllen, und wartet. Es schreibt den Code nicht für Sie fertig, es sei denn, Sie geben zu, dass Sie nicht weiterwissen, oder tippen skip.

Das ist die wertvollste Art von Frage, weil sie die Momente aufdeckt, in denen Sie glauben, Claudes Code zu verstehen, ihn aber eigentlich nicht selbst schreiben könnten. Eine Einschränkung: Sie bricht kurzzeitig Ihren echten Quellcode. Eine Schutzvorkehrung verhindert, dass eine Session mit einem Loch im Baum endet, und genau diese Schutzvorkehrung ist der Teil des Designs, der die kritischste Prüfung verdient.

Sie können ein Quiz auch direkt auslösen, indem Sie auf einem Branch learner quiz eingeben, statt auf den Hook zu warten. Das ist eine hervorragende Angewohnheit. Wenn Sie Fragen zu Ihrem eigenen Branch nicht beantworten können, können es die Reviewer auch nicht.

Eine ehrliche Einschränkung: Nach ein paar Wochen Nutzung ist immer noch unklar, ob alles reibungslos läuft und ob es wirklich jedem hilft, der beim Arbeiten mit Claude Code dazulernen will. Feedback, besonders Widerspruch, würde die nächste Iteration verbessern.

Wenn Sie den Code selbst schreiben

All das setzt voraus, dass Claude den Code schreibt. Was, wenn nicht? Selbst bei allem, was Claude Code kann, möchten Sie vielleicht nicht, dass es jede Zeile schreibt. Manchmal will man selbst tippen, nicht weil es schneller ginge oder Claude es nicht könnte, sondern weil man durch das Schreiben von Zeilen lernt.

Also drehen Sie die Rollen um. Sie schreiben. Claude schaut zu. Im richtigen Moment fordert es Sie heraus. Es korrigiert Ihren Code nicht, übernimmt nicht und liefert Ihnen keine Antwort. Es stupst Sie nur an, genauer nachzudenken. Ein solcher Assistent tut mehr, als Aufgaben zu erledigen und Ihr Verständnis zu prüfen. Er wird zum Sparringspartner, zu jemandem, der Ihnen zuschaut und im richtigen Moment eine Frage einwirft, die etwas bringt.

In diese Richtung könnte eine nächste Version gehen: Coach statt Lehrer. Im Lehrer-Modell baut der Assistent zuerst und fragt danach ab. Im Coach-Modell bleiben Sie am Steuer, der Assistent schweigt, bis eine Frage wirklich hilft, und jede Zeile in der Datei bleibt eine, die Sie selbst schreiben wollten. Das Wachstum kommt dann aus Ihrem eigenen Tippen und Denken, mit einem zweiten Paar Augen, das pragmatisch statt schmeichelnd ist. Entwickler, denen das Handwerk wichtig ist, würden diese Balance vermutlich dem kompletten Auslagern der Tastatur vorziehen, und sie hält die Gewohnheit des produktiven Ringens im Arbeitsalltag lebendig. Wenn Sie Ideen haben, wie er Sie herausfordern sollte, lohnt es sich, sie zu teilen.