Zwei Geschichten wiederholen sich in Engineering-Diskussionen. Eine Anfrage, die mit ein paar SQL-Abfragen beantwortbar gewesen wäre, wird zu einem großen Mehrmonatsprojekt, weil niemand früh genug die richtige Frage gestellt hat. Ein Team gibt sechsstellige Beträge in Engineering-Zeit fur etwas aus, das niemand brauchte - und das Management verkauft es dann als wichtig, statt die Verschwendung einzugestehen.
Beide Geschichten haben dieselbe Struktur. Jemand hatte die Autoritat, Dinge zu bauen. Niemand hatte die Autoritat - oder den Anreiz -, aufzuhoren, die falschen Dinge zu bauen.
KI beruehrt dieses Problem nicht. Sie beschleunigt den Build-Zyklus bei richtigen wie falschen Dingen gleichermaßen. Eine Organisation, die systematisch Features baut, die niemand nutzt, wird das mit KI-unterstuetzter Entwicklung schneller tun. Die Outputrate steigt. Die Verschwendungsrate steigt proportional dazu.
Feature Factories scheitern nicht daran, dass sie langsam bauen. Sie scheitern, weil die Stoppmechanismen - User Research, der tatsachlich Entscheidungen blockiert, Product-Autoritat, die laufende Arbeit abbrechen kann, finanzielle Rechenschaftspflicht fur das, was ausgeliefert wird - fehlen oder bewusst schwach sind. Velocity war nie der Engpass.
Geschwindigkeit macht das schlimmer, nicht besser. Die Verschwendung potenziert sich schneller. Die Schulden kommen fruher. Die Lucke zwischen dem, was gebaut wurde, und dem, was gebraucht wurde, wird in Monaten statt in Jahren sichtbar.
Das ist nicht nichts. Aber schnellere Sichtbarkeit von Misserfolg ist ein Trostpreis, keine Losung.
Gedanken dazu? Findet mich auf Bluesky.