Ich hatte ein Feature geplant und von einem Agent implementieren lassen. Backendseitig funktionierte alles. Nur gab es im UI keine Möglichkeit, das Feature zu benutzen.
Ich hatte schlicht vergessen aufzuschreiben, dass der Kunde dafür auch eine Oberfläche braucht. Der Agent hatte nichts vergessen. Ich schon.
Das ist kein spezielles Agent-Problem. Wenn die eigentliche Anforderung nur in meinem Kopf steht, kann damit niemand arbeiten. Weder ein Kollege noch ein Agent. Ein Agent macht aus dem Missverständnis nur deutlich schneller einen Pull Request.
Beim Permission Management wurde besonders deutlich, wie viel vor der Implementierung geklärt sein muss.
„Flexibel“ ist noch keine Anforderung
Unser bisheriges Berechtigungsmodell war recht flach. Die neue Version sollte Organisationen, Teams und Nutzer getrennt abbilden. Auf Organisationsebene brauchten wir Rollen wie Organisationsadmin und Billing-Admin. Innerhalb eines Teams sollten zum Beispiel Team-Admins, Team-Leads und Analysten unterschiedliche Rechte bekommen. Dazu kamen Regeln für einzelne Nutzer und für Vertretungen: Wer darf während des Urlaubs eines Kollegen dessen Daten bearbeiten?
Wenn ich in einem Team nur sage, wir bräuchten „ein flexibleres Rechtesystem“, können damit sechs feste Rollen gemeint sein – oder ein zweites AWS IAM. Solange ich nicht sage, wo die Grenze liegt, ist beides eine mögliche Interpretation.
Deshalb haben wir auch aufgeschrieben, was wir nicht bauen. Eigene Rollen vollständig frei zu definieren war Out of Scope. Die Anwendung gibt Rollen vor und erlaubt innerhalb dieser Grenzen Anpassungen bei einzelnen Permissions. Wir wollten verschiedene Arbeitsweisen abdecken, aber nicht nebenbei ein universelles Policy-System bauen.
Bevor der erste Agent Code schreibt
Bevor wir über die technische Lösung sprechen, klären wir auf Produktebene, was ein Feature können soll. Beim Permission Management mussten wir zum Beispiel festlegen, was Nutzer sehen, ändern und eben nicht sehen dürfen.
Schon dabei arbeiten wir mit spezialisierten Agents für UI/UX, Backend, Daten oder Security. Sie helfen beim Brainstorming, prüfen Annahmen und zeigen offene Fragen. Entschieden ist dadurch noch nichts. Die Ergebnisse diskutieren wir im Team, und größere Planungen lassen wir gern einen Tag liegen. Ein frischer Blick am nächsten Morgen ist weiterhin ein erstaunlich gutes Tool.
Erst danach planen wir die technische Lösung. Wir schauen, welche Komponenten wir wiederverwenden können, wie das Rollenmodell aussehen soll und welche Schnittstellen sich ändern. Wesentliche Sicherheitsentscheidungen halten wir zusammen mit der Architektur fest.
Anschließend zerlegen wir das Vorhaben in Tickets. Jedes Ticket enthält technische Details, Akzeptanzkriterien, Abhängigkeiten und eine klare Beschreibung von In Scope und Out of Scope.
Auch die Reihenfolge legen wir vorab fest. Wenn Ticket B auf einem Datenmodell aus Ticket A aufbaut, darf B erst starten, wenn A abgeschlossen ist. Das klingt nicht nach besonders exotischer Agent-Orchestrierung. Ist es auch nicht. Es ist ziemlich normale Softwareentwicklung, die danach weitgehend automatisiert weiterläuft.
Wir schreiben dabei nicht jede Zeile Code vor. Der Agent soll technische Details innerhalb eines klaren Rahmens selbst lösen. Trifft er auf eine offene Produkt-, Architektur- oder Sicherheitsfrage, soll er sie eskalieren – und nicht spontan auch noch Produktmanager spielen.
Danach gingen die einzelnen Tickets in unsere Implementierungspipeline.
Fünf Stationen, verschiedene Blickwinkel
Ein Ticket durchläuft fünf getrennte Stationen. Implementierung, Review und Fix passieren nacheinander. Danach folgen das Conflict Gate und die Integration mit Pull Request.
Der Review-Agent bekommt nicht den kompletten Arbeitsverlauf seines Vorgängers. Er sieht das Ticket, den Code und den Projektkontext, beginnt seine Prüfung aber mit einem eigenen Blick. Die Funde hält er in einem Review-Dokument fest, das danach abgearbeitet wird.
Das ähnelt einem menschlichen Review. Wer den Code gerade geschrieben hat, weiß sehr genau, warum er richtig sein müsste. Ein Kollege sieht oft schneller, wo diese Erklärung nicht zum tatsächlichen Verhalten passt.
Beim Kontext geht es vor allem um Fokus. Ein Frontend-Agent arbeitet primär im Frontend, hat aber Zugriff aufs Backend, wenn er ein API-Schema oder das Verhalten eines Endpoints verstehen muss. So können vorhandene API-Schemata direkt verwendet werden. Der Agent hat Zugriff auf das gesamte Repository, muss für eine kleine Änderung aber nicht alles durcharbeiten.
Im Review verschiebt sich der Fokus. Der Agent kennt die Requirements und die veränderten Bereiche, prüft aber auch die betroffenen Schnittstellen. Er kann auf unsere AGENTS.md, die vorgesehenen Skills, den Code und vorhandene Testergebnisse zugreifen. Außerdem startet er nicht in einer leeren Umgebung: Anwendung und eine mit Beispieldaten vorbereitete Datenbank stehen bereit. Er kann den Code also ausführen und sich ansehen, was tatsächlich passiert.
Nach den einzelnen Tickets ist das Epic noch nicht fertig. Auf der Integrationsebene betrachtet ein weiterer Agent mehrere Tickets und Komponenten gemeinsam. Er arbeitet mit einem anderen Prompt und anderen Skills als der Implementierungs-Agent. Jetzt zählt nicht mehr nur, ob eine einzelne Funktion korrekt aussieht, sondern ob Rollenmodell, Backend, Frontend und Authentifizierung zusammen funktionieren.
Mehrere Agents bringen wenig, wenn sie denselben Auftrag mit demselben Blick wiederholen. Bei uns hat deshalb jeder eine klare Rolle und achtet auf etwas anderes.
Was der zweite Blick gefunden hat
Beim Permission Management waren einige Anforderungen nur teilweise umgesetzt. In bestimmten Fällen konnten Nutzer Inhalte nicht sehen, die sie hätten sehen dürfen, oder Rechte verhielten sich anders als vorgesehen. Auch die Erneuerung der JWT-Tokens war an einer Stelle nicht richtig umgesetzt.
In einem anderen Fall sah das Frontend aus, als wäre der Nutzer noch angemeldet. Er konnte sich weiter durch die Oberfläche bewegen. Erst bei der nächsten Aktion gegen das Backend wechselte die Anwendung auf „Not authenticated“.
Das Frontend prüfte nicht sauber, ob das JWT noch vorhanden war. Solange kein Request ans Backend ging, fiel das nicht auf. Entdeckt hat das nicht der Agent, der die Änderung implementiert hatte, sondern ein anderer Agent im Review.
Keiner dieser Fehler war besonders spektakulär. Im Alltag hätten sie trotzdem dafür gesorgt, dass das Feature nicht zuverlässig funktioniert. Genau für solche Lücken trennen wir Implementierung, Review und Integration.
Der Agent kann den PR erstellen. Die Verantwortung bleibt bei uns.
Beim Permission Management kam fast der gesamte Implementierungscode von Agents. Allein entwickelt haben sie das Feature trotzdem nicht.
Beim Rollenmodell, beim Scope, bei der Architektur und bei den wesentlichen Sicherheitsentscheidungen haben Agents in der Planung geholfen. Die Entscheidungen haben wir selbst getroffen. Für jedes Feature ist eine Person von der Planung bis zum Release verantwortlich und gibt die Produktionsfreigabe.
Das ist für uns keine Übergangsregel, bis das nächste Modell noch etwas besser wird. Ein Agent kann Code schreiben, Tests ausführen, Reviews erstellen und einen Pull Request vorbereiten. Verantwortung kann er nicht übernehmen. Wenn das Permission Management falsche Rechte vergibt, lässt sich schlecht der Review-Prompt zum Gespräch bitten.
Unsere Arbeit hat sich dadurch verschoben. Wir verbringen weniger Zeit mit einzelnen Implementierungsschritten und mehr mit Zielen, Grenzen und Abhängigkeiten – und mit der Frage, ob ein Ergebnis wirklich auf Produktion gehen kann.
Die Regel dafür ist ziemlich banal: Wenn wir etwas erwarten, schreiben wir es auf. Trifft der Agent auf eine offene Entscheidung, muss er anhalten und fragen.