Zahlen aus dem Inneren eines großen Technologiekonzerns sind selten, und deshalb lohnt ein genauer Blick auf zwei Angaben, die Google-Ingenieur Haydn Belfield öffentlich gemacht hat. Erstens: Mehr als 75 Prozent des Produktionscodes im Unternehmen werden von KI geschrieben. Zweitens: 88 Prozent der Änderungen erfordern weiterhin menschliche Steuerung.

Beide Werte gehören zusammen. Für sich genommen klingt der erste nach einer Ablösung der Entwicklungsarbeit, der zweite nach Stillstand. Gemeinsam beschreiben sie etwas Nüchterneres: eine Arbeitsteilung, bei der das Schreiben von Code weitgehend automatisiert ist, die Entscheidung über das Was und das Ob aber beim Menschen bleibt.

Produktionscode ist nicht gleich fertige Software

Produktionscode meint den Code, der tatsächlich im laufenden Betrieb eingesetzt wird – im Unterschied zu Experimenten, Prototypen oder Wegwerfskripten. Dass ein Großteil davon maschinell entsteht, zeigt, wie weit Codegenerierung inzwischen trägt.

Der Anteil sagt allerdings nichts darüber aus, wie viel Arbeit in der Formulierung der Aufgabe, in der Prüfung des Ergebnisses und in der Korrektur steckt. Genau darauf verweist die zweite Zahl. Wenn fast neun von zehn Änderungen menschliche Steuerung brauchen, dann ist die KI ein sehr produktiver Ausführender, kein eigenständiger Entwickler.

Für Projektverantwortliche ist diese Unterscheidung zentral. Die Zeitersparnis entsteht beim Tippen, beim Erzeugen von Varianten, beim Ausfüllen bekannter Muster. Sie entsteht nicht automatisch dort, wo die eigentliche Komplexität eines Projekts liegt: in der Abstimmung von Anforderungen, in Architekturentscheidungen, in der Frage, welche Lösung in fünf Jahren noch wartbar ist.

Keine Beschleunigung der Forschung durch Forschungs-KI

Belfield äußerte sich auch zu einer weitergehenden Erwartung: dass KI die KI-Forschung selbst spürbar beschleunigt. Bei Deepmind sei eine solche Beschleunigung nicht messbar. Ein hausinterner Maßstab, der General Capability Index, zeige gleichmäßiges Wachstum – also eine stetige Verbesserung der Fähigkeiten, aber keinen Sprung im Tempo.

Daraus leitet er ab, dass eine sich selbst verbessernde KI vorerst Zukunftsmusik bleibt. Gemeint ist damit ein System, das seine eigenen Nachfolger entwickelt und dadurch immer schneller besser wird. Die Idee prägt viele Szenarien über die nächsten Jahre – nach dieser Einschätzung gibt es derzeit aber keine Belege dafür, dass sie bereits eingetreten ist.

Für die Planung in Unternehmen ist das eine entlastende Nachricht. Wer heute eine Plattform konzipiert, muss nicht damit rechnen, dass die technologische Grundlage in wenigen Monaten unberechenbar davonzieht. Die Verbesserungen kommen, aber sie kommen in einem Tempo, das sich in Roadmaps abbilden lässt.

Was das für die Praxis in Webprojekten heißt

Übertragen lassen sich die Zahlen nicht eins zu eins. Google arbeitet mit eigener Infrastruktur, eigenen Modellen und einer sehr großen, gut dokumentierten Codebasis – Bedingungen, die in einem mittelständischen Umfeld so nicht vorliegen. Die Richtung der Aussage ist trotzdem übertragbar.

  • Codegenerierung ist Alltag, keine Zukunftstechnik. Wer sie in Webprojekten noch nicht einsetzt, verschenkt Zeit bei Routineaufgaben: Standardkomponenten, Tests, Migrationsschritte, wiederkehrende Konfigurationen.
  • Review bleibt der Engpass. Wenn deutlich mehr Code entsteht, muss deutlich mehr Code geprüft werden. Teams, die ihre Review-Kapazität nicht mitwachsen lassen, verlagern das Problem nur nach hinten.
  • Verantwortung lässt sich nicht delegieren. Sicherheit, Datenschutz, Barrierefreiheit und Performance sind Eigenschaften, die jemand prüfen und verantworten muss. Ein generiertes Ergebnis ist ein Vorschlag, keine Freigabe.
  • Erwartungen realistisch halten. Eine Verdopplung der Entwicklungsgeschwindigkeit im Gesamtprojekt ist aus diesen Zahlen nicht abzuleiten. Beschleunigt wird ein Teilschritt, nicht die gesamte Wertschöpfungskette.

Qualitätssicherung wird zur Kernkompetenz

Wenn das Schreiben von Code günstiger wird, steigt der relative Wert aller Tätigkeiten rundherum: saubere Anforderungen, verständliche Schnittstellen, automatisierte Tests, nachvollziehbare Dokumentation. Diese Arbeiten waren schon immer wichtig, ihr Fehlen fiel nur langsamer auf.

Mit generiertem Code fällt es schneller auf. Ein Modell orientiert sich an dem, was es in der bestehenden Codebasis und im Auftrag vorfindet. Ist die Struktur unklar, entstehen schnell viele Zeilen unklarer Struktur. Ordnung in der Codebasis ist damit kein Selbstzweck mehr, sondern die Voraussetzung dafür, dass Automatisierung überhaupt brauchbare Ergebnisse liefert.

Praktisch bedeutet das: Definierte Coding-Standards, ein verbindlicher Review-Prozess mit klaren Zuständigkeiten und eine Teststrategie, die Regressionen – also das unbeabsichtigte Wiederauftreten alter Fehler – früh sichtbar macht. Diese Bausteine entscheiden darüber, ob Codegenerierung Geschwindigkeit bringt oder nur technische Schulden.

Einordnung

Für Web- und Softwareprojekte sind die Google-Zahlen vor allem eine Kalibrierungshilfe: KI-gestützte Entwicklung ist produktiv genug, um sie fest einzuplanen, und zugleich weit davon entfernt, Steuerung und Verantwortung zu übernehmen. Wer Budgets und Zeitpläne daran ausrichtet, sollte die Einsparung bei der Umsetzung einkalkulieren – und zugleich mehr Aufwand für Review und Qualitätssicherung vorsehen. Das Tempo der Modelle wächst stetig, aber ohne Sprung; es bleibt also Zeit, Prozesse und Teamstrukturen geordnet anzupassen, statt sie unter Druck umzubauen.

Quellen