Google Chef-Ingenieur: Zwei Jahrzehnte altes Software-Engineering-Ökosystem an Grenzen gebracht durch zehnfache Beschleunigung großer Modelle

KI ist ein Verstärker, keine Richtung.

KI beschleunigt die Codeerstellung um das 10-fache. Und dann? Mehr Code bedeutet längere Kompilierungszeiten, umfangreichere Tests, engere Code-Reviews und eine Codebasis, die keiner versteht. Software ist eine Verpflichtung. Je schneller Sie schreiben, desto mehr schulden Sie.

Die Warnung von Adam Bender, Chef-Softwareingenieur bei Google, ist direkt: Die Art und Weise, wie Sie heute Software entwickeln, funktioniert bei einer 10-fachen Geschwindigkeit überhaupt nicht. Die echten Gewinner der KI-Ära sind jedoch nicht die Teams mit der höchsten Produktivität, sondern diejenigen mit den besten Grundlagen. Denn die KI ist nur für die Verstärkung verantwortlich, nicht für die Richtung.

Bei einer Keynote-Vorstellung auf der Google I/O 2026 stellte Adam Bender eine Frage, über die die meisten Menschen noch nicht nachgedacht haben: Was wird in unserem Entwickler-Ökosystem zuerst zusammenbrechen, wenn die KI die Codeproduktivität auf ein Niveau treibt, das die bestehenden Engineering-Prozesse nicht mehr bewältigen können? Er verband die gesamte Präsentation mit einem Konzept, das Sie vielleicht noch nie gehört haben: Softwareökologie, eine Disziplin, die die sozial-technologischen Ökosysteme der Softwareproduktion ganzheitlich untersucht. Mit anderen Worten: Sie müssen nicht nur die Technologie betrachten, sondern auch die Menschen, die Kultur und die ungeschriebenen Regeln in der Organisation. InfoQ hat den Inhalt der Präsentationsvideo aufbereitet.

Die Kernaussagen lauten wie folgt:

KI löst standardmäßig keine Probleme für Sie. Wenn Ihre Vorgehensweisen gut sind, kann sie sie verstärken. Wenn sie jedoch nicht gut genug sind, wird sie nur mehr Probleme schaffen.
Es ist cool, wenn jeder ein Entwickler ist, bis Sie alle von allen Entwickelten Dinge warten müssen.
Engineering-Praktiken sind nicht unantastbar. Die Praktiken ändern sich, die Prinzipien sind wichtig.
Als Softwareingenieur an der Frontlinie befinden Sie sich in diesem kritischen Moment an der Kernposition, um zu bestimmen, wohin die Softwareentwicklung gehen wird. Von den Tools bis hin zum Arbeitsablauf, von den Engineering-Praktiken bis hin zur Engineering-Kultur: Wenn Sie das funktionierende System verstehen, können Sie Hebel finden.

Was ist ein "System"?

Ihre Arbeit im Jahr 2026 sieht völlig anders aus als Sie es 2020 sich vorgestellt haben. Wenn Sie versuchen würden, mir aus der Zeit von 2020 zu erklären, was heute passiert, würde ich Ihnen nicht glauben. Es gibt so viele Veränderungen, dass es fast überwältigend ist. Ich kann die Zukunft nicht vorhersagen, aber ich glaube, dass, wenn wir uns das aktuelle Software-Ökosystem genau ansehen, einige Antworten näher liegen, als wir denken.

Heute möchte ich mit Ihnen über ein Wort sprechen: Softwareökologie (Software Ecology). Es klingt, als hätte ich es einfach so erfunden, um auf die Bühne zu gehen, aber es ist ein seriöser Begriff. Bevor ich eine Definition gebe, möchte ich etwas Hintergrundinformationen liefern und uns etwas tiefer in das Systemdenken einarbeiten.

Ein System ist eine Gruppe miteinander verbundener Elemente, die nach einer Reihe von Regeln funktionieren und ein einheitliches Ganzes bilden. Das klingt abstrakt, aber Sie sind mit Systemen nicht unvertraut. Nehmen Sie beispielsweise eine Klimaanlage: Ein Thermostat, der die Zieltemperatur kennt, eine Heizungs- und Lüftungsanlage, die die Temperatur erhöht oder senkt, ein Raum. Wenn die Temperatur passt, stoppt das Signal. Das ist ein System.

Wenn Sie ein Softwareingenieur sind, arbeiten Sie täglich mit Systemen. Sie entwerfen Systeme, bauen sie auf und betreiben sie. In diesem Prozess haben Sie wahrscheinlich gelernt, dass alles miteinander verbunden ist.

Als Nächstes kommt das Ökosystem, ein spezielles System. Die Definition ist etwas lang, aber wichtig: Ein Ökosystem ist ein dynamisches Netzwerk von voneinander abhängigen Akteuren, die sich gemeinsam mit ihrer Umwelt entwickeln. Es zeichnet sich durch emergentes Verhalten und dezentrale Autonomie aus. Einfach ausgedrückt: Ökosysteme sind komplex, die Komponenten sind tief miteinander verbunden, jede Komponente hat ihre eigene Autonomie und kann Entscheidungen treffen und Handlungen unternehmen. Und das Wichtigste: Die Umwelt ist Teil des Systems, Sie können beide nicht trennen.

Ökosysteme sind auch komplexe adaptive Systeme, die im Laufe der Zeit wachsen, sich verändern und entwickeln können. Sie haben auch eine Eigenschaft namens Emergenz (Emergent Property), etwas, das Sie nicht durch die Beobachtung einer einzelnen Komponente sehen können. Erst wenn das System als Ganzes zusammengebaut ist, tritt das Verhalten hervor. Genau diese kontinuierliche Veränderung, das kontinuierliche Lernen und die Emergenz machen es extrem schwierig, herauszufinden, was in einem Ökosystem tatsächlich passiert.

Wenn Sie an Ökosysteme denken, fallen Ihnen wahrscheinlich Berge, Flüsse, Vögelgezwitscher und Blumen duftend in den Sinn. Aber auch die interne Entwicklerumgebung ist ein Ökosystem: Es gibt verschiedene Tools und Dienste, Menschen mit ihren eigenen Ideen und Ansprüchen sowie geschäftliche Beschränkungen. Und es ist ein spezielles System: ein sozial-technologisches System, ein System, das aus Menschen und Technologie besteht. Sozial-technologische Systeme sind äußerst komplex, denn Sie beginnen mit all der Technologie und mischen dann die Menschen hinein.

Sie haben sich wahrscheinlich unbewusst bereits mit der Weisheit sozial-technologischer Systeme befasst. Wissen Sie, was das Conway-Gesetz ist? Die Technologie, die eine Organisation entwickelt, spiegelt ihre interne Kommunikationsstruktur wider. Vereinfacht gesagt: Wenn Sie vier Teams haben, die an demselben Compiler arbeiten, erhalten Sie einen vierstufigen Compiler. So funktioniert es. Die Kernbeobachtung des Conway-Gesetzes ist, dass die Art und Weise, wie wir Technologie entwickeln, untrennbar mit der Organisationsstruktur verbunden ist, die sie entwickelt. Die Organisation prägt das, was am Ende entwickelt wird.

Aber nicht nur die Organisationsstruktur beeinflusst das Entwickler-Ökosystem, auch Werte und Kultur haben einen großen Einfluss. Das, was Ihr Ökosystem entwickelt, ist das, was die Organisation fördert. Ihre Engineering-Kultur schafft die Umgebung um das Entwickler-Ökosystem. Sobald Sie sozial-technologische Systeme verstehen, werden Sie sie in jedem Eck und Ende der Softwareentwicklung finden: in der Architektur, der Incident-Review-Kultur, den Code-Reviews, den Sicherheitsrichtlinien, überall. Das, was wir entwickeln und die Art und Weise, wie wir es tun, spiegeln wider, was uns wichtig ist. Wenn wir uns genug Mühe geben, können wir diese Erkenntnis nutzen, um unsere Werte zu verstärken und in das, was wir entwickeln, einzubauen.

Jetzt kann ich Ihnen eine korrekte Definition geben: Die Softwareökologie ist die Disziplin, die die sozial-technologischen Ökosysteme der Softwareproduktion ganzheitlich untersucht. Wenn die vorherigen Erklärungen etwas abstrakt waren, kein Problem. Jetzt betrachten wir ein reales Beispiel.

Das Entwickler-Ökosystem von Google

Ich spreche über Google, nicht weil ich dort arbeite und es loben muss, sondern weil es das Entwickler-Ökosystem ist, das ich am besten kenne. Mein Ziel ist nicht, Ihnen zu sagen, dass Sie Google kopieren sollten. Das würde Ihnen nicht helfen. Sie sind verschiedene Unternehmen in verschiedenen Stadien und haben unterschiedliche Abwägungen zu treffen. Viele Entscheidungen, die Google getroffen hat, waren auf die spezifischen Bedürfnisse abgestimmt, die wir bei der Entwicklung des Ökosystems hatten.

Vor einigen Jahren haben wir ein Buch geschrieben, das intern als "Flamingo-Buch" bezeichnet wird. Die Hälfte des Buches handelt von Versionskontrolle und Tests, aber der gesamte erste Teil beschäftigt sich mit der Engineering-Kultur. Viele Leute fragen sich, warum so viel Platz auf die Kultur verwendet wird. Wenn Sie die Kultur von Google nicht verstehen, können Sie nicht verstehen, warum wir diese technischen Entscheidungen getroffen haben. Diese Dinge sind miteinander verbunden.

Google hat einige einzigartige kulturelle Merkmale. Wir sind stark engineering-orientiert. Bei wichtigen Entscheidungen sind immer Ingenieure anwesend. Wir legen äußerst großen Wert auf Transparenz und machen so viele Dokumente und Code wie möglich für alle zugänglich. Wir fördern es, anderen zu helfen. Tatsächlich ist die Hilfsbereitschaft der Kollegen das erste, was jeder, der Google verlassen hat, erwähnt. Wir betrachten Code-Reviews als Gelegenheit zur Beratung, nicht als Prüfung. Wir legen äußerst großen Wert auf Standardisierung. Wir glauben an kontinuierliche Verbesserung. Wir befürworten Incident-Reviews ohne Schuldzuweisung. Wir sind überzeugt, dass Nachhaltigkeit besser ist als Heroismus und Automatisierung besser ist als manuelles Arbeiten. Natürlich erreichen wir nicht immer alle diese Ideale, aber das ist die Richtung, in die wir uns kulturell bewegen.

Was ist mit der Technologie? Ein monolithisches Code-Repository, in dem fast der gesamte Code gespeichert ist. Entwicklung auf Basis des Hauptzweigs, bei der jede Änderung direkt in den Hauptzweig integriert wird. Beim Erstellen einer Binärdatei wird fast jede Codezeile aus den Quellcode kompiliert. Eine einheitliche Build-Toolkette, die jeder verwendet. Eine globale Test-Automatisierungsplattform, auf der alle Tests ausgeführt werden, mehrere Milliarden Testfälle pro Tag. Ein globaler "letzter grüner" Signalgeber, mit dem ich Ihnen über eine einfache interne Website den Status jedes Builds mitteilen kann. Eine einheitliche Rechenumgebung, so dass das Problem "läuft auf meinem Rechner" praktisch nicht auftreten kann. Ein hochgradig standardisiertes Entwickler-Framework und eine kleine Gruppe von Kern-Programmiersprachen.

Diese Mischung aus Kultur und Technologie hat Google zu dem gemacht, was es heute ist. Sie können nicht nur die Hälfte verstehen und die andere Hälfte ignorieren.

Geteiltes Schicksal

Wenn ich ein Prinzip auswählen müsste, das uns ständig leise leitet, würde ich "Geteiltes Schicksal (Shared Fate)" wählen. Es beschreibt das Ausmaß, in dem ein Ökosystem und seine Komponenten miteinander verbunden sind. In einem Ökosystem mit hohem geteiltem Schicksal kann eine Komponente alle anderen Komponenten beeinflussen. Im Entwickler-Ökosystem ist das geteilte Schicksal sowohl eine technische als auch eine soziale Entscheidung. Sie können das geteilte Schicksal nicht einfach dadurch erreichen, dass Sie alle auf die gleiche Technologie setzen. Sie müssen auch einen sozialen Vertrag über die Verwaltung dieser Technologien schließen.

Bei Google beginnt das geteilte Schicksal mit dem monolithischen Code-Repository. Jede Codezeile des Unternehmens, mit wenigen Ausnahmen wie Android und Chrome, befindet sich in einem gemeinsamen Repository. Aller Code wird in den Hauptzweig eingecheckt, es gibt keine Zweige und keine Versionsnummern, alles ist an einem Ort. Dieses geteilte Schicksal ermöglicht es uns, in einer Datei einen Sicherheitsfix anzuwenden und zu wissen, dass innerhalb einer Woche jede Anwendung im Unternehmen repariert sein wird. Zehn Codezeilen reparieren eine Milliarde Codezeilen von Anwendungen und Systemsoftware. Das ist wie eine Superkraft.

Aber das geteilte Schicksal ist nicht immer gut. Es ist eine Entscheidung. Es gibt Situationen, in denen das geteilte Schicksal nicht geeignet ist. Beispielsweise in der Produktionsumgebung möchten wir nicht, dass ein Service alle anderen Services lahmlegt oder dass ein Cluster eine gesamte Region infiziert. Deshalb legen wir großen Wert darauf, gefährliches geteiltes Schicksal zu vermeiden, das zu Kaskadenausfällen führen kann. Das geteilte Schicksal ist eine Abwägung. Sie müssen den richtigen Ort finden und sicherstellen, dass es für Sie funktioniert.

Massive Änderungen

Eines der interessantesten emergenten Eigenschaften unseres Ökosystems mit geteiltem Schicksal sind massive Änderungen. Beachten Sie dies: Lange bevor die KI existierte, hat es die internen Tools von Google einem Entwickler ermöglicht, Millionen von Codezeilen zu ändern, die er nie lesen wird, nie wieder sehen wird und möglicherweise überhaupt nicht kennt. Wir haben Tools entwickelt, die all dies automatisch ermöglichen. So ist es heute, und wir machen dies seit mindestens 15 Jahren.

Diese Fähigkeit ermöglicht es uns, das monolithische Code-Repository kontinuierlich zu entwickeln, Sprachen und Frameworks zu aktualisieren und zu verhindern, dass die interne Umgebung verhärtet. Ohne massive Änderungen wären wir nicht das, was wir heute sind. Die Kollegen, die diese Tools entwickeln, leisten eine unsung heroes-Art von Arbeit, die es dem Unternehmen ermöglicht, mit der erforderlichen Geschwindigkeit voranzukommen.

Aber das Wichtigste ist, dass Sie, wenn Sie nicht verstehen, welche kulturellen und technischen Komponenten massive Änderungen ermöglichen, sie nicht wirklich verstehen können. Was brauchen Sie? Eine weit verbreitete Testkultur, in der jeder Tests schreibt. Eine einheitliche Testplattform, von der Sie wissen, wo Sie die Ergebnisse finden können. Ein gemeinsames Build-Tool, so dass Ihr Build das gleiche Ergebnis wie mein Build hat. Standardisierte Bibliotheken, so dass Sie keine Probleme haben, wenn Sie Komponenten austauschen. Standardisierte Code-Reviews und Transparenz des Code-Repositories, so dass Sie wissen, welche Codezeilen geändert werden müssen. Massive Änderungen sind die ultimative Umsetzung des Google-Prinzips "Automatisierung statt manuelles Arbeiten", und sie sind nur möglich, wenn das gesamte Ökosystem zusammenarbeitet. Sie können nicht auf einen Teil der Entwicklerumgebung zeigen und sagen, dass dies der Grund für ihre Entstehung ist. Alle Teile zusammen sind der Grund.

Ihr Ökosystem, Ihre Abwägungen

Jedes Entwickler-Ökosystem hat solche emergenten Eigenschaften. Sie sind normalerweise die Dinge, die es für Sie einzigartig machen, wo Sie arbeiten. Das liegt daran, dass sie das Ergebnis einer Reihe von Entscheidungen sind, die Sie getroffen haben.

Das Entwickler-Ökosystem von Google hat eine einzigartige Reihe von Abwägungen ergeben, die unseren technischen und geschäftlichen Zielen dienen. Aber wie jedes Ökosystem kann es nicht in allen Aufgaben hervorragend abschneiden. Wir haben uns entschieden, auf extreme Skalierbarkeit, Sicherheit und Leistung zu optimieren, auch wenn dies manchmal auf Kosten der Entwicklerproduktivität geht. Wir sind bereit, diese Abwägung zu machen. Das Ökosystem eines fünfköpfigen Startups würde völlig anders aussehen. Hier sind Geschwindigkeit und Agilität am wichtigsten.

Die meisten von Ihnen befinden sich in einem Ökosystem zwischen fünf und zweihunderttausend Personen. Die Abwägungen, die Sie treffen müssen, sind sehr interessant, denn wenn Sie diese Abwägungen betrachten, können Sie beginnen, die Werte der Organisation zu verstehen: Was sie wirklich wichtig ist, nicht was sie nur sagt, sondern was die Entscheidungen, die Sie tatsächlich beobachten, verraten. Wenn Sie diese Werte verstehen, können Sie beginnen, die sich abzeichnende Veränderung zu gestalten.

Der 10-fache Moment: Jeder Knoten ist unter Druck

Es ist an der Zeit, über das in der Ecke sitzende, Token fressende Elefant zu sprechen: Wie sieht ein KI-first-Entwickler-Ökosystem aus?