LLM‑First eller Code‑First? Hvor intelligens hører hjemme i produktions‑AI

Hvordan man beslutter, hvad modellen skal håndtere, hvad din kode skal håndtere, og hvordan man forbinder de to.

For et par år siden så arkitekturen for en AI‑applikation sådan ud: send en prompt til en stor sprogmodel → få et svar → vise det til brugeren. Det er ikke længere hele historien i dag. Modellerne bliver bedt om at fortolke intention, hente information, vælge værktøjer, kalde API’er, lave planer og køre flertrins‑arbejdsprocesser.

Den ændring har delt feltet i to – LLM-først eller kode-først

I en LLM‑først‑arkitektur er modellen i centrum og beslutter, hvad der sker næste. Den læser forespørgslen, vælger et værktøj, bestemmer rækkefølgen af operationer, tjekker mellemliggende resultater og ændrer kursen, når det er nødvendigt.

I en kode‑først‑arkitektur har software/kode ansvaret for sekvensering, forretningsregler, validering, tilladelser og udførelse. LLM’en fungerer her som en specialist, som koden kalder, når sprogforståelse eller generering er nødvendig.

Folk elsker at diskutere, hvilken der er bedst. Jeg synes, det er det forkerte argument. Det bedre spørgsmål er, hvor hver form for intelligens hører hjemme. De stærkeste produktionssystemer, jeg har set, er sjældent udelukkende den ene eller den anden. De blander probabilistisk ræsonnement med deterministisk kontrol, og de gør det bevidst.

Hvorfor LLM‑First er så tiltalende

Traditionel software fungerer fremragende, når du kan specificere kravene. For eksempel vælger en bruger et produkt, indtaster et beløb og indsender en betaling. Du definerer de tilladte tilstande, valideringsreglerne, fejltilstandene og transaktionssekvensen i kode. Sådan er det.

Naturligt sprog samarbejder ikke på den måde. Forestil dig en bruger, der skriver: “Find de transaktioner, der ser usædvanlige ud, forklar hvad der skete, og fortæl mig, hvad jeg skal undersøge først.”

Der er ingen fast vej gennem den forespørgsel. Her skal systemet beslutte, hvad “usædvanligt” betyder, finde ud af, hvilke data der er relevante, måske kalde flere værktøjer, veje svaret og skrive en forklaring, som en person kan bruge. Intet team af ingeniører/ingen kode vil kunne forudse hver formulering og hver kombination af anmodninger på forhånd.

Det er, hvor en LLM spiller en vital rolle som et fleksibelt ræsonnementlag mellem menneskeligt sprog og dine deterministiske tjenester. Det er også grunden til, at agenter får så meget opmærksomhed. Google Cloud’s vejledning om agentisk AI‑arkitektur beskriver en agent som en applikation, hvor en AI‑model fungerer som ræsonnementmotor, mens værktøjer giver den adgang til eksterne systemer og data.

Anthropic’s Byg effektive AI-agenter vejledninggør en sondring, som jeg hele tiden vender tilbage til. arbejdsflow, følger modeller og værktøjer de stier, som din kode definerer. I en agent, dirigerer LLM’en sin egen proces og beslutter, hvordan den skal bruge sine værktøjer. Den samme vejledning anbefaler at starte med den simpleste arkitektur, der løser problemet, i stedet for at tilføje agentisk kompleksitet reflexivt. Jeg ville understrege dette råd to gange.

Begrænsningerne ved “Lad modellen beslutte”

En model kan ræsonnere om, hvad der bør ske. Ræsonnement er ikke det samme som at håndhæve en regel.

Tag for eksempel en finansiel arbejdsflow. En LLM kan være fremragende til at forstå “send det samme beløb, jeg sendte sidste måned, til den samme leverandør.” Men bør den også beslutte, om overførslen er autoriseret, beregne regulatoriske grænser, verificere kontoejerskab, tilsidesætte en sikkerhedspolitik og udføre transaktionen?

Sandsynligvis ikke. Disse opgaver er deterministiske, testbare, auditerbare og håndhævelige, og det er præcis, hvad traditionel software er god til. Risikoen vokser, efterhånden som modeller får adgang til værktøjer. OWASP’s vejledning om generativ AI-sikkerhed markerer overdreven agentur som en væsentlig risiko: at give et LLM-baseret system mere funktionalitet, tilladelser eller autonomi, end dets opgave kræver. Et mærkeligt eller manipuleret modeloutput er én ting, når det kun producerer tekst. Det er en langt større sag, når modellen kan handle i den virkelige verden.

Intet af dette betyder, at modeller aldrig må foretage handlinger. Det betyder, at modelautonomi bør begrænses af deterministisk autoritet.

Code‑First er stadig vigtigt

Med AI, der udvikler sig så hurtigt, er det let at føle, at konventionel ingeniørkunst er gået af mode. Jeg vil argumentere for det modsatte. AI gør gode deterministiske systemer vigtigere, ikke mindre.

Kode er stadig det rigtige valg, når en opgave kræver præcis gentagelighed. Godkendelse er det simpleste eksempel. En model bør ikke “ræsonnere” om, hvorvidt nogen har administratorrettigheder. Din applikation bør spørge et autoritativt identitets‑ og adgangsstyringssystem. Det samme gælder for monetære beregninger, rettighedstjek, datavalidering, regulatoriske begrænsninger, transaktionsgrænser, skemavalidering og alt, der er irreversibelt. Disse kræver eksplicitte kontrakter, ikke gætteri.

Dette passer med bredere styringsmæssig tænkning. Den NIST AI Risk Management Framework beder organisationer om at håndtere AI‑risiko på tværs af design, udvikling, implementering og brug. Dens ledsager Generative AI Profile tilføjer, at generative systemer kan have brug for ekstra tilsyn, dokumentation, gennemgang og kontrol, afhængigt af den involverede risiko.

Så finder jeg det nyttigt at opdele hver designbeslutning i to spørgsmål:

Hvad skal ske?

og

Hvad er tilladt at ske?

En LLM kan ofte hjælpe med den første. Deterministiske systemer bør som regel håndtere den anden.

Det hybride mønster: Resoner probabilistisk, udfør deterministisk

For de fleste virksomheds‑applikationer er det praktiske svar et hybrid. LLM’en fungerer som et fortolknings‑ og resonneringslag. Deterministiske tjenester fungerer som udførelses‑ og håndhævelseslaget.

Her er et eksempel. Forestil dig, at en AI‑assistent hjælper udviklere med at oprette midlertidige API‑testmiljøer, og en udvikler skriver: \”Giv mig et sandbox‑miljø til kundens onboarding‑workflow.\”

LLM’en kan fortolke det, udlede hvilken workflow der sandsynligvis menes, læse dokumentationen og foreslå hvilke API’er der sandsynligvis er relevante. Men selve oprettelsen af miljøet bør ikke afhænge af fri‑formet genereret tekst. Kode kan bekræfte, at de anmodede API’er findes, validere deres kontrakter, tjekke autorisation, håndhæve ressourcegrænser, generere en godkendt konfiguration og udføre implementeringen.

Den grove opdeling ser således ud:

• LLM’en: forstå, resonere, klassificere, foreslå, opsummere.
• Koden: validere, autorisere, beregne, persistere, håndhæve, udføre.

Hver side udfører det arbejde, den er bedst til, og ingen af dem bliver bedt om at efterligne den andens styrker.

Grænser er vigtigere, efterhånden som agenter får mere magt

Denne opdeling bliver vigtigere, efterhånden som vi bevæger os fra assistenter til agenter. En assistent, der giver et dårligt svar, generer nogen. En agent med skriveadgang til produktion kan forårsage et langt større rod.

Løsningen er ikke nødvendigvis at fjerne autonomi. Det handler om at tilføje autonomi gradvist, mens man bevarer eksplicitte kontrolpunkter.Google’s vejledning om multi‑agent‑systemer anbefaler at kombinere dynamisk AI‑adfærd med deterministisk sikkerhedskontrol, observerbarhed, klart defineret autonomi og menneskelig tilsyn for forretningskritiske scenarier.

Menneskelig godkendelse kan også indbygges i selve workflowet i stedet for at være et uformelt sikkerhedsnet. Microsoft’s agent‑framework‑dokumentation, for eksempel understøtter den værktøjskald, der pause indtil en person eksplicit godkender den anmodede handling.

Princippet er enkelt: jo højere konsekvenserne af en handling er, desto stærkere skal de deterministiske kontroller omkring den være.

Fem spørgsmål at stille, før du overlader en opgave til en LLM

Når jeg beslutter, om en komponent skal være LLM‑first eller code‑first, gennemgår jeg disse:

1. Har opgaven ét objektivt korrekt svar? Hvis ja, læn dig mod deterministisk kode. Skatteberegninger, tilladelser og schema‑validering bør ikke ændre sig, fordi en model læser dem anderledes i dag.
2. Involverer den tvetydigt sprog eller ustruktureret information? Hvis ja, kan en LLM tilføre reel værdi.
3. Hvad sker der, hvis modellen tager fejl? Den rette arkitektur for et møde‑referat er meget anderledes end den rette arkitektur for at starte en betaling.
4. Kan outputtet valideres uafhængigt? LLM‑genererede planer bliver meget sikrere, når deterministiske regler kan kontrollere den resulterende handling, før den udføres.
5. Har dette virkelig brug for en agent? Hvis du allerede kender trinnene, er et regulært workflow med et par målrettede LLM‑kald som regel enklere, billigere, lettere at teste og lettere at drive.

Det sidste spørgsmål fortjener ekstra opmærksomhed. Agenter er kraftfulde netop fordi de kan håndtere situationer, hvor du ikke kan forudsige hvert trin. Men hvis du kan forudsige trinnene, så tilføjer det at gøre dem til et åbent resonneringsproblem ofte variabilitet uden at tilføre intelligens.

Pålidelighed er en arkitektonisk egenskab, ikke en prompt

Mange teams begynder med at forsøge at forbedre pålidelighed næsten udelukkende gennem prompt‑engineering. Prompter er vigtige, men de kan ikke bære hele belastningen.

Et produktionssystem bør antage, at modeloutput nogle gange vil være ufuldstændigt, fejlbehæftet, uventet eller blot forkert. OWASP Top 10 for LLM‑applikationer lister risici som promptinjektion og forkert output‑håndtering, hvilket understreger en vigtig vane: behandle modeloutput som upålidelig input til efterfølgende systemer, ikke som instruktioner der skal køres automatisk.

Det ændrer det spørgsmål, du stiller. I stedet for \”Hvordan skriver jeg en prompt, der altid får modellen til at følge reglen?\”, spørg \”Hvordan designer jeg systemet, så reglen ikke kan brydes, selv når modellen begår en fejl?\”

Det er et softwarearkitekturproblem, ikke et prompt‑problem. En prompt kan fortælle en agent, at den ikke skal udføre en uautoriseret handling. En autorisationstjeneste kan faktisk stoppe den. De to kontroller er ikke ækvivalente.

Udover debatten: Intent‑First‑systemer

Når man tænker over alt dette, er jeg kommet til at tro, at debatten mellem LLM‑first og code‑first peger mod en tredje idé: intent‑first arkitektur.

I et intent‑first‑system starter applikationen med at forstå, hvad brugeren forsøger at opnå. Det er her, en LLM er mest værdifuld, fordi folk sjældent er præcise om, hvad de vil. Derfra konverterer systemet gradvist denne uklarhed til strukturerede, deterministiske operationer.

En anmodning som \”Help me resolve the customer’s payment issue\” kan blive til en pipeline: forstå intentionen, hente transaktionen, identificere fejlkilden, anbefale en løsning, anmode om godkendelse, udføre den godkendte handling.

Nogle af disse trin drager fordel af sprogmodel‑reasoning. Andre bør være faste tjenester. Arkitekturen er ikke defineret af, om AI eller kode “vinder”. Den er defineret af, hvor usikkerhed er acceptabel.

Konklusionen

Efterhånden som modellerne forbedres, vil det være fristende at give dem kontrol over større og større dele af stakken. Nogle gange vil det være den rigtige beslutning. I andre systemer vil det mest sofistikerede design være det, der bevidst giver modellen mindre autoritet.

Produktions‑AI‑engineering handler i sidste ende om at placere intelligens ved den rette grænse. Brug sprogmodeller, hvor fortolkning, reasoning, syntese og tilpasning skaber værdi. Brug deterministisk software, hvor konsistens, autorisation, præcision og håndhævelse er vigtige. Forbind derefter de to gennem smalle, observerbare, veltestede grænseflader.

Fremtiden for enterprise‑AI er sandsynligvis ikke udelukkende LLM‑first eller udelukkende code‑first. Det er LLM, hvor usikkerhed kræver intelligens, og kode, hvor sikkerhed kræver kontrol.

Den sondring kan være langt vigtigere end hvilken model du vælger.