Die Idee

Ein Coding-Agent kann eine Codebasis untersuchen und Dateien in derselben Anfrage ändern. Das ist bequem, vermischt aber zwei unterschiedliche Aufgaben: das Problem verstehen und das System verändern. Liegt das Verständnis falsch, bemerkst du es vielleicht erst, nachdem mehrere Dateien bearbeitet wurden.

Beim Planen vor dem Coden trennst du diese Aufgaben. Zuerst bittest du den Agenten, das Repository zu untersuchen und einen Umsetzungsplan zu schreiben. Du prüfst diesen Vorschlag. Erst danach bittest du ihn um Änderungen.

Das bedeutet nicht, dass Planung einen Agenten korrekt macht. Sie schafft einen früheren, sichtbaren Prüfpunkt. Du kannst eine irrelevante Datei, eine zu große Änderung oder einen fehlenden Test erkennen, solange das Ergebnis noch ein Vorschlag und keine Sammlung von Änderungen ist.

Einfach gesagt: Lass dir vom Agenten den geplanten Weg zeigen, bevor du ihn die Codeänderung ausführen lässt.

Einige Werkzeuge unterstützen diesen Ablauf direkt. Claude Code dokumentiert den Planmodus als Modus, der Dateien liest und einen Plan vorschlägt, aber bis zu deiner Freigabe keine Änderungen macht. Die Dokumentation beschreibt ihn als Möglichkeit, Änderungen zu prüfen, bevor sie auf die Festplatte geschrieben werden. Claude-Code-Dokumentation

GitHub dokumentiert für den Copilot Cloud Agent einen ähnlichen Ablauf: Repository untersuchen, einen Plan erstellen und verfeinern, Änderungen auf einem Branch umsetzen und danach den Diff prüfen. GitHub-Dokumentation Die genaue Oberfläche unterscheidet sich je nach Werkzeug. Die zugrunde liegende Gewohnheit bleibt gleich: Prüfe den Ansatz, bevor du die Änderung anforderst.

Ein nützlicher Plan beantwortet konkrete Fragen:

  • Welche Dateien hält der Agent für relevant?
  • Wie versteht er das aktuelle Verhalten?
  • Welche kleinen Änderungen schlägt er vor?
  • Welche Annahmen müssen bestätigt werden?
  • Welche vorhandenen Tests oder welcher neue Regressionstest sollen die Änderung prüfen?

Ein Ticket sagt dem Agenten, welches Ergebnis du möchtest. Ein Plan erklärt, wie er dieses Ergebnis in diesem konkreten Repository erreichen will. Das sind unterschiedliche Artefakte, und beide zu prüfen ist sinnvoll.

Ein kleines Beispiel

Beispiel: Eine TypeScript-Webanwendung akzeptiert abgelaufene Sitzungen. Starte mit einer eng gefassten Anfrage: Untersuche den Sitzungsablauf, benenne die relevanten Dateien, erkläre die wahrscheinliche Ursache und schlage einen kleinen Plan vor. Sage ausdrücklich, dass noch keine Dateien geändert werden sollen.

Der Agent könnte die Session-Middleware, Code zur Token-Validierung und eine vorhandene Testsuite für die Authentifizierung finden. Sein Plan könnte vorschlagen, eine Ablaufprüfung zu ändern und einen Test für ein abgelaufenes Token hinzuzufügen.

Prüfe nun den Plan, nicht nur seine Sicherheit im Auftreten. Läuft die genannte Middleware wirklich für die betroffene Route? Bedeutet „abgelaufen“ in dieser Anwendung tatsächlich das Gemeinte? Liegt der vorgeschlagene Test auf derselben Ebene wie der Fehler? Wenn der Umfang falsch aussieht, bitte um einen überarbeiteten Plan. Wenn er passt, gib die Umsetzung dieses begrenzten Plans frei.

Prüfe danach den Diff. Stelle sicher, dass die geänderten Dateien zum freigegebenen Plan passen und kein unverbundenes Refactoring im Patch gelandet ist. Führe die relevanten Projektprüfungen aus. GitHubs dokumentierter Ablauf umfasst die Diff-Prüfung und Iterationen, bevor ein Pull Request erstellt wird. GitHub-Dokumentation

Probier es aus

Nimm dir fünf Minuten für eine Aufgabe mit geringem Risiko, etwa um eine Validierungsregel zu verschärfen oder einen fehlenden Test hinzuzufügen.

  1. Bitte den Agenten nur um Untersuchung. Fordere relevante Dateien, aktuelles Verhalten, Annahmen, einen minimalen Plan und auszuführende Prüfungen an. Sage, dass er noch nichts ändern darf.
  2. Vergleiche den Plan mit deinem Wissen über den Code. Korrigiere bei Bedarf die Dateiliste, Akzeptanzkriterien oder die Testidee.
  3. Gib nur den überarbeiteten, kleinen Umfang frei. Prüfe nach der Umsetzung den Diff und führe die Prüfungen aus, die der Plan genannt hat.

Diese Übung ist absichtlich klein. Du übst damit, Untersuchung, Freigabe, Umsetzung und Verifikation zu trennen – nicht, ein Redesign zu delegieren.

Darauf solltest du achten

Ein Plan ist ein Vorschlag, kein Beleg. Er kann Anforderungen missverstehen, versteckte Abhängigkeiten übersehen oder falsche Dateien nennen. Auch der Planmodus beweist nicht, dass der spätere Code korrekt, sicher oder vollständig getestet ist.

Mach die Freigabe nicht zu einem Ritual. Lies den Plan genau genug, um seine Annahmen infrage zu stellen. Prüfe die Umsetzung anschließend unabhängig: Inspiziere den Diff, führe passende Tests aus und bewerte, ob das Verhalten die Anforderung erfüllt.

Gehe schließlich nicht davon aus, dass jeder Assistent sich wie Claude Code oder Copilot Cloud Agent verhält. Befehle, Freigabegrenzen, Branch-Verhalten und Verfügbarkeit sind werkzeugspezifisch. Der dokumentierte Planmodus von Claude Code und der dokumentierte Ablauf des GitHub Cloud Agent sind Beispiele für dieses Muster, keine universelle Garantie. Claude-Code-Dokumentation GitHub-Dokumentation