Ich bin Product Owner. Ich schreibe keinen Code. Ich baue trotzdem meine Werkzeuge selbst.

Jeder Product Owner kennt diesen Moment: Irgendetwas im eigenen Arbeitsalltag nervt seit Monaten, und die einzige Reaktion, die dir zur Verfügung steht, ist es, ein Ticket zu erstellen. Beschreiben, gegen Kundenfeatures priorisieren lassen, warten. Meistens schreibst du es gar nicht erst.

Seit einigen Monaten reagiere ich anders. Vor Kurzem wollte ich wissen: Bringt das wirklich was oder bilde ich mir den Effekt nur ein? Also habe ich meinen eigenen Rechner inventarisiert: Agenten, Skills, Sessions, Commits.

Das Ergebnis:

• 247 Commits in sechs eigenen Repositories
• 157 davon mit einer KI als Co-Autor, knapp zwei Drittel
• 114 allein im Testing-Tool, gleichmäßig verteilt ist das also nicht
• ein siebtes Repository habe ich rausgerechnet, das gehört einem fremden Team

Sieht nach was aus. Für jemanden, der keine Zeile davon selbst getippt hat, sowieso.

Nur sagen diese Zahlen nichts darüber, was sich tatsächlich verändert hat. Sie sagen, dass ich viel mit einer Maschine geschrieben habe, sonst nichts. Interessant wird es erst, wenn ich mir anschaue, welche meiner Aufgaben heute anders laufen und welche gleich geblieben sind.

Wer macht die Vorarbeit?

Recherche und Vorplanung waren jahrelang der Teil, der mir die meiste Zeit gefressen hat. Besonders die technische Vorplanung, für die ich immer ein paar ausgesuchte Entwickler gebunden habe. Wertvolle Leute, und das lange bevor überhaupt klar war, wohin es geht.

Heute läuft das über eine Strecke aus zehn spezialisierten Agenten, drei davon für Recherche und Planung, verteilt auf drei verschiedene Modelle je nach Komplexität der Aufgabe. Wie die aufgebaut ist und warum jede Phase eine harte Verbotsregel hat, habe ich in Drei Agenten für den Product Owner im Detail beschrieben.

Der Effekt zeigt sich woanders als erwartet. Ich habe jetzt einen Entwurf, den ich in die Runde werfen kann, und wir steigen gemeinsam auf einer Vorlage ein statt bei null. Was da besprochen wird, ist ein Diskussionsentwurf, kein Beschluss. Und der Mix aus Maschinenvorschlag und Entwicklererfahrung ist am Ende besser als beides für sich.

Wer testet?

Vor jedem Chatbot-Release habe ich früher etwa 45 Minuten manuell durchgeklickt. Immer dieselben Szenarien, nicht reproduzierbar, und zwei Leute kamen bei derselben Oberfläche zu zwei verschiedenen Eindrücken.

Heute macht das ein Tool: 54 automatisierte Tests für UI, UX und Barrierefreiheit, deren Ergebnisse als Jira-Ticket im Sprint-Backlog landen. Auch das habe ich in Chatbot-Testing automatisieren ausführlich beschrieben.

Was damals noch nicht im Blogpost stehen konnte: was danach passiert ist. Der erste Sprint dauerte drei Tage, aber das Repository ist seitdem auf 114 Commits gewachsen, 90 davon mit Claude als Co-Autor. Das Tool ist also nicht nach dem Wochenende verwaist, sondern ein halbes Jahr lang mitgewachsen. Genau das ist der Unterschied zwischen einem Prototyp und einem Werkzeug: Ein Prototyp liegt in der Ecke, ein Werkzeug wird stumpf und muss nachgeschärft werden.

Messen oder schätzen?

Das ist der jüngste Schritt und für mich der überraschendste. Seit Anfang September prüfe ich eine neue Chatbot-Version nicht mehr nur über Jira und Traces, sondern über direkte Browsersteuerung. Der Testplan hat 42 Prüfzeilen in acht Gruppen, von Zugang über Tool-Aufrufe bis Sprachbedienung; 37 davon haben inzwischen ein Urteil, fünf noch nicht.

Der Unterschied steckt nicht in der Automatisierung, sondern in der Art des Urteils. „Das überlappt auf dem Handy“ war früher meine Einschätzung. Damit stand mein Auge gegen das Auge des Entwicklers. Heute ist es der Vergleich zweier ausgelesener Elementpositionen, so wie man zwei Bretter nicht nach Augenmaß vergleicht, sondern den Zollstock anlegt. Und dass ich wirklich ein mobiles Gerät emuliere, zeigen abgefragte Gerätewerte statt eines schmalgezogenen Browserfensters.

Nachprüfbar ist das allerdings nur intern: Testplan und die 46 Screenshots liegen bewusst außerhalb der Versionskontrolle, weil das Repository öffentlich ist.

Was hat sich verschoben?

Wenn ich die drei Punkte nebeneinander lege, ist die Gemeinsamkeit nicht „KI macht meine Arbeit schneller“. Die Gemeinsamkeit ist, dass ich für jedes dieser Probleme ein Werkzeug gebaut habe. Früher wäre das keine Option gewesen.

Ein eigenes Testing-Tool klang nach Entwicklerarbeit. Also hätte ich es beantragt: Ticket ins Backlog, Priorisierung gegen Kundenfeatures, Entwicklungskapazität ziehen, warten. Meistens hätte ich es gar nicht erst versucht. Heute steht auf meinem Rechner eine kleine Werkbank:

Nichts davon ist beeindruckende Software. Aber es liegt an meinem Platz, es passt in meine Hand, und ich musste dafür niemanden fragen.

Nicht mein Anspruch hat sich also geändert, sondern meine Reichweite. Der Abstand zwischen „das nervt mich“ und „dafür gibt es jetzt eine erste brauchbare Version“ ist von Monaten auf Tage geschrumpft. Gepflegt wird danach trotzdem weiter, und zwar von mir.

Und ich benutze diese Werkbank, ich besitze sie nicht nur. Im August waren es zehn Arbeitssessions mit 54 Agentenläufen, also gut fünf Delegationen pro Sitzung. In der ersten Septemberwoche acht Sessions mit 22 Läufen, knapp drei. Über beide Zeiträume sind es gut vier: Ich gebe also die Mehrzahl der Teilaufgaben an einen Spezialisten ab, statt alles selbst zu prompten.

Ist das jetzt AI Slop?

Meine ersten KI-geschriebenen Tickets habe ich für ziemlich gut gehalten. Vollständig, ausformuliert, sauber strukturiert. Ein Entwickler hat sie sich angesehen und gesagt: „Da steht ganz schön viel Slop drin und unnütze Informationen.“

Er hatte recht, und zwar in drei Punkten. Erstens standen Annahmen darin, die einfach falsch waren. Ein Sprachmodell füllt Lücken lieber plausibel, als sie offen zu lassen, und im fertigen Text sieht eine Vermutung genauso aus wie eine Tatsache. Warum das kein Defekt ist, den man einfach wegkonfiguriert, ist bei uns im Blog unter KI-Halluzination ist kein Bug von Sven hergeleitet. Zweitens machte die KI technische Lösungsvorschläge, die im Ticket nichts zu suchen haben, weil sie der Entscheidung der Entwickler vorgreifen. Und drittens war alles zu lang. Was für mich nach Gründlichkeit aussah, war für den, der es umsetzen soll, Material zum Wegsortieren.

Also, was habe ich daraufhin gemacht? Aus diesem einen Satz sind meine Anweisungen für die Ticketerstellung geworden:

• Annahmen als Annahmen markieren oder als offene Frage stehen lassen
• keine Lösungsvorschläge im Ticket
• nur das, was zur Umsetzung gebraucht wird

Rückblickend war das schon die ganze Regel. Dieselben drei Verbote stecken heute in meiner Agentenstrecke, nur eine Ebene höher. Die Recherche darf nicht lösen. Die fachliche Planung darf nicht technisch werden. Die technische Planung darf nicht coden. Und jede Phase hat eine Pflichtsektion für offene Fragen.

Meine Werkbank ist also kein Konzept, das ich mir am Whiteboard ausgedacht habe, sondern eine Sammlung von Regeln, bei der fast jede auf einen konkreten Ärger antwortet. Damit ist auch klar, wofür ich als PO dabei zuständig bin: nicht dafür, dass die Maschine schreibt, sondern dafür, dass sie weiß, wann sie den Mund halten soll.

Darf ich das überhaupt?

Die Frage kommt bei Entscheidern zu Recht. Ein Product Owner, der sich Werkzeuge baut, die in Jira schreiben, Kundenoberflächen prüfen und an sechs Systeme angebunden sind. Wer kontrolliert das?

Die ehrliche Antwort zuerst: bisher ich selbst. Die Hooks habe ich eingerichtet, die Leserechte habe ich gesetzt, freigegeben hat mir das niemand. Das ist Selbstbindung, und ich will das nicht als Governance verkaufen. Trotzdem taugt sie etwas. Nämlich aus dem Grund, dass Mechanik im Gegensatz zu Vorsatz prüfbar ist. Ein Hook, der einen Commit blockiert, hinterlässt eine Spur, die jemand anders nachsehen kann. „Ich passe schon auf“ hinterlässt keine.

Was ist der Harness?

Diese Mechanik sitzt im Harness. Das ist der Teil, der die Wünsche eines Modells tatsächlich ausführt: nicht das Modell selbst, sondern die Schleife drumherum. Stell dir einen Assistenten vor der Tür vor. Das Modell sitzt drinnen und ruft, was es haben will; der Assistent entscheidet, ob er es reinreicht. Und er stellt auch die Unterlagen zusammen, die das Modell überhaupt zu sehen bekommt. Wie dieser Assistent eingerichtet ist, entscheidet deshalb oft mehr über das Ergebnis als das Modell dahinter. Was diese Begriffe im Einzelnen bedeuten, habe ich in Deine Landkarte durchs KI-Vokabular sortiert.

Die Sicherungen im Detail

Konkret sieht das so aus. Bei jedem Commit laufen zwei Hooks mit, zwei Türsteher: einer sucht nach versehentlich mitgeschriebenen Geheimnissen, einer schützt einen Zugangsschlüssel. Schlagen sie an, kommt der Commit nicht durch. Da hilft kein Zureden. Zwei meiner zehn Agenten dürfen ausschließlich lesen, der Review-Agent und der, der mir die Scrum-Master-Arbeit im Jira aufbereitet; die können dort nichts anlegen und nichts ändern, auch wenn sie es für richtig halten. Ausgeführt wird nichts, ohne dass ich es sehe. Die Traces der Chatbot-Läufe liegen auf einer selbst gehosteten Instanz und nicht bei einem fremden Dienst. Und die Abnahmebelege bleiben, wie gesagt, außerhalb des öffentlichen Repositories.

Guardrails vor Autonomie

Die Faustregel dahinter habe ich mir schon beim Sortieren des KI-Vokabulars notiert:

Erst Guardrails, dann Autonomie. Erst die Leine, dann lockern.

Und ehrlich gesagt ist genau das der Teil, den ich weitergebe, bevor ich irgendwem etwas über Produktivität erzähle.

Die nächste Stufe ist dann allerdings nicht mehr meine allein. Wenn zehn Kollegen zehn eigene Werkbänke bauen, braucht es eine gemeinsame Linie und nicht zehn private Absicherungen, die jeweils nur ihr Erbauer versteht.

Ohne Code, ohne Ahnung?

An dieser Stelle muss ich mir selbst widersprechen. Anfang dieses Jahres habe ich über einen gescheiterten Barrierefreiheitsscanner geschrieben, und mein Fazit dort lautete: Ohne fundiertes technisches Verständnis geht es nicht. Wie passt das dazu, dass ich heute Werkzeuge baue, ohne eine Zeile Code zu schreiben?

Es passt, aus zwei Gründen. Der erste ist Zurückhaltung. Am Scanner bin ich daran gescheitert, dass ich nicht beurteilen konnte, was mir zwei KI-Systeme erzählten: CORS-Konfiguration, WebSocket-Upgrades, ein JWT-Key, den eines der Tools frei erfunden hatte, ein Deployment über zwei Plattformen. Acht Stunden habe ich eine leere Anzeige debuggt, weil ich nicht sehen konnte, wo die Wahrheit lag. Heute begrenze ich die Werkbank auf Gebiete, in denen ich das Ergebnis prüfen kann. Ob ein Ticket brauchbar ist, weiß ich. Ob 54 Tests die richtigen Dinge prüfen, weiß ich. Ob ein Modellwechsel unter der Haube die Antwortqualität kippt, sehe ich im Trace. Was ich nicht beurteilen kann, baue ich nicht, oder ich hole jemanden dazu, der es kann.

Der zweite Grund ist der wichtigere, und ich habe ihn mir damals selbst aufgeschrieben. Im Fazit desselben Artikels steht: „Für zukünftige Projekte würde ich ausschließlich mit einer einzigen KI arbeiten, die sowohl Backend als auch Frontend entwickelt.“ Genau das ist die Werkbank geworden. Der Scanner ist nicht daran gescheitert, dass eine KI keine Software bauen kann. Er ist daran gescheitert, dass zwei Systeme nebeneinander herliefen, die nie in den Code des anderen geschaut haben, und ich der Übersetzer dazwischen war. Diesen Zwischenraum gibt es heute nicht mehr, und damit fällt der größte Teil der Reibung weg.

Kein Code zu schreiben heißt also nicht, nichts zu verstehen. Es heißt, sehr genau zu wissen, wo das eigene Urteil endet, und den Aufbau so zu wählen, dass man diese Grenze nicht ständig überschreiten muss.

Was bleibt bei mir?

Priorisierung und Stakeholderarbeit. Daran will ich auch nichts abgeben.

Dafür mache ich jetzt etwas, das früher niemand von mir verlangt hat: Kontext pflegen. 73 Memos und 74 Session-Übergaben liegen auf meiner Platte, plus zwei Commands, die eine Session sauber schließen und die nächste öffnen. Denn ich kann mein Wissen aus einem Stakeholdermeeting nicht einfach beim Modell abkippen. Ich muss es aufbereiten, sonst taugt die nächste Runde nichts. Die Arbeit ist also nicht verschwunden, sie hat die Form gewechselt. Ob unterm Strich Zeit gespart ist, kann ich ehrlich gesagt nicht beziffern. Das ist mein Eindruck, keine Messung.

Und was hat mich das gekostet?

Auf meiner Platte liegt ein Verzeichnis namens WCAG-Scanner. Es enthält nichts außer einem Konfigurationsordner. Daneben ein zweites, a11y-app, ein Git-Repository mit null Commits. Das war mein Herzensprojekt, der Barrierefreiheitsscanner von oben. Von der Idee, die mir am meisten bedeutet hat, ist ein Scherbenhaufen geblieben. Genauer gesagt: zwei leere Ordner. Die Werkbank hat mir viel gebracht, aber die nicht.

Dazu kommt ein Nebeneffekt, den ich nicht wollte. Seit ein Rechercheagent eine Chatbot-Analyse in eine völlig falsche Richtung gedreht hat, traue ich Ergebnissen weniger, die gut aussehen. Ein sauber formatiertes Dokument ist für mich kein Qualitätssignal mehr, sondern erst mal ein Verdacht. Beruflich ist das vermutlich ein Gewinn. Angenehm ist es nicht, und es kostet Energie, die vorher nicht in die Prüfung geflossen ist.

Und die Werkbank selbst hat einen Preis: Sie muss gewartet werden, sie ist auf meinen Rechner und meine Arbeitsweise zugeschnitten, und außer mir kann sie derzeit niemand bedienen. Für ein Werkzeug, das inzwischen in die Arbeit anderer eingreift, ist das kein guter Zustand.

Und jetzt?

Mir fehlt eine Bewertung. Dass die Werkbank läuft, sehe ich jeden Tag. Ob dabei Besseres rauskommt als früher bei meiner Handarbeit, weiß ich schlicht nicht. Deshalb baue ich gerade an einem Golden Set: einer festen Menge von Aufgaben, bei denen ich die gute Lösung schon kenne, so wie die Lösungen hinten im Schulbuch. Dagegen kann ich neue Agenten und neue Modellversionen laufen lassen, mit klaren Ja/Nein-Kriterien statt Bauchgefühl. Dass das übliche grüne Häkchen bei KI-Ergebnissen nicht mehr trägt, ist bei uns unter Das eigene Defekt-Profil von KI-Code beschrieben. Für Rollen wie meine gibt es dafür noch keine etablierte Praxis. Wenn ich in einem halben Jahr wieder etwas schreibe, dann darüber.

Was du mitnehmen kannst

Bau dir diese Woche ein Werkzeug für die eine Aufgabe, die dich am meisten nervt, und zwar für die kleinste Version davon. Nicht die Strecke, nicht das System, nur das eine Ding. Das älteste Artefakt meiner Werkbank ist ein Skill vom 13. April, der nichts anderes tut, als eine Sprint-Zusammenfassung zu schreiben. Das erste Werkzeug ist sogar noch älter, das Testing-Tool gibt es seit März. Kein Konzept, kein Plan, nur konkrete Ärgernisse, die weg sein sollten. Alles andere ist daraus gewachsen.

Du wirst dabei nämlich nicht nur ein Werkzeug bekommen, sondern eine unangenehme Erkenntnis: wie viele deiner Probleme in Wahrheit Werkzeugprobleme waren. Und dann bleib dran. Die Werkbank baut sich von selbst weiter, sobald du einmal angefangen hast.