LLM‑First eller Code‑First? Var intelligens hör hemma i produktions‑AI

Hur man bestämmer vad modellen ska hantera, vad din kod ska hantera och hur man kopplar ihop de två.

För några år sedan såg arkitekturen för en AI‑applikation ut så här: skicka en prompt till en stor språkmodell -> få ett svar -> visa det för användaren. Det är inte hela historien längre nuförtiden. Modellerna ombeds tolka avsikt, hämta information, välja verktyg, anropa API:er, göra planer och köra flerstegiga arbetsflöden.

Den förändringen har delat fältet i två – LLM‑First eller Code‑First

I en LLM‑first‑arkitektur är modellen i centrum och bestämmer vad som händer härnäst. Den läser begäran, väljer ett verktyg, bestämmer ordningen på operationerna, kontrollerar mellanstegens resultat och ändrar kurs när det behövs.

I en code‑first‑arkitektur är mjukvara/kod ansvarig för sekvensering, affärsregler, validering, behörigheter och exekvering. LLM:n här är som en specialist som koden anropar när språkförståelse eller generering behövs.

Folk älskar att diskutera vilken som är bättre. Jag tycker det är fel argument. Den bättre frågan är var varje typ av intelligens hör hemma. De starkaste produktionssystemen jag har sett är sällan enbart den ena eller den andra. De blandar probabilistisk resonemang med deterministisk kontroll, och de gör det medvetet.

Varför LLM‑First är så attraktivt

Traditionell mjukvara fungerar utmärkt när du kan specificera kraven. Till exempel väljer en användare en produkt, anger ett belopp och skickar en betalning. Du definierar de tillåtna tillstånden, valideringsreglerna, felvillkoren och transaktionssekvensen i kod. Klart.

Naturligt språk samarbetar inte så. Föreställ dig en användare som skriver: “Hitta de transaktioner som ser ovanliga ut, förklara vad som hände och berätta vad jag bör undersöka först.”

Det finns ingen fast väg genom den begäran. Här måste systemet avgöra vad “ovanligt” betyder, ta reda på vilken data som är relevant, eventuellt anropa flera verktyg, väga svaret och skriva en förklaring som en person kan använda. Inget ingenjörsteam/ingen kod kommer att förutse varje formulering och varje kombination av frågor i förväg.

Det är där en LLM spelar en avgörande roll, som ett flexibelt resonemangslager mellan mänskligt språk och dina deterministiska tjänster. Det är också anledningen till att agenter får så mycket uppmärksamhet. Google Cloud:s agentiska AI‑arkitekturvägledning beskriver en agent som en applikation där en AI‑modell fungerar som resonemangsmotor, medan verktyg låter den nå externa system och data.

Anthropic’s Building Effective AI Agents vägledning gör en distinktion som jag återkommer till. I en arbetsflöde, följer modeller och verktyg de vägar som din kod definierar. I en agent, styr LLM:n sin egen process och bestämmer hur den ska använda sina verktyg. Samma vägledning rekommenderar att börja med den enklaste arkitekturen som löser problemet, istället för att lägga till agentisk komplexitet reflexivt. Jag skulle understryka det rådet två gånger.

Begränsningarna med “Låt modellen bestämma”

En modell kan resonera om vad som bör hända. Resonemang är inte detsamma som att verkställa en regel.

Till exempel, ta ett finansiellt arbetsflöde. En LLM kan vara utmärkt på att förstå “skicka samma belopp som jag skickade förra månaden till samma leverantör.” Men bör den också avgöra om överföringen är auktoriserad, beräkna regulatoriska gränser, verifiera kontoinnehav, åsidosätta en säkerhetspolicy och genomföra transaktionen?

Troligen inte. Dessa uppgifter är deterministiska, testbara, granskningsbara och verkställbara, och det är exakt vad traditionell mjukvara är bra på. Risken ökar när modeller får tillgång till verktyg. OWASP’s vägledning för generativ AI‑säkerhet markerar överdriven autonomi som en betydande risk: att ge ett LLM‑baserat system mer funktionalitet, behörigheter eller autonomi än vad uppgiften kräver. En märklig eller manipulerad modellutdata är en sak när den bara producerar text. Det är en mycket större sak när modellen kan agera i den verkliga världen.

Inget av detta betyder att modeller aldrig får vidta åtgärder. Det betyder att modellens autonomi bör begränsas av deterministisk auktoritet.

Code‑First är fortfarande viktigt

Med AI som utvecklas så snabbt är det lätt att känna att konventionell ingenjörskonst har gått ur tiden. Jag skulle säga motsatsen. AI gör bra deterministiska system viktigare, inte mindre.

Kod är fortfarande det rätta valet när en uppgift kräver exakt upprepning. Autentisering är det enklaste exemplet. En modell bör inte “resonera” om någon har administratörsbehörighet. Din applikation bör fråga ett auktoritativt identitets- och åtkomsthanteringssystem. Detsamma gäller för monetära beräkningar, rättighetskontroller, datavalidering, regulatoriska begränsningar, transaktionsgränser, schemavalidering och allt irreversibelt. Dessa kräver explicita kontrakt, inte bästa gissningar.

Det här stämmer överens med ett bredare styrningssätt. NIST AI Risk Management Framework ber organisationer att hantera AI-risk över design, utveckling, driftsättning och användning. Dess följeslagare Generative AI Profile tillägger att generativa system kan behöva extra tillsyn, dokumentation, granskning och kontroller, beroende på den involverade risken.

Jag tycker det är hjälpsamt att dela varje designbeslut i två frågor:

Vad bör hända?

och

Vad får hända?

En LLM kan ofta hjälpa till med den första. Deterministiska system bör vanligtvis ansvara för den andra.

Det hybrida mönstret: resonera probabilistiskt, verkställ deterministiskt

För de flesta företagsapplikationer är det praktiska svaret ett hybrid. LLM fungerar som ett tolknings- och resonemangslager. Deterministiska tjänster fungerar som ett exekverings- och verkställande lager.

Här är ett exempel. Föreställ dig att en AI-assistent hjälper utvecklare att skapa tillfälliga API-testmiljöer, och en utvecklare skriver: “Ge mig en sandlåda för kundens onboarding‑arbetsflöde.”

LLM kan tolka det, lista ut vilket arbetsflöde som sannolikt avses, läsa dokumentationen och föreslå vilka API:er som troligen är relevanta. Men själva skapandet av miljön bör inte bero på fritt genererad text. Kod kan bekräfta att de begärda API:erna finns, validera deras kontrakt, kontrollera behörighet, upprätthålla resursgränser, generera en godkänd konfiguration och köra driftsättningen.

Den grova uppdelningen ser ut så här:

• LLM: förstå, resonera, klassificera, föreslå, sammanfatta.
• Koden: validera, auktorisera, beräkna, persistera, verkställa, exekvera.

Varje sida utför det arbete den är bäst på, och ingen förväntas efterlikna den andras styrkor.

Gränser blir viktigare när agenter blir kraftfullare

Denna separation blir viktigare när vi går från assistenter till agenter. En assistent som ger ett felaktigt svar besvärar någon. En agent med skrivbehörighet i produktion kan skapa en mycket större röra.

Lösningen är inte nödvändigtvis att ta bort autonomi. Det handlar om att gradvis lägga till autonomi samtidigt som explicita kontrollpunkter behålls på plats. Googles vägledning om multi‑agentsystem rekommenderar att para ihop dynamiskt AI‑beteende med deterministiska säkerhetskontroller, observabilitet, tydligt definierad autonomi och mänsklig tillsyn för affärskritiska scenarier.

Mänsklig godkännande kan också byggas in i själva arbetsflödet istället för att vara ett informellt skyddsnät. Microsoft’s agent framework documentation stöder till exempel verktygsanrop som pausas tills en person uttryckligen godkänner den begärda åtgärden.

Principen är enkel: ju högre konsekvenser en handling har, desto starkare bör de deterministiska kontrollerna kring den vara.

Fem frågor att ställa innan du överlämnar en uppgift till en LLM

När jag avgör om en komponent ska vara LLM‑först eller kod‑först går jag igenom följande:

1. Har uppgiften ett objektivt korrekt svar? I så fall bör du luta mot deterministisk kod. Skatteberäkningar, behörigheter och schemavalidering bör inte förändras bara för att en modell tolkar dem annorlunda idag.
2. Involverar den tvetydigt språk eller ostrukturerad information? I så fall kan en LLM tillföra verkligt värde.
3. Vad händer om modellen gör fel? Den rätta arkitekturen för ett mötesprotokoll är mycket annorlunda än den rätta arkitekturen för att initiera en betalning.
4. Kan resultatet valideras oberoende? LLM‑genererade planer blir mycket säkrare när deterministiska regler kan kontrollera den resulterande åtgärden innan den körs.
5. Behöver detta verkligen en agent? Om du redan känner till stegen är ett vanligt arbetsflöde med några riktade LLM‑anrop vanligtvis enklare, billigare, lättare att testa och enklare att driva.

Den sista frågan förtjänar extra uppmärksamhet. Agenter är kraftfulla just för att de kan hantera situationer där du inte kan förutsäga varje steg. Men om du kan förutsäga stegen, så lägger man dem ofta om till ett öppet resonemangsproblem som ofta ger variabilitet utan att tillföra intelligens.

Tillförlitlighet är en arkitektonisk egenskap, inte en prompt

Många team börjar med att försöka förbättra tillförlitligheten nästan uteslutande genom prompt‑utveckling. Prompter är viktiga, men de kan inte bära hela bördan.

Ett produktionssystem bör anta att modellens utdata ibland kan vara ofullständiga, felaktiga, oväntade eller helt felaktiga. OWASP Top 10 för LLM‑applikationer listar risker som prompt‑injektion och felaktig hantering av utdata, vilket förstärker en viktig vana: behandla modellens utdata som opålitlig inmatning till nedströmsystem, inte som instruktioner att köras automatiskt.

Det förändrar frågan du ställer. Istället för “Hur skriver jag en prompt som alltid får modellen att följa regeln?”, fråga “Hur designar jag systemet så att regeln inte kan brytas även när modellen gör ett misstag?”

Det är ett problem med mjukvaruarkitektur, inte ett promptproblem. En prompt kan tala om för en agent att inte utföra en obehörig handling. En auktoriseringstjänst kan faktiskt stoppa den. De två kontrollerna är inte ekvivalenta.

Bortom debatten: Intent‑first‑system

Efter att ha tänkt på allt detta har jag kommit att tro att debatten LLM‑first kontra code‑first pekar mot en tredje idé: intent‑first arkitektur.

I ett intent‑first‑system börjar applikationen med att förstå vad användaren försöker åstadkomma. Det är där en LLM är mest värdefull, eftersom människor sällan är precisa om vad de vill. Därefter omvandlar systemet gradvis den osäkerheten till strukturerade, deterministiska operationer.

En begäran som “Hjälp mig att lösa kundens betalningsproblem” kan omvandlas till en pipeline: förstå avsikten, hämta transaktionen, identifiera felorsaken, rekommendera en lösning, begära godkännande, utföra den godkända operationen.

Vissa av dessa steg drar nytta av språkmodellens resonemang. Andra bör vara fasta tjänster. Arkitekturen definieras inte av om AI eller kod “vinner”. Den definieras av var osäkerhet är acceptabel.

Det viktigaste

Allteftersom modellerna förbättras blir det frestande att ge dem kontroll över större och större delar av stacken. Ibland är det rätt beslut. I andra system blir den mest sofistikerade designen den som medvetet ger modellen mindre befogenhet.

Produktions‑AI‑engineering handlar i slutändan om att placera intelligens vid rätt gräns. Använd språkmodeller där tolkning, resonemang, syntes och anpassning skapar värde. Använd deterministisk programvara där konsistens, auktorisation, precision och verkställande är viktiga. Koppla sedan ihop de två genom smala, observerbara, vältestade gränssnitt.

Framtiden för företags‑AI är förmodligen varken renodlat LLM‑first eller renodlat code‑first. Det är LLM där osäkerhet kräver intelligens, och kod där säkerhet kräver kontroll.

Den distinktionen kan vara mycket viktigare än vilken modell du väljer.