Wie Sie einen Plan schreiben, den ein KI-Agent ohne Raten liefert

Woher das Raten kommt

Ein Coding-Agent liest Code, führt Befehle aus und ändert Dateien. Er weiß aber nicht, was das Team in einer Besprechung vereinbart hat, was der Kunde nicht will und welchen von zwei vernünftigen Wegen Sie bevorzugen. Baut der Agent etwas anderes, als Sie erwarten, fehlt ihm meist genau eine solche Information. Der Agent kann eine Bitte auch eng auslegen und die kleinste Version bauen, die sie erfüllt, weil er nicht weiß, wie viel Sie sich erhoffen.

Die zweite Lücke betrifft das Ende der Arbeit. Ein Agent hört meist auf, wenn das Ergebnis fertig aussieht. Gibt es nichts, was er ausführen kann, um zu prüfen, ob es wirklich fertig ist, bleibt ein Fehler im Code, bis Sie ihn bemerken.

Nehmen Sie als Beispiel die Aufgabe „CSV-Export für Rechnungen hinzufügen“. Sie klingt klar, bis der Agent mit der Arbeit beginnt:

• Alle Rechnungen oder nur die eines gewählten Monats?
• Mit Korrekturrechnungen oder ohne?
• Welches Trennzeichen zwischen den Feldern und welche Schreibweise für Beträge?
• Soll bei der Gelegenheit auch der bestehende PDF-Export verbessert werden?

Jede dieser Fragen entscheidet der Agent nach eigenem Ermessen, oder er stellt sie Ihnen während der Arbeit. Ein guter Plan beantwortet sie, bevor die Arbeit beginnt.

Vier Teile eines Plans

Ein Plan für einen Agenten muss nicht lang sein. Er soll vier Fragen beantworten: wozu, was genau, woran ein gutes Ergebnis zu erkennen ist und wann die Arbeit fertig ist. Kommt es auf die Reihenfolge an, schreiben Sie noch die Schritte dazu.

Spec-driven Development heißt auf Deutsch so viel wie Arbeiten nach einer Spezifikation: zuerst das Dokument, dann die Lieferung durch den Agenten, am Ende der Vergleich des Ergebnisses mit demselben Dokument. Ein Plan mit den vier unten beschriebenen Teilen ist genau so eine Spezifikation. Mehr über diesen Ansatz finden Sie im Glossareintrag Spec-driven Development.

Ziel

Wozu diese Arbeit dient, in ein oder zwei Sätzen. Trifft der Agent auf eine Entscheidung, die der Plan nicht vorhergesehen hat, zeigt ihm das Ziel, welche Variante er wählen soll. Der Satz „Die Buchhaltung überträgt jeden Monat die Rechnungen von Hand in ihr Programm“ sagt dem Agenten mehr als „CSV-Export“.

Umfang

Was zur Arbeit gehört und was ausdrücklich nicht dazugehört. Die Ausschlüsse sind genauso wichtig wie das, was dazugehört. Der Satz „Der PDF-Export bleibt unverändert“ schützt vor Änderungen nebenbei, und der Satz „Korrekturrechnungen kommen ebenfalls in die Datei“ vor einer Version, die zu wenig tut.

Abnahmekriterien

Überprüfbare Aussagen, die zutreffen müssen, wenn die Arbeit fertig ist. Jede beurteilen Sie mit einem Wort: ja oder nein. Mit ihnen vergleichen Sie das Ergebnis bei der Abnahme, schreiben Sie sie also wie eine Liste zum Abhaken.

Definition of Done

Woran sich erkennen lässt, dass die Arbeit fertig ist und nichts mehr zu erledigen bleibt. Abnahmekriterien betreffen diese eine Arbeit, die Definition of Done gilt dagegen meist für viele Arbeiten gemeinsam, zum Beispiel: Die Tests laufen durch, neues Verhalten hat einen eigenen Test, die Dokumentation ist aktuell.

Schreiben Sie hier einen Befehl hinein, den der Agent selbst ausführen kann und der mit Erfolg oder mit einem Fehler endet: Tests, den Build des Projekts oder einen Linter, zum Beispiel npm test. Der Agent kann dann selbst eine Änderung vornehmen, die Prüfung ausführen und, wenn etwas kaputtgeht, den Fehler beheben und noch einmal prüfen.

Beispiel: ein Plan für den Rechnungsexport

Derselbe Export, so beschrieben, dass der Agent ihn ohne Rückfragen liefern kann:

# Rechnungen als CSV exportieren

## Ziel
Die Buchhaltung überträgt jeden Monat die Rechnungen von Hand
in ihr Programm. Eine CSV-Datei soll das ersetzen.

## Umfang
- Eine Schaltfläche für den Export in der Rechnungsliste, für
  den gewählten Monat.
- Nicht im Umfang: PDF-Export und Versand der Datei per E-Mail.

## Abnahmekriterien
- Am Anfang der Datei steht eine Zeile mit den Spaltennamen.
- Die Datei enthält alle Rechnungen des Monats, auch
  Korrekturrechnungen.
- Felder trennt ein Semikolon, Beträge haben ein Dezimalkomma.
- Gibt es im Monat keine Rechnungen, sieht der Benutzer eine
  Meldung statt einer leeren Datei.

## Definition of Done
- npm test läuft durch, und der Export hat eigene Tests.
- Nichts aus dem Umfang wurde auf später verschoben.

Wie Sie Kriterien schreiben, die sich prüfen lassen

Die Kriterien sind der Teil des Plans, den man am leichtesten zu allgemein schreibt. Vier Regeln helfen:

• Eine Aussage, eine Prüfung. „Der Export funktioniert korrekt“ sagt nicht, was zu prüfen ist. „Die Datei enthält Korrekturrechnungen“ sagt es.
• Verhalten, das man sieht. Beschreiben Sie, was der Benutzer sieht oder was das Programm zurückgibt, nicht, wie der Code aussehen soll.
• Eine Zahl statt eines Adjektivs. „Schnell“ versteht jeder anders. „Der Export eines Monats mit tausend Rechnungen dauert weniger als fünf Sekunden“ lässt sich messen.
• Grenzfälle, die Ihnen wichtig sind. Ein leerer Monat, fehlerhafte Daten, fehlende Rechte. Einen Fall, den Sie nicht hineinschreiben, kann der Agent übergehen oder anders lösen, als Sie erwarten.

Offene Entscheidungen und die Größe des Plans

Vor dem Start ist nicht alles klar, und das ist kein Problem, wenn der Plan es sagt. Bleibt eine Wahl offen, nennen Sie sie und geben Sie eine Empfehlung, zum Beispiel: „Kodierung der Datei: UTF-8, es sei denn, das Buchhaltungsprogramm verlangt eine andere“. Der Agent entscheidet dann nicht stillschweigend, und Sie wissen, worauf Sie bei der Abnahme achten müssen. Genauso bei zwei guten Lösungen: Wenn Sie eine davon bevorzugen, schreiben Sie es in den Plan.

Fehlen Ihnen die meisten Antworten, drehen Sie die Reihenfolge um: Bitten Sie den Agenten, Ihnen so lange Fragen zu stellen, bis sich aus den Antworten eine Spezifikation schreiben lässt. Die Arbeit am Code beginnen Sie danach in einer neuen Sitzung, mit dem fertigen Dokument.

Bleibt noch die Größe. Ein Plan sollte eine Arbeit beschreiben, die eine Agentensitzung vollständig liefert. Eine große Aufgabe teilen Sie in mehrere Pläne auf und halten fest, welcher auf welchen wartet. Jeder bekommt dann eigene Kriterien und eine eigene Abnahme.

Warum es weniger Fragen und weniger Nacharbeit gibt

Fragen des Agenten tauchen dort auf, wo der Plan schweigt. Jede Entscheidung, die vor dem Start festgehalten ist, ist eine Frage, die die Arbeit nicht unterbricht. Nacharbeit entsteht aus Erwartungen, die niemand aufgeschrieben hat: Das Ergebnis erfüllt die Anweisung, verfehlt aber, was Sie brauchen.

Abnahmekriterien machen aus der Abnahme einen Vergleich. Sie prüfen die Liste Punkt für Punkt, und wenn etwas nicht stimmt, nennen Sie bei der Ablehnung das konkrete Kriterium. Der Agent weiß dann, was er nachbessern soll, und muss nicht ein zweites Mal raten.

So funktioniert es in featureloom

In featureloom ist eine Aufgabe für den Agenten ein Plan: ein Dokument in Markdown auf einem Kanban-Board, das die Konsole vollständig erhält. Mit „Neuer Plan“ schreiben Sie einen Plan selbst. Ein solcher Plan beginnt mit einem leeren Dokument, deshalb tragen Sie Ziel, Umfang, Abnahmekriterien und Definition of Done unter eigenen Überschriften ein, wie im Beispiel oben.

Ein Plan, der aus Material generiert oder von einem Agenten in der Konsole geschrieben wird, entsteht nach der Planvorlage des Projekts. Die eingebaute Vorlage fragt unter anderem nach Ziel, Umfang, Schritten, Abnahmekriterien und der Definition of Done. Der Prompt Planer weist den Agenten an, Pläne in den Abschnitten der Vorlage zu schreiben und eine Wahl, die das Material offenlässt, im Plan zu nennen, mit einer Empfehlung. Eine eigene Vorlage speichern Sie auf dem Bildschirm „Projekteinstellungen“ im Reiter „Planvorlage“.

Den fertigen Plan geben Sie dem Agenten, indem Sie in der Konsole den Befehl aus dem Plan einfügen, zum Beispiel featureloom umsetzer INV-14. In einem Aufruf bekommt der Agent den Prompt, das ganze Plandokument und die Dokumente der gelieferten Pläne, von denen dieser Plan direkt abhängt. Der Prompt Umsetzer weist ihn an, nur das zu tun, was im Plan steht, und, wenn der Plan etwas offenlässt, zu fragen, statt zu raten. Die Frage und Ihre Antwort bleiben im Plandokument, und der Agent liest die Antwort, wenn er den Plan das nächste Mal abruft.

Am Ende weist der Umsetzer den Agenten an, die Lieferung mit einer Notiz zu melden: was getan wurde, was vom Plan abweicht und warum, und was nicht getan wurde. Sie vergleichen das Ergebnis mit den Abnahmekriterien und klicken im Abschnitt „Abnahme“ auf „Abnehmen“ oder „Nicht abnehmen“. Die Entscheidung trifft nur eine Person in der App. Nach einer Ablehnung liest der Agent die Entscheidung mit Ihrer Begründung und bessert nach.