KI-Tooling hat sich von Ende 2025 bis Anfang 2026 dramatisch verbessert. Agentische IDEs, CLI-Agents, Desktop-Assistenten — die Leistungsfähigkeit ist real. Aber eine Erkenntnis bestätigt sich immer wieder: Gute Tools reparieren keine Workflows, die für ein anderes soziotechnisches System gebaut wurden.
Starship Command Center, Steamship-Heizraum
Manche Tage fühlen sich an wie die Brücke eines Starships. Du orchestrierst mehrere KI-Agents über Repositories hinweg, delegierst Codegenerierung, lässt Modelle über Architektur nachdenken. Strategische Planung, Orchestrierung auf hoher Ebene, globale Intention — die Zukunft des Engineering, direkt auf deinem Bildschirm.
Dann öffnest du einen Pull Request.
Plötzlich stehst du im Heizraum. Manuelle Auflösung von Merge-Konflikten, die kein Modell „wegdenken“ kann. Tiefe Diffs, die den vollen Kontext erfordern — nicht nur was sich geändert hat, sondern warum. PR-Approvals, die menschliches Urteil über Grenzen, Risiken und Absichten verlangen. Randfälle, die von Hand behandelt werden, weil kein Agent die organisationspolitischen Hintergründe einer Namenskonvention versteht.
Der Kontrast ist nicht witzig — er ist diagnostisch. Der Starship-Teil läuft auf neuer Infrastruktur. Der Heizraum läuft auf Workflows, die entworfen wurden, bevor es diese Tools gab.
Der Workflow ist der Flaschenhals, nicht das Tool
Der Instinkt ist, weiter in bessere Tools zu investieren. Bessere Modelle, bessere Agents, bessere IDE-Integration. Aber die Reibung steckt nicht im Tool — sie steckt im Prozess, in den das Tool eingesteckt wird.
GitHubs Pull-Request-Modell wurde für Menschen entworfen, die Menschen reviewen. Es setzt einen Autor voraus, einen Reviewer, sequenziellen Kontext. Wenn ein KI-Agent 15 PRs parallel über 4 Repositories erzeugt, skaliert das Review-Modell nicht — nicht weil der Reviewer zu langsam ist, sondern weil der Workflow ein Tempo und ein Kontextmodell voraussetzt, das nicht mehr der Realität entspricht.
Merge-Konflikte sind dieselbe Geschichte. Sie sind keine Modelllimitation — sie sind ein Artefakt einer Branching-Strategie, die für menschliche Tippgeschwindigkeit entworfen wurde. Wenn Agents schneller Code erzeugen als Menschen ihn integrieren können, wird das Branching-Modell zum Flaschenhals.
Das ist es, was „soziotechnisches System“ in der Praxis bedeutet: Tools, Prozesse und menschliche Rollen haben sich gemeinsam entwickelt. Ändere eines ohne die anderen, und das System wehrt sich. Der Widerstand zeigt sich als Reibung — und diese Reibung ist der Punkt, an dem Workflows für KI-gestütztes Engineering neu zu denken die eigentliche Arbeit wird, nicht einfach bessere Tools zu adoptieren.
Modelle führen Scheiben aus. Menschen verantworten das Ganze.
KI-Agents sind exzellent darin, definierte Arbeitspakete auszuführen. Generiere diese Funktion. Refactore dieses Modul. Schreib diesen Test. Innerhalb eines begrenzten Kontexts sind sie schnell und oft gut genug.
Aber Integration — der Akt, Einzelteile zu einem kohärenten Ganzen zusammenzuführen — bleibt menschliche Verantwortung. Nicht weil Modelle nicht über Integration nachdenken können, sondern weil Integrationsentscheidungen organisatorisches Gewicht tragen. Welcher PR landet zuerst? Welcher Breaking Change ist diesen Sprint akzeptabel? Welcher Test-Failure ist ein echter Bug versus eine flaky Assertion?
Das sind keine technischen Fragen. Es sind Urteilsentscheidungen, die von Kontext abhängen, den kein Modell hat: Teamvereinbarungen, Release-Timelines, Kundenzusagen, politische Dynamiken. Der Mensch verantwortet Integration nicht, weil das Modell zu dumm ist. Der Mensch verantwortet Integration, weil Accountability nicht an ein stochastisches System delegiert werden kann.
Was Workflow-Design hier konkret bedeutet
„Fix den Workflow“ klingt offensichtlich. In der Praxis bedeutet es, Annahmen zu hinterfragen, die sich wie Naturgesetze anfühlen:
Braucht jede Änderung einen PR? Wenn ein KI-Agent einen einzeiligen Config-Fix macht, der durch CI läuft, reicht vielleicht ein Post-Merge-Review. Die PR-Zeremonie existiert, um menschliche Fehler in menschlich geschriebenem Code zu fangen. Das Fehlermodell hat sich geändert — die Zeremonie sollte es auch.
Muss Branching so komplex sein? Wenn Agents schneller Arbeit produzieren als sie gemerged werden kann, ist Trunk-Based Development mit Feature Flags vielleicht weniger Reibung als Gitflow mit langlebigen Branches. Das Branching-Modell war für menschliche Koordinationsgeschwindigkeit optimiert.
Bedeutet Code Review, Diffs zu lesen? Wenn der Autor eine KI ist, verschiebt sich die Aufgabe des Reviewers von „ist dieser Code korrekt“ zu „dient diese Änderung der Intention.“ Das ist eine andere Kompetenz, und sie braucht anderes Tooling — Zusammenfassungen, Impact-Analysen, Verhaltens-Diffs statt Zeile-für-Zeile-Inspektion.
Nichts davon ist radikal. Es sind Workflow-Anpassungen, die der Tooling-Shift verlangt, aber die organisatorische Trägheit verhindert. Die Tools haben sich bewegt. Die Prozesse nicht. Die Lücke ist da, wo das Kohleschippen stattfindet.
Tooling zählt. Workflow-Design zählt mehr.
Die Versuchung ist, weiter in bessere Tools zu investieren und darauf zu hoffen, dass der Workflow schon nachzieht. Wird er nicht. Workflows sind soziale Verträge mit technischer Implementierung. Sie ändern sich durch bewusstes Redesign, nicht durch Osmose von besserem Tooling.
Das Starship Command Center ist real. Der Heizraum auch. Der Unterschied zwischen Organisationen, die Wert aus KI-Tooling ziehen, und solchen, die nur schnelleres Chaos bekommen, liegt darin, ob sie den Workflow redesignen — oder nur die Tools innerhalb des alten aufrüsten.
