Gemini 3.8 Flash gjorde det billigare att generera kod. Vad kostar fortfarande lika mycket för att lansera ett POS?

Gemini 3.8 Flash gjorde det återigen billigare att generera kod. Vad som fortfarande kostar lika mycket för att lansera ett POS: riskbedömning för handlare (underwriting), PCI-intyg, hårdvarucertifiering för kort närvarande (card-present), terminalen på disken och personalarbetstimmarna som krävs för att ställa in skatteregler, produktkatalog och behörigheter. Det är dessa poster som sätter priset på lanseringen, och ingen av dem är kod.

Google lanserade Gemini 3.8 Flash den 2 september 2026 till samma introduktionspriser för tokens som sin föregångare: 0,75 $ per miljon indatatokens och 3,75 $ per miljon utdatatokens¹. Resultaten i prestandatest (benchmarks) gick upp medan priset stod stilla, vilket är det tysta sättet kodgenerering blir billigare på. Ett förbehåll innan siffrorna nedan: modellnamn, priser och prestandatester ändras varje månad, så se detaljerna i detta inlägg som en ögonblicksbild, aktuell vid publicering.

Vad gjorde Gemini 3.8 Flash faktiskt billigare?

Utkastskrivandet. Kassa-skärmar, produktrutnät, rabattlogik, kvittolayouts: beskriv dem och modellen genererar rimlig kod för mindre pengar per fungerande resultat än vad 3.7 Flash gjorde för en månad sedan. Googles lansering lutar sig mot prestandatester för mjukvaruutveckling, och oberoende analyser per uppgift rankar den som den billigaste modellen på sin intelligensnivå². Det finns dock en hake värd att känna till: modellen resonerar längre vid svåra problem och anropar verktyg oftare, så ett enskilt komplext jobb kan förbruka fler tokens än vad föregångaren gjorde. Trenden pekar ändå åt samma håll. Varje Flash-generation levererar mer fungerande kod per dollar.

Vi tog upp samma mönster när Gemini 3.6 Flash lanserades: att ta fram ett utkast till en kassaskärm är nästan gratis, men att ta emot en riktig betalning är en helt annan sak. Det här inlägget handlar om pengasidan av den klyftan, eftersom en modellansering som ändrar en enskild rad i din budget lätt kan missuppfattas som en lansering som ändrar hela budgeten.

Vilka kostnader för en POS-lansering minskar inte med modellen?

Fem poster, och de uppför sig som klockor och fakturor i stället för kod:

• Riskbedömning för handlare (underwriting) och KYC (identitetskontroller av företaget och dess ägare). Innan du kan ta emot en kortbetalning granskar en betalleverantör vem du är, vad du säljer och din riskprofil. Den granskningen sker i leverantörens tempo, inte ditt, och en snabbare modell förkortar den inte.

• PCI-intyg (bevis på att kortdata hanteras säkert). En mindre handlare hos en validerad leverantör lägger tid på ett självutvärderingsformulär samt skanningar, vilket vanligtvis kostar några hundra dollar om året. Ett företag som hanterar kortdata själv ställs inför granskningar på plats för runt 40 000 $, inom efterlevnadsprogram som kostar 70 000 $ och uppåt³.

• Hårdvarucertifiering för kort närvarande (card-present). En kortläsare som kommunicerar med riktiga kortnätverk måste genomgå EMV-certifiering (standarden för chip och blipp), och organisationer lägger rutinmässigt många månader och avsevärda arbetstimmar på en enda certifiering⁴.

• Själva hårdvaran. En certifierad terminal eller blippläsare är ett fysiskt inköp. Ingen mängd genererad kod kommer att leverera en kortläsare till din disk.

• Konfigurationsarbete. Skatteregler, produktkatalog, personalbehörigheter och tester inför det första riktiga arbetspasset. AI kan utforma mycket av det, men en människa måste fortfarande verifiera det, eftersom en felaktig skattesats kostar riktiga pengar på varje försäljning den berör.

Varför påverkar billigare kodgenerering knappt lanseringsbudgeten?

Eftersom koden redan var den billigaste posten. Publicerade intervall från 2026, samlade i vad ett POS-system egentligen kostar, sätter mjukvaran för POS till 0 $ till 165 $ i månaden, medan hårdvara kostar upp till 2 000 $ och kortbearbetning tar 2,4 till 3,5 procent av varje försäljning. Att krympa den minsta tårtbiten i en budget, till och med till noll, lämnar totalsumman nästan där den var.

Så varför känns det som om AI drastiskt sänkte kostnaden för att lansera ett POS? För att den synliga delen blev billig. En övertygande kassaskärm brukar förr signalera månader av betald utveckling; nu signalerar den en eftermiddag med en prompt, vilket alla som har vibe-kodat ett kassasystem eller byggt ett i Lovable eller Replit har sett. Fakturaposterna som dominerar lanseringen förblir osynliga fram till den första riktiga betalningen, och de anländer enligt tidsplaner som modellen inte kan påverka.

En budget skriven utifrån antagandet att modellen gör arbetet har prissatt demon, inte lanseringen. Den ärliga versionen har en liten och krympande rad för genererad mjukvara, och en uppsättning fasta rader för riskbedömning, intyg (det formella godkännandepappersarbetet), certifiering, hårdvara och installationstid.

Så, vad kostar fortfarande lika mycket för att lansera ett POS?

Allt som aldrig var kod. Gemini 3.8 Flash krympte den del av projektet som redan var billigast, och de fasta posterna behöll sitt pris på samma sätt som de gjorde genom 3.6 och 3.7. Tumregel: budgetera en POS-lansering utifrån de poster som ingen modell kan generera; koden är bara ett avrundningsfel nu.

Det praktiska steget är inte att återuppbygga de fasta posterna, utan att lansera där de redan är betalda. På Final finns det ingen månatlig mjukvaruprenumeration, Final Pay hanterar PCI-efterlevande betalningar via en betalningsprocessor med certifierad terminalhårdvara, och mjukvarulagret är den del du formar: beskriv kassan du vill ha, eller anslut din egen AI via MCP och låt den skriva utkastet till vad än dagens billigaste modell tar betalt. Ta det som modellen gör billigt. Det som den inte kan göra billigt ska du inte betala för att återupptäcka.