LLM‑Først eller Kode‑Først? Hvor intelligens hører hjemme i produksjons‑AI

Hvordan bestemme hva modellen skal håndtere, hva koden din skal håndtere, og hvordan koble de to sammen.

For noen år siden så arkitekturen til en AI‑applikasjon slik ut: send en prompt til en stor språkmodell -> få et svar -> vise det til brukeren. Det er ikke hele historien lenger i dag. Modellene blir bedt om å tolke intensjon, hente informasjon, velge verktøy, kalle API‑er, lage planer og kjøre flertrinns arbeidsflyter.

Den endringen har delt feltet i to – LLM‑Først eller Kode‑Først

I en LLM‑først‑arkitektur er modellen i sentrum og bestemmer hva som skjer videre. Den leser forespørselen, velger et verktøy, bestemmer rekkefølgen på operasjonene, sjekker mellomresultater og endrer kursen når det er nødvendig.

I en kode‑først‑arkitektur har programvaren/koden ansvaret for sekvensering, forretningsregler, validering, tillatelser og utførelse. LLM‑en her er som en spesialist koden kaller på når språkforståelse eller -generering er nødvendig.

Folk elsker å diskutere hvilken som er best. Jeg mener det er feil argument. Det bedre spørsmålet er hvor hver type intelligens hører hjemme. De sterkeste produksjonssystemene jeg har sett er sjelden kun den ene eller den andre. De blander probabilistisk resonnering med deterministisk kontroll, og de gjør det bevisst.

Hvorfor LLM‑Først er så tiltalende

Tradisjonell programvare fungerer utmerket når du kan spesifisere kravene. For eksempel velger en bruker et produkt, angir et beløp og sender inn en betaling. Du definerer tillatte tilstander, valideringsregler, feilsituasjoner og transaksjonssekvensen i kode. Ferdig.

Naturlig språk samarbeider ikke på den måten. Forestill deg en bruker som skriver: «Finn transaksjonene som ser uvanlige ut, forklar hva som skjedde, og fortell meg hva jeg bør undersøke først.»

Det finnes ingen fast vei gjennom den forespørselen. Systemet må her avgjøre hva «uvanlig» betyr, finne ut hvilke data som er relevante, eventuelt kalle flere verktøy, vurdere svaret og skrive en forklaring som en person kan bruke. Ingen gruppe ingeniører/ingen kode vil kunne forutse hver formulering og hver kombinasjon av forespørsler på forhånd.

Det er hvor en LLM spiller en avgjørende rolle, som et fleksibelt resonneringslag mellom menneskelig språk og dine deterministiske tjenester. Det er også grunnen til at agenter får så mye oppmerksomhet. Google Cloud sin veiledning for agentisk AI‑arkitektur beskriver en agent som en applikasjon hvor en AI‑modell fungerer som resonneringsmotor, mens verktøy lar den nå eksterne systemer og data.

Anthropic sin Bygge effektive AI‑agenter veiledning gjør en distinksjon jeg stadig vender tilbake til. I en arbeidsflyt, modeller og verktøy følger stier som koden din definerer. I en agent, LLM‑en styrer sin egen prosess og bestemmer hvordan den skal bruke verktøyene sine. Den samme veiledningen anbefaler å starte med den enkleste arkitekturen som løser problemet, i stedet for å legge til agentisk kompleksitet ved reflex. Jeg ville understreket det rådet to ganger.

Begrensningene ved «La modellen bestemme»

En modell kan resonere om hva som bør skje. Resonering er ikke det samme som å håndheve en regel.

For eksempel en finansiell arbeidsflyt. En LLM kan være flink til å forstå «send samme beløp som jeg sendte forrige måned til samme leverandør». Men bør den også avgjøre om overføringen er autorisert, beregne regulatoriske grenser, verifisere kontoeierskap, overstyre en sikkerhetspolicy og utføre transaksjonen?

Sannsynligvis ikke. Disse oppgavene er deterministiske, testbare, reviderbare og håndhevbare, og det er akkurat det tradisjonell programvare er god på. Risikoen øker når modeller får tilgang til verktøy. OWASP sin veiledning for generativ AI‑sikkerhet markerer overdrevet myndighet som en betydelig risiko: å gi et LLM‑basert system mer funksjonalitet, tillatelser eller autonomi enn oppgaven krever. En merkelig eller manipulert modellutdata er én ting når den kun produserer tekst. Det er en mye større sak når modellen kan handle i den virkelige verden.

Dette betyr ikke at modeller aldri skal utføre handlinger. Det betyr at modellautonomi bør begrenses av deterministisk autoritet.

Kode‑Først er fortsatt viktig

Med AI som utvikler seg så raskt, er det lett å føle at tradisjonell ingeniørkunst er gått av moten. Jeg vil hevde det motsatte. AI gjør gode deterministiske systemer viktigere, ikke mindre.

Kode er fortsatt det rette valget når en oppgave krever nøyaktig gjentakbarhet. Autentisering er det enkleste eksempelet. En modell bør ikke «resonnere» om noen har admin‑rettigheter. Applikasjonen din bør spørre et autoritativt identitets‑ og tilgangsstyringssystem. Det samme gjelder for pengeberegninger, rettighetskontroller, datavalidering, regulatoriske begrensninger, transaksjonsgrenser, skjema‑validering og alt som er irreversibelt. Disse krever eksplisitte kontrakter, ikke gjetninger.

Dette stemmer overens med bredere styrings tenkning. NIST AI Risk Management Framework ber organisasjoner om å håndtere AI‑risiko gjennom design, utvikling, utrulling og bruk. Dens tilhørende Generative AI Profile legger til at generative systemer kan trenge ekstra tilsyn, dokumentasjon, gjennomgang og kontroller, avhengig av den aktuelle risikoen.

Derfor synes jeg det er nyttig å dele hver designbeslutning inn i to spørsmål:

Hva bør skje?

og

Hva er tillatt å skje?

En LLM kan ofte hjelpe med den første. Deterministiske systemer bør vanligvis håndtere den andre.

Hybridmønsteret: Resonner sannsynlighetsbasert, utfør deterministisk

For de fleste bedriftsapplikasjoner er det praktiske svaret et hybrid. LLM‑en fungerer som et tolk‑ og resonneringslag. Deterministiske tjenester fungerer som utførelses‑ og håndhevelseslaget.

Her er et eksempel. Si at en AI‑assistent hjelper utviklere med å sette opp midlertidige API‑testmiljøer, og en utvikler skriver: «Gi meg et sandkasse‑miljø for kunde‑onboarding‑arbeidsflyten.»

LLM‑en kan tolke dette, finne ut hvilken arbeidsflyt som sannsynligvis menes, lese dokumentasjonen og foreslå hvilke API‑er som sannsynligvis er relevante. Men selve opprettelsen av miljøet bør ikke avhenge av fritt generert tekst. Kode kan bekrefte at de forespurte API‑ene finnes, validere deres kontrakter, sjekke autorisasjon, håndheve ressursgrenser, generere en godkjent konfigurasjon og kjøre utrullingen.

Den grove inndelingen ser slik ut:

• LLM‑en: forstå, resonner, klassifiser, foreslå, oppsummere.
• Koden: valider, autoriser, beregn, persister, håndhev, utfør.

Hver side gjør det den er best på, og ingen blir bedt om å etterligne den andres styrker.

Grenser blir viktigere etter hvert som agenter blir kraftigere

Denne separasjonen blir viktigere når vi går fra assistenter til agenter. En assistent som gir et dårlig svar er bare til ulempe for noen. En agent med skriveadgang til produksjon kan skape et mye større rot.

Løsningen er ikke nødvendigvis å fjerne autonomi. Det handler om å legge til autonomi gradvis mens man beholder eksplisitte kontrollpunkter.Google sin veiledning om multi‑agent‑systemeranbefaler å kombinere dynamisk AI‑atferd med deterministiske sikkerhetskontroller, observabilitet, tydelig definert autonomi og menneskelig tilsyn i forretningskritiske scenarier.

Menneskelig godkjenning kan også bygges inn i selve arbeidsflyten i stedet for å være et uformelt sikkerhetsnett. Microsoft’s agent framework documentation, for eksempel, støtter verktøy‑kall som pause til en person eksplisitt godkjenner den forespurte handlingen.

Prinsippet er enkelt: jo høyere konsekvensene av en handling er, desto sterkere bør de deterministiske kontrollene rundt den være.

Fem spørsmål du bør stille før du gir en oppgave til en LLM

Når jeg skal avgjøre om en komponent skal være LLM‑først eller kode‑først, går jeg gjennom disse:

1. Har oppgaven ett objektivt korrekt svar? I så fall bør du lene deg mot deterministisk kode. Skatteberegninger, tillatelser og skjema‑validering bør ikke endres fordi en modell tolker dem annerledes i dag.
2. Involverer den tvetydig språk eller ustrukturert informasjon? I så fall kan en LLM tilføre reell verdi.
3. Hva skjer hvis modellen tar feil? Den riktige arkitekturen for et møtesammendrag er svært forskjellig fra den riktige arkitekturen for å initiere en betaling.
4. Kan resultatet valideres uavhengig? LLM‑genererte planer blir mye tryggere når deterministiske regler kan sjekke den resulterende handlingen før den kjøres.
5. Trenger dette virkelig en agent? Hvis du allerede kjenner trinnene, er en vanlig arbeidsflyt med noen målrettede LLM‑kall vanligvis enklere, billigere, lettere å teste og lettere å drifte.

Det siste spørsmålet fortjener ekstra oppmerksomhet. Agenter er kraftige nettopp fordi de kan håndtere situasjoner der du ikke kan forutsi hvert trinn. Men hvis du kan forutsi trinnene, fører det ofte til at du gjør dem til et åpent resonneringsproblem som tilfører variasjon uten å tilføre intelligens.

Pålitelighet er en arkitektonisk egenskap, ikke en prompt

Mange team begynner med å prøve å forbedre pålitelighet nesten utelukkende gjennom prompt‑engineering. Prompt‑er er viktige, men de kan ikke bære hele belastningen.

Et produksjonssystem bør anta at modellens output noen ganger vil være ufullstendig, feilformatert, uventet eller rett og slett feil. OWASP Top 10 for LLM‑applikasjoner lister risikoer som promptinjeksjon og feil håndtering av utdata, noe som forsterker en viktig vane: behandle modellens output som upålitelig input til nedstrøms systemer, ikke som instruksjoner som skal kjøres automatisk.

Det endrer spørsmålet du stiller. I stedet for «Hvordan skriver jeg en prompt som alltid får modellen til å følge regelen?», spør «Hvordan designer jeg systemet slik at regelen ikke kan brytes selv når modellen gjør en feil?»

Det er et problem med programvarearkitektur, ikke et prompt‑problem. En prompt kan fortelle en agent at den ikke skal utføre en uautorisert handling. En autoriseringstjeneste kan faktisk stoppe den. De to kontrollene er ikke ekvivalente.

Utover Debatten: Intensjons‑Først‑Systemer

Når jeg tenker på alt dette, har jeg kommet til å tro at debatten LLM‑først versus kode‑først peker mot en tredje idé: intensjons‑først arkitektur.

I et intensjons‑først‑system starter applikasjonen med å forstå hva brukeren prøver å oppnå. Det er her en LLM er mest verdifull, fordi folk sjelden er presise om hva de vil. Derfra konverterer systemet jevnt den uklarheten til strukturerte, deterministiske operasjoner.

En forespørsel som «Hjelp meg med å løse kundens betalingsproblem» kan bli til en pipeline: forstå intensjon, hente transaksjonen, identifisere feilsårsaken, anbefale en løsning, be om godkjenning, utføre den godkjente handlingen.

Noen av disse fasene drar nytte av språkmodell‑resonnement. Andre bør være faste tjenester. Arkitekturen er ikke definert av om AI eller kode «vinner». Den er definert av hvor usikkerhet er akseptabel.

Det viktigste

Etter hvert som modeller forbedres, vil det være fristende å gi dem kontroll over stadig større deler av stacken. Noen ganger vil det være riktig valg. I andre systemer vil den mest sofistikerte designen være den som bevisst gir modellen mindre myndighet.

Produksjons‑AI‑engineering handler i bunn og grunn om å plassere intelligens ved riktig grense. Bruk språkmodeller der tolkning, resonnering, syntese og tilpasning skaper verdi. Bruk deterministisk programvare der konsistens, autorisering, presisjon og håndheving er viktig. Deretter kobler du de to gjennom smale, observerbare, grundig testede grensesnitt.

Fremtiden for bedrifts‑AI er sannsynligvis verken rent LLM‑først eller rent kode‑først. Det er LLM der usikkerhet krever intelligens, og kode der sikkerhet krever kontroll.

Den distinksjonen kan være langt viktigere enn hvilken modell du velger.