Czerwcowy plan zbudowany na lipcowym modelu

Menedżerka produktu w Warszawie wpisała Gemini 3.5 Pro do czerwcowego planu wydania, z ustawioną wokół niego demonstracją dla klienta. Potem Google przesunął model na 17 lipca 2026 roku i, co bardziej niezwykłe, oświadczył, że wyrzucił leżącą u podstaw architekturę bazową i zbudował ją od nowa. Demonstracja opiera się teraz na modelu, który jeszcze nie istnieje.

To druga decyzja ukryta w jednym ogłoszeniu. Google dokonał twardego wyboru wobec własnego produktu. Zespół z Warszawy dokonał łagodniejszego wiele miesięcy wcześniej, gdy potraktował obiecaną datę premiery jako wielkość stałą. Tylko jedna z tych dwóch decyzji była zdyscyplinowana i nie była to decyzja kupującego.

Dlaczego Google wyrzucił gotowy model

Google DeepMind nie doszlifował starego modelu; porzucił go. Ujawnione wewnętrzne oceny pokazały, że wcześniejsza architektura bazowa Gemini 2.5 Pro radziła sobie ze zwykłym tekstem, ale załamywała się przy rekurencyjnych wywołaniach narzędzi i złożonych, wielowarstwowych układach oraz potykała się na rozumowaniu matematycznym. Zamiast wypuścić flagowy model, który zawodził dokładnie tam, gdzie rywale są silni, Google przebudował podstawę i wyzerował datę.

Następca celuje w okno kontekstu o wielkości dwóch milionów tokenów, głębszą warstwę rozumowania i stabilniejsze procesy w długim horyzoncie, wymierzone wprost w GPT-5.6 od OpenAI i Fable 5 od Anthropic. Tło nie było spokojne: w czerwcu starsi badacze odeszli do OpenAI i Anthropic, a Alphabet stracił około 225 miliardów dolarów wartości rynkowej w jednej sesji 22 czerwca. Wypuszczenie słabego flagowego modelu w takiej sytuacji byłoby łatwym, kosztownym błędem.

Dyscyplina, którą większość zespołów pomija

Trudność kosztu utopionego polega na tym, że przypomina postęp. Projekt ukończony w dziewięćdziesięciu procentach, z realnymi pieniędzmi i miesiącami już włożonymi, to dokładnie ten projekt, do którego wypuszczenia zespoły same siebie przekonują. Racjonalny sprawdzian pomija to, ile projekt kosztował, i pyta jedynie, ile wart jest jego dokończenie od tego miejsca. Google zastosował ten sprawdzian do niemal gotowego modelu i go zatrzymał. Większość organizacji wobec tego samego niemal gotowego projektu wypuszcza go, a potem zarządza szkodami.

Lekcja nie brzmi, że opóźnienia są dobre; brzmi ona, że decyzja o zatrzymaniu powinna zależeć od przyszłej wartości, nigdy od tego, ile już zainwestowano. Jeśli projekt nie przeskakuje poprzeczki, dla której go zbudowano, utopione miesiące przepadają, czy go wypuścicie, czy nie, a wypuszczenie dokłada jedynie koszt sprzątania. Google właśnie wyłożył tę lekcję publicznie, w skali flagowego produktu.

Co to zmienia dla waszej własnej mapy drogowej

Traktujcie każdy nieopublikowany model jako datowane założenie, a nie zobowiązanie. Jeśli premiera leży na waszej ścieżce krytycznej, zapiszcie datę, na którą liczycie, model zapasowy, którego użyjecie, jeśli się obsunie, oraz ostatni dzień, w którym możecie się przełączyć bez złamania obietnicy wobec klienta. Zapisaną zależnością można zarządzać; taka, która żyje tylko na slajdzie, zarządza wami.

Firmy, które ucierpiały w tym kwartale, były tymi, które podpisały dostawy na poczet premiery, która się nie odbyła. Dostępność to zmienna zakupowa, a w tym miesiącu poruszyła się dla wszystkich naraz. Planujcie wobec tego, co już wydano, trzymajcie przetestowaną alternatywę o jedno przełączenie od siebie i pozwólcie dostawcom nieść własne obsunięte daty, zamiast przenosić ryzyko na waszych klientów.

Czytaj dalej: Dlaczego najcenniejsze laboratorium SI nie jest już najsłynniejsze?  |  Gdy najbardziej zaangażowany wyznawca SI robi krok wstecz, co ci mówi?