Ein Juni-Fahrplan, gebaut auf einem Juli-Modell

Eine Produktverantwortliche in Berlin hatte Gemini 3.5 Pro fest in einen Juni-Releaseplan eingetragen, mit einer Kundendemo drumherum. Dann verschob Google das Modell auf den 17. Juli 2026 und sagte, ungewöhnlicher noch, es habe die darunterliegende Basisarchitektur verworfen und von Grund auf neu gebaut. Die Demo hängt nun an einem Modell, das es noch nicht gibt.

Das ist die zweite Entscheidung, die in einer einzigen Ankündigung steckt. Google traf eine harte Wahl über das eigene Produkt. Das Berliner Team traf Monate zuvor eine weichere, als es ein zugesagtes Startdatum als feste Größe behandelte. Nur eine dieser beiden Entscheidungen war diszipliniert, und es war nicht die des Käufers.

Warum Google ein fertiges Modell wegwarf

Google DeepMind justierte das alte Modell nicht; es gab es auf. Durchgesickerte interne Bewertungen zeigten, dass die frühere Basisarchitektur von Gemini 2.5 Pro bei reinem Text standhielt, aber bei rekursiven Tool-Aufrufen und komplexen, mehrschichtigen Layouts einbrach und beim mathematischen Denken strauchelte. Statt ein Flaggschiff auszuliefern, das genau dort versagt, wo die Rivalen stark sind, baute Google die Basis neu und setzte den Termin zurück.

Der Nachfolger zielt auf ein Kontextfenster von zwei Millionen Token, eine tiefere Denkschicht und stabilere Abläufe über lange Strecken, gerichtet direkt gegen OpenAIs GPT-5.6 und Anthropics Fable 5. Der Hintergrund war nicht ruhig: leitende Forscher gingen im Juni zu OpenAI und Anthropic, und Alphabet verlor an einem einzigen Handelstag am 22. Juni rund 225 Milliarden Dollar an Marktwert. Ein schwaches Flaggschiff in diese Lage zu schicken, wäre der leichte, teure Fehler gewesen.

Die Disziplin, die die meisten Teams auslassen

Das Schwere an versunkenen Kosten ist, dass sie sich wie Fortschritt anfühlen. Ein Vorhaben, das zu neunzig Prozent fertig ist, mit echtem Geld und Monaten an Aufwand, ist genau das Projekt, das Teams sich schönreden auszuliefern. Der rationale Test ignoriert, was ein Projekt gekostet hat, und fragt nur, was es von hier an wert ist, es fertigzustellen. Google wandte diesen Test auf ein fast fertiges Modell an und stoppte es. Die meisten Organisationen liefern dasselbe fast fertige Vorhaben aus und verwalten dann den Schaden.

Die Lehre ist nicht, dass Verzögerungen gut sind; sie ist, dass die Entscheidung zum Abbruch am künftigen Wert hängen sollte, nie daran, wie viel bereits investiert wurde. Wenn ein Projekt die Latte nicht schafft, für die es gebaut wurde, sind die versunkenen Monate verloren, ob Sie ausliefern oder nicht, und das Ausliefern fügt nur die Kosten der Aufräumarbeit hinzu. Google hat diese Lehre gerade öffentlich vorgestreckt, im Maßstab eines Flaggschiffs.

Was das für Ihren eigenen Fahrplan ändert

Behandeln Sie jedes unveröffentlichte Modell als datierte Annahme, nicht als Zusage. Wenn ein Start auf Ihrem kritischen Pfad liegt, notieren Sie das Datum, mit dem Sie rechnen, das Ausweichmodell, das Sie bei Verzug nutzen, und den letzten Tag, an dem Sie wechseln können, ohne ein Kundenversprechen zu brechen. Eine notierte Abhängigkeit können Sie steuern; eine, die nur auf einer Folie lebt, steuert Sie.

Die Firmen, die es dieses Quartal traf, waren die, die Zusagen gegen einen Start unterschrieben, der nicht stattgefunden hatte. Verfügbarkeit ist eine Beschaffungsgröße, und diesen Monat verschob sie sich für alle zugleich. Planen Sie gegen das, was ausgeliefert ist, halten Sie eine getestete Alternative einen Wechsel entfernt, und lassen Sie die Anbieter ihre eigenen verschobenen Termine tragen, statt das Risiko an Ihre Kunden weiterzureichen.