Softwareleute haben über zwanzig Jahre hinweg eine leise radikale Art entwickelt, miteinander zu arbeiten. Sie nennen es Versionskontrolle. Von innen wirkt es banal: Commits, Branches, Pull Requests, Merges. Von außen sollte es außergewöhnlich wirken, weil keine andere Disziplin die Probleme gelöst hat, die diese löst.

Mehrere Personen, die zur gleichen Zeit am gleichen Artefakt arbeiten, ohne einander zu überschreiben. Jede Änderung zugeordnet, datiert, reversibel. Meinungsverschiedenheiten schriftlich geklärt, öffentlich, mit der vorgeschlagenen Änderung sichtbar neben der Kritik. Eine Historie, durch die man rückwärts gehen kann, um zu fragen: wann wurde diese Entscheidung getroffen, und warum.

Die meisten Organisationen arbeiten ohne all das. Strategie wohnt in einer Folie, die irgendwer letzten Dienstag aktualisiert hat. Prozesse wohnen in einer Confluence-Seite, die seit dem Onboarding niemand mehr gelesen hat. Die “aktuelle Version” des Betriebsplans ist das, was die ranghöchste Person in der letzten Sitzung gesagt hat. Es gibt kein Diff. Es gibt keine Historie. Es gibt keinen Merge.

Das ist kein Werkzeug-Problem. Es ist ein Modell-Problem.

Der Commit. Ein Commit ist eine kleine, benannte, zugeordnete Änderung an einem gemeinsamen Artefakt. Die meisten Organisationen haben dafür kein Pendant. Entscheidungen passieren im Gespräch und verschwinden im Chat. Eine Woche später weiß niemand mehr, ob entschieden, vorgeschlagen oder nur in den Raum gestellt wurde. Der Commit lässt die Änderung als Objekt existieren, etwas, auf das man zeigen, das man referenzieren und auf das man zurückkommen kann.

Der Branch. Ein Branch ist die Erlaubnis, etwas zu probieren, ohne den Hauptbetrieb zu destabilisieren. Organisationen sind darin meistens schlecht. Entweder das Experiment kontaminiert den Betrieb, oder der Betrieb erstickt das Experiment. Branching ist das ausdrückliche Eingeständnis, dass diese Arbeit vorläufig ist, und hier wird die Linie zwischen vorläufig und festgeschrieben gezogen.

Der Pull Request. Der unterschätzte Schritt. Ein Pull Request ist eine vorgeschlagene Änderung, sichtbar für alle Betroffenen, offen für Kritik, und erst nach Review zusammengeführt. Er trennt eine Idee haben von das System verändern. Die meisten Organisationen werfen die beiden in einen Topf: die lauteste Person im Raum pusht funktional direkt auf Main. Pull Requests bremsen die vorschlagende Person bewusst aus, und diese Langsamkeit ist das Feature.

Der Merge. Und dann: Integration. Die Änderung wird in den Hauptzweig aufgenommen, die Historie hält fest, wer was und warum gemacht hat, und das System läuft weiter. Das organisatorische Pendant, der Moment in dem eine Entscheidung zum neuen Standard wird, ist fast immer unsichtbar. Hinterher streiten die Leute darüber, ob das jemals stattgefunden hat.

Der Grund, warum das jetzt akut wird, ist die KI. KI macht die Abwesenheit von Versionskontrolle schmerzhaft sichtbar. Wenn jede Person im Team Strategiepapiere, Marktanalysen und Prozessentwürfe zu fast null Kosten erzeugen kann, verschiebt sich der Flaschenhals von Produktion zu Integration. Welche Version ist aktuell? Wer hat was geändert? Auf welcher Grundlage? Gegen welche Alternative?

Ohne ein Modell dafür beschleunigt KI die Organisation nicht. Sie überschwemmt sie.

Die Softwarebranche ist nicht schneller geworden, weil sie härter gearbeitet hat. Sie ist schneller geworden, weil sie den Merge erfunden hat. Die meisten Organisationen leben noch vor dem ersten Merge. Genau dort landen die meisten KI-Rollouts und wundern sich dann, warum nichts wächst.