De flesta team låtsas fortfarande bygga med AI

Det finns ett tal som dyker upp i varje AI-rapport just nu: 11 %.

Det är andelen organisationer som använder agentisk AI i produktion, enligt Gartner. Samtidigt "utforskar" 30 % och 38 % "pilottestar". Alla har en demo. Nästan ingen har levererat något verkligt.

Vi har tillbringat det senaste året med att integrera AI i riktiga produkter, inklusive våra egna öppen källkod-verktyg som tanam, ett självhostat CMS med AI-ghostwriting byggt på Firebase Genkit, och genkitx-deepseek, vårt Genkit-plugin för DeepSeek-modeller. Så när vi läser trendrapporter om vart AI är på väg tenderar vi att filtrera dem genom en annan lins.

Det slutade handla om autokomplettering för ett tag sedan

Det verkliga skiftet 2026 är inte att modellerna blivit smartare. Det är att de nu kan resonera över flerstegade arbetsflöden: anropa verktyg, tolka resultat, loopa tillbaka och slutföra uppgifter utan att en människa behöver övervaka varje steg.

Gartner förutspår att 40 % av företagsapplikationer kommer att inkludera uppgiftsspecifika AI-agenter vid årets slut, upp från mindre än 5 % för tolv månader sedan. Vi ser det i vårt eget arbete. Klienter slutade fråga "ska vi lägga till AI?" någonstans runt mitten av förra året. Frågan nu är "exakt var ska agenten lämna över till en människa?" Det är en mycket svårare fråga att besvara väl.

För här är saken: ingenjörsutmaningen handlar inte om prompt-engineering eller modellval. Det handlar om systemdesign. Var drar man gränsen mellan vad agenten bestämmer på egen hand och vad en person fortfarande behöver bekräfta? Vad händer när ett arbetsflöde misslyckas halvvägs? Hur får man verklig insyn i en kedja av modellanrop spridda över flera tjänster? Det är arkitekturproblem. Team som går in och tror att de löser ett AI-problem hamnar vanligtvis fast och frustrerade.

Mindre och mer fokuserade vinner

Ett skifte som inte pratas om tillräckligt: mindre, ändamålsbyggda modeller presterar konsekvent bättre än stora generalister för specifika produktionsanvändningsfall.

Om du bygger en funktion med ett tydligt jobb (klassificera supportärenden, dra ut strukturerad data från rörig indata, sammanfatta transkript) kommer en fokuserad modell att vara snabbare, billigare och mer tillförlitlig än att routa allt genom den största modellen du kan komma åt. Vi byggde genkitx-deepseek delvis på grund av detta. DeepSeeks modeller presterar långt över sin vikt för kod- och resonemangsuppgifter till en bråkdel av kostnaden. När du optimerar för latens och kostnad i en verklig produktionsmiljö adderas det gapet snabbt.

Frågan värd att ställa är inte vilken modell som presterar bäst i ett benchmark. Det är vilken modell som fungerar bäst för just det här jobbet, inom den här latensbudgeten, till det här priset. Det är olika frågor.

Du behöver fortfarande deterministisk kod runt det

De team som bygger de mest tillförlitliga AI-funktionerna just nu kör inte allt genom en språkmodell och korsar fingrarna. De kombinerar LLM:er med strukturerade, deterministiska system: hämtningslager, valideringslogik, kod som inte hallucinerar.

Vi gör detta i tanam. AI-ghostwriting-funktionen är inte en svart låda där innehåll bara dyker upp. Modellen genererar ett utkast, men publiceringslogik, schemavalidering och användarrecension hanteras alla av kod som beter sig förutsägbart. Den gränsen är avsiktlig, och det är vad som gör funktionen tillförlitlig nog att sätta framför användare. När du väl låter en modell äga hela pipeline från början till slut blir saker oförutsägbara på sätt som är svåra att felsöka.

Vad vi har sett gå fel

Det mönster vi ser oftast är team som bygger på hype-tidslinjer. Klyftan mellan "det här ser fantastiskt ut i en demo" och "det här håller för tusentals riktiga användare" är större än vad nästan någon budgeterar för, och att stänga den tar längre tid än förväntat.

De AI-funktioner som har levererats väl i våra projekt delar en sak: ett tight, väldefinierat scope. Ju bredare automationen är, desto svårare blir det att testa, övervaka och återhämta sig från när något går sönder. Att börja smalt är inte en kompromiss. Det är det smartare sättet att komma in. Och innan du spenderar tid på att designa vad AI:n gör är det värt att spendera minst lika mycket tid på att designa vad som händer när den har fel, är långsam eller osäker. Team som hoppar över det samtalet tenderar att lära sig det på det hårda sättet, vanligtvis i produktion.

Vart vi tror att saker är på väg

2026 känns som året då AI slutar vara en funktion och börjar vara närmre infrastruktur. De team som behandlar det med samma disciplin de skulle ta med sig till en databasmigration eller ett API-kontrakt är de som bygger saker som håller. Resten itererar fortfarande på demos.

Vi har byggt på Firebase, Genkit, Flutter och Google Cloud långt innan något av det här fick etiketten "agentisk". Den grunden har inte förändrats. Det som har förändrats är hur mycket av det arbete som brukade kräva konstant mänsklig uppmärksamhet nu kan delegeras noggrant, och hur mycket omdöme det fortfarande krävs för att bestämma vad som är värt att delegera.

Om du försöker lista ut var AI passar in i din produkt diskuterar vi gärna det med dig.