> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w21-the-inflection-point-of-software-engineering.md).

# W21-Der Wendepunkt im Software Engineering

Vergangene Woche sah ich Adam Benders Vortrag auf der Google I/O 2026, [„Software engineering at the tipping point“](https://io.google/2026/explore/workshop-2). Er untersucht, wie KI Software Engineering verändert und an welche Grenzen das bestehende Softwareökosystem stößt, wenn Code zehnmal oder noch schneller entsteht.

Der Vortrag erinnerte mich an [„Software Engineering at Google“](https://abseil.io/resources/swe-book/html/toc.html), das Flamingobuch. Es fasst mehr als zwanzig Jahre Google-Praxis zusammen: Monorepo, Trunk-based Development, große Änderungen, Reviews, Tests und Engineering-Kultur. Früher las ich das vor allem als bewährte Praxis eines Großunternehmens. Heute sehe ich, dass es nicht um einzelne Werkzeuge geht, sondern darum, wie Software über Zeit und zunehmende Größe hinweg weiterentwickelt werden kann.

Hier liegt der wichtigste Unterschied zwischen Programmieren und Software Engineering. Programmieren löst das unmittelbare Problem durch Code. Software Engineering fragt, ob ein System nach Jahren und mit Hunderten Beteiligten noch verstanden, verändert, geprüft und sicher weiterentwickelt werden kann. Geschriebener Code ist nur der Anfang. Schwierig ist, ihn dauerhaft in einem kontrollierbaren Ökosystem zu halten.

Viele Google-Praktiken schaffen im Kern ein gemeinsames Schicksal. Das Monorepo lässt das ganze Unternehmen dieselben Codebestände teilen. Trunk-based Development hält alle fortlaufend auf derselben Version. Große automatisierte Änderungen reparieren grundlegende Bibliotheken und Sicherheitsprobleme. Reviews und schuldzuweisungsfreie Retrospektiven verwandeln individuelle Erfahrung in organisatorische Fähigkeit. Dahinter steht kein bloßer Werkzeugkult, sondern ein soziotechnisches System. Werkzeuge lösen Größenprobleme, Engineering-Kultur löst Zusammenarbeit.

Besonders interessant ist, dass Bender KI innerhalb dieses Ökosystems betrachtet, statt nur zu fragen, ob sie Code schreiben kann. Die alten Engineering-Probleme verschwinden nicht, sie werden größer. Ich teile DORAs Aussage, [KI sei ein Verstärker](https://dora.dev/capabilities/user-centric-focus/). Sie verstärkt das Ausmaß, bestimmt aber nicht die Richtung. In einem Team mit gesunden Tests, guter Architektur und tragfähiger Zusammenarbeit verstärkt sie Effizienz. Sind diese Grundlagen schwach, verstärkt sie Unordnung.

Früher schrieb jemand täglich einige Dutzend oder Hundert Zeilen. Viele Probleme wurden langsam sichtbar. Wenn künftig mehrere Agenten gleichzeitig Code ändern und die Produktion um das Zehn- oder Hundertfache wächst, erreicht das Engineering-System seine Grenzen schneller. Billiger Code lässt minderwertigen Code leichter anwachsen. Aus Codevermögen werden rasch Codeschulden. Build- und Testsysteme stehen stärker unter Druck. Eine bislang ausführbare Testsuite kann durch mehr Code und Abhängigkeiten unbezahlbar werden. Reviews stoßen ebenfalls an Durchsatzgrenzen. Wenn menschliche Experten nur noch große Mengen KI-Änderungen abarbeiten, geraten sie leicht unter Druck, Standards zu senken.

Schlimmer noch: Ohne globale Regeln könnten Agenten gegenseitig ihre Änderungen überschreiben. Einer refaktoriert in eine Richtung, ein anderer macht es rückgängig. So entsteht ein Bearbeitungskrieg zwischen Agenten. Das klingt scherzhaft, ist bei schnellerer und billigerer Codeproduktion aber durchaus möglich. Fehlen klare Abstraktionsgrenzen und Rückmeldungsmechanismen, wird auch Chaos schneller automatisiert.

Software Engineering mit KI darf sich deshalb nicht darauf beschränken, mehr Code erzeugen zu lassen. Knapp bleiben Systemgrenzen, Prüffähigkeit und architektonisches Urteil. Wir müssen vom einzelnen Baum zum ganzen Wald übergehen. Früher betrachteten wir Funktionen, Module und einzelne Reviews. Künftig zählen stärker die Grenzen, Rückkopplungen und Entwicklungsordnung des gesamten Softwareökosystems.

Einige Richtungen sollte das Team vorbereiten.

Erstens werden Tokens und Rechenleistung für Tests zu eigenen Engineering-Ressourcen. Sie sind kein unbegrenzter Hintergrunddienst.

Zweitens muss die Prüfstrategie intelligenter werden. Vollständige Testläufe und manuelle Reviews allein reichen nicht.

Drittens brauchen Systeme stärkere Isolation, damit experimenteller KI-Code zentrale Abläufe nicht leicht beeinträchtigt.

Viertens müssen Menschen ihr Systemverständnis zurückgewinnen. KIs größter Wert besteht nicht nur im Codeschreiben, sondern darin, komplexe Systeme verständlich zu machen, dynamische Architekturgrafiken zu erzeugen, Abhängigkeiten durchzuspielen und Folgen zweiter Ordnung zu analysieren.

Das liegt nahe an unserer Diskussion über KI-bereites Engineering. Es bedeutet nicht, einige Werkzeuge anzuschließen oder zusätzliche Prompts zu schreiben. Das bestehende System muss eine Produktionsweise mit höherer Geschwindigkeit, mehr Parallelität und mehr Unsicherheit tragen können. Infrastruktur, Coderegeln, Tests, Dokumentation, Architekturdarstellung und Reviews wirkten früher eher langsam. In der KI-Ära werden sie wichtiger.

Die Prinzipien des Software Engineering bleiben gleich. Produktivität und Systemdruck verändern sich. Je schneller Code entsteht, desto stärker müssen wir zu den Grundlagen zurück. Der entscheidende Wettbewerbsvorteil eines Teams könnte künftig nicht darin liegen, mit KI mehr Code zu schreiben, sondern ein Ökosystem zu entwerfen, in dem KI sicher mitarbeitet, kontinuierlich geprüft wird und die Entwicklung kontrollierbar bleibt.