Discovery bleibt menschlich, Execution wird zur Spec: Wie du als Product Manager im Brownfield mit KI arbeitest

Der Moment, in dem wir gerade stecken

KI-Coding-Tools sind überall. Cursor, Claude Code, GitHub Copilot, Codex. Jeder Entwickler hat mindestens eins offen. Die Demos sind beeindruckend. Ein Prompt, und es entsteht eine App. Das Versprechen: zehnmal schneller.

Und dann landest du in der Enterprise-Realität. Du bist CPO bei einer Bank, einem Versicherer, einem Medtech- oder Industrieunternehmen in der DACH-Region. Deine Codebasis ist nicht leer. Sie ist fünfzehn Jahre alt, trägt Geschäftsregeln, die niemand mehr vollständig kennt, und sie steht unter Regulierung. Hier ist «schau mer mal, was die KI ausspuckt» keine Strategie. Hier ist es ein Risiko.

Das ist die Spannung dieses Artikels. Der Hype sagt: lass die KI machen. Die Realität in regulierten Brownfield-Umgebungen sagt: nicht ohne Plan. Die gute Nachricht ist, dass diese beiden Welten sich nicht widersprechen. Du musst nur wissen, wo der Mensch führt und wo die Maschine ausführt.

Die These: vier Phasen für ein Brownfield-Projekt, aus Sicht des Product Managers

Teklens denkt den Software-Lebenszyklus in vier Phasen: Discover, Define, Build, Operate. Plus eine Fast Lane für kleine Änderungen. Das ist nicht nur eine Prozesslandkarte, das ist die neue Arbeitsweise eines Product Managers im KI-Zeitalter.

«Code Intelligence» ist dabei der Hebel. In einfachen Worten: dein Code, dein Jira und dein Confluence werden zu einem durchsuchbaren, semantischen Index, den ein KI-Agent versteht. Nicht Keyword-Suche, sondern echtes Verständnis dafür, warum eine Entscheidung 2023 so getroffen wurde. Das ist genau der Kontext, der im Brownfield fehlt und ohne den jede KI nur rät. Oder wie es das Team formuliert: ohne Kontext ist ein LLM ein Praktikant, der rät, mit Kontext ein Teammitglied, das mitdenkt.

So mappt die These auf die vier Phasen:

Discover (menschlich, SVPG). Hier entscheidest du, welches Problem es wert ist, gelöst zu werden. Continuous Discovery, Kundeninterviews, die vier Risiken von Cagan: Wert, Usability, Machbarkeit, Geschäftsfähigkeit. Diese Phase delegierst du nicht an einen Agenten. Cagan ist hier deutlich: Discovery ist der Kern, und in der KI-Ära wird er wichtiger, nicht unwichtiger. In seinen Worten aus «AI Product Management 2 Years In» (Dezember 2024) wird die PM-Rolle mit generativer KI «essentieller und schwieriger, nicht weniger».

Define (das Gate). Hier entsteht die Spec. Aus dem validierten Problem wird ein präziser, geprüfter Vertrag: Was wird gebaut, warum, mit welchen Akzeptanzkriterien, unter welchen Constraints. Diese Spec wird vereinbart, bevor eine Zeile Code entsteht. Das ist das Gate. Es ist der wichtigste neue Handgriff im PM-Werkzeugkasten.

Build (KI-Execution, SDD/BMAD/OpenSpec). Jetzt führt die Maschine aus. Der Agent baut gegen die Spec, nicht gegen einen vagen Prompt. Welches Framework, hängt vom Kontext ab: OpenSpec für schlanke Einzel-Features, BMAD für schwere Enterprise-Systeme mit Audit-Trail.

Operate. Betrieb, Monitoring, Regressionssicherung. Im Brownfield ist das der Teil, der über Vertrauen entscheidet. Hier zeigt sich, ob die Änderung das System stabil gelassen hat.

Fast Lane. Nicht jede Änderung braucht den vollen Zyklus. Ein Button, ein Textfix, eine kleine Validierung. Dafür gibt es die Fast Lane: leichter Spec-Schritt, schnelle Ausführung, trotzdem nachvollziehbar.

Kosten Gates wirklich Tempo? Die Daten sagen Nein

Der häufigste Einwand gegen Specs: das bremst uns. Die Daten sagen das Gegenteil. Ohne Struktur ist die KI nicht schneller, sondern oft langsamer.

Die METR-Studie von 2025 ist hier die härteste Evidenz (Becker, Rush, Barnes, Rein, arXiv 2507.09089). Ein randomisiert-kontrollierter Versuch mit 16 erfahrenen Open-Source-Entwicklern über 246 reale Tasks, mit Cursor Pro und Claude 3.5/3.7 Sonnet. Vorab erwarteten Experten 24 Prozent schneller, die Devs schätzten hinterher noch 20 Prozent Gewinn.

Das tatsächliche Ergebnis: «we find that allowing AI actually increases completion time by 19% – AI tooling slowed developers down.» 19 Prozent langsamer. Und sie merkten es nicht einmal. Sie fühlten sich schneller.

GitClear analysierte für den Report «AI Copilot Code Quality 2025» 211 Millionen geänderte Codezeilen von 2020 bis 2024. Der Anteil refactorter («moved») Zeilen fiel von 24,1 auf 9,5 Prozent, kopierter Code stieg von 8,3 auf 12,3 Prozent, und duplizierte Codeblöcke (fünf Zeilen und mehr) nahmen 2024 achtfach zu.

Und Churn – Code, der binnen zwei Wochen wieder geändert wird – stieg von 3,1 auf 5,7 Prozent. GitClear-CEO Bill Harding bringt es auf den Punkt: «hastily added code is caustic to the teams expected to maintain it afterward.» Mehr Output, schlechtere Wartbarkeit.

Der DORA-Report 2024 (Accelerate State of DevOps, über 39'000 Befragte) schliesst den Kreis: Pro 25 Prozent mehr KI-Adoption sank die geschätzte Delivery-Stabilität um 7,2 Prozent und der Durchsatz um 1,5 Prozent. 39,2 Prozent der Befragten gaben «little to no trust in AI-generated code» an. Der Grund ist laut DORA nicht «KI-Code ist Müll», sondern dass KI grössere Change-Sets ohne Disziplin erleichtert, und grosse Change-Sets bedeuten mehr Risiko.

Die Schlussfolgerung ist nicht «weniger KI». Sie ist «mehr Struktur vor der KI». Ein Gate, das die Spec festklopft, bevor der Agent baut, ist genau die Disziplin, die diese Studien einfordern. Du verlierst keine Geschwindigkeit, du verhinderst Nacharbeit.

Wie strukturierte Specs zu Qualitäts-Leitplanken werden

Spec-Driven Development dreht die alte Reihenfolge um. Jahrzehntelang war Code König und die Spec Wegwerf-Material. SDD macht die Spezifikation zur Quelle der Wahrheit. GitHub bringt das mit Spec Kit auf den Punkt: «specifications don't serve code, code serves specifications.»

Praktisch heisst das: erst die Spec, dann der Plan, dann kleine testbare Tasks, dann erst die Implementierung durch den Agenten. Spec Kit arbeitet mit über 30 KI-Coding-Agenten und nutzt eine «Constitution» für nicht verhandelbare Projektprinzipien. Das ist die Leitplanke, an der sich jeder Agent ausrichtet, egal ob Copilot, Claude Code oder Cursor. Spec Kit selbst ist explizit kein 80-seitiges Pflichtenheft, sondern eine schlanke, lebende Spec.

BMAD geht weiter. Statt einem Agenten orchestriert es ein Ensemble spezialisierter Personas: Analyst, PM, Architect, Developer, QA, plus einen Orchestrator. Jede Persona produziert ein versioniertes Artefakt und übergibt an die nächste. Mit Git-Versionierung wird jedes Artefakt nachvollziehbar, vom PRD über die Architektur bis zu den Stories.

Für regulierte Umgebungen, in denen Code-Provenienz zählt, ist das der entscheidende Punkt: ein Audit-Trail, der zeigt, wer was wann warum entschieden hat. BMAD behandelt Brownfield bewusst anders als Greenfield – mit einem eigenen Test-Architect-Agenten für Regressionsrisiken, Legacy-Abhängigkeiten und Breaking Changes. Wichtig: BMAD ersetzt Copilot, Cursor und Co. nicht, es orchestriert sie.

OpenSpec von Fission-AI ist die leichte Variante. Eine lebende Spec, ein Zyklus aus explore, propose, apply, archive. Menschen und KI einigen sich auf die Spec, bevor Code entsteht («Agree before you build»). Kein schwerer Phasen-Gate-Apparat, sondern flüssiges Iterieren, und am Ende landet die Änderung im Archiv für die Audit-Historie. Ideal, wenn ein Entwickler plus ein KI-Assistent ein Feature liefern soll. OpenSpec positioniert sich bewusst leichter als Spec Kit, das sie selbst als «thorough but heavyweight» beschreiben.

Der gemeinsame Nenner aller drei: die Einigung vor dem Code. Das ist der Unterschied zwischen Prompt-Engineering on-the-fly und einem Vertrag, an dem die Ausführung gemessen wird.

Warum gerade das Brownfield ein Gate vor dem Code braucht

Greenfield ist einfach für KI. Leeres Feld, keine Altlasten. Brownfield ist gefährlich. Etablierte Systeme tragen unsichtbare Verträge: Annahmen über Datenflüsse, Integrations-Eigenheiten, Geschäftsregeln in Code, an den sich niemand erinnert. Agenten können diese oft nicht ableiten und raten. Dann brechen Dinge leise. Ein dokumentiertes Beispiel: ein Team liess Claude einen acht Jahre alten Django-Monolithen refactoren, bekam saubere, selbstbewusste Patches, die still Integrationen zu externen Services brachen. Nach mehreren Rollbacks legten sie das Experiment beiseite.

Dazu kommen die technischen Brownfield-Grenzen der Modelle: Kontext-Overflow bei grossen Dateien, Vergessen über Sessions hinweg, übersehene Konventionen. Genau die Themen, die ein semantischer Code-Index und eine schriftlich fixierte Spec adressieren.

In regulierten Branchen kommt die Compliance-Last dazu. Audit-Trails sind nach HIPAA, GDPR, 21 CFR Part 11 und branchenspezifischen Regeln Pflicht. Wer was wann an einem System geändert hat, muss rekonstruierbar sein, auch Monate später. Ein nachvollziehbarer Spec-zu-Code-Pfad ist hier kein Nice-to-have, sondern Teil der Defensibility.

Genau deshalb ist die Kombination aus Code Intelligence und Gate so passend für DACH-Banken, Versicherer und Medtech. Erst den Code-Kontext verstehen, dann die Spec festschreiben, dann den Agenten bauen lassen, dann gegen Regressionen absichern. Charakterisierungstests vor dem KI-Refactor, schmale Diffs, ein Intent pro Pull Request. So bleibt das System vorhersehbar unter Last, und am Ende steht Code, der läuft.

Das letzte und wichtigste Argument: Je besser die Modelle, desto wertvoller die Gates

Hier kommt der Punkt, der die ganze These trägt.

Die Modelle werden rasant besser. Claude Code arbeitet inzwischen über lange Zeiträume autonom. Anthropic dokumentiert in «Measuring AI agent autonomy in practice» (Oktober 2025 bis Januar 2026), dass die längsten Arbeitsabschnitte sich in drei Monaten fast verdoppelt haben, vom 99,9. Perzentil unter 25 Minuten auf über 45 Minuten. Agenten laufen über mehrere Kontextfenster, hinterlassen Fortschritts-Logs und arbeiten an Aufgaben, die früher Tage dauerten. Die Auto-Approve-Rate erfahrener Nutzer steigt von rund 20 Prozent bei Neulingen auf über 40 Prozent.

Die naive Schlussfolgerung wäre: dann brauchen wir bald keine Specs mehr, die KI macht alles. Das ist falsch herum gedacht.

Je autonomer ein Agent über Stunden baut, desto teurer ist eine falsche Annahme. Ein Agent, der eine Stunde in die falsche Richtung läuft, weil das Ziel unklar war, produziert eine Stunde Schaden.

Anthropic selbst zeigt es: Ein Frontier-Modell wie Opus 4.5, das nur einen vagen Prompt wie «bau einen Klon von claude.ai» bekommt, scheitert an Produktionsqualität – es versucht zu viel auf einmal und verliert mitten in der Implementierung den Kontext. Was es rettet, sind ein Initializer-Schritt, strukturierte Fortschritts-Logs und inkrementeller Fortschritt. Also: Struktur und ein Gate.

Das ist die eigentliche Verschiebung. Wenn das Coden billig und schnell wird, ist nicht mehr das Tippen der Engpass. Der Engpass ist die Entscheidung, was gebaut werden soll, und die präzise Definition dieser Entscheidung. Andrew Ng bringt es auf den Punkt (Januar 2025): «Writing software, especially prototypes, is becoming cheaper. This will lead to increased demand for people who can decide what to build. AI Product Management has a bright future!» Genau das ist der Job des Product Managers.

Cagan argumentiert in dieselbe Richtung: Die Product-Owner-Rolle als reiner Backlog-Verwalter ist gefährdet («a very easy kind of thing for an assistant to make a big dent into»), der echte Product Creator wird wertvoller. Je mehr die KI baut, desto mehr zählt das menschliche Urteil darüber, was es wert ist, gebaut zu werden, und wie präzise man das definiert.

Anders gesagt: Bessere Modelle machen gate-basierte, spec-getriebene PM-Arbeit nicht überflüssig. Sie machen sie zur wichtigsten Arbeit überhaupt.

Die neue Rolle des Product Managers

Der PM wird zum Orchestrator. Vorne menschliche Discovery, hinten KI-Execution, dazwischen die präzise Spec. Du verwaltest keine Anforderungslisten mehr, du entscheidest über Outcomes und definierst sie so klar, dass ein autonomer Agent sie nicht missversteht. Das ist die Brücke zwischen Cagans menschenzentriertem Modell und den KI-nativen Frameworks: SVPG-Prinzipien für Discovery und Strategie, dann Übergabe an OpenSpec (für agile, schlanke Apps) oder BMAD (für schwere Enterprise-Systeme) für die Execution.

Und damit sind wir zurück am Anfang. Der Hype sagt: lass die KI machen. Die Enterprise-Realität sagt: nicht ohne Plan. Der Widerspruch löst sich auf, sobald du die Arbeit richtig aufteilst. Die KI baut. Du entscheidest, was, und definierst es so präzise, dass die Maschine nicht rät. Im Brownfield, unter Regulierung, mit einer Codebasis, die du nicht wegwerfen kannst, ist das nicht die langsame Variante. Es ist die einzige, die unter Last hält.

Empfehlungen

• Starte jetzt mit dem Define-Gate. Führe für jede nicht-triviale Änderung eine vereinbarte Spec ein, bevor ein Agent baut. Das ist der billigste Hebel mit dem grössten Effekt.
• Wähle das Framework nach Kontext: OpenSpec für schlanke Einzel-Features und schnelle Zyklen, BMAD für komplexe Enterprise-Systeme mit Compliance- und Audit-Anforderungen, Spec Kit, wenn du toolübergreifend mit vielen Agenten arbeitest.
• Schütze die Discovery. Delegiere niemals die Entscheidung, welches Problem gelöst wird, an einen Agenten. Halte Cagans vier Risiken (Wert, Usability, Machbarkeit, Geschäftsfähigkeit) als Checkliste in der Discover-Phase.
• Sichere Brownfield-Änderungen ab: Charakterisierungstests vor dem KI-Refactor, ein Intent pro Pull Request, schmale Diffs, Regressions-Harness um kritische Flows wie Billing, Auth, Pricing. Faustregel: keine Charakterisierungstests, kein KI-Refactor in diesem Bereich.
• Baue den Audit-Trail von Anfang an ein, nicht nachträglich. In regulierten Umgebungen ist der Spec-zu-Code-Pfad Teil der Compliance, nicht ein Edge Case.
• Schwellen, die deine Entscheidung ändern: Wenn deine Change-Failure-Rate oder Rework-Rate nach KI-Einführung steigt, ist das das Signal, das Gate zu verschärfen, nicht es abzuschaffen. Steigt sie nicht und sinkt die Lead Time, kannst du die Fast Lane für mehr Änderungsklassen öffnen.

Einordnung & Grenzen

• Die METR-Studie hatte 16 Entwickler in grossen, reifen Open-Source-Repos (im Schnitt 22'000+ Stars, 1 Mio.+ Zeilen). Die Autoren betonen selbst, dass das Ergebnis nicht auf alle Kontexte verallgemeinerbar ist und neuere Modelle anders abschneiden könnten. Es ist starke Evidenz für reife Brownfield-Codebasen, nicht ein universelles Urteil. Die getesteten Modelle (Claude 3.5/3.7) sind inzwischen mehrere Generationen alt.
• Die DORA- und GitClear-Zahlen sind Korrelationen und Branchen-Aggregate, keine Aussagen über dein spezifisches Team. Nutze sie als Warnsignal, nicht als Prognose.
• SDD ist nicht gratis. Kritiker wie Gojko Adzic warnen, dass schwere Spec-Prozesse die Rigidität zurückbringen könnten, der Agile-Methoden entkommen wollten. Manche Praktiker berichten, dass Spec Kit ohne zusätzliche Regeln und MCP-Server nicht automatisch zu besserem Code führt. Die Lösung sind schlanke, lebende Specs, keine 80-seitigen Pflichtenhefte.
• Alle genannten Produktivitäts- und Qualitätszahlen stammen aus externen Quellen (METR, GitClear, DORA, Anthropic) und sind diesen zugeschrieben. Sie sind keine Teklens-Ergebnisse und keine Versprechen über bestimmte Geschwindigkeitsgewinne.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.