Agentic engineering

Wat is agentic engineering?

Agentic engineering is software bouwen door coding agents aan te sturen die plannen, code schrijven, uitvoeren en testen, terwijl jij verantwoordelijk blijft voor wat er in productie gaat. De agent typt. Jij beslist wat er gebouwd wordt, controleert of het klopt en geeft je fiat voor er iets bij een collega of een klant terechtkomt.

Een coding agent is een programma dat rond een large language model een set tools legt: bestanden lezen en aanpassen, een commando uitvoeren, de uitvoer lezen en opnieuw proberen. Claude Code, Codex van OpenAI en Gemini CLI van Google werken alle drie zo. Die loop is het verschil met een autocomplete-assistent: de agent draait je testsuite, ziet wat faalt en herstelt het zonder dat jij iets moet plakken.

Andrej Karpathy gaf het begin februari 2026 die naam, precies een jaar nadat hij vibe coding had gemunt. Zijn vaststelling: werken via agents was voor professionals de standaard geworden, "except with more oversight and scrutiny". "Agentic" omdat je de code meestal niet meer zelf typt maar agents aanstuurt, "engineering" omdat er vakmanschap in zit waar je beter in kan worden. Simon Willison nam de term enkele weken later over voor zijn gids met patronen, en zijn korte omschrijving is "the practice of developing software with the assistance of coding agents".

De tools zijn dezelfde als bij vibe coding. Wat verandert, is dat iemand het resultaat leest en er zijn naam onder zet.

Wat je nog altijd zelf doet

Het typen uitbesteden haalt het traagste stuk van het werk weg. Wat overblijft, zijn de stukken die bepalen of de software deugt.

De specificatie. De agent bouwt wat je beschrijft. Beschrijf je vaag, dan krijg je een geloofwaardig antwoord op de verkeerde vraag. De richtlijnen van Anthropic voor Claude Code raden aan om je eerst door de agent te laten interviewen en het resultaat in een spec-bestand te zetten: welke bestanden en koppelingen erbij betrokken zijn, wat buiten scope valt, en welke controle bewijst dat het werkt.

Architectuur en oordeel. Karpathy geeft een voorbeeld uit zijn eigen app MenuGen: de agents stelden voor om Stripe-aankopen aan Google-accounts te koppelen via het e-mailadres. Dat had gewerkt, en het was een slecht ontwerp geweest. Iemand met genoeg product- en engineeringinzicht moest erop staan dat er een vaste gebruikers-ID kwam.

Review. Het eerste anti-patroon in Willisons gids is een pull request indienen met code die je zelf niet gelezen hebt: "The initial review pass is your responsibility, not something you should farm out to others." De agent heeft ze geschreven, maar jouw naam staat op de commit.

Tests en verificatieloops

De richtlijnen van Anthropic voor Claude Code maken er een regel van: kan je het niet verifiëren, dan gaat het niet live. Tests waren vroeger al goede praktijk. Met agents worden ze het mechanisme waar de hele aanpak op draait, want een test is een controle die de agent zelf kan uitvoeren. Geef hem iets waarmee hij geslaagd van mislukt kan onderscheiden en hij gaat door tot het slaagt. Geef hem niets, dan is "het lijkt klaar" het enige signaal en ben jij de verificatieloop, fout per fout.

Willisons gids stelt dat geautomatiseerde tests niet langer optioneel zijn met coding agents, en twee van zijn patronen kan je meteen toepassen.

• Eerst de tests draaien. Begin elke sessie door de agent de bestaande testsuite te laten uitvoeren. Hij leert hoe hij ze moet draaien en zal ze na elke wijziging veel sneller opnieuw draaien.

• Red/green TDD. Vraag eerst de test die faalt, kijk of hij effectief faalt, en laat de agent hem dan doen slagen. Sla je die stap over, dan riskeer je een test die al slaagde voor de code bestond.

De controle hoeft geen unit test te zijn. Een build die zonder fouten afsluit, een script dat de uitvoer vergelijkt met een gekend bestand, een screenshot naast het ontwerp: alles wat een signaal teruggeeft dat de agent kan lezen, telt. Een tweede nuttige loop is een reviewer die de code niet geschreven heeft: Anthropic raadt een verse sessie of subagent aan die alleen de diff en het plan te zien krijgt, zodat hij niet vasthangt aan de redenering die tot de wijziging leidde.

Een voorbeeld. Een boekhoudster wil dat inkomende leveranciersfacturen automatisch aan bestelbonnen gekoppeld worden. Voor de agent één regel schrijft, spreek je met haar de regel af (zelfde leverancier, bedrag binnen 2 procent, besteldatum voor factuurdatum) en zet je die om in vijf testgevallen, waaronder één die net niet mag matchen. De agent draait de tests, ziet de vier gevallen die moeten matchen falen, schrijft de koppelingscode en draait alle vijf opnieuw. Jij leest de diff, draait de tests zelf op de export van vorige maand, en pas dan komt het in de buurt van het boekhoudpakket.

Agentic engineering tegenover vibe coding en pair programming

Tegenover vibe coding

Allebei gebruiken ze dezelfde agents. Het verschil zit in wie de kwaliteit in handen heeft en of de code bedoeld is om te blijven. Bij vibe coding leest niemand de code, is het draaiende resultaat de enige rechter en mag de code daarna weg. Bij agentic engineering leest iemand met naam de code, bewijzen tests dat ze klopt en wordt ze verondersteld jaren onderhouden te worden. Karpathy zegt het zelf zo: vibe coding is prima voor prototypes en persoonlijke tools, agentic engineering is wat serieuze teams nodig hebben.

Willisons waarschuwing hoort erbij: de agent haalt de kost van het typen weg, en niets van de kost om het juist te krijgen.

Tegenover klassiek pair programming

Bij pair programming delen twee mensen één toetsenbord: de ene typt, de andere reviewt terwijl het gebeurt en houdt het grotere geheel in de gaten. Van buitenaf lijkt agentic engineering daarop, de agent typt en jij navigeert, maar twee dingen zijn anders. Meekijkende review is bij een agent niet vanzelf aanwezig; je moet ze als aparte stap inbouwen. En de agent leert niets uit een sessie. Willison formuleert het zo: LLM's leren niet van hun fouten, coding agents wel, op voorwaarde dat jij wat je geleerd hebt in het instructiebestand van het project zet, zodat de volgende sessie ermee begint.

Wanneer past het voor een KMO?

De aanpak past bij werk waar de vraag duidelijk is, de controle makkelijk te schrijven is en de code lang meegaat binnen het bedrijf.

• Interne tools. Een kleine webpagina waar planners leveringsslots verschuiven, een formulier dat een gedeelde spreadsheet vervangt. De spec is een gesprek met de mensen die het gebruiken, en de test is of zij het aanvaarden.

• Integraties. Klanten uit het CRM naar het boekhoudpakket synchroniseren, bestellingen van de webshop in het ERP duwen. Beide kanten hebben een gedocumenteerde API en je kan testen op een voorbeeldrecord voor je aan live data komt.

• Rapporten en datapipelines. Een nachtelijke job die de verkoop in een warehouse laadt en een Power BI-model ververst. De controle is een afstemming: het totaal in het rapport is gelijk aan het totaal in de bron.

Het past minder goed als niemand in het bedrijf de code kan lezen, want dan heeft de reviewstap geen reviewer en zit je terug bij vibe coding met extra stappen. Hetzelfde als er geen manier is om de uitvoer te verifiëren: een agent op een oud systeem zonder tests en zonder documentatie levert zelfverzekerde wijzigingen die niemand kan nakijken. En overal waar een fout resultaat zwaar doorweegt, loonberekening, een prijs die de klant ziet, medische of veiligheidssoftware, behandel je de agent als een snelle junior en laat je elke wijziging door een mens goedkeuren.

Wat vraag je aan een leverancier die zegt zo te werken?

Deze vragen maken het verschil tussen agentic engineering en vibe coding met een factuur eraan:

1. Wie leest elke wijziging voor ze erin gaat, en kan die persoon de code uitleggen zonder de agent?

2. Welke geautomatiseerde controles bestaan er, en mogen we ze zien draaien? Een testsuite die bij elke commit in CI loopt, is het antwoord dat je wil horen.

3. Waar draait de agent en waar kan hij aan? Claude Code, Codex en Gemini CLI ondersteunen alle drie sandboxing en toestemmingsregels. Vraag of die gebruikt worden, zeker voor alles wat aan productiedata raakt.

4. Als jullie weggaan, kan een andere ontwikkelaar dit overnemen? Het eerlijke antwoord hangt af van de tests, de documentatie en de reviewgeschiedenis, niet van welke agent gebruikt werd.