Hohe Änderungskosten fördern große und schwer prüfbare Batches
Behauptung
Wenn Review, Test und Deployment je Änderung erhebliche Fixkosten verursachen, ist es für Teams lokal rational, mehrere Arbeiten in einem großen Merge Request oder Rollout zu bündeln. Diese Bündelung spart scheinbar wiederholte Prozesskosten, kann aber Prüfbarkeit, Feedbackgeschwindigkeit, Fehlereingrenzung, Reversibilität und sicheren Rollout verschlechtern.
Agentisch beschleunigte Codeerzeugung löst diesen Zielkonflikt nicht. Bleiben die Fixkosten bestehen, kann zusätzlicher Output den Anreiz zu größeren Batches und den Druck auf Review, Test und Delivery sogar erhöhen.
Herkunft und Evidenzlage
Der Nutzer berichtet aus dem betrachteten Scrum-Prozess, dass große oder thematisch vermischte Merge Requests teils durch breite Änderungen über mehrere Services entstehen. Als wichtigere Ursache nennt er jedoch die Tendenz, Features nicht zu schneiden: Review, Test und Deployment sollen nur einmal durchlaufen werden, weil insbesondere Test und Rollout auch für kleine Änderungen aufwendig sind. Siehe die Beobachtung zum heutigen Review.
Die Beobachtung zu instabilen Feature-Testumgebungen konkretisiert einen dieser Kostenblöcke: Bereitstellung und Testausführung benötigen wiederholt menschliche Aufmerksamkeit und fördern zusätzliche parallele Arbeit.
Development Value Stream Mapping empfiehlt kleinere Batches, weniger Übergaben und Investitionen an der systemischen Engstelle. Die Studie gescheiterter agentischer Pull Requests verbindet größere Änderungen mit geringerem Integrationserfolg. Keine der Quellen misst jedoch den hier vermuteten lokalen Kausalpfad von hohen Review-, Test- und Deploymentkosten über Bündelungsentscheidungen zu schlechterer Reviewwirksamkeit. Die Behauptung bleibt daher unverified.
Konsequenz für Experimente
Eine Aufforderung, Features lediglich kleiner zu schneiden, ignoriert den ökonomischen Anreiz des heutigen Systems. Ein Experiment müsste mindestens eine relevante Fixkostenkomponente senken und prüfen, ob dadurch kleinere, thematisch kohärente und unabhängig verifizierbare Änderungen praktisch werden.
Mögliche Hebel sind schnellere und zuverlässigere Testläufe, wiederholbare Testdaten und Umgebungen, automatisierte Vertrags- und Migrationsprüfungen, von Releases entkoppelte Deployments, progressive Auslieferung, Observability und verlässlicher Rollback. Nicht jede breite Änderung lässt sich beliebig teilen; über mehrere Services reichende fachliche Invarianten und sichere Zwischenzustände bleiben Architekturfragen.
Als sinnvolle Batch-Grenze bietet sich deshalb nicht eine feste Zahl geänderter Zeilen an, sondern die kleinste fachlich beziehungsweise technisch kohärente Änderung, die unabhängig geprüft, ausgerollt, beobachtet und zurückgenommen werden kann.