En juni-plan bygget på en juli-model
En produktansvarlig i København havde skrevet Gemini 3.5 Pro ind i en udgivelsesplan for juni, med en kundedemo bygget op omkring den. Så rykkede Google modellen til 17. juli 2026 og sagde, mere usædvanligt, at den havde skrottet den underliggende basisarkitektur og bygget den om fra bunden. Demoen hviler nu på en model, der endnu ikke findes.
Det er den anden beslutning gemt i en enkelt meddelelse. Google traf et hårdt valg om sit eget produkt. Teamet i København traf et blødere valg måneder før, da det behandlede en lovet lanceringsdato som en fast størrelse. Kun den ene af de to beslutninger var disciplineret, og det var ikke køberens.
Hvorfor Google smed en færdig model væk
Google DeepMind finjusterede ikke den gamle model; den opgav den. Lækkede interne evalueringer viste, at den tidligere basisarkitektur i Gemini 2.5 Pro holdt til ren tekst, men brød sammen ved rekursive værktøjskald og komplekse layouts i flere lag og snublede i matematisk ræsonnement. I stedet for at sende et flagskib ud, der fejlede netop dér, hvor rivalerne er stærke, byggede Google basen om og nulstillede datoen.
Efterfølgeren sigter mod et kontekstvindue på to millioner tokens, et dybere ræsonnementslag og mere stabile arbejdsgange over lang tid, rettet direkte mod OpenAI's GPT-5.6 og Anthropics Fable 5. Baggrunden var ikke rolig: seniorforskere forlod virksomheden til fordel for OpenAI og Anthropic i juni, og Alphabet tabte omkring 225 milliarder dollars i markedsværdi på en enkelt handelsdag den 22. juni. At sende et svagt flagskib ind i den situation havde været den lette, dyre fejl.
Disciplinen, de fleste teams springer over
Det svære ved en sunk cost er, at den føles som fremskridt. Et projekt, der er halvfems procent færdigt, med rigtige penge og måneder allerede brugt, er præcis det projekt, teams taler sig selv til at sende ud. Den rationelle prøve ser bort fra, hvad et projekt har kostet, og spørger kun, hvad det er værd at gøre det færdigt herfra. Google anvendte den prøve på en næsten færdig model og standsede den. De fleste organisationer sender det samme næsten færdige projekt ud og håndterer så skaderne.
Læren er ikke, at forsinkelser er gode; den er, at beslutningen om at stoppe bør afhænge af den fremtidige værdi, aldrig af hvor meget der allerede er investeret. Hvis et projekt ikke klarer den tærskel, det blev bygget til, er de tabte måneder væk, uanset om I sender ud eller ej, og at sende ud tilføjer kun omkostningen ved oprydningen. Google lagde netop denne lære frem offentligt, i flagskibsstørrelse.
Hvad dette ændrer for jeres egen køreplan
Behandl enhver ikke-udgivet model som en dateret antagelse, ikke som et løfte. Hvis en lancering ligger på jeres kritiske vej, så notér den dato, I regner med, den alternative model, I bruger, hvis den skrider, og den sidste dag, I kan skifte uden at bryde et kundeløfte. En nedskrevet afhængighed kan I styre; en, der kun lever på et slide, styrer jer.
De virksomheder, der led skade i dette kvartal, var dem, der underskrev leverancer mod en lancering, der ikke havde fundet sted. Tilgængelighed er en indkøbsvariabel, og denne måned flyttede den sig for alle på én gang. Planlæg mod det, der allerede er udgivet, hold et testet alternativ ét skift væk, og lad leverandørerne bære deres egne skredne datoer i stedet for at sende risikoen videre til jeres kunder.
Læs videre: Hvorfor er det mest værdifulde AI-laboratorium ikke længere det mest berømte? | Når den mest investerede troende på AI træder tilbage, hvad fortæller han dig så?
