En juniplan byggd på en julimodell

En produktansvarig i Stockholm hade skrivit in Gemini 3.5 Pro i en släppplan för juni, med en kunddemo byggd kring den. Sedan sköt Google fram modellen till den 17 juli 2026 och sa, mer ovanligt, att den hade skrotat den underliggande basarkitekturen och byggt om den från grunden. Demon vilar nu på en modell som ännu inte finns.

Det är det andra beslutet som göms i ett enda tillkännagivande. Google gjorde ett hårt val om sin egen produkt. Teamet i Stockholm gjorde ett mjukare val månader tidigare, när det behandlade ett utlovat lanseringsdatum som en fast storhet. Bara ett av de två besluten var disciplinerat, och det var inte köparens.

Varför Google slängde en färdig modell

Google DeepMind finjusterade inte den gamla modellen; det övergav den. Läckta interna utvärderingar visade att den tidigare basarkitekturen i Gemini 2.5 Pro höll för ren text men bröt samman vid rekursiva verktygsanrop och komplexa layouter i flera lager, och snubblade på matematiskt resonemang. I stället för att skicka ut ett flaggskepp som fallerade just där rivalerna är starka byggde Google om basen och nollställde datumet.

Efterträdaren siktar på ett kontextfönster på två miljoner tokens, ett djupare resonemangslager och stabilare arbetsflöden över lång tid, riktade rakt mot OpenAI:s GPT-5.6 och Anthropics Fable 5. Bakgrunden var inte lugn: seniora forskare lämnade för OpenAI och Anthropic i juni, och Alphabet tappade omkring 225 miljarder dollar i marknadsvärde på en enda handelsdag den 22 juni. Att skicka ut ett svagt flaggskepp i det läget hade varit det lätta, dyra misstaget.

Disciplinen som de flesta team hoppar över

Det svåra med en sunk cost är att den känns som framsteg. Ett projekt som är nittio procent klart, med riktiga pengar och månader redan nedlagda, är precis det projekt som team pratar sig själva till att skicka ut. Det rationella provet bortser från vad ett projekt har kostat och frågar bara vad det är värt att slutföra härifrån. Google tillämpade det provet på en nästan färdig modell och stoppade den. De flesta organisationer skickar ut samma nästan klara projekt och hanterar sedan skadorna.

Läxan är inte att förseningar är bra; den är att beslutet att sluta bör bero på det framtida värdet, aldrig på hur mycket som redan har investerats. Om ett projekt inte klarar den ribba det byggdes för är de nedlagda månaderna förlorade vare sig ni skickar ut eller inte, och att skicka ut lägger bara till kostnaden för städningen. Google sträckte just fram den här läxan offentligt, i flaggskeppsskala.

Vad detta ändrar för er egen färdplan

Behandla varje opublicerad modell som ett daterat antagande, inte ett åtagande. Om en lansering ligger på er kritiska väg, skriv ner datumet ni räknar med, den alternativa modell ni använder om den glider, och sista dagen ni kan byta utan att bryta ett kundlöfte. Ett nedskrivet beroende kan ni styra; ett som bara lever på en slide styr er.

De företag som drabbades detta kvartal var de som skrev under leveranser mot en lansering som inte hade ägt rum. Tillgänglighet är en inköpsvariabel, och den här månaden rörde den sig för alla samtidigt. Planera mot det som redan är utskickat, håll ett testat alternativ ett byte bort, och låt leverantörerna bära sina egna glidna datum i stället för att skicka risken vidare till era kunder.