Essay von **Bill Staples**, CEO von **GitLab**, veröffentlicht am **24. August 2026** im Blog von about.gitlab.com: eine angekündigte Lesezeit von **31 Minuten**, rund **39.000 Zeichen**, dargestellt als Fortsetzung eines im Januar 2026 an den Verwaltungsrat gerichteten Memos, das im Mai teilweise unter dem Titel *GitLab Act 2* veröffentlicht wurde. Der Text versteht sich als Antwort auf das drei Tage zuvor veröffentlichte KI-native-SDLC-Playbook von **Anthropic**, dem er die Eingangszeile entlehnt – „Code is no longer the bottleneck“ –, um die Frage zu stellen, die ihn trägt: Was wird knapp, wenn Code im Überfluss vorhanden ist. (A) Die ökonomische Diagnose: Die nützliche Einheit sind nicht die Kosten pro Zeile, sondern die **Kosten pro akzeptierter Änderung**, die Generierung, Umgebung, Kontext, Verifikation, Review, Behebung und Governance zusammenfasst; KI lässt allein den Generierungsterm kollabieren, wodurch die übrigen proportional schwerer wiegen – eine Organisation, die zehnmal schneller generiert, „wird die Warteschlange lediglich verschieben“. (B) Die architektonische Antwort: vier Fähigkeiten – Agentenplattform, maschinenskalige Ausführung, dauerhafter Kontext, Governance – bilden eine Unternehmensschicht, die das Modell überdauert, „Das Modell sollte austauschbar sein. Der Agent sollte dem Kunden gehören.“ (1) Drei Modi koexistieren dauerhaft, vom menschengesteuerten Altsystem bis zur autonomen Entwicklung, gegen die Vorstellung einer einzigen Reifekurve. (2) Die CI/CD-Pipeline wird zu dem Ort, an dem die innere Schleife läuft, statt ein Gate am Ende der Kette zu sein. Die zitierten Zahlen stammen von Stripe, Spotify und Amplitude; GitLab liefert nur eine einzige, zur eigenen Quellcodeverwaltung. Der Korpus enthält bereits [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], die Quelle, auf die dieser Text antwortet, sowie [[sfeir-sdlc-pdlc-articulation-2026-07-22]] zur Verzahnung von SDLC/PDLC, die Staples sich zu eigen macht.
#Codeüberfluss#Kosten pro akzeptierter Änderung#Theory of Constraints
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
SFEIR-Analyse (Stimme eines Beratungsunternehmens, „die Lesart eines Ingenieurs“), die zwei zu oft vermischte Frameworks artikuliert: den **SDLC** (Software Development Life Cycle — *die Software korrekt und zuverlässig bauen*) und den **PDLC** (Product Development Life Cycle — *das richtige Produkt bauen und am Markt erfolgreich sein*). Zentrale These: Die beiden Zyklen sind keine Konkurrenten, sondern **verschachtelt** — der SDLC ist die Teilmenge des PDLC, **untergebracht in dessen Entwicklungsphase**; wenn ein Produktteam die „Build“-Phase erreicht, läuft darin ein vollständiger SDLC-Zyklus (Design → Build → Test → Review → Deployment) ab. Der SDLC ist standardisiert (**ISO/IEC/IEEE 12207**, Ausgaben 2017 und 2026), mit seiner Modell-Genealogie (Waterfall 1970, V-Modell, iterativ/spiralförmig, **Agile 2001**, **DevOps/DevSecOps ab 2009**) und seinen **DORA**-Metriken (Durchsatz, Stabilität, MTTR, Change-Failure-Rate). Der PDLC, als übergeordneter Zyklus, reicht von **Ideation/Discovery** bis zum **Marktrückzug** (nicht zu verwechseln mit dem marketingbezogenen **PLC** von Theodore Levitt, 1965, der eine *kommerzielle Kurve* beschreibt, keine *organisierte Arbeit*: „der PLC beobachtet eine Kurve; der PDLC organisiert Arbeit“). **Wendepunkt**: Der SDLC adressiert nativ **nur eines von vier Risiken** — über **Marty Cagans „Four Big Risks“**-Framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business Viability → PM) — eine Organisation, die im SDLC exzellent, aber gegenüber dem PDLC blind ist, produziert „Software, die niemand will“ — John Cutlers **„Feature Factory“** (Erfolg gemessen am Output, nicht am Outcome). **Warum KI alles verändert**: Generative KI **komprimiert den SDLC** (Google/JetBrains-Daten, Mai 2026: **~85 % der Entwickler** nutzen regelmäßig Coding-Agenten, **~41 % des neuen Codes** ist KI-generiert; die Implementierung schrumpft von Wochen auf Stunden), sodass sich der **Engpass stromaufwärts verlagert** — die Entscheidung, *was* gebaut werden soll (Marty Cagan, April 2026: „wenn die Kosten der Auslieferung einbrechen, verlagert sich der Engpass zur Discovery“). Konsequenzen: DORA 2025 (~5.000 Fachleute, 90 % KI-Adoption) zeigt eine **positive Korrelation mit dem Durchsatz, aber eine negative mit der Stabilität** (mehr unvalidierte Features bedeuten Instabilität und Nacharbeit); Andrew Ng (AI Startup School, Juli 2025) berichtet von Teams, die das **Verhältnis „1 PM auf 4 Ingenieure“ zu „2 PMs auf 1 Ingenieur“ umkehren**; und mit **Spec-driven Development** wird die Grenze zwischen PDLC/SDLC **durchlässig** (die Produktspezifikation wird direkt von Agenten ausführbar). **Was ein CIO mitnehmen sollte**: Ein augmentierter SDLC wird zum **Marktstandard, nicht zum Differenzierungsmerkmal** — die Schnittstelle zum Produkt muss instrumentiert, **ausführbare Spezifikationen** als Input verlangt, technische Metriken mit Outcome-Metriken abgeglichen und die Rolle des „Feature-Lieferanten“ **abgelehnt** werden. Für einen CPO: Die Verlagerung des Engpasses zur Discovery ist zugleich eine **Aufwertung** (Produkturteil wird wieder knapp) und eine **Handlungsaufforderung** (Discovery industrialisieren, um mit dem SDLC gleichzuziehen). SFEIRs eigenes Framework („Designing and building in the agentic era“ — **11-Phasen-Zyklus** + **Software Factory 10x**) wird als Antwort auf der Engineering-Seite positioniert, wobei die **Verknüpfung der beiden Zyklen** als nächster Hebel gilt. Fazit: „während Code zur Commodity wird, verschiebt sich die Marge hin zu Produkturteil und Governance.“