Waarom Uw AI-agentopzet 50x Langzamer Is Dan Nodig

Het verschil tussen een ontwikkelaar die 2x waarde haalt uit AI-tools en iemand die 100x haalt, zit niet in het model dat ze gebruiken. Het zit in de architectuur die dat model omhult. Steve Yegge beweerde begin 2026 dat mensen die AI-codeeragenten gebruiken 10x tot 100x productiever zijn dan degenen die nog steeds chatinterfaces en autocomplete gebruiken. Dezelfde modellen. Dezelfde onderliggende intelligentie. De variabele is structuur.

In één week in april 2026 publiceerden vijf onafhankelijke builders frameworks voor AI-agentarchitectuur. Garry Tan (Y Combinator), Andrej Karpathy, Viv Trivedy, Daniel Miessler en een community-repository die 19.700 GitHub-sterren bereikte, kwamen allemaal uit op dezelfde kernthese: breng intelligentie onder in draagbare markdown-bestanden, houd de orkestratie-infrastructuur zo dun mogelijk, laat het model het redeneren doen. Dit artikel legt uit waar ze het over eens zijn, waar ze van mening verschillen en wat dat betekent voor iedereen die met AI bouwt.

Belangrijkste Inzichten

• Intelligentie hoort in markdown-skillbestanden, niet in frameworkcode. Skills zijn draagbaar, versioneerbaar en verbeteren automatisch mee als het model verbetert.

• Het harnas moet vier dingen doen en niets anders. Het model in een lus uitvoeren, bestanden lezen en schrijven, context beheren, veiligheid bewaken. Elke functie die u daarbovenop toevoegt, verbruikt context en vertraagt het redeneren.

• Vijf builders publiceerden onafhankelijk dezelfde these binnen drie dagen (12 tot 15 april 2026). Garry Tan, Andrej Karpathy, Viv Trivedy, Daniel Miessler en een community-repo met 19.700 sterren. Die convergentie is het signaal.

• LangChain is het er niet mee eens en heeft benchmarks om dat te onderbouwen. Harrison Chase stelt dat het harnas het product IS. Het antwoord hangt er mogelijk van af of u consumententools of enterprise-pipelines bouwt.

• Voorschrijvende instructies verlopen. Context niet. Elk stap-voor-stap recept dat u voor een AI schrijft, degradeert bij de volgende modelrelease. Context over wie u bent en wat u wilt, groeit in waarde.

De Hele Architectuur Past op een Indexkaart

Op 31 maart 2026 publiceerde Anthropic per ongeluk de volledige broncode van Claude Code op het npm-register. 512.000 regels. Garry Tan las het. Wat hij vond, bevestigde een patroon dat hij al maanden bij Y Combinator doceerde: het productiviteitsverschil gaat niet over modelintelligentie. Het gaat over wat het model omhult.

Tan destilleerde de architectuur in drie lagen:

Het principe is richtinggevend. Breng intelligentie omhoog naar skills. Breng uitvoering omlaag naar deterministische tooling. Houd het harnas dun. 90% van de waarde zit in de skilllaag. Het harnas is een dirigent die bestanden leest. Het bezit ze niet.

Tan's eigen ervaring maakt het punt duidelijk. Zijn persoonlijke CLAUDE.md begon op 20.000 regels. Elke eigenaardigheid, elke conventie, elke les die hij ooit was tegengekomen. Het resultaat: de aandacht van Claude Code degradeerde. Het model vertelde hem letterlijk om het in te korten. Zijn oplossing was 200 regels verwijzingen naar documenten die op aanvraag laden. De volledige 20.000 regels kennis bestaan nog steeds. Ze laden alleen wanneer relevant in plaats van bij elke beurt het contextvenster te vervuilen.

Als u AI-tools of workflows voor uw bedrijf bouwt, bepaalt de architectuur van het begin af aan goed inrichten of u eindigt met een demo die imponeer of een systeem dat daadwerkelijk in productie gaat.

Vijf Definities Die 100x Builders Onderscheiden van de Rest

De architectuur rust op vijf concepten. Sla er één over en het systeem presteert ondermaats.

1. Skillbestanden

Een skill is een herbruikbaar markdown-document dat het model leert hoe iets gedaan moet worden. Niet wat er gedaan moet worden. De gebruiker levert de taak. De skill levert het proces. Het werkt als een methodeaanroep: dezelfde procedure, andere argumenten, radicaal verschillende uitvoer.

Tan's voorbeeld: een skill genaamd /investigate heeft zeven stappen (de dataset afbakenen, een tijdlijn opstellen, elk document diariseren, synthetiseren, beide kanten beargumenteren, bronnen citeren). Richt het op een veiligheidswetenschapper en 2,1 miljoen discovery-e-mails en u krijgt een medisch onderzoeksanalist. Richt het op een brievenbusfirma en FEC-documenten en u krijgt een forensisch onderzoeker. Dezelfde zeven stappen. De aanroep levert de wereld.

2. Resolvers

Een resolver is een routeringstabel voor context. Wanneer taaktype X verschijnt, laad dan eerst document Y. Zonder een resolver wijzigt een ontwikkelaar een prompt en publiceert die. Met een resolver leest het model eerst de documentatie van de evaluatiesuite, voert benchmarks uit en keert terug als de nauwkeurigheid meer dan 2% daalt. De ontwikkelaar wist niet dat de evaluatiesuite bestond. De resolver laadde de juiste context op het juiste moment.

3. Latent versus deterministisch

Elke stap in een systeem is het een of het ander. Ze door elkaar halen is de meest voorkomende fout in agentontwerp. Een LLM kan 8 mensen aan een diner plaatsen, rekening houdend met persoonlijkheden. Vraag het 800 mensen te plaatsen en het hallucineert een tafelindeling die plausibel oogt maar volledig onjuist is. Dat is een deterministisch probleem dat in de latente ruimte wordt gedwongen. De beste systemen zijn meedogenloos over deze grens.

4. Diarisering

Het model leest alles over een onderwerp en schrijft een gestructureerd profiel. Geen SQL-query produceert dit. Geen RAG-pipeline produceert dit. Het model moet lezen, tegenstrijdigheden in gedachten houden, opmerken wat er veranderd is en wanneer, en gestructureerde inzichten synthetiseren.

Tan's team bouwde een systeem voor YC Startup School dat op deze manier 6.000 oprichterprofielen beheert. De diariseringsuitvoer vangt dingen op die geen trefwoordzoekactie kan vinden: een oprichter die "Datadog voor AI-agenten" zegt maar wiens GitHub-commits voor 80% uit factureringscode bestaan. Ze bouwt een FinOps-tool vermomd als observability. Dat verschil tussen "zegt" en "bouwt feitelijk" vereist het gelijktijdig lezen van de commitgeschiedenis, de aanvraag en het adviseurstranscript. Geen embedding-similariteitszoekactie vindt dat.

5. Permanente upgrades

Tan's instructie aan zijn AI: "Als ik u vraag iets te doen en het is het soort dat vaker zal moeten gebeuren, codificeer het dan in een skillbestand. Als het automatisch moet lopen, zet het dan op een cron. Als ik u twee keer om iets moet vragen, heeft u gefaald." Elke geschreven skill is een permanente upgrade. Die degradeert nooit. Wanneer het volgende model uitkomt, verbetert elke skill automatisch mee. Het systeem groeit in waarde.

Vijf Frameworks Gepubliceerd in Één Week Zeggen Hetzelfde

De convergentie is het sterkste signaal. Deze vijf kenniscorpora verschenen onafhankelijk van elkaar tussen 12 en 15 april 2026. Geen van deze builders werkt samen. Ze kwamen vanuit verschillende uitgangspunten bij dezelfde architectuur uit.

Tan kwam hier uit na het verzenden van 600.000 regels productiecode in 60 dagen met gstack (23.000+ GitHub-sterren in zijn eerste week). Karpathy kwam hier uit na het debuggen van de drie persistente faalwijzen van AI-coderingassistenten. Trivedy kwam hier uit na het itereren op harnesontwerp via 30+ versies. Miessler kwam hier uit na het toepassen van Richard Sutton's bittere les op AI-tooling.

Wanneer vijf onafhankelijke bronnen binnen 72 uur op dezelfde architectuur uitkomen, is die architectuur waarschijnlijk correct.

LangChain Is Het Oneens en Heeft Benchmarks om Dat te Bewijzen

Harrison Chase (CEO van LangChain) publiceerde Deep Agents in dezelfde week en betoogde het tegenovergestelde: het harnas IS het product. Ingebouwde taakplanning, subagentspawning, middleware, hooks, volledige orkestratie-infrastructuur. Zijn bewijs: alleen het harnas wijzigen bracht LangChain's DeepAgent van buiten de top 30 naar de top 5 op TerminalBench 2.0.

Dit is geen marginaal bezwaar. LangChain verwerkt dagelijks miljoenen agentaanroepen. Hun benchmarks zijn openbaar. De echte verdeling: Tan's standpunt is dat elk stukje logica in het harnas het redeneren dat het model had kunnen doen beperkt. Hoe beter het model wordt, hoe dunner het harnas moet zijn. Chase's standpunt is dat harnasengineering de modelcapaciteit uitbreidt in plaats van vervangt.

Beide standpunten kunnen correct zijn voor verschillende contexten. Consumenten- en persoonlijke agenten (waar draagbaarheid en levensduur belangrijk zijn) geven de voorkeur aan een dun harnas. Enterprise-pipelines (waar betrouwbaarheid en controleerbaarheid belangrijk zijn) kunnen een dik harnas rechtvaardigen. Geen van beide partijen betwist dat skills dik moeten zijn. De vraag voor uw project is niet welk kamp gelijk heeft. Het is aan welke kant van de lijn uw use case valt.

De meeste bedrijven die voor het eerst AI-functies bouwen, doen er verstandig aan dun te beginnen en infrastructuur alleen toe te voegen wanneer ze specifieke betrouwbaarheidsdrempels bereiken. Weet u niet zeker waar uw project valt? Praat met ons team over welke architectuur past.

Uw Instructies Verlopen. Uw Context Niet.

Daniel Miessler publiceerde de scherpste diagnose van de week. Hij noemt het de bittere-les-engineeringaudit, naar Richard Sutton's observatie uit 2019 dat algemene benaderingen die meeschalen met rekenkracht op de lange termijn consequent beter presteren dan handgecodeerde benaderingen.

Toegepast op AI-tools: slechte harnasengineering zijn voorschrijvende instructies. "Kopieer eerst dit bestand, laad dan dit, doe dan dat, doe dan dat." Stap-voor-stap micromanagement van de uitvoering door de AI. Deze aanpak degradeert naarmate modellen slimmer worden. Overdreven rigide stappen verhinderen het model zijn eigen redenering toe te passen.

Goede harnasengineering is contextueel. Wie u bent, waaraan u werkt, wat u probeert te bereiken, hoe goed en slecht eruitzien. Identiteit, smaak, standaarden, doelen. Het model bepaalt zelf de aanpak.

Miessler's diagnose is eenvoudig. Als uw configuratie leest als een recept (stap 1, stap 2, stap 3), doet u slechte harnasengineering. Als het leest als een briefingdocument (hier is wie ik ben, hier is wat belangrijk is, hier zijn de tools), doet u goede harnasengineering. Context over wie u bent verloopt nooit. Voorschrijvende instructies verouderen bij elke modelverbetering.

De architectuur is niet ingewikkeld. Dikke skills, dun harnas, meedogenloze scheiding van latent en deterministisch werk. Het moeilijke deel is discipline: oordeel vastleggen in herbruikbare skills in plaats van eenmalig werk doen, het harnas dun houden wanneer de verleiding is om functies toe te voegen, en het model vertrouwen het "hoe" te bepalen wanneer u het de juiste "wat" en "waarom" geeft.

Bij webvise bouwen we AI-gestuurde systemen volgens deze architectuurprincipes. Of u nu een agentworkflow, een geautomatiseerde pipeline of een productie-AI-integratie nodig heeft: de architectuur telt zwaarder dan het model.