LLM-First of Code-First? Waar intelligentie thuishoort in productie‑AI

Hoe bepaal je wat het model moet afhandelen, wat je code moet afhandelen, en hoe je de twee verbindt.

Een paar jaar geleden zag de architectuur van een AI‑applicatie er als volgt uit: een prompt naar een groot taalmodel sturen → een antwoord ontvangen → het aan de gebruiker tonen. Dat is tegenwoordig niet meer het hele verhaal. De modellen worden gevraagd om intentie te interpreteren, informatie op te halen, tools te kiezen, API’s aan te roepen, plannen te maken en meerstaps‑workflows uit te voeren.

Die verschuiving heeft het veld opgesplitst in twee – LLM-First of Code-First

In een LLM‑first‑architectuur staat het model centraal en beslist wat er vervolgens gebeurt. Het leest het verzoek, kiest een tool, bepaalt de volgorde van bewerkingen, controleert tussentijdse resultaten en past de koers aan wanneer dat nodig is.

In een code‑first‑architectuur blijft software/code verantwoordelijk voor de volgorde, bedrijfsregels, validatie, permissies en uitvoering. Het LLM fungeert hier als een specialist die de code oproept wanneer taalbegrip of -generatie nodig is.

Mensen houden ervan te discussiëren over welke beter is. Ik vind dat het verkeerde argument is. De betere vraag is waar elke vorm van intelligentie thuishoort. De sterkste productiesystemen die ik heb gezien zijn zelden puur de een of de ander. Ze combineren probabilistisch redeneren met deterministische controle, en dat doen ze bewust.

Waarom LLM‑First zo aantrekkelijk is

Traditionele software werkt uitstekend wanneer je de vereisten kunt uitschrijven. Bijvoorbeeld, een gebruiker kiest een product, voert een bedrag in en dient een betaling in. Je definieert de toegestane toestanden, de validatieregels, de foutcondities en de transactiereeks in code. Klaar.

Natuurlijke taal werkt niet op die manier mee. Stel je een gebruiker voor die typt: “Zoek de transacties die er ongebruikelijk uitzien, leg uit wat er gebeurd is, en vertel me wat ik eerst moet onderzoeken.”

Er is geen vaste route door dat verzoek. Het systeem moet hier bepalen wat “ongewoon” betekent, uitzoeken welke gegevens relevant zijn, mogelijk meerdere tools aanroepen, het antwoord afwegen en een uitleg schrijven die een persoon kan gebruiken. Geen enkel team van engineers/no‑code zal van tevoren elke formulering en elke combinatie van vragen kunnen voorspellen.

Het is waar een LLM een cruciale rol speelt, als een flexibele redeneerlagen tussen menselijke taal en je deterministische services. Het is ook de reden waarom agenten zoveel aandacht krijgen. Google Cloud’s agentische AI‑architectuurrichtlijnbeschrijft een agent als een applicatie waarbij een AI‑model fungeert als de redeneermotor, terwijl tools het in staat stellen externe systemen en data te bereiken.

Anthropic’s Building Effective AI Agents richtlijn maakt een onderscheid waar ik steeds op terugkom. In een werkstroom, modellen en hulpmiddelen volgen paden die uw code definieert. In een agent, de LLM leidt zijn eigen proces en beslist hoe het zijn hulpmiddelen moet gebruiken. Dezelfde richtlijn beveelt aan om te beginnen met de eenvoudigste architectuur die het probleem oplost, in plaats van agentische complexiteit toe te voegen door reflex. Ik zou dat advies twee keer onderstrepen.

De grenzen van “Laat het model beslissen”

Een model kan redeneren over wat er moet gebeuren. Redeneren is niet hetzelfde als het handhaven van een regel.

Neem bijvoorbeeld een financiële werkstroom. Een LLM kan uitstekend begrijpen “stuur hetzelfde bedrag dat ik vorige maand naar dezelfde leverancier heb gestuurd”. Maar moet het ook beslissen of de overboeking geautoriseerd is, de regelgeving limieten berekenen, eigendom van de rekening verifiëren, een beveiligingsbeleid overschrijven, en de transactie uitvoeren?

Waarschijnlijk niet. Deze taken zijn deterministisch, testbaar, controleerbaar en afdwingbaar, en dat is precies waar traditionele software goed in is. Het risico groeit naarmate modellen toegang krijgen tot tools. OWASP’s generatieve AI-beveiligingsrichtlijnmarkeertexcessieve autonomie als een aanzienlijk risico: een LLM‑gebaseerd systeem meer functionaliteit, permissies of autonomie geven dan de taak vereist. Een vreemde of gemanipuleerde modeloutput is één ding wanneer het alleen tekst produceert. Het is een veel groter probleem wanneer het model in de echte wereld kan handelen.

Dit betekent niet dat modellen nooit acties mogen ondernemen. Het betekent dat modelautonomie begrensd moet worden door deterministische autoriteit.

Code‑First blijft belangrijk

Met AI die zo snel evolueert, is het gemakkelijk te denken dat conventioneel engineering uit de mode is geraakt. Ik zou het tegenovergestelde beweren. AI maakt goede deterministische systemen belangrijker, niet minder.

Code blijft de juiste keuze wanneer een taak exacte herhaalbaarheid vereist. Authenticatie is het eenvoudigste voorbeeld. Een model mag niet “redeneren” over of iemand admin‑rechten heeft. Je applicatie moet een autoritatief identiteit‑ en toegangsbeheersysteem raadplegen. Hetzelfde geldt voor monetaire berekeningen, rechttoe‑toetsen, datavalidatie, regelgeving‑beperkingen, transactielimieten, schemavalidatie en alles wat onomkeerbaar is. Deze vereisen expliciete contracten, geen gokwerk.

Dit sluit aan bij bredere governance-denken. Het NIST AI Risk Management Framework vraagt organisaties om AI-risico te beheren over ontwerp, ontwikkeling, uitrol en gebruik. De bijbehorende Generative AI Profile voegt toe dat generatieve systemen extra toezicht, documentatie, beoordeling en controles kunnen nodig hebben, afhankelijk van het risico dat ermee gemoeid is.

Ik vind het daarom handig om elke ontwerpbeslissing in twee vragen te verdelen:

Wat moet er gebeuren?

en

Wat mag er gebeuren?

Een LLM kan vaak helpen bij het eerste. Deterministische systemen zouden meestal het tweede moeten beheren.

Het hybride patroon: probabilistisch redeneren, deterministisch uitvoeren

Voor de meeste bedrijfsapplicaties is het praktische antwoord een hybride aanpak. De LLM fungeert als een interpretatie- en redeneerlagen. Deterministische services vormen de uitvoerings- en handhavingslaag.

Hier is een voorbeeld. Stel dat een AI-assistent ontwikkelaars helpt tijdelijke API-testomgevingen op te zetten, en een ontwikkelaar typt: “Geef me een sandbox voor de klant‑onboarding‑workflow.”

De LLM kan dat interpreteren, uitzoeken welke workflow waarschijnlijk bedoeld wordt, de documentatie lezen en suggereren welke API’s waarschijnlijk relevant zijn. Maar het daadwerkelijk creëren van de omgeving mag niet afhangen van vrij‑vormige gegenereerde tekst. Code kan bevestigen dat de gevraagde API’s bestaan, hun contracten valideren, autorisatie controleren, resource‑limieten handhaven, een goedgekeurde configuratie genereren en de uitrol uitvoeren.

De ruwe verdeling ziet er als volgt uit:

• De LLM: begrijpen, redeneren, classificeren, voorstellen, samenvatten.
• De code: valideren, autoriseren, berekenen, opslaan, handhaven, uitvoeren.

Elke kant doet het werk waar hij het beste in is, en niemand wordt gevraagd de sterke punten van de ander te imiteren.

Grenzen worden belangrijker naarmate agents krachtiger worden

Deze scheiding wordt belangrijker naarmate we van assistenten naar agents gaan. Een assistent die een slecht antwoord geeft, veroorzaakt ongemak. Een agent met schrijfrechten in productie kan echter een veel grotere puinhoop veroorzaken.

De oplossing is niet per se om autonomie te verwijderen. Het is om autonomie geleidelijk toe te voegen terwijl expliciete controlepunten behouden blijven. Google’s richtlijn over multi-agent systemen beveelt aan om dynamisch AI-gedrag te combineren met deterministische beveiligingscontroles, observeerbaarheid, duidelijk gedefinieerde autonomie en menselijke toezicht voor bedrijfskritische scenario’s.

Menselijke goedkeuring kan ook in de workflow zelf worden ingebouwd in plaats van een informele veiligheidsnet. Microsoft’s agent framework documentation ondersteunt bijvoorbeeld tool‑calls die pauzeren totdat een persoon expliciet de gevraagde handeling goedkeurt.

Het principe is simpel: hoe groter de consequenties van een actie, hoe sterker de deterministische controles eromheen moeten zijn.

Vijf vragen om te stellen voordat je een taak aan een LLM toevertrouwt

Wanneer ik bepaal of een component LLM‑first of code‑first moet zijn, doorloop ik de volgende vragen:

1. Heeft de taak één objectief correct antwoord? Zo ja, ga dan voor deterministische code. Belastingberekeningen, permissies en schema‑validatie mogen niet veranderen omdat een model ze vandaag anders leest.
2. Betreft het vage taal of ongestructureerde informatie? Zo ja, kan een LLM echte meerwaarde bieden.
3. Wat gebeurt er als het model het fout heeft? De juiste architectuur voor een samenvatting van een vergadering verschilt sterk van de juiste architectuur voor het initiëren van een betaling.
4. Kan de output onafhankelijk worden gevalideerd? LLM‑gegenereerde plannen worden veel veiliger wanneer deterministische regels de resulterende actie kunnen controleren voordat deze wordt uitgevoerd.
5. Heeft dit echt een agent nodig? Als je de stappen al kent, is een reguliere workflow met een paar gerichte LLM‑calls meestal eenvoudiger, goedkoper, makkelijker te testen en te beheren.

Die laatste vraag verdient extra aandacht. Agents zijn krachtig juist omdat ze situaties aankunnen waarin je niet elke stap kunt voorspellen. Maar als je kunt de stappen voorspellen, leidt het omzetten ervan in een open‑ended redeneerprobleem vaak tot variabiliteit zonder extra intelligentie toe te voegen.

Betrouwbaarheid is een architecturale eigenschap, geen prompt

Veel teams beginnen met het verbeteren van betrouwbaarheid bijna uitsluitend via prompt‑engineering. Prompts zijn belangrijk, maar ze kunnen de volledige last niet dragen.

Een productiesysteem moet ervan uitgaan dat modeloutput soms onvolledig, misvormd, onverwacht of gewoon fout kan zijn. De OWASP Top 10 voor LLM-toepassingen somt risico’s op zoals prompt injection en improper output handling, wat een belangrijke gewoonte versterkt: behandel modeloutput als onbetrouwbare invoer voor downstream‑systemen, niet als instructies die automatisch uitgevoerd moeten worden.

Dat verandert de vraag die je stelt. In plaats van “Hoe schrijf ik een prompt die het model altijd de regel laat volgen?”, vraag je “Hoe ontwerp ik het systeem zodat de regel niet kan worden overtreden, zelfs wanneer het model een fout maakt?”

Dat is een software‑architectuurprobleem, geen prompt‑probleem. Een prompt kan een agent vertellen geen ongeautoriseerde handeling uit te voeren. Een autorisatieservice kan dat daadwerkelijk blokkeren. Die twee controles zijn niet gelijkwaardig.

Voorbij het debat: intent‑first systemen

Als ik hierover nadenk, ben ik tot de conclusie gekomen dat het debat LLM‑first versus code‑first wijst op een derde idee: intent‑first architectuur.

In een intent‑first systeem begint de applicatie met het begrijpen wat de gebruiker probeert te bereiken. Daar is een LLM het meest waardevol, omdat mensen zelden precies zijn over wat ze willen. Vanaf dat punt zet het systeem die vage intentie geleidelijk om in gestructureerde, deterministische bewerkingen.

Een verzoek als “Help me het betalingsprobleem van de klant op te lossen” kan zich vertalen naar een pijplijn: intentie begrijpen, de transactie ophalen, de foutoorzaak identificeren, een oplossing aanbevelen, goedkeuring vragen, de goedgekeurde handeling uitvoeren.

Sommige van die fasen profiteren van redeneren met een taalmodel. Andere moeten vaste services zijn. De architectuur wordt niet bepaald door of AI of code “wint.” Ze wordt bepaald door waar onzekerheid acceptabel is.

De conclusie

Naarmate modellen verbeteren, zal het verleidelijk zijn hen controle te geven over steeds grotere delen van de stack. Soms is dat de juiste keuze. In andere systemen zal het meest verfijnde ontwerp het ontwerp zijn dat het model bewust minder autoriteit geeft.

Productie‑AI‑engineering draait uiteindelijk om het plaatsen van intelligentie op de juiste grens. Gebruik taalmodellen waar interpretatie, redeneren, synthese en aanpassing waarde creëren. Gebruik deterministische software waar consistentie, autorisatie, precisie en handhaving belangrijk zijn. Verbind vervolgens beide via smalle, observeerbare, goed geteste interfaces.

De toekomst van enterprise‑AI is waarschijnlijk niet puur LLM‑first of puur code‑first. Het is LLM waar onzekerheid om intelligentie vraagt, en code waar zekerheid om controle vraagt.

Dat onderscheid kan veel belangrijker zijn dan welk model je kiest.