Wie sich PM-Arbeit im KI-Zeitalter verändert: KI verschiebt die Engpässe der Produktentwicklung

Warum der Engpass gewandert ist und die PM-Arbeit ihm folgt

«Unsere Entwickler sind mit Claude und Codex deutlich schneller. Meine Product Manager verbringen den Tag damit, das alles zusammenzuhalten.» So beschreibt ein CTO aus unseren Gesprächen, wie sich PM-Arbeit im KI-Zeitalter verändert. Casey Winters hat für seinen Newsletter Casey Accidental Product Manager von Startups bis zu börsenkotierten Unternehmen interviewt und kommt zum gleichen Befund, in einem Satz: «AI removed one constraint and exposed several others.»¹

Die eine Beschränkung war Engineering-Kapazität. Product Manager haben Jahre damit verbracht, auf Entwicklung zu warten, die auch mit den besten Engineers langsam und teuer war. Jetzt ist Code leicht zu erzeugen, und der Engpass sitzt woanders: beim Design, bei der Integration neuer Features ins bestehende Produkt, bei den Edge Cases, bei der organisatorischen Abstimmung und bei gemeinsamen Produktprinzipien. Die Organisationen haben ihre Produktprozesse noch nicht um diese neuen Beschränkungen herum gebaut, und die Technologie verändert sich schneller, als sich Prozesse stabilisieren können.¹

Ich bin Mitgründer von Teklens. Davor habe ich Aioma aufgebaut und Localinas CRM an Swisscom verkauft, und ich unterrichte an HWZ, ZHAW und FHNW. Bei Teklens haben wir 24 Discovery-Gespräche mit Product-Leuten darüber geführt, wie ihre Teams mit KI arbeiten, und der Satz des CTO oben fällt in Varianten fast jedes Mal. Dieser Beitrag nimmt Winters' Interviews als Ausgangspunkt und legt die Messdaten daneben. Du nimmst mit, wohin der Engpass gewandert ist und wie du ihn in eurem Team findest, warum mehr Output bisher kaum mehr Wirkung gebracht hat, welche drei Betriebsmodi Teams nach den ersten KI-Fehlern entwickeln, und wie du den Produktprozess in sieben Schritten um die neuen Engpässe herum neu baust.

Die These in einem Satz: KI hat die Knappheit beim Coding entfernt, aber nicht den Mechanismus ersetzt, den diese Knappheit erzwungen hat, die Priorisierung. Coding ist schnell geworden. Die Koordination nicht. Der Engpass liegt nicht mehr beim Coding, sondern bei der Abstimmung und beim Urteil darüber, was überhaupt gebaut werden soll.

Wohin ist der Engpass gewandert?

Vom Coding in die Arbeit davor und danach. Die Product Manager in Winters' Interviews nennen fünf Stellen: Design, Integration neuer Features ins breitere Produkt, Umgang mit Edge Cases, organisatorische Abstimmung und gemeinsame Produktprinzipien. Keine davon ist neu. Neu ist, dass sie jetzt die Wartezeit bestimmen, weil die Stelle davor, die Umsetzung, in Stunden statt Wochen fertig ist.¹

Theory of Constraints. Eliyahu Goldratt hat das Muster 1984 in «The Goal» beschrieben. Seine fünf Schritte: Engpass identifizieren, ausnutzen, alles andere unterordnen, Engpass erweitern, und sobald er gebrochen ist, zurück zu Schritt eins, damit nicht die Trägheit zum neuen Engpass wird. Die meisten Produktorganisationen haben mit Coding-Agents Schritt vier erledigt und Schritt fünf ausgelassen. Sie arbeiten weiter mit Prozessen, Rollen und Meetings, die für knappes Engineering entworfen wurden.²

Die Messung. Faros AI hat 2025 Telemetrie von über 10'000 Entwicklern in 1'255 Teams ausgewertet. Teams mit hoher KI-Nutzung erledigen 21 Prozent mehr Aufgaben und mergen 98 Prozent mehr Pull Requests. Gleichzeitig steigt die Review-Zeit pro Pull Request um 91 Prozent, und die Pull Requests werden 154 Prozent grösser. Die Warteschlange ist vom Schreiben zum Prüfen und Integrieren gewandert. Genau dort, wo Winters' Product Manager den Engpass spüren.³

Atlassian hat 2025 rund 3'500 Entwickler und Manager in sechs Ländern befragt. Zwei Drittel sparen nach eigener Angabe mehr als zehn Stunden pro Woche durch KI-Werkzeuge. Die Hälfte verliert mehr als zehn Stunden pro Woche an organisatorische Reibung: Informationen suchen, zwischen Werkzeugen wechseln, teamübergreifend abstimmen. Was KI im Editor schenkt, holt sich die Organisation in der Koordination zurück.⁴

Für Product Manager hat das Warten die Seite gewechselt. Früher wartete Product auf Engineering. Jetzt warten Design, Review und Abstimmung auf Entscheide, die eine Product Managerin hätte treffen sollen, bevor der Agent losgelegt hat. Der CTO aus dem Einstieg nennt das «zusammenhalten». Es ist die Arbeit eines Engpasses, der noch keinen Namen hat.

Warum bedeutet mehr Output nicht mehr Wirkung?

Weil KI Arbeit billig genug macht, die vorher unwirtschaftlich war. Winters beschreibt Teams, die mehr Code, mehr Specs, mehr Prototypen, mehr Bugfixes, mehr Evals und mehr Dashboards produzieren, und Product Manager, die kaum einen vergleichbaren Anstieg der Geschäftsresultate sehen. Die unpriorisierte Arbeit, die Arbeit, die keine Kennzahl bewegt, die Arbeit, die früher im Backlog blieb, wird jetzt gemacht. Und sie frisst die Zeit, in der die wirkungsvollste Arbeit geplant würde.¹

Die Firmenebene bestätigt das. In den Faros-Daten verschwindet der Zusammenhang zwischen KI-Nutzung und Leistungskennzahlen, sobald man auf das Unternehmen schaut: Durchsatz, Durchlaufzeit und Incident-Lösung bleiben flach, während der Output pro Entwickler steigt. DORA hat 2025 fast 5'000 Technologie-Fachleute befragt und nennt KI einen Verstärker. Höhere Nutzung geht mit mehr Durchsatz einher, aber weiterhin mit weniger Stabilität. Verstärkt wird, was die Organisation schon hat, auch die Unordnung.^3,5

Dazu kommt eine Wahrnehmungslücke. METR hat erfahrene Open-Source-Entwickler in einem randomisierten Experiment mit und ohne KI-Werkzeuge arbeiten lassen. Mit KI waren sie 19 Prozent langsamer und glaubten, schneller zu sein. Die Stichprobe ist klein und der Kontext speziell, aber der Befund zur Selbstwahrnehmung passt zu dem, was Winters' Product Manager berichten: Das Gefühl von Tempo und die gemessene Wirkung laufen auseinander.⁶

Der Nebeneffekt. Mehr Ergänzungen erreichen die Kunden schneller und stiften Verwirrung, und viele davon hätten gar nicht gebaut werden sollen. Winters' Fazit: Das Produkt ist schwerer zu verstehen geworden, und die Codebasis auch. GitClear hat 211 Millionen geänderte Codezeilen aus den Jahren 2020 bis 2024 analysiert: Duplizierte Blöcke von fünf und mehr Zeilen kamen 2024 achtmal häufiger vor, verschobene Zeilen, das Signal für Refactoring, gingen um rund 40 Prozent zurück, und 2024 übertraf kopierter Code erstmals den verschobenen. Jede ungeprüfte Ergänzung macht die nächste Entscheidung schwerer.^1,7

Eine Frage bleibt offen, und Winters stellt sie ehrlich: Wenn jedes Unternehmen Bugs und kleine Feature-Wünsche jetzt schneller abarbeitet, sind die Kundenerwartungen so gestiegen, dass man zurückfällt, wenn man es nicht tut? Die Antwort kennt heute niemand. Was sich beantworten lässt, ist die Frage, ob euer Team diese Arbeit bewusst macht oder weil sie billig geworden ist.¹

Was passiert, wenn Knappheit die Priorisierung nicht mehr erzwingt?

Teams bauen, was baubar ist, statt was zählt. Winters bringt es auf den Punkt: «Before AI, engineering scarcity forced prioritization. AI removed some of the scarcity without replacing the prioritization mechanism.» Die alte Logik war einfach: Code war Hebel, Code war teuer, also sparte man ihn für die besten Ideen. Alles andere wurde nicht gemacht oder von Menschen von Hand erledigt.¹

Priorisierung hatte zwei weitere Aufgaben, die kaum jemand so benannt hat. Sie kontrollierte die Rate der Veränderung, die beim Kunden ankommt. Und sie lehnte schlechte Ideen ab. Beide Funktionen sind mit der Knappheit verschwunden. Deshalb erreichen jetzt mehr Konzepte die Kunden, die nie hätten gebaut werden sollen, und deshalb sind Produkt und Codebasis schwerer zu verstehen.¹

Die falschen Anreize. Gleichzeitig entsteht die Erwartung, Product Manager sollten selbst Daten abfragen, prototypen, Prompts ändern, Code schreiben, interne Tools bauen, Agents erstellen und Evals definieren. Winters beobachtet, dass der Massstab für Product Manager überdreht hat: von «Technologie gut genug verstehen, damit gute Entscheide fallen und umgesetzt werden» zu «selbst technische Fähigkeit demonstrieren». Product Manager arbeiten härter daran, technisch und AI-native zu wirken, und haben weniger Zeit zu prüfen, ob das, was ihre Teams produzieren, überhaupt existieren sollte.¹

Reifere Organisationen ziehen die Linie anders. KI zur Effizienz zu nutzen ist dort Grundvoraussetzung. Geschätzt wird, wer mit KI Wert für Kunden und Geschäft schafft, der vorher nicht möglich war. Das braucht zwei Dinge. Geschmack, also zu wissen, wie gut aussieht, als Fähigkeit, die mit einer Technologie neu erlernt werden muss, die verändert, welche Produkte überhaupt möglich sind. Und Prinzipien, die festhalten, wogegen Menschen und Agents ausführen, als Prozess. Winters' Satz dazu trägt den ganzen Beitrag: «AI raises the value of judgment only when PMs make their judgment understandable to others and reusable.» Wie das in der Planung aussieht, zeigt der Beitrag zur KI-Roadmap; wie Teams Kontext statt Arbeit managen, der zum AI Product Operating Model.¹

Wie reagieren Teams auf die ersten KI-Fehler? Drei Betriebsmodi

Jede Organisation beginnt gleich: KI nutzen, Magie erleben, schneller bauen, Fehler erleben. Was danach passiert, prägt das Team. Winters sieht drei Antworten: den Nachteil absichern («What if it's wrong?»), den Vorteil maximieren («Why not try it?») und auf Wirkung optimieren («Did it matter?»). Das sind keine drei Firmentypen. Teams derselben Firma arbeiten in verschiedenen Modi, und ein Team wechselt den Modus je nach Phase.¹

Modus 1: den Nachteil absichern. Diese Teams haben Prozesse verschärft: freigegebene Werkzeuge für bestimmte Anwendungsfälle, starke Gates, Deck-Kultur, Konsequenzen bei falscher KI-Nutzung. Der Gewinn ist Qualitätskontrolle. Das Risiko: Die Firma verteidigt ihre Position, während Wettbewerber etwas Neues entdecken, das diese Position entwertet. Innovation findet ausserhalb der Arbeitszeit in privaten Projekten statt. Unser AI Monitor 2026 mit der ETH Zürich und der Universität St. Gallen zeigt dasselbe Muster bei 163 Befragten: Sechs von zehn greifen zusätzlich zu privaten KI-Werkzeugen, obwohl 87 Prozent Werkzeuge vom Arbeitgeber bekommen. Freigabelisten verhindern Nutzung nicht. Sie verschieben sie aus dem Blickfeld.^1,9

Modus 2: den Vorteil maximieren. Diese Teams probieren standardmässig. Sie nehmen in Kauf, dass ein Teil der Arbeit Slop ist, weil sie insgesamt mehr schaffen und schneller lernen wollen. Sie arbeiten härter als je zuvor und wachsen kaum schneller. Die Kette «schneller liefern, mehr Experimente, schneller lernen, schneller wachsen» bricht, sobald die Kapazität zu liefern die Kapazität zu lernen übersteigt. KI-geschriebene Updates führen zu KI-Tools, die die Updates zusammenfassen. Winters' Definition dafür ist präzise: «Organizational slop is what happens when an organization can generate work faster than it can evaluate, coordinate, or absorb it.»¹

Das Misstrauen der Entwickler ist in diesem Modus das gesündeste Signal. Im Stack Overflow Developer Survey 2025 mit über 49'000 Antworten nutzen oder planen 84 Prozent KI-Werkzeuge, 46 Prozent misstrauen der Genauigkeit der Ergebnisse, und 66 Prozent nennen als grösste Frustration Lösungen, die «fast richtig, aber nicht ganz» sind. Fast richtig ist bei einem Prototyp billig und bei einem Produktentscheid teuer. Modus 2 verwechselt beides.⁸

Modus 3: auf Wirkung optimieren. Diese Teams interessiert, ob das Gebaute Nutzer- oder Geschäftskennzahlen bewegt. Produktivität zählt nur, wenn sie in Wachstum oder Gewinn mündet. Sie setzen Token-Verbrauch nicht mit Fortschritt gleich, haben weniger Werkzeuge als Modus-2-Teams und vertrauen ihnen mehr. Ihre Arbeit lebt in Dokumenten und Tabellen, nicht in Decks, und jedes Artefakt ist für Menschen und Agents als gleichberechtigte Leser geschrieben, oft in Markdown statt in Slides. Fast alle Modus-3-Teams in Winters' Interviews haben in Modus 2 begonnen. Vielleicht muss ein Team von KI überwältigt werden, bevor es lernt, sie klug zu begrenzen.¹

Was alle drei Modi verbindet: Um KI zu zentralisieren heisst nicht, ihr zu vertrauen. Winters' Product Manager arbeiten in einer persönlichen KI-Umgebung aus bevorzugtem Modell, Firmenkontext, eigenem Kontext und den Firmen-Tools, oft über MCP angebunden, und exportieren das Ergebnis erst am Ende als Deck, Dokument oder Slack-Nachricht. Je ausgefeilter diese Umgebung, desto weniger blind vertrauen sie ihr. Alle haben erlebt, wie KI den gegebenen Kontext überbewertet und die Nuance glättet, in der die besten Produkteinsichten stecken. Daraus entsteht eine neue Fähigkeit mit fünf Entscheidungen: welchen Kontext die KI bekommt, welche Synthese sie machen darf, was sie ausführen darf, wo menschliches Urteil nötig bleibt, und was ein Mensch prüft.¹

Wie baust du den Produktprozess um die neuen Engpässe herum neu?

In sieben Schritten, in dieser Reihenfolge: Engpass finden, Priorisierung ohne Knappheit wieder einsetzen, Veränderungsrate begrenzen, Prinzipien schreiben, Prüfung vor dem Bau definieren, Vertrauensgrenzen für KI festlegen, Wirkung statt Output messen. Die Reihenfolge folgt Goldratt: erst identifizieren, dann unterordnen, dann erweitern.²

1. Finde den Engpass, bevor du ihn behandelst. Miss, wo Arbeit heute wartet: Review-Zeit pro Pull Request, Tage in der Design-Warteschlange, Freigaberunden pro Feature, Abstimmungsmeetings pro Vorhaben. In den Faros-Daten ist das Review der häufigste Kandidat, bei euch kann es die Integration oder das Design sein. Frag Engineering, wo sie auf Product warten. Die Antwort ist meistens ein Entscheid, der fehlt.³

2. Setze die Priorisierung ohne die Knappheit wieder ein. Ein Vorhaben muss zeigen, warum es existieren soll, nicht, dass es billig ist. Verlange für jedes Vorhaben eine Wirkungsbehauptung: welche Kunden- oder Geschäftskennzahl es bewegt und was passiert, wenn ihr es nicht baut. Ein brauchbarer Test: Würden wir das bauen, wenn es zehn Engineer-Wochen kosten würde? Wenn nein, baut es auch für zehn Minuten nicht. Die Activity Prioritize against your objectives gibt dem eine Form.

3. Begrenze die Veränderungsrate beim Kunden. Priorisierung hat die Veränderung früher nebenbei gedrosselt. Jetzt braucht es die Drossel explizit: ein Budget an Änderungen pro Release, das Kunden aufnehmen können, und Support-Tickets pro Release als Messgrösse. Was das Budget sprengt, wartet oder wird gestrichen.

4. Schreib Produktprinzipien als Ground Truth. Prinzipien regeln, wie sich das Produkt in den Fällen verhält, die niemand spezifiziert hat. Sie sind das, wogegen Menschen und Agents ausführen. Schreib sie mit Beispiel und Gegenbeispiel, versioniert, an einem Ort, den ein Agent lesen kann. Die Activity Write a PRD zeigt, wie Absicht und Prinzipien in das Dokument kommen, das Agents und Menschen gemeinsam lesen.

5. Definiere die Prüfung vor dem Bau. Das Eval wird zum zentralen Produktartefakt. Bevor etwas gebaut wird, steht fest, woran ihr erkennt, dass es funktioniert hat: ein Eval-Set für KI-Features, eine Erfolgsmetrik für alles andere. Das PRD sagt, was ihr bauen wolltet. Das Eval sagt, ob ihr es getan habt. Die Activity Define success metrics und der Beitrag zu KPIs für KI-Produkte helfen bei der Wahl.¹

6. Lege fest, was KI wissen und entscheiden darf. Schreib pro Workflow die fünf Entscheidungen auf: Kontext, Synthese, Ausführung, menschliches Urteil, Prüfung. Manche Teams geben der KI Rohdaten und verlangen die Rohdaten zurück statt geglätteter Schlussfolgerungen. Andere lassen sie nie an Rohdaten. Beides ist vertretbar. Unvertretbar ist, es nicht entschieden zu haben.¹

7. Miss Wirkung, nicht Output. Einmal pro Quartal: Was von allem, was ihr geliefert habt, hat eine Kunden- oder Geschäftskennzahl verändert? Dieser Anteil ist die Gesundheitskennzahl eures Prozesses. Ist er tief, baut ihr schneller, was ihr nicht hättet bauen sollen. Dann gilt: Streiche Arbeit, bevor du sie automatisierst.

Was ist jetzt der Job des Product Managers?

Zu entscheiden, was passieren soll, warum, nach welchen Prinzipien sich das Produkt verhält und woran Erfolg geprüft wird. Nach einer kurzen Phase, in der Product Manager selbst Engineers werden sollten, beobachtet Winters, dass Engineering die Umsetzungsmechanik wieder übernimmt. Die Debatte «PRD oder Prototyp» verdeckt dabei, dass das Eval zum Kernartefakt wird. Das Strategiedokument oder PRD kehrt zurück als Artefakt, aus dem Agents und Menschen lesen, was gebaut werden sollte. Das Eval sagt, ob es gelungen ist.¹

Damit schliesst sich der Kreis zum CTO vom Anfang. Seine Product Manager halten alles zusammen, weil der neue Engpass in seiner Organisation noch keinen Namen und keinen Prozess hat. Die Fülle macht den alten Kern des Jobs wichtiger, nicht unwichtiger: Wenn alles gebaut werden kann, wird die Entscheidung, was nicht gebaut wird, wertvoller. Winters' Schlusssatz: «AI made it easier for PMs to build. It did not make it easier to know what was worth building.»¹

Unsere Arbeit bei Teklens setzt genau an diesem Engpass an. Das Product Brain ist ein gemeinsames Gedächtnis für Menschen und KI-Agenten: Es hält Produktentscheide, Kundenfeedback, Jira und Code verbunden und aktuell, damit Prinzipien, Prioritäten und Prüfkriterien an einem Ort stehen, aus dem Agents und Menschen lesen. Du entscheidest. Teklens hält das Wissen zusammen. Wenn du wissen willst, wo der Engpass in eurem Team heute sitzt: Zeig uns in 30 Minuten, wie eure Produktarbeit abläuft, und wir sagen ehrlich, ob Teklens dort hilft.

Häufige Fragen

Empfehlungen

• Miss, wo Arbeit wartet, bevor du Werkzeuge kaufst. Review-Zeit, Design-Warteschlange, Freigaberunden und Abstimmungsmeetings pro Vorhaben, vier Wochen lang. Der grösste Wert ist euer Engpass. Behandle ihn, nicht das Coding.
• Verlange von jedem Vorhaben eine Wirkungsbehauptung. Welche Kennzahl bewegt es, und was passiert, wenn ihr es nicht baut? Ohne Antwort kein Ticket, egal wie billig die Umsetzung ist.
• Schreib die Absagen auf. Abgelehnte Ideen mit Begründung an einen Ort, den Menschen und Agents lesen. Das ist der Priorisierungsmechanismus, den die Knappheit früher gratis geliefert hat.
• Mach Prinzipien und Evals zu den Kernartefakten. Das PRD trägt Absicht und Prinzipien, das Eval die Prüfung. Beide vor dem Bau, beide für Agents und Menschen lesbar.
• Lege Vertrauensgrenzen für KI pro Workflow fest. Kontext, Synthese, Ausführung, Urteil, Prüfung: fünf Entscheidungen, aufgeschrieben. Ein Team, das sie kennt, darf schneller sein.
• Bewerte Product Manager nach Entscheiden, nicht nach demonstrierter Technik. Frag im Review, was die Person nicht gebaut hat und warum, und was das Gebaute verändert hat. Nicht, wie viele Prototypen, Skills oder Agents entstanden sind.

Einordnung & Grenzen

• Casey Winters' Befunde stammen aus Interviews mit Product Managern von Startups bis zu börsenkotierten Unternehmen, veröffentlicht in seinem Newsletter Casey Accidental. Stichprobengrösse und Methode sind nicht publiziert. Es ist eine Praktiker-Synthese, keine Studie; die Zitate sind seine Formulierungen, die Lesart in diesem Beitrag ist meine.
• Faros AI hat im Juli 2025 Telemetrie von über 10'000 Entwicklern in 1'255 Teams ausgewertet. Die Zusammenhänge sind korrelativ, der Bericht stammt vom Anbieter, und die längere Review-Zeit kann Aufschub oder tieferes Prüfen bedeuten; die Daten unterscheiden das nicht.
• DORA 2025 beruht auf fast 5'000 Befragten und zeigt Zusammenhänge, keine Ursachen. Atlassians Zahlen sind Selbstauskünfte von rund 3'500 Entwicklern und Managern; die Stundenwerte stammen aus dem Bericht und seiner Berichterstattung. Der Stack Overflow Survey 2025 hat über 49'000 selbst rekrutierte Teilnehmer; der Anteil, der KI vertraut, wird je nach Aggregation mit 29 bis 33 Prozent angegeben.
• METRs Studie ist ein randomisiertes Experiment mit kleiner Stichprobe in einem spezifischen Umfeld. GitClear ist ein Anbieter und analysiert eigene Kundendaten plus 25 grosse Open-Source-Projekte; die Duplikationswerte unterscheiden sich zwischen GitClears eigenen Seiten (achtfache Blöcke, Copy-Paste-Anteil von 8,3 auf 12,3 Prozent). Goldratts Theory of Constraints stammt aus der Fertigung; die Übertragung auf Produktorganisationen ist eine Analogie.
• Der AI Monitor 2026 beruht auf Selbstauskünften von 163 Befragten und sagt aus, dass private Werkzeuge genutzt werden, nicht, welche Daten dabei fliessen. Die 24 Discovery-Gespräche sind Gespräche von Teklens, keine Studie, und das CTO-Zitat ist daraus sinngemäss wiedergegeben. Die Teklens-Aussagen beschreiben Fähigkeiten des Produkts, keine gemessenen Kundenresultate.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Casey Winters, «How PM Work Is Changing in the AI Era», Casey Accidental ↗ – Interviews mit Product Managern von Startups bis zu börsenkotierten Unternehmen; die fünf neuen Engpässe, die drei Betriebsmodi und die Zitate in diesem Beitrag.
2. 2.Theory of Constraints Institute, «Five Focusing Steps», nach Eliyahu M. Goldratt, «The Goal» (1984) ↗ – Identifizieren, ausnutzen, unterordnen, erweitern, zurück zu Schritt eins.
3. 3.Faros AI, «The AI Productivity Paradox», Juli 2025 ↗ – Telemetrie von über 10'000 Entwicklern in 1'255 Teams: 21 Prozent mehr Aufgaben, 98 Prozent mehr Pull Requests, 91 Prozent längere Review-Zeit, keine Korrelation auf Firmenebene.
4. 4.Atlassian, «State of Developer Experience Report 2025», 2025 ↗ – Rund 3'500 Entwickler und Manager in sechs Ländern; Zeitgewinn durch KI und Zeitverlust durch organisatorische Reibung.
5. 5.DORA, «State of AI-assisted Software Development 2025», Google Cloud, September 2025 ↗ – Fast 5'000 Fachleute; KI als Verstärker; mehr Durchsatz, weniger Stabilität.
6. 6.METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10. Juli 2025 ↗ – Randomisiertes Experiment: 19 Prozent langsamer bei gefühlt höherem Tempo; kleine Stichprobe.
7. 7.GitClear, «AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones», 2025 ↗ – 211 Millionen geänderte Zeilen 2020 bis 2024; Duplikate steigen, Refactoring sinkt.
8. 8.Stack Overflow, «2025 Developer Survey: AI», 2025 ↗ – Über 49'000 Antworten; 84 Prozent nutzen oder planen KI-Werkzeuge, 46 Prozent misstrauen der Genauigkeit, 66 Prozent nennen «fast richtig» als grösste Frustration.
9. 9.Teklens mit ETH Zürich und Universität St. Gallen, «AI Monitor 2026», 2026 ↗ – 163 auswertbare Antworten zur Werkzeugnutzung; 6 von 10 nutzen zusätzlich private KI-Werkzeuge, 87 Prozent erhalten Werkzeuge vom Arbeitgeber.

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Activities aus dem Playbook

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