Das Briefing schreiben, bevor der Agent anfängt

Das erste, was ich einen Coding-Agent tun lasse, ist nicht Code schreiben. Ich lasse ihn einen Plan schreiben.

Diese einzelne Gewohnheit hat verändert, wie wir KI-gestützte Projekte bei Studio Hyra durchführen, mehr als jedes Model-Upgrade, IDE-Plugin oder Prompt-Trick. Es klingt offensichtlich, wenn ich es laut sage. In der Praxis macht es fast niemand.

Das Folgende ist ein praktischer Bericht darüber, wie wir KI-gestützte Entwicklung um diskrete, begrenzte Phasen strukturieren. Es ist kein theoretischer Rahmen. Es ist der Prozess, den wir tatsächlich verwenden, mit den Fehlern, die wir dabei gemacht haben.

Das Kernproblem mit reiner Prompt-Optimierung

Coding-Agenten sind wirklich leistungsfähig. Tools wie Cursor, GitHub Copilot Workspace und Devin können große Mengen Kontext halten und Code mit einer Geschwindigkeit produzieren, die kein einzelner Entwickler an einem guten Tag erreicht. Diese Fähigkeit ist real.

Der Fehlerzustand ist genauso real. Wenn du ein vages Ziel in einen Agent wirfst und ihn laufen lässt, bekommst du vage Output, der selbstbewusst geliefert wird. Der Agent trifft architektonische Entscheidungen, die du nicht gebilligt hast. Er führt Abhängigkeiten ein, die du nicht gewählt hast. Er löst das Problem, das er hergeleitet hat, nicht immer das Problem, das du hattest.

Das zugrunde liegende Problem ist nicht das Modell. Es ist der Umfang. Agenten werden, wie Junior-Entwickler, eine unbegrenzte Vorgabe mit ihren eigenen Annahmen ausfüllen. Der Unterschied ist, dass ein Junior-Entwickler normalerweise eine klärende Frage stellen wird. Ein Agent wird das nicht. Er wird einfach bauen.

Diese Lücke schließt eine Leistungsbeschreibung.

Die Leistungsbeschreibung mit dem Agent schreiben, nicht davor

Eine Leistungsbeschreibung in klassischen Projekten ist ein Dokument, das die Agentur vor dem Start schreibt. Sie definiert Leistungen, Ausschlüsse, Abhängigkeiten und Akzeptanzkriterien. Sie schützt beide Seiten.

Bei KI-gestützter Entwicklung verwenden wir das gleiche Konzept, schreiben es aber mit dem Agent als erste Aufgabe. Nicht als Formalität. Als Diagnose.

So sieht das in der Praxis aus.

Wir öffnen einen frischen Kontext und geben dem Agent einen einzelnen Absatz, der die Funktion oder das Modul beschreibt, das wir gebaut bekommen wollen. Dann bitten wir ihn, eine kurze Leistungsbeschreibung zu produzieren: was er vorschlägt zu bauen, was er explizit nicht tun wird, was er von uns braucht, bevor er anfangen kann, und wie fertig aussieht.

Das Output ist beim ersten Mal fast nie richtig. Das ist der Punkt. Die Lücken und falschen Annahmen in der Agent-Leistungsbeschreibung zeigen uns genau, wo unsere Vorgabe unterspecifiziert war. Wir beheben die Vorgabe, führen die Leistungsbeschreibung erneut aus und iterieren, bis der Plan die echte Arbeit widerspiegelt. Das dauert normalerweise zwei oder drei Runden und vielleicht zwanzig Minuten.

Was wir tun, ist die Mehrdeutigkeit in ein billiges, niedriges Risiko-Gespräch vorzuverlagern, statt sie mid-build zu entdecken, wenn die Kosten für Kurskorrektur hoch sind.

Die Falle hier. Es ist verlockend, eine Leistungsbeschreibung zu akzeptieren, die angemessen klingt, auch wenn sie vage ist. Dränge auf Spezifiken. Wenn der Agent ein Leistungspaket als "eine Komponente, die Benutzerauthentifizierung handhabt" beschreibt, bitte ihn auf, die genauen Flows, die Fehlerzustände und die externen Services aufzuzählen, die er berühren wird. Vage Akzeptanzkriterien in der Leistungsbeschreibung werden zu den genauen Bugs, die du zwei Wochen später einreichst.

Phasen als Verträge

Sobald die Leistungsbeschreibung präzise ist, unterteilen wir die Arbeit in diskrete Phasen. Jede Phase hat einen klaren Input, einen klaren Output und einen expliziten Handoff-Punkt, an dem ein Mensch überprüft, bevor der Agent fortfährt.

Ein typischer Modul-Aufbau könnte so aussehen:

Phase 1. Datenmodell. Der Agent produziert das Schema, Migrations-Dateien und eine kurze schriftliche Begründung für jede Design-Entscheidung. Wir überprüfen. Wir genehmigen oder bitten um Änderungen. Der Agent berührt keine Geschäftslogik, bis diese Phase genehmigt ist.

Phase 2. Kernlogik. Angesichts des genehmigten Schemas implementiert der Agent die Service-Schicht oder ähnliches. Keine UI. Keine Integrations-Verkabelung. Nur die Logik, mit Tests.

Phase 3. Integration. Der Agent verkabelt die Logik an alles, das sie erreichen muss: eine API, eine Queue, ein Drittanbieter-SDK. Diese Phase tendiert dazu, die meisten Überraschungen zu zeigen, was genau der Grund ist, warum wir sie isolieren.

Phase 4. UI oder Oberfläche. Falls es eine benutzergerichtete Schicht gibt, kommt sie zuletzt. Das ist der einfachste Teil zum Ändern und der am wenigsten teure zum Wiederholen.

Jede Phase endet mit einem menschlichen Kontrollpunkt. Der Agent kennt dies voraus, weil wir es in der Leistungsbeschreibung angeben. Er überspringt nicht. Falls er es versucht, ist das ein Signal, dass die Phasengrenzen nicht explizit genug waren.

Die Falle für diese Struktur. Phasengrenzen halten nur, wenn der Agent isolierten Kontext pro Phase beibehält. In der Praxis bedeutet das, ein frisches Gespräch bei jedem Handoff zu beginnen oder sehr bewusst zu sein, welchen vorherigen Kontext du mitführst. Agenten, die die vollständige Session-Historie behalten, werden manchmal auf frühere Entscheidungen verweisen und zurück zum umfassenden Plan abdriften. Saubere Kontexttrennungen sind das Reiben wert, sich relevante Hintergrundinformation manuell wieder einzuführen.

Was das mit dem Team macht

Der Prozess ändert, was Entwickler tun, nicht wofür sie da sind.

In einem Phase-gesteuerten, Leistungsbeschreibung-getriebenen Workflow verschiebt sich die Aufgabe des Entwicklers hin zu drei Dingen: die Vorgabe präzise schreiben, den Plan kritisch evaluieren bevor die Arbeit beginnt, und Outputs an jedem Gate mit genug technischer Tiefe überprüfen, um subtile Fehler zu fangen.

Keines davon ist passiv. In manchen Hinsichten verlangen sie mehr von einem Entwickler als sich hinzusetzen und selbst die Funktion zu schreiben, weil die Urteilssprüche explizit sind statt eingebettet in Tastenanschläge.

Wir haben festgestellt, dass Senior-Entwickler sich daran schnell anpassen. Sie denken bereits in Begriffen von Verträgen und Schnittstellen. Junior-Entwickler kämpfen manchmal mit den Review-Gates, weil ihnen die Pattern-Erkennung fehlt, um eine plausible-aber-falsche Implementierung zu erkennen. Das ist wertvoll zu wissen, bevor du ein Agent-lastiges Projekt bestaffst. Der Agent erhöht den Boden. Er ersetzt nicht die Decke.

Es gibt auch eine Team-Dynamik, die erwähnt wert ist. Studios, die Agent-gestützte Aufgaben ohne Review-Gates zuweisen, neigen dazu, den Überblick darüber zu verlieren, was tatsächlich gebaut wird. Der Code existiert. Er mag sogar funktionieren. Aber niemand im Team kann die architektonischen Entscheidungen erklären, weil der Agent sie in einer Black Box gemacht hat und niemand den Plan überprüft hat. Das ist ein Lieferrisiko und ein Wartungsrisiko, das sich über die Lebenszeit des Projekts verstärkt.

Der Prozess als Pitch-Artefakt

Eine Sache, die wir nicht erwartet haben. die Leistungsbeschreibung wurde nützlich außerhalb des Aufbaus selbst.

Wenn ein Client fragt, wie wir mit KI-Tools arbeiten, können wir ihnen die Leistungsbeschreibung aus der Planungsphase zeigen. Das zeigt, dass wir nicht einfach prompting und hoffend sind. Es zeigt eine Methodik. Es zeigt Scope-Disziplin. Es zeigt, dass die Agent-Rolle begrenzt, nicht offen ist.

Für Agenturen, die KI-gestützte Lieferung an Clients pitchen, die nervös sind, was Agenten tatsächlich in einem Projekt tun, ist diese Transparenz etwas Konkretes wert. Ein zwei-seitiges Planungsdokument, das produziert wird, bevor irgendwelcher Code existiert, ist überzeugender als jede Behauptung über Process-Reife.

Falls deine Agentur KI-gestützte Entwicklung adoptiert und sich fragt, wie man das Clients erklärt ohne zu klingen wie man nur Prompts auf ein Problem wirft, fang hier an. Schreibe die Leistungsbeschreibung zuerst. Schreibe sie mit dem Agent. Zeig sie dem Client. Das Gespräch, das folgt, ist fast immer produktiver als jede Folie, die du vor ihnen hättest legen können.

Das ist keine Verkaufstechnik. Es ist nur das, was passiert, wenn das Planungs-Artefakt seine echte Aufgabe tut.