Coding-Assistenten: eine Aufgabe sauber umreißen

Ein freiberuflicher Entwickler bittet seinen Coding-Assistenten: „Füge einen CSV-Export der Rechnungen hinzu.“ Zwanzig Minuten später hat das Tool elf Dateien angefasst, eine Bibliothek hinzugefügt, zwei völlig unbeteiligte Module umformatiert und einen Export geschrieben, der die Gutschriften vergisst. Sichtbar kaputt ist nichts, und trotzdem muss er alles nachlesen.

Die heutigen Coding-Assistenten vervollständigen nicht mehr nur eine Zeile. Sie lesen das Projekt, ändern mehrere Dateien, führen Befehle und Tests aus. Je selbstständiger das Tool handelt, desto mehr muss deine Anfrage einem Briefing ähneln, wie man es einem Dienstleister gibt, den man bis zur Lieferung nicht mehr sieht.

Was ein Aufgaben-Briefing enthält

Meistens reichen fünf Elemente.

1. Das Ziel, als Ergebnis formuliert: was der Nutzer oder das System danach können wird.
2. Der Rahmen: die betroffenen Dateien oder Ordner und das, was nicht angefasst werden darf.
3. Die Vorgaben: vorgeschriebene Technologien, Konventionen, verbotene Abhängigkeiten.
4. Das Erfolgskriterium: woran du erkennst, dass es fertig ist, am besten ein Befehl oder ein Test.
5. Die Arbeitsweise: vor dem Ändern einen Plan vorlegen oder in kleinen Schritten vorgehen.

Hier das Briefing des Entwicklers, sauber formuliert:

Ziel: einen CSV-Export der Rechnungen eines bestimmten Monats hinzufügen, erreichbar von der Seite Abrechnung.

Rahmen: Du darfst das Modul abrechnung/ und die Seite Abrechnung ändern. Fasse die anderen Module und die Projektkonfiguration nicht an.

Vorgaben: keine neue Abhängigkeit, wir verwenden das CSV-Modul der Standardbibliothek. Gleicher Stil wie die bestehenden Exporte (siehe export_kunden).

Fachliche Regeln: Der Export enthält die Rechnungen und Gutschriften des Monats. Gutschriften sind negativ. Die Beträge stehen in der Datenbank in Cent und in der Datei in Euro mit zwei Nachkommastellen.

Erfolgskriterium: Die bestehenden Tests laufen durch, und du ergänzt einen Test, der einen Monat mit einer Rechnung und einer Gutschrift prüft.

Bevor du irgendetwas änderst, beschreibe mir deinen Plan in höchstens fünf Zeilen und warte auf mein Okay.

Der letzte Satz zahlt sich am meisten aus. Ein falscher Plan ist in zehn Sekunden korrigiert, falscher Code in zehn Minuten.

Was das Tool nicht erraten kann

Fachliche Regeln stehen nirgends im Code, oder nur indirekt. Dass Gutschriften in den Export gehören, dass die Beträge in Cent vorliegen, dass die Seite Abrechnung heißt: Der Assistent kann einen Teil davon beim Lesen des Projekts herausfinden, aber du bist schneller, wenn du es aufschreibst. Lieber einmal zu viel etwas Selbstverständliches sagen, als einen falschen, aber plausiblen Export zu bekommen.

Alles, was du von Aufgabe zu Aufgabe wiederholst (Konventionen, Testbefehle, zu meidende Ordner), kann in eine Anweisungsdatei, die das Tool automatisch liest. Name und Ort der Datei hängen vom verwendeten Assistenten ab. Der Artikel über Anweisungen für KI-Agenten erklärt, wie du sie schreibst, ohne einen Roman daraus zu machen.

Eine Änderung nach der anderen

Wenn das Tool schnell ist, liegt die Versuchung nahe, Anfragen zu stapeln: der Export, dann ein Filter, dann ein Umbau der Seite, alles in derselben Sitzung. Jede Ergänzung macht das Ergebnis schwerer nachzulesen. Gewöhne dir an, wie bei einer Prompt-Kette zu zerlegen:

• eine Aufgabe, ein Ziel, ein überprüfbares Ergebnis;
• eine Sicherung deiner Arbeit (ein Commit) vor jeder Aufgabe, damit du zurückgehen kannst;
• eine neue Sitzung, wenn das Thema wechselt, denn die Unterhaltung wird schwerfällig, und das Tool verliert irgendwann Details vom Anfang.

Ist die Aufgabe zu groß für ein einseitiges Briefing, bitte zuerst um eine Aufteilung:

Ich möchte die Authentifizierung der Anwendung auf [NEUE METHODE] umstellen. Ändere vorerst nichts. Geh das Projekt durch, liste die betroffenen Dateien auf und schlage eine Aufteilung in unabhängige Schritte vor, die jeweils für sich testbar sind. Nenne zu jedem Schritt das Hauptrisiko.

Danach wählst du den Schritt, den du starten willst, und schreibst sein Briefing.

Das Ergebnis nachlesen

Die Arbeit endet nicht, wenn das Tool „fertig“ sagt. Vier Kontrollen, in dieser Reihenfolge.

Zuerst der Diff. Sieh dir die Liste der geänderten Dateien an, bevor du eine einzige öffnest. Steht dort etwas außerhalb des Rahmens, frag nach dem Grund oder mach es rückgängig.

Dann die Tests, wenn möglich von dir selbst gestartet. Ein Assistent kann behaupten, die Tests liefen durch, ohne sie richtig ausgeführt zu haben, oder einen Test ändern, damit er besteht. Prüfe, dass die bestehenden Tests nicht grundlos verändert wurden.

Die Grenzfälle. Nimm die fachlichen Regeln aus deinem Briefing und teste sie von Hand: der Monat ohne Rechnung, die Gutschrift, die größer ist als die Rechnung, der Wert null.

Die stillen Ergänzungen. Eine neue Abhängigkeit, eine Konfigurationsdatei, das Entfernen eines Codestücks, das er für überflüssig hielt: Lass sie dir vom Tool auflisten, falls es das nicht getan hat.

Fasse zusammen, was du geändert hast, Datei für Datei, in je einer Zeile. Nenne, was du gelöscht, als Abhängigkeit hinzugefügt oder außerhalb des verlangten Rahmens geändert hast. Liste danach die Grenzfälle auf, die du nicht getestet hast.

Diese Zusammenfassung ersetzt nicht deine Durchsicht des Diffs, denn das Tool kann vergessen, eine Änderung zu erwähnen. Sie zeigt dir nur, wohin du schauen musst.

Wenn es nicht klappt

Wenn der Assistent sich im Kreis dreht, behebe die Ursache, statt die Anfrage zu wiederholen. Oft fehlt Kontext, oder das Briefing enthält eine widersprüchliche Anweisung. Starte mit einem korrigierten Briefing in einer neuen Sitzung, statt zwanzigmal „nein, nicht so“ anzuhängen. Für Reviews, Debugging oder Testgenerierung außerhalb dieses Rahmens liefert der Artikel über Prompts für Entwickler weitere Vorlagen, und der über GitHub Copilot geht auf die Arbeit im Editor ein.

Und behalte die Kontrolle darüber, was das Tool darf: Befehle ausführen, Dateien löschen, auf das Netzwerk zugreifen. Lies, was dein Assistent dich freigeben lässt, bevor du zustimmst, und gib ihm keinen Zugriff auf Schlüssel oder Produktivdatenbanken für eine Aufgabe, die das nicht braucht.

Vor deiner nächsten Aufgabe

Nimm eine Aufgabe, die du diese Woche dem Assistenten übergibst. Schreib die fünf Zeilen des Briefings, einschließlich des Befehls, der beweist, dass sie erledigt ist. Wenn du diesen Befehl nicht schreiben kannst, ist die Aufgabe noch nicht klar genug, und jetzt ist der richtige Moment, das herauszufinden.