Wie ein Product Owner KI-Agenten führt statt nur nutzt
Von Lars Decker
Wann ich einem Agenten einfach vertraue – und wann ich trotzdem noch mal genau hinschaue.
Ich habe an anderer Stelle beschrieben, wie ich mir mit KI-Skills den PO-Alltag leichter mache und warum viele Entwickler KI beim Coden zu früh aufgeben. Beide Artikel drehen sich im Kern um dieselbe Frage: Wie viel Verantwortung gebe ich an ein Werkzeug ab, das nicht mehr nur antwortet, sondern selbstständig handelt?
Genau diese Frage stellt sich mir gerade in einer neuen Schärfe. Denn zwischen „KI nutzen" und „KI führen" liegt ein Unterschied, der im PO-Alltag lange unterschätzt wurde.
Vom Nutzer zum Auftraggeber
Ein Prompt in ein Chatfenster tippen ist Nutzung. Man stellt eine Frage, bekommt eine Antwort, fertig.
Ein Agent ist etwas anderes. Er liest Dateien, ändert Code, führt Befehle aus, trifft während der Arbeit kleine Zwischenentscheidungen, ohne dass ich jeden einzelnen Schritt absegne. Das fühlt sich weniger an wie „ein Tool bedienen" und mehr wie „einer Person eine Aufgabe geben".
Und genau da beginnt für mich als Product Owner der eigentlich interessante Teil. Denn ich mache diese Art von Führung nicht zum ersten Mal. Aufgaben klar formulieren, Kontext mitgeben, Zwischenstände einordnen, am Ende das Ergebnis bewerten – das ist im Kern dieselbe Fähigkeit, die ich auch gegenüber Entwicklern, Stakeholdern oder Dienstleistern brauche.
Der Unterschied ist nur: Bei einem KI-Agenten kann ich diese Führungsrolle heute auch bei sehr kleinen, sehr konkreten Dingen selbst übernehmen. Ohne dafür ein Ticket zu schreiben und auf das nächste Refinement zu warten.
Der Fehler, den ich lange gemacht habe: Alles als Task an Entwickler geben
Lange war mein Reflex bei allem, was nach „technisch" aussah, derselbe: Ticket schreiben, Entwickler zuweisen, warten.
Das war bei komplexen Themen richtig. Aber bei vielen kleinen Dingen war es einfach nur ein unnötiger Umweg:
- eine kleine Textänderung auf der Website
- ein Redirect, der fehlt
- ein Datenexport, der einmalig aufbereitet werden muss
- eine kleine Auswertung aus vorhandenen Daten
- ein Formularfeld, das validiert werden soll
- eine kurze Recherche, welche Bibliothek für ein kleines Problem infrage kommt
Für all das brauchte es früher aus meiner Sicht zwingend jemanden mit Entwicklungshintergrund. Heute nehme ich mir solche Dinge zunehmend selbst vor, direkt mit einem KI-Agenten. Nicht, weil ich jetzt programmieren kann. Sondern weil der Agent den Teil übernimmt, für den ich früher einen Entwickler gebraucht hätte, und ich den Teil übernehme, für den ich sowieso zuständig bin: sagen, was gebraucht wird, und beurteilen, ob das Ergebnis stimmt.
Der Effekt ist spürbar. Entwickler werden nicht mehr mit Kleinkram unterbrochen, der ihre eigentliche Arbeit an komplexeren Themen ausbremst. Und ich warte nicht mehr tagelang auf eine Ein-Zeilen-Änderung, nur weil sie sich in die Kapazität eines Sprints einreihen musste.
Das ist für mich der eigentliche Kern dieses Artikels: Nicht jede kleine Aufgabe verdient ein Ticket. Manche verdienen einfach fünf Minuten mit einem Agenten.
Wann ich selbst zum Agenten greife statt zu delegieren
Ich merke, dass sich bei mir eine Art Faustregel herausgebildet hat, wann ich eine Sache direkt selbst mit einem Agenten erledige, statt sie an das Team zu geben:
- Die Aufgabe ist klar umrissen und klein. Ich kann in zwei, drei Sätzen beschreiben, was ich will, ohne dass ich selbst noch unsicher bin, was eigentlich das Problem ist.
- Das Risiko bei einem Fehler ist gering. Geht etwas schief, kostet es mich Zeit, aber es gefährdet kein Produktivsystem und keine Kundendaten.
- Ich kann das Ergebnis selbst beurteilen. Ich sehe, ob ein Text richtig ist, ob eine Auswertung plausibel wirkt, ob ein Formular sich korrekt verhält. Ich muss dafür nicht den Code lesen können.
- Es lohnt sich zeitlich nicht, jemanden einzubeziehen. Der Abstimmungsaufwand wäre größer als die Aufgabe selbst.
Sobald eine dieser Bedingungen nicht mehr zutrifft, ändert sich mein Verhalten komplett. Dann wird aus „ich mache das eben selbst" wieder „das gehört ins Team, mit echtem Review".
Die Kehrseite: Ein Agent ist kein Praktikant, dem man einfach vertraut
Hier wird es aus meiner Sicht wichtig, ehrlich zu bleiben. Ein Agent liefert selbstbewusst. Er zögert selten, er wirkt selten unsicher, auch wenn er es eigentlich sein müsste. Das unterscheidet ihn von einem neuen Kollegen, der bei Unsicherheit meistens nachfragt.
Das heißt für mich konkret: Je größer die Reichweite einer Änderung, desto weniger reicht mein eigenes „sieht gut aus" als Prüfung.
Ein Redirect, den ich selbst ausprobiere, kann ich gut beurteilen. Ob ein Datenexport wirklich alle Sonderfälle korrekt behandelt, ob eine Änderung an einem Kernprozess wirklich keine Nebenwirkungen hat, ob Sicherheitsaspekte sauber berücksichtigt wurden – das kann ich als Product Owner oft nicht abschließend beurteilen. Egal wie überzeugend das Ergebnis auf den ersten Blick aussieht.
Warum Code Reviews trotzdem unverzichtbar bleiben
Genau deshalb bleibt für mich eine Sache nicht verhandelbar: Sobald es um kritische Systeme geht, um Produktivcode, um Zahlungen, Kundendaten, Authentifizierung oder alles, was im Fehlerfall echten Schaden anrichten kann, gehört ein echtes Code Review durch jemanden mit Entwicklungshintergrund dazu. Ohne Ausnahme.
Das ist kein Misstrauen gegenüber der KI. Es ist derselbe Grund, aus dem auch menschlicher Code nicht ungeprüft in Produktion geht. Ein Agent kann syntaktisch sauberen, sogar elegant wirkenden Code produzieren und trotzdem eine Sicherheitslücke übersehen, einen Edge Case ignorieren oder eine Annahme treffen, die im Gesamtsystem nicht stimmt. Genau die Dinge, die ein erfahrener Entwickler beim Review erkennt, bevor sie zum Problem werden.
Meine Faustregel dazu ist einfach:
- Kleine, isolierte, risikoarme Dinge: Ich mache sie selbst mit einem Agenten, ohne formales Review. Der Praxistest ist die Prüfung.
- Alles, was Produktivsysteme, Sicherheit, Zahlungen oder größere Architektur betrifft: Ganz normaler Entwicklungsprozess, inklusive echtem Code Review. Egal, ob der erste Entwurf von einem Menschen oder einem Agenten stammt.
Diese Trennung ist für mich keine Bremse, sondern der Grund, warum ich mir bei den kleinen Dingen überhaupt erlauben kann, selbst Hand anzulegen. Weil ich weiß, dass die kritischen Stellen weiterhin durch einen zuverlässigen Prozess abgesichert sind, verliere ich bei den unkritischen Dingen keine Zeit mit übertriebener Vorsicht.
Führen heißt: Vertrauen dosieren, nicht pauschal vergeben
Wenn ich das Ganze mit klassischer Führung vergleiche, passt ein Bild ziemlich gut. Auch bei einem neuen Teammitglied vertraut man nicht am ersten Tag jede Entscheidung ungeprüft. Man gibt zuerst überschaubare Aufgaben, beobachtet die Ergebnisse, und erweitert den Vertrauensspielraum mit der Zeit.
Bei einem KI-Agenten funktioniert dieses Prinzip erstaunlich ähnlich, nur schneller. Ich habe längst ein Gefühl dafür, bei welcher Art von Aufgabe ich dem ersten Ergebnis vertrauen kann und bei welcher ich automatisch genauer hinschaue. Dieses Gefühl entsteht nicht aus der Technologie an sich, sondern aus der Erfahrung damit, genau wie bei jeder anderen Zusammenarbeit auch.
Der Unterschied zu einem menschlichen Teammitglied ist trotzdem wichtig: Ein Agent lernt aus meinem Feedback nicht dauerhaft dazu. Jede neue Aufgabe beginnt wieder bei null Vertrauen, unabhängig davon, wie gut die letzte war. Diese Disziplin, jedes Mal neu zu prüfen statt sich auf den letzten Eindruck zu verlassen, ist genau der Punkt, den ich auch beim Thema technisches Verständnis für Product Owner für zentral halte.
Fazit
Ich sehe KI-Agenten für mich als Product Owner mittlerweile nicht mehr nur als Werkzeug, das ich bediene, sondern als etwas, das ich führe. Bei vielen kleinen, klar umrissenen Dingen bedeutet das: Ich erledige sie direkt selbst, statt sie unnötig als Task an Entwickler weiterzugeben, die dann mit Kleinkram von wichtigeren Themen abgehalten werden.
Aber Führung bedeutet eben auch, Grenzen zu kennen. Sobald es um kritische Systeme, Sicherheit oder größere Auswirkungen geht, bleibt ein echtes Code Review durch erfahrene Entwickler Pflicht, egal wie überzeugend der erste Entwurf aussieht.
Genau diese Mischung, selbst anpacken, wo es sinnvoll ist, und bewusst Kontrolle abgeben an einen geprüften Prozess, wo es nötig ist, macht für mich den Unterschied zwischen „KI benutzen" und „KI wirklich führen".
