Wat is agentic engineering?

Wat is agentic engineering?

Agentic engineering is software bouwen met AI-agents die zelf code schrijven, uitvoeren en testen, terwijl jij het doel, de grenzen en de eindcontrole bepaalt. Je typt de code grotendeels niet meer zelf. Je beschrijft wat er moet gebeuren, knipt het werk op in taken die een agent aankan en controleert of het resultaat klopt.

Een agent is meer dan een chatvenster dat code voorstelt. Simon Willison definieert hem⁠↗ in één zin: “An LLM agent runs tools in a loop to achieve a goal.” Een coding agent leest bestanden, draait commando's, voert tests uit, ziet de foutmelding en probeert het opnieuw. Daarom heet het ook wel agentic coding. Het maakt een agent krachtig, en ook riskant: hij kan veel werk doen voordat iemand meekijkt.

Het woord engineering gaat over alles rond die agents: hoe je taken afbakent, hoe je bewijst dat iets werkt en wie wanneer beslist.

Waar komt de term vandaan?

Andrej Karpathy stelde de term agentic engineering voor op 4 februari 2026⁠↗, een jaar nadat hij vibe coding een naam had gegeven. In die terugblik schrijft hij dat programmeren met agents voor professionals de standaard wordt, “except with more oversight and scrutiny”. Hij zocht een naam die dat werk onderscheidt van vibe coding.

Het tweede deel van de naam licht hij ook toe: engineering, omdat er vakmanschap bij komt kijken dat je kunt leren en waarin je beter kunt worden. Addy Osmani publiceerde dezelfde dag een uitwerking⁠↗ met een zin die de rolverdeling samenvat: “AI does the implementation, human owns the architecture, quality, and correctness.”

Simon Willison begon op 23 februari 2026 de reeks Agentic Engineering Patterns⁠↗. Hij gebruikt de term voor “building software using coding agents”: tools als Claude Code en OpenAI Codex, die code kunnen schrijven én uitvoeren, en die code dus zelf kunnen testen en verbeteren. Ook IBM heeft inmiddels een definitiepagina⁠↗, die het omschrijft als “the practice of using engineering expertise to orchestrate and oversee AI agents through the software development process.”

We schrijven bewust dat Karpathy de term voorstelde, niet dat hij hem bedacht. Het idee leefde al eerder. Willison sprak in oktober 2025 al van vibe engineering⁠↗ voor hetzelfde soort werk. Karpathy gaf het een naam die bleef hangen.

Wat is het verschil tussen agentic AI en agentic engineering?

Agentic AI is de verzamelnaam voor AI-systemen die zelfstandig stappen zetten richting een doel. Agentic engineering is één toepassing daarvan: software bouwen met zulke systemen, onder menselijke regie. De eerste term zegt wat de technologie doet, de tweede hoe je ermee werkt.

Anthropic maakt in Building effective agents⁠↗ een bruikbaar onderscheid binnen agentic systemen. Workflows zijn systemen “where LLMs and tools are orchestrated through predefined code paths”. Bij agents bepalen de modellen zelf de volgende stap: ze “dynamically direct their own processes and tool usage”. Een agentic workflow volgt dus een vast pad, een agent kiest zijn pad zelf. Beide vallen onder agentic AI.

Een assistent die zelf een retour aanmaakt in je webshop is agentic AI. Een agent die een bug in je app opspoort, een test schrijft die de bug laat zien en een pull request opent, is agentic AI in dienst van agentic engineering. Wil je agents inzetten buiten softwareontwikkeling, lees dan AI-agents in je bedrijf.

Hoe werkt agentic engineering in de praktijk?

Je werkt in een lus: doel vastleggen, opknippen in taken, een agent laten bouwen en testen, het resultaat laten beoordelen en pas dan samenvoegen. Elke stap heeft een eigen controle.

1. Doel. Je legt vast wat er moet gebeuren en waaraan het resultaat moet voldoen. Dus niet “verbeter de app”, maar “de app start zonder internet en toont de laatst bekende stand”.
2. Taken. Je knipt het doel op in taken die klein genoeg zijn om te controleren. Kun je een taak niet testen, dan is hij te groot.
3. Agents. Een agent voert de taak uit met de bestanden, tools en achtergrondinformatie die hij nodig heeft, en niet meer dan dat.
4. Tests. De agent draait de tests zelf. Dat is volgens Willison het kenmerk van coding agents: ze kunnen code schrijven én uitvoeren, en dus zelf testen en bijsturen.
5. Review. Een onafhankelijke reviewer beoordeelt het werk: een ander model of een aparte context die het werk niet zelf heeft gemaakt. Daarna beslist een mens of het erin gaat.

Wat je nodig hebt om te beginnen

• Versiebeheer, zodat elke wijziging van een agent een eigen branch en een eigen diff heeft die je kunt terugdraaien.
• Geautomatiseerde tests en CI. Zonder tests kan een agent niet zelf vaststellen of hij klaar is, en jij ook niet.
• Een vaste vorm voor taken: wat moet er gebeuren, wanneer is het klaar en wat mag niet.
• Een reviewstap die losstaat van de maker.
• Afgesproken beslismomenten: wat keurt een mens goed voordat het werk verdergaat?

Begin klein. Kies een afgebakende klus in een bestaand project met tests eromheen, en kijk hoe een agent hem oppakt. Van één taak die je zorgvuldig nakijkt, leer je meer dan van een complete app die je in een middag laat genereren.

Zo ging het bij Plens

Plens, onze app die fietsers vertelt wanneer ze het droogst vertrekken, is zo gebouwd. De webrepo kreeg zijn eerste commit op 31 augustus 2026. Op 10 oktober stonden er 1.286 commits in; van de 632 pull requests waren er 604 samengevoegd. De native app begon op 16 september en telde op 11 oktober 684 commits, waarvan 397 met een Co-Authored-By: Claude-regel. Vrijwel alle commits staan op naam van medeoprichter Alan Abdulla, die werkte met Claude Code, Codex en Cursor.

Zoveel sessies naast elkaar vragen om afspraken. Elke wijziging begint met een vastgelegd productwijzigingsrecord, zodat “het niet uitmaakt welke sessie de wijziging start”. Sessies in de cloud en op de Mac melden hun branch aan op een gedeeld werkbord, dat overlap tussen branches toont als “mergeconflict in wording”. En een contractbestand tussen web en app laat de CI falen zodra de twee repo's uit elkaar lopen.

Wat doet de mens nog?

De mens bepaalt het doel, de grenzen en de eindcontrole, en neemt de beslissingen die een agent niet mag nemen. Je typt minder en kiest, weegt en controleert meer.

• Doel en afweging. Wat bouwen we, voor wie, en wat valt af? Een agent werkt aan de taak die hij krijgt. Of dat de juiste taak is, beslist hij niet.
• Grenzen. Welke bestanden, tools en rechten krijgt een agent? Wat mag hij nooit zonder akkoord, zoals naar productie deployen of iets betalen?
• Eindcontrole. Op vooraf afgesproken momenten keurt een mens het werk goed, wijst het af of vraagt om aanpassingen.
• Bewijs eisen. “Het werkt” is pas waar als je het kunt laten zien: een test die slaagt, een scherm op een echt toestel, een meting.

In onze eigen regels voor ARCS staat het zo: “Money, contracts, and external customer commitments require a visible final human action.”

In de documentatie van Plens staat dat als regel: “Claim geen toestelbewijs op basis van een succesvolle bundel of EAS-build.” En: “Claude deployt niet zelf naar productie.” Claude dient builds wel zelf in bij de stores, maar pas na Alans go. Over de publieke release beslist medeoprichter Melle Doreleijers.

Ook de grote keuzes bleven bij mensen. Codex werkte het architectuurbesluit voor de native app uit, met vier opties die tegen elkaar zijn gewogen: Expo met React Native kwam uit op 157 punten, twee volledig native apps op 106, een webwrapper op 104 en alleen een web-app op 92. Alan nam het besluit, op 21 september. Hij besloot ook om een Apple Watch-app voorlopig niet te bouwen, en om een knop die al klaar was weer te schrappen, omdat Plens de gebruiker niets terug wil vragen.

Op onze over-ons-pagina staat het als uitgangspunt: “AI helpt ons meer werk te verzetten. Mensen bepalen het doel, maken de afwegingen en sturen bij.”

Wat gaat er mis zonder controles?

Zonder controles krijg je code die er goed uitziet maar die niemand heeft gelezen, en claims die niet kloppen. Een agent die snel werkt, maakt zijn fouten ook snel, en hij meldt zelden uit zichzelf dat hij iets niet zeker weet.

• Code die niemand gelezen heeft, en die dus ook niemand kan onderhouden.
• Een agent die zijn eigen werk nakijkt en daarbij dezelfde denkfout opnieuw maakt.
• Te ruime rechten: een agent die kan deployen, betalen of data verwijderen zonder akkoord.
• Claims zonder bewijs, zoals “werkt op iOS” terwijl alleen de build slaagde.

We kwamen het tegen in onze eigen bouw. Op 24 september haalden we de native Plens-app door een onafhankelijke review, met aparte agents die alleen mochten lezen. De eerste blokkerende bevinding was dat de hele app in één bestand van 317 regels zat, zonder deep links. Een eerdere claim over Siri op de Apple Watch bleek onjuist. En op een emulator maakte een testregistratie per ongeluk een echt account aan, omdat een native build nooit voorbeelddata gebruikt.

Je kunt ook verkeerd inschatten wat het je oplevert. In een gerandomiseerde studie van METR uit juli 2025⁠↗ deden zestien ervaren open-source-ontwikkelaars met AI-tools 19% langer over hun taken, terwijl ze dachten dat ze 20% sneller waren. METR noemt dat zelf een momentopname van begin 2025. In een update van 24 februari 2026⁠↗ schrijft het onderzoeksbureau dat ontwikkelaars nu waarschijnlijk meer versnelling uit AI-tools halen dan begin 2025, maar dat de nieuwe data over de omvang daarvan maar zwak bewijs geven.

Vertrouw dus niet op het gevoel dat het sneller gaat of goed werkt. Laat het zien met tests, een review en een meting.

Hoe pakken wij het aan?

Wij bouwen met ARCS, ons eigen agentic platform, dat de controles uit dit artikel vastlegt in de werkwijze. ARCS staat voor Agentic Reasoning & Coordination Systems. Het verdeelt het werk in afgebakende taken en wijst die toe aan gespecialiseerde councils: groepen agents met elk een eigen specialisme.

• Elk resultaat gaat langs een onafhankelijke reviewer: een ander model of een aparte context die het werk niet zelf heeft gemaakt.
• Het werk stopt als er goedkeuring nodig is, als het geblokkeerd is of als het budget op is. De reden wordt vastgelegd, zodat het werk later verder kan.
• Elke werksessie bewaart een checkpoint, zodat je kunt nagaan wat er gebeurde en het werk kunt hervatten.
• Een opdracht in tekst geeft een agent geen rechten. In de documentatie van ARCS staat het als regel: “Prompt text is never execution authority.” Rechten komen uit een vastgelegd beleid en expliciete toestemming.

Binnen een taak werkt ARCS met een vaste kwaliteitslus: een kandidaat, een controle die niet van een model afhangt, een gerichte reparatie en dan opnieuw de controle. Standaard zijn dat maximaal drie pogingen. Komt dezelfde fout terug, dan telt dat als geen voortgang en stopt de lus. Die lus mag nooit een menselijk beslismoment overslaan of een agent meer rechten geven: “Do not let the optimizer override a human gate or widen tool authority.”

Bij elke taak staat het langetermijndoel centraal: de north star. Hoe dat stap voor stap werkt, lees je in hoe ARCS agents laat bouwen met controles en op de pagina over hoe we bouwen. De review-stap behandelen we apart in AI-codereview door een council. En in Jev van TypeSafe uitgelegd lees je hoe een model dat één getypeerde keuze maakt in plaats van vrije tekst past in zo'n werkwijze.

Benieuwd of deze aanpak past bij wat jij wilt bouwen? Onze werkwijze staat op de homepage, en via contact kijken we er graag samen naar.