Van prototype naar enterprise-productie: uitbreiding van Andrew Ng's drie lussen

In een brief van eind juni 2026 beschreef Andrew Ng hoe hij in een weekend een typtraining-app voor zijn dochter bouwde — waarbij de coding agent ongeveer een uur zelfstandig werkte en zelfs herhaaldelijk een browser opende om zijn eigen werk te controleren — als het concrete voorbeeld van zijn drie geneste lussen voor het bouwen van 0-naar-1 AI-producten: de agentic coding-lus (minuten), de developer-feedbacklus (uren) en de externe feedbacklus (dagen tot weken). We hebben elders al geschreven over de lussen zelf — hun kloksnelheden, failure modes en de telemetrie die ze elk nodig hebben — in ons begeleidende artikel over het schalen van operationele lussen. Dit artikel gaat over een andere zijde van Ng's kader, de zijde die enterprise-lezers naar verluidt aanstipten volgens een kroniek van de brief op explainx.ai: wat gebeurt er met de buitenste lus wanneer het product geen weekend-app is, maar een enterprise-systeem. Ng's brief is er eerlijk over dat de externe lus bestaat uit "vrienden, alpha-testers, productie met A/B-tests." Een kroniek van explainx.ai meldt dat enterprise-lezers aanvoerden dat in gereguleerde omgevingen de externe lus ook beleid, governance, audit en verantwoording zou moeten omvatten, en niet alleen consumentenexperimenten. Die observatie is het snijvlak waar dit artikel zich bevindt. De drielussenmethode legt een nuttig onderscheid vast en stopt niet met werken bij de deur van de onderneming — maar de buitenste lus krijgt daar eisen waaraan een weekendproject nooit hoeft te voldoen. Het voldoen aan die eisen maakt het verschil tussen een prototype dat een demo geeft en een product dat daadwerkelijk binnen een bedrijf wordt uitgerold. Het tweede deel van dit artikel koppelt die eisen aan gedocumenteerde mechanismen; de eerlijke grens blijft, zoals altijd, dat infrastructuur de methode ondersteunt in plaats van het menselijk oordeel in het centrum ervan te vervangen.

1. Het kader blijft overeind; de buitenste lus veranderd bij de deur

Begin met het geven van de verdiende eer aan Ng's kader, omdat dit artikel erop vertrouwt dat het correct is. De drie lussen beschrijven iets politieks en echts: de binnenste agentic lus schrijft en verifieert nu snel genoeg code zodat de taak van de mens opschuift naar productbeslissingen (de middelste lus), en het geheel is slechts zo goed als het externe signaal dat de visie valideert (de buitenste lus). Ng's weekend-app is de perfecte illustratie juist omdat deze klein is — de buitenste lus is zijn dochter die de app gebruikt en hij die van gedachten verandert over kattenkostuums en de inlogflow voor ouders. Niets daarvan is triviaal om te bouwen, maar de verplichtingen van de buitenste lus zijn licht: niemand auditeert de typtraining-app, geen compliance-eigenaar geeft er zijn goedkeuring aan, en geen auditor vraagt wie een wijziging heeft goedgekeurd. Verplaats nu exact dezelfde methode naar een bedrijf. De binnenste lus is ongewijzigd — de agent schrijft en test nog steeds elke paar minuten code. De middelste lus is qua vorm ongewijzigd — een mens stuurt nog steeds op een cadans van uren bij. Maar de buitenste lus transformeert: "uitrollen naar gebruikers" betekent nu uitrollen naar klanten, onder beleid, met verantwoording, en de externe feedback die er toe doet omvat niet alleen "vinden mensen het leuk", maar ook "voldoet het aan de restricties waarvoor het bedrijf verantwoordelijk is." Dit is geen kritiek op Ng's kader; het is de enterprise-toepassing ervan die enterprise-lezers, volgens de kroniek van explainx.ai, opmerkten, en het is het punt waar een build stopt een build te zijn en een product wordt.

2. De overgang naar productie is een probleem van de buitenste lus

Het geruststellende deel, voor elk team dat valt voor de drielussenmethode bij een prototype, is dat de overgang naar productie je niet vraagt om te veranderen hoe je bouwt — hoewel governance een groot onderdeel van de overgang is, is het niet het geheel: teams hebben nog steeds conventionele production engineering nodig (deployment, betrouwbaarheid, capaciteit, rollback, incident response, beveiliging, testen op applicatieniveau), waarbij het control plane de governance en de model/tool-verkeerslaag van dat grotere systeem afhandelt. De binnenste lus — specificatie, agentic iteratie, verificatiepoorten, gecapte uitgaven per run — blijft dezelfde discipline, ongeacht of de output een typtraining-app of een schadeclaimverwerker is. Wat verandert is alles rondom de lus, en het verandert omdat de nieuwe verplichtingen van de buitenste lus naar binnen reiken. Een agent die onder je eigen referenties op je laptop draaide, heeft nu een eigen identiteit nodig, omdat "wie heeft dit gedaan" een antwoord moet hebben dat niet "de sleutel van de ontwikkelaar" is. Een agent waarvan de weekenduitgaven onder je persoonlijke abonnement vielen, heeft nu een budget met een eigenaar nodig, omdat iemand verantwoordelijk is voor de kostenpost. Een agent die alleen je testdata zag, verwerkt nu echte gebruikersdata, wat betekent dat wat erin gaat en eruit komt moet worden geïnspecteerd. En een agent waarvan elke actie zichtbaar was in je terminal, draait nu ergens waar anderen het moeten kunnen beoordelen, wat een duurzaam dossier vereist. Geen van deze zaken is een zorg van de build-lus; het zijn allemaal zorgen van de buitenste lus in de enterprise-zin — de beleid-governance-auditdimensie van de gerapporteerde enterprise-governance-observatie — en vele kunnen worden afgedwongen via de omliggende infrastructuur, terwijl de agent en applicatie nog steeds eigenaar zijn van het taakontwerp, dataminimalisatie, tool-semantiek en bedrijfslogica. Dat is voor een groot deel de reden waarom de overgang naar productie haalbaar is. Zodra het model en het geregistreerde MCP-verkeer van een applicatie via de relevante gateways zijn geïntegreerd, kunnen teams veel plannen op verkeersniveau centraliseren in plaats van ze onafhankelijk in elke agent opnieuw te implementeren. Integratie vereist nog steeds referenties, endpoints, beleidskoppeling, agentregistratie, metadata en tool-routing.

3. De drie lussen in productie: Waar TrueFoundry bij elke lus past

Neem Ng's lussen één voor één en voeg de enterprise-eis toe die elke lus krijgt, gekoppeld aan een gedocumenteerd mechanisme. De binnenste lus blijft zoals hij is — bewust. De agentic coding-lus met zijn verificatiepoorten en uitgavenlimieten per run is het deel dat je precies zo behoudt; als het in een beheerde runtime draait, levert de Agent Harness orkestratie, status, tool-executie en observatie op stapniveau, die nu zichtbaar zijn voor meer dan één persoon; de applicatie definieert nog steeds de specificatie, tests, verificatiecriteria en voorwaarden om te stoppen. De middelste lus wordt evaluatie plus gefaseerde uitrol. Ng raadt al evals aan wanneer dezelfde fout zich herhaalt; in productie wordt dat gevoel infrastructuur — gateway-telemetrie die een verbonden online of offline evaluatiesysteem voedt (het evaluatiepatroon) — waarbij de scorer, sampling-policy, calibratie, regressiedetectie en promotielogica een aangrenzende workflow blijven die het team implementeert of integreert — en virtuele modelgewichten die een gecontroleerd deel van het verkeer naar een kandidaat-doel sturen, uitgebreid of hersteld door bewuste configuratie zonder de modelnaam te wijzigen die aanroepers gebruiken, de mechanica die onze routing-analyse gedetailleerd beschrijft. De bijsturende feedback van de ontwikkelaar krijgt met andere woorden een vangrail: wijzig de spec, rol uit naar 5% van het verkeer, bekijk de evals, breid uit of draai terug. De buitenste lus krijgt zijn governance-dimensie. Dit is waar die gerapporteerde governance-observatie configuratie wordt: model-account toegangcontroles beheren welke gebruikers, teams en applicaties goedgekeurde modellen mogen aanroepen, terwijl voor attributie op agentniveau bij MCP Gateway- en Agent Gateway-verkeer elke onafhankelijk beheerde agent een geregistreerde Agent Identity presenteert, met zijn Agent Registration en bijbehorende policies die bepalen wie hem mag aanroepen, namens wie hij mag handelen en welke downstream bronnen hij mag bereiken; budgetten wijzen uitgaven toe aan een eigenaar en leggen, wanneer handhaving is ingeschakeld, een harde limiet op — een modus voor alleen waarschuwingen biedt meldingen zonder verkeer te blokkeren; geconfigureerde gateway-policies kunnen modelverzoeken en -antwoorden inspecteren, evenals geregistreerde MCP tool-calls die de relevante gateways doorkruisen — elke MCP tool-aanroep wordt afzonderlijk geëvalueerd; dit omvat geen willekeurige tools aan de applicatiezijde, en output-guardrails vereisen een volledig, niet-gestreamd antwoord — ter bescherming van de echte gebruikersdata die het prototype nooit zag (guardrails-documentatie); en het Metrics Dashboard biedt geaggregeerd inzicht in uitgaven, volume, fouten, latentie, routing en guardrail-resultaten, terwijl Request Traces en Request Logs het bewijs op verzoekniveau leveren dat "verantwoording" concreet betekent — logconfiguratie bepaalt afzonderlijk of verzoek- en antwoord-bodies worden bewaard en gecensureerd; kosten, tokens, latentie en metadata van verzoeken blijven opgeslagen. Ng's contextvoordeel-punt blijft een verantwoordelijkheid van de ontwikkelingslus: teams coderen gebruikersbehoeften, domeinrestricties, compliance-eisen en productintenties via specificaties, prompts, datasets, evaluaties en reviews. Afzonderlijk kan Agent Harness gevoelige tool-calls pauzeren totdat een expliciete goedkeuringsbeslissing is genomen — een controlepunt tijdens de uitvoering, geen vervanging voor autorisatie of upstream context engineering. Voor gevoelige acties die expliciete beoordeling vereisen, creëert een goedkeuringsbeleid een menselijk controlepunt voordat de tool wordt uitgevoerd bij een ingrijpende stap, het patroon dat onze taakgebaseerde toegang controle (TBAC) analyse ontwikkelt. De methode is ongewijzigd; de buitenste lus heeft simpelweg tanden gekregen, en die tanden zijn gedocumenteerd.

4. Grenzen, duidelijk geformuleerd

Eerst de credits: de drielussenstructuur, het voorbeeld van de weekend-app en de luscadansen zijn van Ng, gepubliceerd in The Batch eind juni 2026; de observatie over de enterprise-buitenste-lus is door die kroniek gerapporteerd als afkomstig van enterprise-lezers, en we hebben deze uitgewerkt als de redactionele analyse van TrueFoundry in plaats van deze zelf te hebben bedacht. Dit artikel leert de drie lussen bewust niet opnieuw aan — dat is de taak van ons begeleidende artikel en van de bron — en lezers die nieuw zijn met de structuur moeten daar beginnen. De koppeling van Ng's lussen aan TrueFoundry-mechanismen is onze redactionele structuur; deze koppeling wordt niet gepresenteerd in de geciteerde bronnen. Twee grenzen zijn het vermelden waard. Ten eerste: infrastructuur ondersteunt de methode; het levert niet het menselijk oordeel in het centrum ervan — de productvisie, de spec, de beslissing over welke gebruikersrestricties er toe doen en het menselijke contextvoordeel dat Ng terecht centraal stelt, blijven allemaal menselijk werk dat een vlak kan faciliteren, maar nooit kan overnemen. Ten tweede: niet elk AI-product is een enterprise-product: er zijn genoeg waardevolle 0-naar-1 builds die precies de schaal hebben van de weekend-app die Ng beschrijft, en het voortijdig vastschroeven van enterprise-governance daarop is een fout op zich — de overgang naar productie die dit artikel beschrijft is voor builds die echt naar een bedrijf gaan, en de kunst is om te weten welke dat zijn. Voor de builds die dat wel zijn, is onze meer specifieke conclusie die welke de gerapporteerde observatie impliceerde: de enterprise-verplichtingen van de buitenste lus zijn echt, ze komen er aan of je er nu op hebt gepland of niet, en het voldoen daaraan is infrastructuur die je vóór de eerste gebruiker kunt inrichten, in plaats van na de eerste audit.

Aanvullend geldt dat door TrueFoundry beheerde PII/PHI Detection, Prompt Injection en Content Moderation guardrails beperkingen hebben qua deployment-modus; self-hosted of hybride configuraties kunnen externe of aangepaste guardrail-integraties vereisen voor die categorieën.

Sommige mogelijkheden rond Agent Identity en Governance worden incrementeel uitgerold; organisaties moeten de huidige beschikbaarheid verifiëren bij TrueFoundry.

Referenties

• Primair — Andrew Ng, "Three Key Loops for Building Great Software," The Batch, DeepLearning.AI (eind juni 2026) — het drielussenkader, het voorbeeld van de typtraining-app en de luscadansen.
• Secundair — explainx.ai, "Andrew Ng's Three Loops for Building 0-to-1 Products with AI Agents" (kroniek van 30 juni 2026; gebruikt voor de gerapporteerde governance-observatie van enterprise-lezers).
• TrueFoundry-documentatie — AI Gateway-introductie (officieel architectuurdiagram); Agent Harness (runtime, traces, goedkeuringspoorten); toegangscontrole; budgetten; guardrails; Metrics Dashboard (officiële afbeelding).
• Dit blog — het schalen van operationele agent-lussen; loop engineering op enterprise-niveau; online evaluatie bij de gateway; kosten- en kwaliteitsbewuste routing; TBAC: taakgebaseerde toegangscontrole; wat is een Agent Harness?.

Korte zinnen uit de bron zijn geciteerd met bronvermelding in de tekst; het overige bronmateriaal is geparafraseerd; Ng's kader is verankerd in de DeepLearning.AI-brief, en de observaties van enterprise-lezers zijn geparafraseerd uit de geciteerde explainx.ai-kroniek en gepresenteerd zoals gerapporteerd. De koppeling van de lus aan mechanismen is een redactionele invulling van TrueFoundry op basis van functionaliteiten die zijn geparafraseerd uit publieke documentatie die actueel was op het moment van schrijven; de drie productafbeeldingen zijn onderdelen uit de TrueFoundry-documentatie die zijn overgenomen met bronvermelding; Figuur 2 is een originele TrueFoundry-afbeelding. Er is geen goedkeuring van TrueFoundry door de geciteerde partijen vermeld of geïmpliceerd.

‍