Ein KI-Agent schreibt in einer Stunde so viel Code wie dein Team in einer Woche. Das klingt nach einem Geschwindigkeitsproblem, das gelöst ist — und ist in Wahrheit ein Anforderungsproblem, das gerade erst anfängt.
Denn die Stunde ist billig geworden. Teuer ist, was danach kommt. Am Ende der Stunde liegen achthundert Zeilen vor dir, sauber formatiert, mit Tests, und daneben steht das Ticket, aus dem sie entstanden sind: drei Sätze, geschrieben für einen Kollegen, der beim Termin dabei war. Jemand muss nun entscheiden, ob die achthundert Zeilen zu den drei Sätzen passen — und vor allem, ob die Annahmen stimmen, die zwischen beiden liegen.
Die Woche ist nicht verschwunden; sie ist von der Tastatur vor den Bildschirm gewandert, an eine Stelle, an der niemand geübt ist und für die niemand Zeit eingeplant hat.
Und dort ist sie unsichtbar. Niemand trägt „Generat gelesen“ in eine Zeiterfassung ein. Es sieht aus wie Lesen, es fühlt sich an wie Kontrolle, und am Abend hat man das Gefühl, nichts geschafft zu haben — obwohl genau das die eigentliche Arbeit war.
Der Agent verstärkt, was er bekommt
Ein Agent ist kein schnellerer Entwickler. Er ist ein Verstärker. Er nimmt die Vorlage, die er bekommt, und multipliziert sie — die Klarheit genauso wie die Lücke. Eine gute Vorlage ergibt in einer Stunde eine Woche Arbeit. Eine schlechte ergibt in einer Stunde eine Woche Nacharbeit, und die Nacharbeit sieht aus wie ein fertiges Ergebnis.
Das ist der unangenehme Teil: Eine Vermutung des Agenten sieht nicht wie eine Vermutung aus. Ein Mensch, der an einer unklaren Stelle hängen bleibt, hinterlässt ein TODO, schreibt in den Teamchat oder wartet bis morgen. Ein Agent hinterlässt an derselben Stelle eine Implementierung — benannt, kommentiert, getestet, im Stil des restlichen Projekts. Die Annahme ist von einer Entscheidung nicht mehr zu unterscheiden; sie fällt erst auf, wenn jemand das Verhalten sieht: im günstigen Fall im Review, im wahrscheinlichen Fall in der Demo.
Zwanzig Jahre lang war die Umsetzung der teure Teil eines Vorhabens. Alles andere hat sich danach ausgerichtet — Schätzungen, Sprints, die Frage, wie viele Entwickler ein Team noch verträgt. Diese Rechnung stimmt nicht mehr. Der Engpass ist nicht die Umsetzung, sondern die Frage, was genau gebaut werden soll: präzise genug, dass sie niemand stellvertretend beantworten muss.
Das Review fängt diese Verschiebung nicht auf. Wer generierten Code gegen ein vages Ticket liest, prüft am Ende Benennung, Struktur und Stil — das sind die Fragen, die sich aus dem Code selbst beantworten lassen. Ob das Verhalten das gewünschte ist, lässt sich dort nicht klären, weil die Grundlage fehlt, gegen die man es halten müsste. Ein Review ohne belastbare Anforderung ist ein Lesbarkeitsurteil. Zwei Kollegen können es zügig erteilen, und es sagt nichts über die Richtigkeit.
Das ist der Punkt, an dem gute Entwickler still werden. Nicht weil ihnen etwas fehlt, sondern weil sie merken, dass sie eine Frage beantworten sollen, die vor ihnen niemand gestellt hat: War das hier überhaupt gemeint?
„Kontext“ ist dafür das Wort der Stunde, und es klingt nach Werkzeug. Es ist aber Arbeit. Jemand muss den Kontext herstellen, aufschreiben, aktuell halten und auffindbar machen — dieselbe Arbeit, die ein neuer Kollege in seiner ersten Woche braucht. Nur dass ein Agent sie jedes Mal neu braucht. Er hat keine erste Woche. Er hat diesen einen Lauf, und was in der Vorlage nicht vorkommt, existiert für ihn nicht.
Wie eine Anforderung aussieht, aus der ein Agent bauen kann
Vier Eigenschaften, und keine davon ist neu. Neu ist, dass ihr Fehlen sofort teuer wird statt in drei Wochen.
- Abgegrenzt. Ein Ergebnis, eine Grenze. Nicht „das Berichtswesen“, sondern der eine Bericht — und dazu der Satz, was ausdrücklich nicht dazugehört.
- Prüfbar. Ein beobachtbares Ergebnis, über das sich am Ende nicht streiten lässt: eine Zahl, eine Bedingung, ein Verhalten.
- Selbsttragend. Alles, was zum Bauen nötig ist, steht darin oder ist von dort aus erreichbar: wer das verlangt hat, welche Nachbaranforderung berührt wird, welche Regel bereits gilt. Ein Agent war in keinem Termin.
- In der Sprache, in der dein Team denkt. „Beleg“, „Vorgang“, „Sachbearbeiter“ überstehen die Übersetzung ins Englische nicht ohne Verlust — und danach baut das Modell gegen ein ungefähres Wort.
Ein Beispiel, wie es täglich hereinkommt: „Der Freigabeprozess für Angebote muss einfacher werden.“
Daraus baut ein Agent etwas. Er findet eine Freigabe, vereinfacht eine Regel und liefert. Was er nicht wissen kann: welche Freigabe gemeint war, ab welchem Betrag sie überhaupt nötig ist, ob Rabatte eine Ausnahme bilden und was geschieht, wenn jemand die Regel umgeht. Vier Entscheidungen, die er trifft, weil sie getroffen werden müssen — nicht, weil er sich anmaßt, sie zu treffen.
Dieselbe Sache, tragfähig aufgeschrieben: Als Vertriebsleiter möchte ich Angebote bis 10.000 Euro ohne zweite Freigabe versenden, damit ein Standardangebot am selben Tag beim Kunden liegt. Umfang: Die Betragsgrenze ist je Organisation einstellbar, Sonderrabatte bleiben freigabepflichtig, jede Ausnahme wird am Vorgang vermerkt. Nicht enthalten: Rahmenverträge und deren Verlängerung. Erfüllt ist die Anforderung, wenn ein Angebot über 9.800 Euro ohne zweiten Klick hinausgeht und eines über 10.200 Euro nicht.
Der Unterschied zwischen beiden Fassungen sind vier Sätze und zehn Minuten. Für die erste Fassung braucht der Agent genauso lang wie für die zweite. Du brauchst hinterher zwei Tage länger.
WIE ES ANKOMMT
„Das Rechnungsmodul muss flexibler werden.“
WIE ES BAUBAR WIRD
„Buchhaltung stellt für einen Kunden mit mehreren Projekten eine Sammelrechnung je Quartal, mit Einzelnachweis je Projekt.“
Diese Vorarbeit ist nicht KI-spezifisch. Ein Team, das seine Anforderungen so führt, gewinnt auch ohne einen einzigen Agenten — kürzere Reviews, weniger Rückfragen, seltener Streit in der Demo. Der Agent macht die Rechnung nur sichtbar, weil er schlechte Vorlagen schneller in Code verwandelt, als ein Mensch sie korrigieren kann.
Der Prompt ist nicht der Anfang der Arbeit. Er ist ihr Ergebnis.
Übergabe: was heute wirklich hinausgeht
Irgendwann verlässt eine Anforderung das Werkzeug, in dem sie gepflegt wird. Drei Wege gibt es dafür heute, und jeder hat eine Grenze, die man vorher kennen sollte.
Der erste ist Jira. Ein Klick erzeugt aus einer Anforderung einen Jira-Vorgang, und genau fünf Felder gehen hinüber: Projekt, Titel, Beschreibung, Vorgangstyp und Priorität. Den Typ wählt angajuu selbst — Epic für eine Produktanforderung, Story für eine Kundenanforderung. Keine Labels, keine Komponenten, kein Bearbeiter. Vor allem: Der Vorgang wird einmal angelegt und danach nie wieder angefasst. Änderst du die Anforderung, bleibt Jira so stehen, wie es war.
Zurück kommt wenig, und das mit Absicht. Der Statusabgleich ist ab Werk ausgeschaltet, und er liest nur — zurückgeschrieben wird nie etwas. Eingeschaltet nimmt er vier Angaben auf: den Status des Vorgangs, sein Auflösungsdatum, die darauf vermerkte Version und ob diese Version freigegeben ist. Kundenanforderungen gehen ohnehin nur hin, und betroffen sind allein Produktanforderungen mit eigenem Epic. Einen Bildschirm, auf dem du deinen Jira-Arbeitsablauf auf die Zustände in angajuu abbildest, gibt es nicht: Was nicht zugeordnet ist, landet stillschweigend auf „In Bearbeitung“. Und angajuu plant sich nie selbst um — weicht Jira vom Plan ab, entsteht daraus eine Arbeitsliste für einen Menschen, keine stille Korrektur.
Der zweite Weg ist das Produktanforderungsdokument. Es gehört zu einem Projekt und beschreibt dessen Kundenanforderungen: nach Priorität geordnet, gruppiert, mit einer Abdeckungszahl aus bestätigten Verknüpfungen. Heraus kommt ein PDF oder eine Markdown-Datei. Die Grenze solltest du vor dem ersten Versand kennen: Erzeugt und gespeichert wird zweisprachig, ausgegeben wird in beiden Formaten nur die englische Hälfte.
Der dritte Weg ist das Lieferantenpaket je Release, ebenfalls als PDF oder Markdown. Es entsteht im Moment des Abrufs und wird nirgends abgelegt. Wer es verschickt, verschickt den Stand von heute — und morgen ist es ein anderer Stand.
Alle drei haben dasselbe Merkmal: Jeder erzeugt eine Kopie. In dem Moment, in dem der Vorgang in Jira steht oder das PDF im Postfach liegt, beginnt die Kopie zu altern. Für einen Menschen ist das erträglich, er fragt nach. Für einen Agenten ist es die eigentliche Fehlerquelle. Er liest die Kopie und hält sie für den aktuellen Stand — mit derselben Selbstsicherheit, mit der er alles andere liest.
Im Bau Der nächste Schritt ist ein MCP-Server: deine Anforderungen als live abrufbarer Kontext direkt im Werkzeug des Agenten — keine Kopie, keine Übergabe, kein Veralten.
Was du vor dem nächsten Lauf aufschreibst
Nicht mehr als eine halbe Seite, und vier Dinge darauf.
- Das Ergebnis, nicht den Weg. Ein Agent braucht kein Vorgehen. Er braucht ein Ziel und eine Grenze.
- Was ausdrücklich nicht dazugehört — und was er nicht anfassen darf. Der zweite Halbsatz erspart die meiste Nacharbeit.
- Den Kontext, den er nirgends nachlesen kann: warum das verlangt wurde, von wem, und welche bestehende Regel dabei im Weg steht.
- Den Satz, an dem du am Ende erkennst, dass es erfüllt ist. Fällt dir keiner ein, ist die Anforderung noch nicht fertig — sonst denkt der Agent sich selbst einen aus.
Und danach eine Prüfung, die zwanzig Sekunden dauert: Lies den Text noch einmal und markiere jede Stelle, an der du im Kopf etwas ergänzt hast. Genau diese Stellen füllt der Agent — nur eben mit etwas anderem.
Es ist eine unspektakuläre halbe Seite, und solange man sie schreibt, fühlt sie sich nach Umweg an. Den Unterschied merkst du, wenn der Lauf zurückkommt und du das Ergebnis nicht mehr auseinandernehmen musst, um herauszufinden, ob es das Richtige ist.
Die Disziplin dahinter, für Menschen wie für Modelle, steht in VSDD — Verified Spec-Driven Development: Spezifikation zuerst, Test zuerst, ein Review, das wehtut, und ein „fertig“, das zwei Fragen beantwortet statt einer. Und wie sich beides in einer gewöhnlichen Woche anfühlt, wenn die Anforderung tatsächlich trägt, zeigt Ein Tag im Entwicklungsteam — vom Ticket am Morgen bis zur Frage, was die Arbeit am Ende abgedeckt hat.