Ein paar Monate mit Claude Code, Cursor und Copilot im Alltag verändern etwas Grundsätzlicheres als das Tempo. Sie verschieben, was „programmieren" überhaupt heißt — weg von „ich schreibe jede Zeile" hin zu „ich steuere, prüfe und entscheide". Das ist keine kleinere Fähigkeit als Coden. Es ist eine andere.
Kontext ist die eigentliche Währung
Ein Modell ist nur so gut wie das, was es gerade sehen kann. Die wichtigste Fähigkeit im Umgang mit KI-Tools ist deshalb nicht Prompt-Wortwahl, sondern Kuratieren: welche Datei, welcher Ausschnitt, welche frühere Entscheidung gehört gerade ins Kontextfenster — und was lenkt nur ab. Wer der KI die ganze Codebasis vor die Füße wirft, bekommt selten präzisere Antworten als jemand, der drei relevante Dateien gezielt zeigt.
Harnesses, Loops und Gedächtnis
Ein „Harness" ist im Kern die Umgebung, die einem Modell erlaubt, nicht nur zu antworten, sondern zu handeln — Dateien lesen, Befehle ausführen, das Ergebnis sehen und weitermachen. Genau da entsteht der eigentliche Sprung: nicht in der Antwortqualität einer einzelnen Nachricht, sondern in der Fähigkeit, iterativ zu arbeiten. Ein Loop, der Code schreibt, testet, den Fehler liest und korrigiert, ersetzt kein Verständnis — aber er ersetzt sehr viel Tipparbeit. Und ein Gedächtnis, das über einzelne Sitzungen hinaus besteht, verhindert, dass man sich jedes Mal neu erklären muss, wie das eigene System tickt.
Skills und Prompt-Engineering: Präzision, keine Zauberformel
Prompt-Engineering klingt nach Trick, ist in der Praxis aber eher Spezifikation. Ein guter Prompt beschreibt Randbedingungen, die man sonst im Kopf hätte: was darf sich nicht ändern, welches Muster gilt schon im Projekt, wo ist Fehlertoleranz null. Wiederverwendbare „Skills" — feste Vorgehen für wiederkehrende Aufgaben — sind im Grunde nichts anderes als Code-Reviews und Checklisten, nur eine Ebene höher: Wissen, das man einmal präzise formuliert und danach nicht mehr neu erfinden muss.
Was nicht ersetzt wird
- Architektur-Urteilsvermögen: ob ein Vorschlag zum restlichen System passt, entscheidet kein Modell für dich
- Die Fähigkeit, eine Lösung zu bewerten statt sie zu übernehmen — Code lesen bleibt Pflicht, nicht Kür
- Domain-Wissen über das eigene System: warum eine Tabelle so aussieht, wie sie aussieht, steht selten im Code
Neuentwicklung ist gnädig. Legacy ist es nicht
Bei einem neuen Projekt darf ein Modell viel: wenig Kontext, viel Freiheit, ein falscher Ansatz kostet eine Iteration. In einem gewachsenen System ist jede automatische Änderung ein potenzieller stiller Schaden — eine Nebenwirkung, die erst in drei Wochen auffällt. Der Unterschied im Umgang ist deshalb keine Stilfrage: bei Legacy-Code zählt kleine, verifizierbare Schritte statt „mach das ganze Feature", und ein Vertrauensvorschuss, der sich Stück für Stück verdient, nicht voraussetzt.
Was bei mir dadurch wichtiger geworden ist, nicht unwichtiger: die Fähigkeit, ein System in fünf Sätzen zu erklären, bevor ich es jemanden — Mensch oder Modell — daran arbeiten lasse. Das war schon immer eine gute Übung. Jetzt zahlt sie sich täglich aus.