De non-coder en de augmented engineer — Deel 2

Eén speelveld, twee spelers, drie werkfasen, één omhulsel

In Deel 1 stond Hinton's voorspelling van 2016 over radiologen centraal — en het patroon dat keer op keer terugkomt: bij elke significante technologische vernieuwing wordt verlies voorspeld dat zelden uitkomt. De aanname eronder klopt niet. De taart groeit. Voor software is het niet anders — wat verandert is wie er werkt, met welke gereedschappen, en hoe ze samenwerken. Ik introduceerde het model: één speelveld, twee spelers — de non-coder en de augmented engineer — en drie lagen van werken.

Nu ik dat model verder uitwerk, moet ik iets corrigeren.

Een model in beweging

Terwijl ik schrijf, lees ik verder. Ik spreek met mensen die er dagelijks in werken en kijk opnieuw naar bronnen — Karpathy, Böckeler, Thoughtworks. En ik merk dat mijn eerste opzet iets miste. Harness is geen modaliteit naast vibe en spec. Harness is de omgeving waarbinnen vibe en spec plaatsvinden — een andere orde van ding, geen derde stap. En er ontbrak een expliciete uitvoeringsfase: tussen de gekristalliseerde intent van de spec en de werkende uitkomst zit een eigen werkfase, die van de agent. Karpathy maakte dat onderscheid in februari 2026 expliciet: vibe coding raises the floor, agentic engineering extrapolates the ceiling.

Het bijgestelde model: één speelveld, twee spelers, drie werkfasen — vibe, spec, agent — en één omhulsel: harness.

En ik zeg dit niet als correctie-om-de-correctie. Elke blog die ik schrijf is een uitkristallisering van waar ik op dat moment sta in mijn denken — niet meer, niet minder. Ik ben geen onderzoeker die dit veld van bovenaf overziet. Ik ben iemand die probeert te begrijpen wat er gebeurt, die leest, met mensen praat, en zijn gedachten ordent. De blogs zijn geen autoriteitsuitspraken. Ze zijn de manier waarop ik de wereld begrijpelijk voor mezelf maak. Dat het beeld scherper wordt terwijl ik schrijf, is geen fout in het systeem. Het is het systeem.

De spelers

Twee figuren staan op het speelveld. Ze waren er allebei al, maar wat ze doen en waarmee ze het doen is veranderd.

De non-coder is de figuur die altijd al ideeën had voor wat er gebouwd moest worden. Domeinexpert, ondernemer, product owner, jurist, marketeer, ontwerper. Hij weet wat hij wil en waarom — hij staat midden in het probleem. Wat hij vroeger niet had, was een taal om dat direct uit te drukken in iets werkends. Die taal heeft hij nu: vibe. Hij is niet vervangen, en hij is ook niet opeens een developer geworden. Hij is zichzelf, maar met een nieuwe manier om zijn kennis direct te laten doorwerken.

De augmented engineer is wat de developer wordt. Niet een vervanger, niet een afgeleide, maar een figuur met andere verantwoordelijkheden en een fundamenteel groter impact-bereik. Kent Beck formuleerde het zo: in vibe coding geef je niets om de code, alleen om het gedrag; in augmented coding geef je wél om de code, de complexiteit, de tests en hun dekking. Die zorg voor kwaliteit is precies wat zijn toegevoegde waarde is ten opzichte van de non-coder naast hem.

De drie werkfasen

Het werk van de twee spelers verloopt in drie werkfasen. Niet drie treden die je opeenvolgend doorloopt en achter je laat, maar drie soorten werk die in de praktijk doorlopend in elkaar overgaan — van het ontdekken van intent, naar het preciseren ervan, naar de uitvoering.

Werkfase 1: Vibe — waar intent wordt verkend

Voor de non-coder is wat er veranderd is, niet ingewikkeld: hij had altijd ideeën, hij wist altijd wat hij wilde dat er gebouwd werd. Wat hem ontbrak was een taal om dat direct uit te drukken in iets werkends. Vibe is die taal. Hij beschrijft in gewone woorden wat hij wil zien, de AI maakt het, hij stuurt bij op gevoel. Een uur later staat er een werkend prototype waar voorheen alleen een whiteboard-schets stond.

Vibe is zijn natuurlijke taal. Hij stuurt op uitkomst — werkt het, voelt het goed, doet het wat ik wil — niet op hoe het onder de motorkap is opgebouwd. Dat is geen onvolwassenheid; dat past bij zijn rol. Hij brengt domeinkennis, gebruikerscontext, gevoel voor wat het moet betekenen voor wie. Precies die kennis kan nu, voor het eerst, direct doorwerken in wat er gebouwd wordt — in de woorden van degene die de kennis bezit.

De augmented engineer werkt ook in vibe — maar anders. Als hij met de non-coder aan tafel zit en samen het prototype verkent, gaat hij mee in vibe-modus: hij denkt mee in uitkomsten, suggereert variaties, helpt het idee scherper te krijgen. Hij vibet ook alleen — voor verkenning, om snel een aanpak te testen voordat hij naar spec gaat. Het verschil is niet dat hij niet vibet, maar dat het voor hem een modus is waar hij in en uit stapt, terwijl het voor de non-coder zijn natuurlijke taal blijft.

Vibe is gedeeld terrein — maar niet gelijkmatig. De non-coder is hier thuis. De augmented engineer is hier op bezoek.

Werkfase 2: Spec — waar intent kristalliseert

Wat in vibe los en zoekend was, krijgt in spec vorm en stabiliteit. Dit is waar de twee spelers elkaar ontmoeten.

De non-coder brengt wat de engineer niet heeft: domeinkennis, gebruikerscontext, gevoel voor wat het moet betekenen voor wie. Hij weet wat het moet doen en waarom — beter dan wie ook. Maar hij articuleert dat als in vibe: voorbeelden, mockups, "zoiets, maar dan...". Rijk maar onvast.

De engineer brengt wat de non-coder niet heeft: het oog voor wat overeind moet blijven. Welke aannames de AI stilzwijgend maakt en die later breken. Welke edge cases nu lijken op uitzonderingen maar straks elke dag voorkomen. Welke kwaliteitseisen niet onderhandelbaar zijn.

Spec is waar die twee invoeren samenkomen — niet als compromis, maar als gedeeld eigenaarschap. De non-coder herkent zijn intentie terug, niet in technische terminologie maar in de structuur van wat het systeem moet doen. De engineer heeft de constraints en aannames expliciet. En de spec is ook geen eenmalig artefact: Thoughtworks merkte op dat code-generatie vanuit spec naar LLM niet deterministisch is — spec drift en hallucinatie zijn inherent moeilijk te vermijden. Agent-output keert terug als feedback die de spec corrigeert, en soms zelfs de vibe herformuleert als de intent zelf onjuist bleek.

Spec is gedeeld terrein bij uitstek. Hier is de non-coder nog aanwezig. Hier is hun samenwerking op haar best.

Werkfase 3: Agent — waar intent wordt uitgevoerd

Na de spec begint de uitvoering — en dit is de fase die in mijn eerste model ontbrak.

In de vibe-modus is er AI-uitvoering, maar ongestructureerd en direct: de AI genereert, jij stuurt bij, de code is bijvangst. In de agent-fase werkt een agent — of meerdere agents — zelfstandig, op basis van de spec, binnen de harness. De augmented engineer superviseert het resultaat.

Karpathy beschreef zijn eigen verschuiving: waar hij in november 2025 nog 80% zelf codeerde, had hij die ratio in december volledig omgedraaid. "The unit of programming changed from typing lines of code to delegating larger macro actions: implement this feature, refactor this subsystem, write tests and fix failures." De augmented engineer is niet langer primair een codeschrijver — hij is een orkestrator.

Wat hij concreet doet in de agent-fase: hij formuleert de agent-opdracht op basis van de spec, reviewt de output, en grijpt in waar zijn oordeel het verschil maakt — race conditions die de spec niet uitsloot, abstracties die op korte termijn werken maar over zes maanden schuren. Soms past hij de spec aan en laat hij de agent opnieuw draaien. Soms schrijft hij zelf de kritieke twintig regels.

De non-coder is hier niet aanwezig. De agent-fase is technisch terrein — zijn werk zat in de vibe-fase, zijn bijdrage kristalliseerde in de spec. De rest is aan de augmented engineer en zijn agents. Dat is ook geen verlies voor de non-coder: zijn ideeën worden uitgevoerd op een schaal en snelheid die voorheen niet mogelijk was. De scheiding is eerlijk — elk op het terrein waar hij het meeste waarde toevoegt.

Karpathy verwoordde het onderscheid in februari 2026 in twee zinnen: "Vibe coding raises the floor. Agentic engineering extrapolates the ceiling." De vibe-fase maakt het speelveld toegankelijk voor iedereen. De agent-fase is waar de augmented engineer zijn werkelijke plafond vindt — en dat plafond ligt hoger dan ooit.

Het omhulsel: harness

Vibe, spec en agent zijn de drie werkfasen. Maar ze vinden niet in het luchtledige plaats — ze vinden alle drie plaats binnen een harness.

Een harness is wat een AI-model in staat stelt iets te doen in de wereld. Een model alleen produceert tekst. Het kent geen bestanden, het onthoudt niets na het einde van een sessie, het kan niet zelf een API aanroepen. Een harness is alles eromheen: de tools die het model mag aanroepen, het geheugen dat over sessies heen blijft, de context die uit andere systemen wordt opgehaald, de grenzen waarbinnen het mag opereren, de feedbackloops die ingrijpen als iets misgaat. De formule: agent = model + harness. Zonder harness is een AI een gesprekspartner. Mét harness is het een uitvoerder.

Harness is daarom geen modaliteit naast vibe en spec, maar een andere orde van ding. Böckeler van Thoughtworks formuleert het precies: harness engineering occupies a distinct architectural layer from prompt engineering and context engineering — voor multi-session en multi-agent werk wat single-turn technieken niet zijn. Geometrisch: harness is het omhulsel, de drie werkfasen zijn de werkruimte erbinnen.

Drie harness-niveaus

Harness bestaat op drie niveaus met verschillende eigenaars en levensduren.

Op het kleinste niveau zit de task-harness: wat één agent omringt om één type taak te doen. Een AGENTS.md die de coding agent vertelt welke conventies hij moet volgen, welke tests hij moet draaien, welke commando's hij niet zelf mag uitvoeren. Eindig en vervangbaar — ze hoort bij het project.

Op het middelste niveau zit de organisatie-harness: de gedeelde infrastructuur waarin teams samenwerken. Persistent memory die context over systemen heen beschikbaar maakt, een gedeelde bibliotheek van werkpatronen zodat de doorbraak van één engineer de baseline van iedereen wordt. Glass bij Ramp is hiervan het meest uitgewerkte voorbeeld. Niet 99,5% AI-adoptie ondanks hun tools — maar dankzij hun organisatie-harness. Niet-engineers die productiecode mergen, niet omdat ze betere modellen hadden, maar omdat de organisatie de friction tussen mens en model heeft weggenomen. De organisatie-harness is waar individuele winst collectief wordt — en dat maakt haar in impact groter dan de task-harness ooit kan zijn.

Op het hoogste niveau zit de meta-harness: de stabiele interface waaronder specifieke harnesses kunnen veranderen zonder dat het systeem bezwijkt. Anthropic noemt zijn Managed Agents-platform expliciet zo. De analogie die ze zelf gebruiken is een operating system: stabiele abstracties waaronder de implementatie verandert, zoals read() hetzelfde werkt op een magneetschijf uit 1975 of een SSD van vandaag. De grote labs bouwen hun meta-harnesses expliciet als de volgende OS-laag. De keuze welke je adopteert is daarmee geen tooling-keuze maar een strategische keuze, met lock-in implicaties die we kennen van de strijd om OS-dominantie in de afgelopen decennia.

Wiens werk is de harness?

Harness inrichten is werk dat primair bij de augmented engineer ligt — net zoals vibe primair bij de non-coder ligt en spec hun gedeelde tafel is. In grotere organisaties verdeelt het werk zich: een platform-team bouwt de organisatie-harness, individuele augmented engineers configureren de task-harness, en de meta-harness wordt grotendeels door leveranciers geleverd.

De non-coder werkt binnen een harness — vaak zonder dat te merken. Wanneer hij in Cursor met een AI praat, werkt hij in een harness die door iemand anders is ingericht. De augmented engineer is daar wél van aware: hij kiest, configureert en onderhoudt die harness. Dat is zijn onzichtbare, maar fundamentele werk.

Het verklaart waarom hetzelfde model — exact dezelfde Claude, exact dezelfde GPT — zich totaal anders gedraagt in Cursor dan in een eenvoudige chat-interface. Niet omdat het model anders is, maar omdat de harness anders is. Hetzelfde model, ander vermogen. Een augmented engineer die zijn harness goed inricht, krijgt meer voor elkaar met een middelmatig model dan een collega met een topmodel zonder harness.

Een dinsdag

Het model wordt pas tastbaar als je het door een dag heen volgt.

Voordat de ondernemer aanschuift heeft hij al aan de harness gewerkt: hij paste gisteren na de review een AGENTS.md aan op basis van wat hij de agent zag doen, en configureerde een eval-loop voor een nieuwe agent die hij deze week inzet. Harness-werk is geen apart tijdslot — het zit tussen de sessies in, voor het begin van een project, en telkens als de uitvoering hem iets nieuws leert.

Om tien uur zit hij met een ondernemer aan tafel. Het prototype van vorige week werkt, maar moet klaargemaakt worden voor echte klanten. Hij stelt vragen die de ondernemer niet uit zichzelf zou stellen: Wat gebeurt er als de klantdata uit twee bronnen verschillend is? Wat als deze workflow tegelijk door twee medewerkers wordt gestart? Wat zijn de GDPR-regels voor wat we hier opslaan? Hij codeert hier niet. Hij specificeert. Hij maakt impliciete aannames expliciet. Spec-fase — de non-coder aan tafel, domeinkennis en structuurbewustzijn samen.

Om elf uur formuleert hij een opdracht voor zijn agent: "Implementeer de factuur-matching workflow zoals beschreven in spec/billing.md. Gebruik de bestaande database-laag. De edge cases in spec/billing-cases.md moeten allemaal getest zijn. Bouw eerst de tests." Tien minuten later levert de agent een pull request op — tweehonderd regels code, vijftien tests. Hij heeft geen letter van die tweehonderd regels zelf getypt. Wat hij wél doet: reviewen als kerntaak. Hij ziet de race condition die de spec niet uitsloot. Hij ziet de abstractie die over zes maanden gaat schuren. Hij grijpt in. Agent-fase — de non-coder is hier niet aan tafel.

Om vier uur zit hij weer met de ondernemer. Een nieuwe vraag. De cyclus opnieuw.

Wat is er anders dan vroeger? De ratio is gedraaid. Vroeger schreef hij misschien achthonderd regels code per dag. Nu schrijft hij misschien dertig regels zelf — de kritieke regels — terwijl er duizend tot tweeduizend regels door agents worden geproduceerd onder zijn supervisie. Zijn output is hoger, niet lager. Maar wat hij telt als zijn werk is verschoven: van coderegels die ik heb getypt naar uitkomst die overeind blijft, en die ik kan verantwoorden.

Een groeiend speelveld

Één speelveld, twee spelers, drie werkfasen, één omhulsel. Voor de non-coder een nieuwe taal om zijn ideeën in werkende vorm uit te drukken — in vibe en spec, samen met de augmented engineer. Voor de augmented engineer een hoger plafond: vibe-partner en spec-curator in de eerste twee fases, orkestrator van agents in de derde — en doorlopend bouwer van de harness waarbinnen dat alles plaatsvindt.

De spelers zijn niet weg. Ze doen ander werk. Het speelveld is groter dan ooit.

Eén eerlijke noot — en een belangrijke. Wat hier beschreven staat is frontier. Het is het patroon dat zichtbaar wordt bij de organisaties en mensen die het verst zijn: Ramp met Glass, de engineers die Karpathy beschrijft, de teams die al volledig in agent-workflows werken. Voor de meeste bedrijven is dit nog een ver-van-mijn-bed-show.

Dat komt niet alleen doordat mensen of organisaties achterlopen. Het komt ook doordat er echte belemmeringen zijn. Bestaande systemen die niet zomaar te vervangen zijn. Regelgeving die bepaalt wat je mag automatiseren en wat niet. Organisatiestructuren die zijn gebouwd rond een andere manier van werken. Die traagheid is reëel en verstandig — niet alles wat kan, moet ook meteen.

Maar de richting is duidelijk, en de beweging is ingezet. Het beeld dat hier staat is geen rapportage van de huidige norm — het is een oriëntatie op waar het naartoe gaat. Wie dat beeld heeft, kan betere keuzes maken over wat hij vandaag al oppakt en wat hij morgen voorbereidt. Niet om er zo snel mogelijk te zijn, maar om niet verrast te worden door waar het speelveld naartoe beweegt.

Het speelveld wordt groter. Meer mensen kunnen meedoen, meer ideeën bereiken de werkelijkheid, meer is mogelijk dan ooit. Dat vraagt aanpassing — en verandering is niet altijd fijn. Maar wie de beweging ziet en meegaat, vindt geen krimpende wereld. Die vindt een wereld die zich opent.

Bronnen voor Deel 2

• Andrej Karpathy, X-post van februari 2026 ('Many people have tried to come up with a better name for this... my current favorite is agentic engineering') en Sequoia AI Ascent 2026-keynote ('Vibe coding raises the floor; agentic engineering extrapolates the ceiling'). Transcript op karpathy.bearblog.dev. Primaire bron voor het onderscheid tussen vibe als floor-raising en agentic engineering als ceiling-extending, en voor de verschuiving van coderen naar orkestrator.
• Kent Beck, 'Augmented Coding: Beyond the Vibes' (Tidy First, Substack, 25 juni 2025) — het onderscheid tussen vibe coding en augmented coding. Beck is auteur van Test Driven Development by Example (2002), mede-architect van Extreme Programming en JUnit, en een van de zeventien ondertekenaars van het Agile Manifesto.
• Birgitta Böckeler, 'Harness engineering for coding agent users' (martinfowler.com, april 2026) — de meest rigoureuze uitwerking van harness als architecturaal onderscheiden laag, inclusief het onderscheid inner/outer harness en de guide/sensor-taxonomie.
• Thoughtworks, 'Spec-driven development: Unpacking one of 2025's key new AI-assisted engineering practices' (december 2025) — voor de non-deterministische aard van spec-naar-LLM en de noodzaak van continue feedbackloops.
• Anthropic Engineering, 'Scaling Managed Agents: Decoupling the brain from the hands' (april 2026) — primaire bron voor de meta-harness als concept en de OS-analogie.
• OpenAI (Ryan Lopopolo), harness engineering field report (februari 2026) — de formule agent = model + harness en het één-miljoen-regels-experiment.
• Pragmatic Engineer (Gergely Orosz), 'AI Tooling for Software Engineers in 2026' (maart 2026) — empirische data over AI-coding-adoptie; Staff+ engineers als heaviest users van coding agents.
• Seb Goddijn (Ramp) en Geoff Charles (CPO Ramp), op het Behind the Craft podcast met Peter Yang (maart 2026) — primaire bron voor de Glass-casus als organisatie-harness in de praktijk.

Deze blog maakt deel uit van een bredere reeks over AI als systeemverschuiving — van de economie van tokens tot de versnelling van de technologie en wat dat betekent voor mensen en organisaties. De technische kant van AI in de praktijk beschrijft Edwin van Dillen. De bredere gedachten over organisatie, intentie en uitvoering zijn uitgewerkt op augmentedorganisation.nl, intentdriven.nl en augmentedengineering.nl.

Co-creatie: Dit stuk is gemaakt samen met Claude (Anthropic) en NotebookLM (Google). De gedachten, posities en interpretaties zijn van mij.