Vom Gespräch zum Pull Request

Am deutlichsten wird das an einem konkreten Ablauf, wie ich ihn heute bereits in Teilen aufbaue. Man kann ihn als kleine Geschichte lesen – vom ersten Gespräch bis zum fertigen Pull Request.

Es beginnt mit einem Meeting.

Fireflies zeichnet das Gespräch auf, transkribiert es und erstellt eine Zusammenfassung. Diese Informationen landen automatisch in Obsidian und erweitern mein Wissenssystem.

Codex oder Claude greifen anschließend auf dieses Wissen zu und besitzen zusätzlich Zugriff auf GitHub.

Damit kennen sie die Dokumentation, die Architektur, die Codebasis und den aktuellen Entwicklungsstand – gleichzeitig.

Nun entsteht ein neuer Feature-Wunsch.

Statt ihn sofort in ein Ticket zu überführen, stellt ein von mir definierter Skill zunächst Rückfragen. Er präzisiert die Anforderung so lange, bis das eigentliche Bedürfnis klar ist.

Auf dieser Grundlage erstellt die KI ein vollständiges Jira-Ticket.

Dieses Ticket ist kein generischer Vorschlag. Es orientiert sich an unserer internen Struktur, berücksichtigt den aktuellen Stand der Software, bestehende Patterns und bekannte technische Entscheidungen.

Im besten Fall liest es sich so, als hätte es jemand geschrieben, der das Produkt wirklich kennt – weil die KI über den bereitgestellten Kontext tatsächlich ein fundiertes Verständnis davon entwickeln konnte.

Im nächsten Schritt kann die KI ersten Code erzeugen, Tests vorbereiten und die Änderungen als Pull Request bereitstellen.

Und genau hier verläuft die entscheidende Grenze.

Alles, was danach kommt, bleibt Aufgabe der Entwickler: Review, Architektur, Qualität, Sicherheit, Skalierbarkeit, Performance, Edge Cases und die finale Entscheidung.

Die KI liefert einen ersten Entwurf. Nicht die fertige Lösung.

Werkzeuge wie Claude Code, OpenAI Codex, GitHub Copilot oder Devin zeigen heute bereits, wie weit dieser erste Entwurf reichen kann – und gleichzeitig, wo seine Grenzen liegen.

Ein Pull Request, den niemand mit Sachverstand überprüft, ist keine Beschleunigung. Er ist eine potenzielle Zeitbombe mit CI-Pipeline.

Der Gewinn entsteht nicht allein dadurch, dass eine Maschine Code schreibt. Er entsteht dadurch, dass ein Mensch nicht mehr bei null beginnen muss, sondern einen vorhandenen Entwurf prüfen, verändern und verbessern kann.

Über die Idee, dass Product Owner künftig eigene Pull Requests öffnen, habe ich an anderer Stelle ausführlicher geschrieben. Was ich hier beschreibe, ist die Maschinerie dahinter: der konkrete Weg, auf dem aus einem Gespräch Code entstehen kann, ohne dass unterwegs die menschliche Verantwortung verloren geht.

Wenn ich diesen Aufbau weiterdenke, verändert er nicht nur meinen Arbeitsalltag, sondern langfristig auch die Rolle des Product Managers.

Ich glaube, dass Product Manager künftig deutlich technischer arbeiten werden.

Nicht, weil sie Entwickler ersetzen. Diesen Gedanken halte ich für falsch.

Sondern weil KI ihnen erstmals ermöglicht, selbst produktiv an technischen Lösungen mitzuwirken.

Konkret bedeutet das: Product Manager können bessere Dokumentationen erstellen, klarere Tickets formulieren, Discovery strukturierter vorbereiten, Quellcode besser verstehen, erste technische Lösungsansätze entwickeln, Wissensdatenbanken nahezu nebenbei pflegen und Entwickler dadurch gezielter unterstützen.

Die Rechnung dahinter ist vergleichsweise einfach:

Entwickler gewinnen Zeit. Product Manager gewinnen technisches Verständnis. Produkte gewinnen Geschwindigkeit.

Die Rolle verschiebt sich dadurch.

Der Product Manager wird weniger zum Verwalter von Tickets und stärker zum Designer von Systemen – zum Übersetzer zwischen Business und Technologie und zunehmend auch zum Gestalter intelligenter Arbeitsabläufe.

Der Kern des Berufs verändert sich dabei gar nicht grundlegend. Es verändert sich vielmehr, wie viel Verantwortung und operative Umsetzung eine einzelne Person mithilfe solcher Systeme übernehmen kann.

Einen Punkt möchte ich zum Schluss so deutlich formulieren, dass er nicht missverstanden werden kann:

KI ersetzt keine Entwickler.

Meine Überzeugung ist das Gegenteil.

Je leistungsfähiger KI wird, desto wichtiger werden gute Entwickler. Architektur, Qualität, Sicherheit, Skalierbarkeit, Performance und langfristige Wartbarkeit bleiben menschliche Verantwortung.

Und je günstiger und schneller der erste Entwurf entsteht, desto wichtiger wird das Urteil derjenigen, die ihn überprüfen.

KI liefert den ersten Entwurf.

Menschen verantworten das Ergebnis.

Genau darin sehe ich die Zukunft moderner Produktentwicklung – und zugleich die Antwort auf die Frage, mit der dieser Text begonnen hat.

Es ging nie nur um die Tools.

Es ging immer darum, was man aus ihnen baut.