19.3.2026
Wenn sich der Engpass verschiebt
Deutsch · English
Softwareentwicklung verändert gerade ihre grundlegende Natur.
Eine hilfreiche Perspektive darauf kommt aus der Theory of Constraints, entwickelt von Eliyahu M. Goldratt.
Theory of Constraints im Kern
Die Grundidee ist überraschend simpel: In jedem System gibt es meist eine dominante Engstelle, die den Durchsatz bestimmt.
Verbessert man diesen Engpass, verbessert sich das gesamte System. Und wenn er verschwindet, taucht er an anderer Stelle wieder auf. Fortschritt besteht deshalb oft nicht darin, Systeme einfach schneller zu machen. Fortschritt bedeutet, den Engpass zu verschieben.
Goldratt formulierte daraus einen iterativen Prozess:
- Constraint identifizieren
- Constraint maximal ausnutzen
- Alles andere darauf ausrichten
- Constraint erweitern
- Zurück zu Schritt 1 (weil sich der Engpass verschiebt)
Jede ernsthafte Verbesserung eines Systems besteht letztlich darin, diesen Engpass bewusst zu verlagern. In Wissensarbeit kann dieser schnell wechseln oder fragmentieren.
Interessanterweise hilft diese Perspektive auch, eine der einflussreichsten Ideen der Softwareentwicklung neu zu verstehen.
XP als Engpass-Verschiebung
Als Extreme Programming Ende der 90er entstand, lag das Radikale nicht in einzelnen Praktiken wie Pair Programming, Test-Driven Development oder Simple Design.
Das Radikale war das Systemdenken. XP funktionierte, weil sich seine Praktiken gegenseitig verstärkten.
XP war kein Werkzeugkasten. Es war ein zusammenhängendes System von Praktiken, das darauf ausgelegt war, den Durchsatz eines Teams unter Unsicherheit zu maximieren.
Im Kern war XP ein Versuch, die dominanten Engpässe in der Softwareentwicklung systematisch zu stabilisieren. Das Ergebnis war ein Entwicklungsprozess, der Änderungen dauerhaft möglich halten sollte.
Der Engpass verschiebt sich erneut
Mit generativer KI verändert sich diese Landschaft erneut. Und radikal.
Große Sprachmodelle reduzieren viele Aufgaben, die lange Zeit einen erheblichen Teil der Entwicklungsarbeit ausmachten. Modelle können Code generieren, Varianten vorschlagen und Lösungsräume erkunden.
Coding Agents gehen noch einen Schritt weiter. Sie können selbstständig ganze Entwicklungszyklen automatisieren.
Damit verändert sich nicht nur die Geschwindigkeit. Es verändert sich die Struktur des gesamten Systems.
Die technische Umsetzung ist nicht mehr automatisch der limitierende Faktor. Der Engpass liegt zunehmend an anderen Stellen:
- Problemformulierung – Was bauen wir eigentlich?
- Designentscheidungen – Welche Struktur trägt langfristig?
- Evaluation – Ist eine generierte Lösung wirklich gut?
- Verständnis – Kann das Team den Code noch erklären?
Der limitierende Faktor wird zunehmend kognitiv und koordinativ.
Was das für XP bedeutet
XP bewegt sich vom Schwerpunkt Coding hin zur kollektiven Kognition.
Wenn sich der Engpass verschiebt, verschiebt sich auch die Funktion der Praktiken.
Einige werden zentraler.
Einige verändern ihre Rolle.
Und einige entstehen erst jetzt.
Der neue Engpass: menschliches Verständnis
Pair Programming
Cognitive Triad
Pair Programming verbindet zwei Perspektiven: „Driver“ schreibt Code, „Navigator“ behält Struktur und Design im Blick.
Mit großen Sprachmodellen entstehen neue spannende Konstellationen.
Modelle sind starke Sparringspartner. Sie können Code vorschlagen, Varianten diskutieren, Lösungsräume explorieren.
Aber sie verstärken auch Confirmation Bias. Kritische Reflexion kann abnehmen. Falsche Annahmen skalieren schneller als je zuvor.
Mit Coding Agents verändert sich diese Dynamik weiter. Werkzeuge können selbstständig Code schreiben, Tests ausführen und Änderungen als Pull Requests zur Integration vorschlagen.
In der Extremform entwickelt sich Pair Programming zu einer kognitiven Triade: Customer — Developer — Model.
Agenten machen die engst mögliche Kopplung plötzlich operational.
Der Kunde bringt Problemverständnis. Der Entwickler verantwortet Systemstruktur und Kontext. Das Modell übernimmt Umsetzung und Exploration.
Der Entwickler wird weniger „Driver“ und stärker „Navigator“ eines Systems, das ganze Lösungsräume ausarbeitet und in großen Strukturen materialisiert.
Die Spannung zwischen diesen drei Rollen erhöht die kollektive Intelligenz – genau das ursprüngliche Ziel von Pair Programming.
Collective Code Ownership
Radical Code Transparency
Collective Ownership bedeutet: Jeder darf alles ändern.
Mit Coding Agents wird diese Idee radikalisiert.
Ein Agent mit Projektzugriff kann alles verändern, aber nur innerhalb der System-Constraints.
Code entsteht zunehmend in orchestrierten Prozessen. Collective Ownership mit einer Maschine.
Autorschaft verliert an Bedeutung.
Entscheidend wird stattdessen kollektives Verständnis. Mit dem Ziel: Maximale Reduktion von Black-Box-Risiko.
Collective Ownership wird zu radikaler Code-Transparenz.
Wenn Code jederzeit durch Menschen oder Agenten verändert werden kann, muss seine Struktur und Motivation für alle nachvollziehbar bleiben.
Im Limit verliert Code seinen Status als langlebiges Asset. In vielen Fällen ist es effizienter, Code neu zu erzeugen, als bestehenden Code zu ändern.
Damit wird Code austauschbar. Zwei Implementierungen sind gleichwertig, solange sie im selben Kontext entstehen und dieselben Tests erfüllen.
Das System besitzt keinen Code mehr – es besitzt stattdessen die Fähigkeit, ihn jederzeit neu zu erzeugen.
Kontrolle über ein driftendes System, das Code erzeugt
Test-Driven Development
Behavior-First Engineering
Tests waren schon immer Spezifikation.
Mit generativer Programmierung werden sie zur Steuerschnittstelle.
Coding Agents können Code erzeugen, verändern und neu strukturieren. Aber sie brauchen klare Grenzen für akzeptables, erwartetes Verhalten.
Test-First erfüllt genau diese Funktion. Tests definieren das gewünschte Verhalten vor der Implementierung und werden somit zum Vertrag zwischen Mensch und Maschine.
In einer agentischen Entwicklungsumgebung werden Tests zur Programmiersprache, mit der wir Coding Agents steuern.
Der Agent kann Tests lesen, schreiben, ausführen und seine Implementierung so lange anpassen, bis Tests grün sind. Die klassische TDD-Schleife, nur dass ein Teil davon automatisiert wird.
Damit verschiebt sich die Hierarchie: Tests werden zum Primärartefakt. Code wird zur Ableitung.
TDD wird somit noch zentraler, zu verhaltensorientierter Entwicklung.
Es stabilisiert ein probabilistisches System gegen Drift – also gegen das schleichende Auseinanderlaufen von Verhalten unter scheinbar gleichen Bedingungen.
Continuous Integration
Continuous System Verification
Continuous Integration sorgt dafür, dass Integrationsprobleme früh sichtbar werden.
Mit generativer KI steigt jedoch die Änderungsrate erheblich.
CI wird zum Immunsystem.
Neben klassischen Tests prüfen Pipelines zunehmend auch, ob grundlegende Systemeigenschaften stabil bleiben.
In einem System, das durch generative Modelle verändert wird, entsteht eine neue Gefahr: probabilistische Drift. Kleine, lokal korrekte Änderungen können das System schrittweise von seiner ursprünglichen Struktur und Semantik wegbewegen.
CI wird zum Mechanismus, diese Drift sichtbar und kontrollierbar zu machen.
Da Änderungen schneller und in größeren Einheiten entstehen, wächst auch ihr potenzieller Impact. Den Blastradius zu begrenzen wird zentral.
XP kannte schon immer Acceptance Tests als Schnittstelle zum Kunden. In einer agentischen Entwicklungsumgebung entsteht eine ähnliche Struktur innerhalb des Teams:
Continuous Integration wird zum Akzeptanztest für den generierten Code, zu kontinuierlicher Systemverifikation.
Das Entwicklungsteam definiert die Kriterien, die ein System erfüllen muss, bevor es als verstanden und integrierbar gilt.
Designstrategie für eine Welt extrem billigen Codes
Refactoring
Continuous Code Assimilation
Refactoring hält Software soft – langfristig.
Im Zeitalter generativen Codes ist Refactoring nicht mehr Aufräumen. Es ist Entropiekontrolle.
Modelle erzeugen funktionierenden Code, doch selten ein kohärentes Design. Unterschiedliche Patterns, redundante Abstraktionen und inkonsistente Strukturen entstehen parallel.
Refactoring wird zum kontinuierlichen Assimilationsprozess.
Generierter Code wird nicht einfach übernommen, sondern aktiv in die Architektur integriert.
Erst durch Refactoring übersetzt das Team maschinell erzeugtes Rohmaterial in sein Systemverständnis. Das Refactoring hilft, generierten Code zu verdauen.
Coding Agents verstärken diese Dynamik weiter. Große strukturelle Änderungen, die einst Tage kosteten, lassen sich mit agentischer Unterstützung in Minuten durchziehen.
Refactoring wird von einer knappen Ressource zu einer billigen Operation und fast kontinuierlichen Aktivität.
Damit solche Systeme stabil bleiben, gewinnen klare Kontextgrenzen an Bedeutung. Konzepte wie Core Models und Bounded Contexts helfen, Systeme in Einheiten zu strukturieren, die sich unabhängig verstehen, generieren und neu zusammensetzen lassen. Sie schaffen Inseln, in denen generativer Code beherrschbar bleibt – mit begrenztem Blastradius und einer Komplexität, die sowohl für Menschen als auch für Modelle im Kontext bleibt.
Gleichzeitig entsteht eine neue Gefahr: Wenn Veränderung zu billig wird, steigt die Versuchung, Struktur permanent zu verschieben, ohne sie wirklich durchdrungen zu haben. Mit generiertem Code steigt die Änderungsrate und strukturelle Konsistenz wird fragiler.
Design wird insgesamt weniger vorausschauend und stärker evolutionär. XP hat das immer behauptet. Agentic Coding macht es realistisch.
Simple Design
Radical Simplicity
Simple Design bedeutet: nur so viel Design wie nötig.
Im LLM-Zeitalter wird diese Praxis noch wichtiger.
Generative Systeme haben eine natürliche Tendenz zur Überkomplexität.
Sie erzeugen zusätzliche Abstraktionen, defensive Strukturen und generische Architekturen.
Generierter Code unterscheidet sich grundlegend: Produzierter Code entsteht nicht mehr 100% aus unserer Intention heraus, sondern als Ergebnis eines probabilistischen Prozesses.
Die Aufgabe des Teams verschiebt sich.
Es geht weniger darum, Lösungen zu erfinden. Und mehr darum, Komplexität konsequent zu entfernen.
Simple Design wird zu einer Praxis der radikalen Einfachheit – einem Filter gegen generative Komplexität und somit zu einer der wichtigsten Fähigkeiten überhaupt.
System Metaphor
Shared Mental Model
Die System Metaphor war selbst eine Form eines generativen Modells.
Sie adressierte ein zentrales Problem: Wie schafft man ein gemeinsames Verständnis mit ausreichend Bandbreite, um ein wachsendes System zu tragen.
Diese Funktion wird im Zeitalter generierten Codes wieder wichtig.
LLM-generierter Code kann lokal sinnvoll erscheinen, ohne global kohärent zu sein. Unterschiedliche Teile des Systems folgen dann implizit verschiedenen Architekturideen.
Teams brauchen deshalb wieder stärker ein gemeinsames mentales Modell ihres Systems. Erzählbare Strukturen wie Metaphern, Domänenmodelle und narrative Beschreibungen.
Eine gute Systemmetapher wirkt wie ein kognitiver Kompressionsmechanismus: Sie macht Komplexität erzählbar. Und somit überhaupt erst kollektiv beherrschbar.
In einer Welt mit Coding Agents wird sie zur generativen Architektur.
Coding Standards
Machine-Readable Design
Coding Standards sind nicht mehr nur soziale Konventionen.
Mit KI-generiertem Code verändert sich diese Rolle deutlich.
Code entsteht heute schneller und in größerer Menge als je zuvor.
Dabei entstehen neben Implementierungen auch zahlreiche Zwischenartefakte. Teams müssen Systeme strukturstabil halten, obwohl ständig neues Material entsteht.
Damit wächst eine neue Gefahr: strukturelle Drift.
Coding Standards werden zu einer Form maschinell durchsetzbarer Design-Disziplin, die verhindert, dass ein System aus ständig neu erzeugtem Code seine Kohärenz verliert.
Sie sind das System Prompt des Repositories – Steuersignale für generativen Code.
Äußerer Wertschöpfungsloop: Earn or Learn
On-Site Customer
Customer-Driven Discovery
Der On-Site Customer sollte im ursprünglichen XP den Anforderungsdialog direkt ins Team bringen.
Im Zeitalter generativer KI verschiebt sich diese Rolle am deutlichsten.
Der Kunde kann heute selbst beginnen, den Problem- und Lösungsraum zu explorieren. Mit Hilfe generativer Modelle lassen sich Szenarien durchspielen, Interaktionen testen und mögliche Lösungen skizzieren.
Auch Acceptance Tests verändern sich dadurch. Was früher häufig ein Engpass war, kann nun test-first vom Kunden vorbereitet werden. Mit KI-Unterstützung lassen sich Beispiele, Szenarien und Grenzfälle schnell formulieren und iterieren.
Kunde (oder Product Person) wird zum Mit-Entdecker im Suchprozess nach der richtigen Lösung. Die alte XP-Idee der Driving Metaphor bekommt neues Momentum.
Doch in Kombination mit Coding Agents entsteht eine noch tiefere Veränderung. Wenn Modelle aktiv an Exploration und Implementierung teilnehmen, verschiebt sich die grundlegende Einheit der Zusammenarbeit.
Das klassische XP-Paar erweitert sich zur kleinsten funktionsfähigen Einheit moderner Produktentwicklung: Customer — Developer — Model.
Was im Pair Programming als kognitive Triade sichtbar wird, wird hier zur Struktur des gesamten Teams.
Der Kunde bringt Problemverständnis und Hypothesen ein. Der Entwickler verantwortet Systemstruktur, Kontext und Integration. Das Modell ermöglicht schnelle Exploration und Umsetzung.
Der On-Site Customer entwickelt sich weiter zur kundengeleiteten Exploration innerhalb einer kognitiven Triade.
Die Idee des Whole Team wird radikalisiert. Das Team wird zu einem gekoppelten System aus Menschen und generativen Modellen, das gemeinsam den Problem- und Lösungsraum durchsucht.
On-Site Customer wird damit zu etwas, das XP immer angedeutet hat, aber selten vollständig erreicht wurde: Der Kunde wird zum Ko-Designer eines sozio-technischen Systems, das Denken und Implementieren eng miteinander verschränkt.
Planning Game
Continuous Discovery Loop
Das Planning Game synchronisiert Entwicklung und Business.
Mit LLMs verschiebt sich der Engpass fundamental.
Implementierung wird billig. Exploration wird skalierbar. Teams können plötzlich mehr Lösungen erzeugen, als sie sinnvoll bewerten können.
Das eigentliche Risiko ist zu frühes Bauen.
Das Planning Game entwickelt sich zu einem kontinuierlichen Erkenntniszyklus aus Hypothesenbildung, Exploration und Lernen.
Coding Agents verstärken diese Dynamik weiter. Sie können Experimente vorbereiten, Tests ausführen und Ergebnisse analysieren.
Das Planning Game wird teilweise automatisiert. Entwickler planen weniger Arbeit, als sie Erkenntnisgewinn orchestrieren.
Wert entsteht nicht mehr im Schreiben von Code, sondern im Verwerfen von Möglichkeiten.
Wenn Optionen explodieren, wird Selektion zum Engpass. Einschränkungen durchzusetzen wird zu einem zentralen Skill.
Nein wird wichtiger als Ja.
Small Releases
Micro-Experiments
Small Releases reduzieren Risiko, indem Software in kleinen Schritten ausgeliefert wird.
Mit generativer KI wird Codeproduktion extrem billig. Features lassen sich schneller erzeugen als je zuvor.
Das neue Risiko ist Feature-Überproduktion.
Small Releases werden zu kleinen Experimenten. Jede Änderung testet eine Hypothese über Nutzerverhalten, Systemwirkung, Produktwert.
Ein Release ist dann vor allem eines: ein Lernschritt.
Wenn Experimente billig genug werden, ersetzen sie zunehmend Diskussionen. Ein Release kann schneller Klarheit schaffen als ein Meeting.
XP hatte diese Idee immer implizit. Generative Systeme treiben sie nun auf die Spitze.
Nachhaltigkeit als Systeminvariante
Sustainable Pace
Sustainable Cognitive Load
XP zielte immer auf nachhaltiges Arbeitstempo.
Mit KI entsteht jedoch eine neue Versuchung: Geschwindigkeit künstlich zu erhöhen.
Der eigentliche Engpass bleibt jedoch menschliche Urteilskraft.
KI verschiebt den Engpass in den menschlichen Kopf.
Wenn Iterationsgeschwindigkeit steigt, wachsen auch Entscheidungsdruck, Kontextwechsel, mentale Belastung.
Sustainable Pace entwickelt sich zu nachhaltiger mentaler Belastung.
XP schützt damit seine wichtigste Ressource: menschliche Aufmerksamkeit.
Neue Muster
Neben diesen Transformationen entstehen auch neue Muster, die im ursprünglichen XP noch nicht existierten.
Ein besonders interessantes ist Disposable Code.
Wenn LLMs Prototypen extrem schnell erzeugen können, wird Code zu etwas, das man explorativ nutzt und anschließend verwirft. Die gute alte Spike Solution wird zur Kerndisziplin.
Daraus ergibt sich ein weiteres Muster: Reconstructive Programming.
Ein generiertes System dient zunächst als Exploration. Danach wird die eigentliche Implementierung bewusst neu aufgebaut – testgetrieben und aus Verständnis heraus.
Ein dritter neuer Aspekt ist Exploration at Scale.
LLMs erlauben es, viele Varianten eines Lösungsraums zu untersuchen. Die Rolle des Menschen verschiebt sich dadurch von der Produktion zur Auswahl und Entscheidung.
XP-Shift durch generative KI
XP verschiebt sich systematisch entlang des neuen Engpasses – von Codeproduktion hin zu Verständnis, Entscheidung, Systemkohärenz.
| XP-Shift | Stabilisierter Engpass |
|---|---|
| kognitive Triade | Qualität von Entscheidungen |
| radikale Code-Transparenz | kollektives Verständnis des Codes |
| verhaltensorientierte Entwicklung | stabil definiertes Systemverhalten |
| kontinuierliche Systemverifikation | Systemintegrität |
| kontinuierlicher Assimilationsprozess | strukturelle Kohärenz des Systems |
| radikale Einfachheit | kognitive Komplexität |
| gemeinsames mentales Modell | kollektives Architekturverständnis |
| maschinell durchsetzbares Design | strukturelle Konsistenz generierten Codes |
| kundengeleitete Exploration | Problem-Solution-Fit |
| kontinuierlicher Erkenntniszyklus | Problemverständnis und Problemwahl |
| kleine Experimente | Lernen aus Nutzerfeedback |
| nachhaltige mentale Belastung | menschliche Urteilskraft |
Warum XP gerade jetzt relevant ist
XP zielte nie primär auf Geschwindigkeit, sondern auf Stabilität unter Unsicherheit. Genau diese Eigenschaft wird im Umgang mit generativen Systemen zentral.
Wir programmieren nicht mehr primär ein System. Wir programmieren die Bedingungen, unter denen ein System entsteht. Generativer Code macht einige der radikalsten XP-Ideen wieder notwendig.
XP war immer eine Methode zur Maximierung der Lernrate. Ein System aus engen Lernschleifen und bewusst verschobenen Engpässen.
Im KI-Zusammenhang tritt dieser ursprüngliche Kern deutlicher hervor. Generative KI erhöht die Geschwindigkeit der Exploration. Sie vergrößert den Lösungsraum dramatisch. XP sorgt dafür, dass Teams in diesem Raum nicht die Orientierung verlieren.
Modelle und Coding Agents erzeugen enorme Mengen Code. Doch genau diese Produktionsmaximierung erzeugt neue Risiken. Große Mengen Code können so schnell degenerieren wie sie generiert werden. Ohne starke Feedbackmechanismen wächst Komplexität unkontrolliert über unsere Köpfe hinweg.
Die neuen Engpässe
Der Engpass verschiebt sich dadurch. Während Maschinen immer schneller Code erzeugen, stabilisieren die XP-Praktiken die Ressourcen, die sich nicht einfach automatisieren lassen:
- Verstehen
- Entscheiden
- gemeinsame mentale Modelle
- kohärente Systemstruktur
Mit anderen Worten: In einer Welt, in der Code billig wird, werden Verständnis und Urteilskraft zur knappsten Ressource.
Genau hier greifen die klassischen XP-Praktiken.
Der eigentliche XP-Shift
Extreme Programming wollte ursprünglich eine Sache erreichen: Änderungen jederzeit billig halten.
Wenn Codeproduktion billig wird, verschiebt sich der Preis. Dann wird Verständnis teuer.
Die neue Mission lautet deshalb:
Die Kosten des Verstehens flach halten.
Die Produktion von Code ist nicht mehr der Engpass.
Die Produktion von Bedeutung ist es.
Wenn dir dieser Text etwas gebracht hat, kannst du meine Arbeit mit einer Spende unterstützen. Ich entwickle diese Ideen weiter und möchte daraus eine kleine Serie machen.
