wenn der product owner selbst ausliefert
Spec statt Ticket, Coding-Agent statt Team, Prüf-Agenten für Recht, Datenschutz und Security statt Review-Runden. Was davon heute schon trägt — und was wir beim Ausprobieren an der eigenen Codebasis gelernt haben.
von tokyn studio · 6 min lesezeit
KIKurz gefasst. Ein Product Owner beschreibt ein Feature, ein Coding-Agent baut es, Prüf-Agenten für Recht, Datenschutz und IT-Sicherheit lesen den Code und geben Empfehlungen — echte Expertinnen und Experten werden nur dort eingebunden, wo es tatsächlich klemmt. Das ist kein Zukunftsbild mehr, die Bausteine haben Namen und Produkte. Was fehlt, ist das Setup drumherum. Wir haben es an einer Codebasis ausprobiert, die wir betreuen, und dabei gelernt, wo die Grenze verläuft. Stand: 2026-09.
was sich gerade zusammensetzt
Drei Entwicklungen, die einzeln unspektakulär sind und zusammen die Arbeitsteilung verschieben.
Die Spezifikation wird zur Quelle der Wahrheit. „Spec-Driven Development" gilt inzwischen als Nachfolger des Vibe Codings: Nicht der Code ist das Zentrum, sondern eine versionierte Spezifikation, aus der die Agenten den Rest erzeugen. Der Unterschied zur alten Anforderungsdokumentation ist entscheidend — die Spec beschreibt das System nicht passiv, sie regiert es. Sie ist das gemeinsame Gedächtnis von Mensch und Agent.
Coding-Agenten sind Alltag geworden. Nicht als Autovervollständigung, sondern als etwas, das eine Aufgabe annimmt, einen Plan macht, Dateien anfasst, Tests laufen lässt und am Ende einen Vorschlag zur Übernahme hinlegt.
Und es gibt jetzt eine Kategorie für die Aufpasser. Gartner nennt sie Guardian Agents: Agenten, deren einziger Zweck es ist, andere Agenten zu beobachten und zu begrenzen. Der erste Market Guide dazu erschien im Februar 2026, die Prognose sieht 10 bis 15 Prozent des gesamten Agenten-Marktes bis 2030. Die drei Fähigkeitsfelder: Nachvollziehbarkeit des Agentenverhaltens, Identität und Zugriff, plattformübergreifende Durchsetzung von Regeln.
Wie schnell das kippt, zeigt eine andere Gartner-Zahl: Ende 2026 sollen rund 40 Prozent der Unternehmensanwendungen aufgabenspezifische Agenten enthalten — Anfang 2025 waren es unter 5 Prozent.
das bild, über das wir reden
Ein Product Owner will ein Feature. Er schreibt keine Tickets für ein Team, sondern eine Spezifikation: Was soll passieren, für wen, unter welchen Bedingungen, woran merken wir, dass es funktioniert.
Ein Coding-Agent setzt sie um. Danach lesen mehrere Prüf-Agenten denselben Code, jeder mit einem klaren Auftrag:
→ Recht prüft Vertragsbezüge, Fristen, Zusagen im Interface — sagt der Text etwas zu, das der Vertrag nicht hergibt?
→ Datenschutz prüft, welche Daten erhoben, wohin übertragen und wie lange gehalten werden — und ob die Datenschutzerklärung das noch abdeckt.
→ IT-Sicherheit prüft Berechtigungen, Abhängigkeiten, Umgang mit Secrets, Angriffsfläche.
Jeder liefert Empfehlungen, keine Freigaben. Wo eine Empfehlung Gewicht hat, geht sie an einen Menschen aus der jeweiligen Abteilung — nicht als Meeting, sondern als konkrete Frage mit Fundstelle. Der Rest läuft durch.
Das Versprechen ist nicht, dass Fachleute überflüssig werden. Es ist, dass ihre Zeit dort landet, wo sie wirkt: bei den drei Fragen, die wirklich eine Entscheidung brauchen, statt in der Durchsicht von dreißig Seiten, bei denen 27 unstrittig sind.
was wir beim ausprobieren gelernt haben
Wir haben genau so ein Setup auf eine Codebasis losgelassen, die wir betreuen: fünf Prüfrollen, jede mit eigener Perspektive — technisches SEO, Barrierefreiheit, Conversion, Performance sowie Inhalt und Recht. Rein lesend, jede mit dem Auftrag, Befunde zu belegen statt zu behaupten. Danach haben wir umgesetzt.
Drei Dinge daraus sind uns wichtiger als jede Marktprognose.
Erstens: Prüf-Agenten sind gut im Lesen und blind fürs Tun. Die fünf Rollen fanden 29 Punkte. Beim Umsetzen kamen zehn weitere dazu — und darunter waren die beiden schwersten des ganzen Durchgangs. Eine Formularverarbeitung lief seit Monaten in einem Rechenzentrum auf der falschen Seite des Atlantiks, weil nirgends eine Region konfiguriert war. Und eine einzige fehlplatzierte CSS-Zeile machte die halbe Typografie-Skala wirkungslos: Auf einer einzigen Seite rendern 29 von 38 Absätzen eine andere Schriftgröße, als im Code steht. Beides sieht man nicht beim Lesen. Beides fällt auf, sobald man etwas anfasst.
Zweitens: Agenten irren selbstbewusst. Jede folgenreiche Behauptung haben wir vor der Umsetzung selbst am Code nachgeprüft. Das hat sich gelohnt: Eine Rolle hatte aus einer Commit-Nachricht geschlossen, drei Bilder stammten aus einem Template — sie waren KI-generiert, was die Kennzeichnungspflicht komplett verändert. Der Befund war plausibel, gut begründet und falsch. Ohne Gegenprobe wäre er durchgegangen.
Drittens: Die Empfehlungen werden erst nützlich, wenn jemand entscheidet. Zwei der Befunde haben wir bewusst nicht umgesetzt, drei gehören vor einen Anwalt, vier hängen an Geschäftsentscheidungen. Ein Agent kann sagen „hier steht eine Aussage, die dein eigener Code widerlegt". Ob daraufhin die Aussage oder der Code geändert wird, ist keine technische Frage.
was das setup braucht
Aus dieser Erfahrung, nicht aus einem Whitepaper:
1. Eine Spec, die verbindlich ist. Wenn die Spezifikation nur Beschreibung bleibt, wandert die Wahrheit zurück in den Code — und der PO verliert die Kontrolle über das, was er eigentlich steuern wollte. 2. Rollen mit Auftrag und Kompetenzgrenze. „Empfehlung, keine Freigabe" muss im Auftrag der Rolle stehen, sonst genehmigt sich das System selbst. 3. Gegenprobe-Pflicht für folgenreiche Aussagen. Nicht jede, aber jede, aus der eine Änderung folgt. 4. Human-in-the-Loop an definierten Stellen. Nicht überall — dann ist nichts gewonnen. Sondern dort, wo eine Aktion unumkehrbar ist, Geld kostet oder rechtlich bindet. 5. Ein Protokoll, das einer Prüfung standhält. Wer hat was wann auf welcher Grundlage entschieden, Agent wie Mensch. 6. Und die unbequeme Frage: Wer prüft die Prüfer. Gartner nennt es Metagovernance. Ein Guardian Agent mit falscher Regel ist gefährlicher als gar keiner, weil er Sicherheit suggeriert.
wo wir stehen
Ehrlich eingeordnet: Wir verfolgen diese Entwicklung sehr genau, wir bauen an dem Setup, und wir haben es nicht als fertiges Produkt im Regal. Was wir haben, sind Erfahrungen aus dem eigenen Alltag — inklusive der Stellen, an denen es nicht funktioniert hat.
Unsere These: Die Engstelle in der Produktentwicklung verschiebt sich gerade von „wer baut das" zu „wer verantwortet das". Teams, die das früh sauber aufsetzen, gewinnen nicht ein paar Prozent Geschwindigkeit, sondern eine andere Arbeitsteilung.
Wenn ihr gerade überlegt, wie weit ein Product Owner bei euch allein kommen soll — und was an Leitplanken dafür stehen muss: Sprecht uns an. 30 Minuten, ohne Pitch-Deck. Wir erzählen auch gern, was bei uns schiefgegangen ist.
quellen
verwandter service
dazu im journal.
dein fall, konkret - reden wir.
30 Minuten, kein Pitch-Deck. Wir schauen uns deinen Use Case an und sagen ehrlich, ob und wie es sich lohnt.