Aufträge, die ein Agent abnehmen lassen kann

Ein Coding-Agent setzt um, was du schreibst – einschließlich der Lücken. Wo dein Auftrag offen ist, entscheidet er, und zwar ohne es zu erwähnen. Die Qualität des Ergebnisses hängt deshalb weniger am Modell als am Auftrag.

Fünf Teile

1. Ausgangslage. Was ist heute der Fall? „Die Suche findet nur exakte Treffer.“

2. Gewünschtes Verhalten. Was soll danach beobachtbar anders sein? Beschreib das Ergebnis, nicht den Weg – es sei denn, der Weg ist vorgegeben.

3. Abnahme. Ein Befehl, der Erfolg oder Misserfolg zeigt. Das ist der Teil, der am häufigsten fehlt und am meisten bewirkt.

4. Grenzen. Was nicht angefasst werden darf: Dateien, Schnittstellen, Abhängigkeiten.

5. Einstieg. Wo der Agent anfangen soll zu lesen. Ein Dateiname spart ihm zehn Suchschritte.

## Ausgangslage
Die Suche in src/search.ts findet nur exakte Treffer.
„Fahrad“ liefert nichts.

## Gewünschtes Verhalten
Bei einem Tippfehler mit einem falschen oder fehlenden Buchstaben
erscheinen die Treffer des richtigen Wortes.

## Abnahme
- npm test läuft grün
- neuer Test: „Fahrad“ findet Einträge mit „Fahrrad“
- bestehende Tests sind unverändert

## Grenzen
- keine neue Abhängigkeit
- src/db/ nicht anfassen

## Einstieg
src/search.ts, Tests in src/search.test.ts

Dieses Format ist zugleich ein gutes GitHub-Issue. Wer seine Aufgaben so schreibt, kann sie einem Menschen oder einem Agenten geben.

Erst der Test, dann der Code

Die schärfste Form der Abnahme ist ein Test, der vor der Umsetzung existiert und fehlschlägt. Das Vorgehen in drei Schritten:

1. Lass den Agenten nur den Test schreiben.
2. Lies den Test. Prüft er das, was du meinst? Schlägt er aus dem richtigen Grund fehl?
3. Erst dann: „Setz es um, bis der Test grün ist. Ändere den Test nicht.“

Der letzte Satz ist wichtig. Ein Agent unter Druck, einen Test grün zu bekommen, findet gelegentlich den kürzesten Weg: den Test anpassen.

Kleine Aufgaben

Ein Auftrag, ein Ziel, ein Pull Request. Als Maß: Wenn du die Änderungen nicht in zehn Minuten lesen kannst, war die Aufgabe zu groß.

Große Vorhaben zerlegst du – am besten mit dem Agenten im Planungsmodus. Lass dir die Teilschritte auflisten, bring sie in eine Reihenfolge, in der jeder Schritt für sich prüfbar ist, und gib sie einzeln in Auftrag.

Drei Auftragsfehler

Mehrere Ziele in einem. „Fix den Fehler und räum dabei auf“ erzeugt einen Pull Request, in dem sich die eigentliche Korrektur zwischen zweihundert Zeilen Umformatierung versteckt.

Lösung statt Problem. „Bau einen Cache ein“ – vielleicht war das Problem eine fehlende Datenbankabfrage-Optimierung. Beschreib, was langsam ist und wie schnell es sein soll.

Kein Kriterium. „Mach es robuster“, „verbessere die Lesbarkeit“. Der Agent ändert etwas und meldet Erfolg, und du kannst nicht widersprechen.

Was der Agent zurückliefern soll

Schreib ans Ende jedes Auftrags, was du als Ergebnis erwartest:

Melde zum Schluss: welche Dateien geändert wurden, den ausgeführten
Prüfbefehl mit seiner Ausgabe und alles, was du bewusst nicht
angefasst hast.

Der dritte Punkt bringt oft das Nützlichste zutage: die Stelle, an der der Agent ein weiteres Problem gesehen und richtigerweise liegen gelassen hat.

In der nächsten Station wandert dieser Ablauf auf GitHub – der Auftrag wird zum Issue, das Ergebnis zum Pull Request.