Prompt Engineering Is Dood. Leve Loop Engineering.

Het citaat dat de illusie verbrijzelde

Een paar dagen geleden ging één enkel citaat van Boris Cherny — de engineer die de ontwikkeling van Claude Code bij Anthropic leidt — in alle stilte als een schokgolf door de softwaregemeenschap.

Tijdens een publiek panel lichtte Cherny een tipje van de sluier op over hoe de mensen die ’s werelds meest geavanceerde codeer-AI bouwen, daadwerkelijk met hun eigen modellen werken. Wat hij zei, daagde niet alleen de status quo uit — het verklaarde een hele opkomende discipline achterhaald:

Laat dat even bezinken.

De man met beide handen aan het stuur van het beste ontwikkelaarsmodel ter wereld vertelt je dat hij zijn handen van het stuur heeft gehaald. Hij zit niet in een chatvenster de perfecte alinea instructies te slijpen. Hij schrijft code die de AI dwingt met zichzelf te praten, haar eigen fouten te beoordelen en ze op te lossen binnen een gesloten, autonoom circuit. Hij bouwt de machine die het model stuurt — en laat het dan rijden.

Als je nog steeds je dagen besteedt aan het bijschaven van prompts om het juiste stukje code uit een LLM te lokken, is zijn boodschap keihard duidelijk: je optimaliseert een wereld die al verdwenen is.

De paradigmaverschuiving: van micromanagement naar systeemarchitectuur

Om te zien waarom dit een tektonische verschuiving is, kijk naar hoe onze relatie met generatieve AI in slechts een paar jaar is geëvolueerd.

Fase 1 — De lineaire prompt (het menselijke knelpunt)

Tot voor kort was de hele industrie geobsedeerd door prompt engineering. We behandelden LLM’s als briljante maar snel afgeleide junior ontwikkelaars. De workflow was lineair, kwetsbaar en volledig handmatig:

jij prompt  ─▶  AI schrijft code  ─▶  jij vindt de bug  ─▶  jij verbetert de prompt  ─┐
     ▲                                                                          │
     └─────────────────────────  weer met de hand  ◀─────────────────────────────┘

In dit paradigma is de mens het knelpunt. Je schrijft een prompt, leest de uitvoer, spot een syntaxfout, plakt die terug in de chat, en hoopt dat het model de context vijf stappen later niet vergeten is. Het voelt productief. Het is uitputtend, niet-schaalbaar micromanagement — en het kan absoluut niet draaien terwijl je slaapt.

Fase 2 — Loop engineering (het autonome circuit)

Wat Cherny beschrijft is loop engineering — agentic workflows waarbij de mens volledig uit de uitvoeringslus stapt. Je stopt met autorijden. Je bouwt het circuit en laat de machine de rondjes rijden.

In plaats van een prompt te schrijven om een probleem op te lossen, schrijf je een programmatische loop die de AI inbedt in een geautomatiseerde cyclus van uitvoering en verificatie:

1. Het doel. Een mens stelt één doel op hoog niveau — "bouw dit API-eindpunt en behaal 98% testdekking."
2. De actie. De AI genereert een eerste versie van de code.
3. De verificatie. Een geautomatiseerde omgeving — compilers, linters, unit tests, jouw CI — voert de code uit en vangt elke fout.
4. De zelfcorrectie. Bij een fout legt het systeem de stack trace vast, voert die terug naar de AI als een nieuwe instructie en beveelt het opnieuw te proberen.

jij stelt het doel
     │
     ▼
AI schrijft code  ─▶  CI draait elke controle  ─▶  groen?  ─▶  ✦ uitgeleverd
     ▲                      │
     │                      ▼  (rood)
     └──  AI leest de logs en prompt zichzelf opnieuw

De loop draait op machinesnelheid, doorloopt tientallen iteraties, corrigeert en herstelt zichzelf totdat aan de verificatiecriteria is voldaan. Je hebt nooit een enkele vervolgprompt getypt. Je schreef de prompts niet — je bouwde het circuit, en het model reed elk rondje zelf.

De echte vaardigheid is niet code schrijven. Het is de rechter schrijven.

Dit is het deel dat bijna iedereen mist — en het is het hele spel. Het moeilijke deel van een loop is niet het genereren van de code. Modellen zijn daar al angstaanjagend goed in. Het moeilijke deel is het ding dat beslist of de code goed is.

Geef de loop een sterke, meedogenloze verificator — echte tests, statische analyse, een compiler die weigert te liegen — en hij convergeert naar iets dat werkelijk werkt. Geef hem een zwakke, en diezelfde loop produceert vrolijk een oneindige rivier van zelfverzekerde, prachtig opgemaakte rommel, hallucinerend op weg naar een groen vinkje dat niets betekent.

Dus de vaardigheid van het komende decennium is geen promptvaardigheid. Het is de verificatie ontwerpen — de kogelvrije validatiesystemen die een AI veilig met zichzelf laten praten zonder van een klif te rijden. Dat is een moeilijker, zeldzamer en veel waardevoller soort engineering dan het vinden van de juiste woorden.

Van filosofie naar productie: hoe we de loop hebben ontworpen

Terwijl de rest van de techwereld het citaat van Cherny op sociale media ontleedt, is de echte uitdaging weinig glamoureus: hoe bouw je loop-engineering-infrastructuur die daadwerkelijk werkt in productie — buiten de interne laboratoria van Anthropic?

Sluit een loop rond één enkel model en je stuit al snel op de muren van de echte wereld: degradatie van het contextvenster, hallucinerende doodsspiralen, en geen geheugen dat een project overspant. Bij Fractera hebben we het afgelopen jaar Cherny’s filosofie niet als voorspelling maar als architectonische blauwdruk behandeld — en de loop gebouwd waarop deze werkruimte draait.

De anatomie van een productiewaardige loop

Om loops levensvatbaar te maken voor echte software, moet je stoppen met het model te bewonderen en beginnen met het bouwen van de drie weinig glamoureuze dingen eromheen — de rechter, het geheugen, en de hand die uitlevert:

• Een verificator die niet met mooie praatjes te overtuigen is. De rechter is geen tweede model met een mening; het is een set scripts die de build laten mislukken. Bestaan de taalsignalen op elke publieke pagina? Heeft elke post de markdown-tweeling die een AI-lezer nodig heeft? Wordt er verwezen naar een afbeelding die niemand heeft gecommit? Elke controle bestaat omdat precies dat defect ooit is uitgeleverd, en elke controle antwoordt met een exitcode in plaats van een alinea.
• Geheugen dat een sessie overleeft. Het geheugenverlies-effect is reëel: loop vijftien keer op een hardnekkige bug en de agent verliest de architectuur uit het oog. Hier is het geheugen geen dienst die offline kan zijn — het zijn bestanden naast de code die met de repository meereizen: de werkinstructie, de lessen die worden toegevoegd op het moment dat de eigenaar iets corrigeert, de lijst met antipatronen, de bevestigde gebruikerscasussen. Een nieuwe sessie begint met ze te lezen, zodat de vijftiende iteratie weet wat de eerste heeft geleerd.
• Een slotakte die niet bij de agent hoort. De loop eindigt in het bedieningspaneel: het bouwt het project, houdt een logboek bij van implementaties en kan terugkeren naar de laatst werkende build. Instellingen, teksten en afbeeldingen veranderen daar zonder enige herbouw — zodat aan de loop nooit wordt gevraagd op te lossen wat nooit een codeprobleem was.

Let op wat niet in die lijst staat: een zwerm modellen die elkaar superviseren. Dat was onze eerste architectuur, en we hebben hem verwijderd. Orkestratie is het meest opwindende deel van een agentic diagram en het minst dragende deel van een werkend exemplaar — een zwakke rechter wordt niet gerepareerd door een tweede mening toe te voegen, en een sterke rechter heeft er zelden een nodig.

Het nieuwe functieprofiel van de softwareontwikkelaar

We bewegen ons weg van het schrijven van code, voorbij het schrijven van prompts, en recht op het bouwen van cognitieve pijplijnen af. Het vakmanschap is niet langer de instructie — het is het systeem waarin de instructie draait.

En het is niet gratis. Er komen twee nieuwe kosten met de loops mee. Begripsschuld: wanneer een agent een bestand driehonderd keer achter de schermen schrijft en herschrijft, verslijt je grip op je eigen codebase stilletjes — het werkt, je weet alleen niet meer precies waarom. En rauwe rekenkracht: een loop kan echt geld in tokens verbranden terwijl hij één bug over honderd stille pogingen achtervolgt. De engineers die dit tijdperk winnen, behandelen kosten-versus-kwaliteit als een bewuste ontwerpbeslissing, niet als een verrassing op de factuur.

Het tijdperk van prompt engineering ligt officieel achter ons. De enige vraag die overblijft, is degene die Cherny al voor zichzelf heeft beantwoord: probeer je nog steeds met je AI te praten — of bouw je de loops die haar laten rennen?

Bron: een veelgedeelde LinkedIn-post van Guillermo Flor die Boris Cherny’s uitspraken naar boven bracht. Het citaat is weergegeven zoals het circuleerde; de architectuur en de analyse zijn van ons.