Agentic productontwikkeling betekent dat je de volledige softwareleveringscyclus zo inricht dat AI-agents het scaffolding, de contextoverdracht en de codegeneratie voor hun rekening nemen, terwijl engineers zich richten op oordeelsvorming, review en beslissingen. Het werkt het best als de basis solide is en de context expliciet wordt vastgelegd.
Gestructureerde fases leveren betere agent-output
AI-agents produceren betere output als ze heldere context en duidelijke grenzen hebben. Vage prompts leveren generieke code op. Gedetailleerde specs leveren code die past binnen je codebase, aansluit bij je design system en je conventies volgt.
Dit heeft teams teruggebracht naar lineaire, gestructureerde leveringsfases: eerst discovery, dan design, dan engineering. De logica is eenvoudig. Als je alle context en beslissingen naar voren haalt voordat de delivery begint, hebben coding agents alles wat ze nodig hebben. Geen giswerk, improviseren of heen-en-weergepraat midden in een sprint.
De adminlaag automatiseren
Als je elke stap in een typisch productproces in kaart brengt, blijkt het merendeel van het werk meta-werk te zijn: uitkomsten opschrijven, handoff-documenten maken, acties structureren en context overdragen tussen mensen. E-mails, spreadsheets, handoff-decks. Noodzakelijk, maar niet waar waarde wordt gecreëerd.
Teams die agents goed inzetten, hebben die adminlaag geautomatiseerd en de vrijgekomen tijd herbelegd in de gesprekken waar productkeuzes daadwerkelijk worden gemaakt: dieper ingaan op domein, prioriteiten en randvoorwaarden met stakeholders.
Een contextlaag die handoff-verlies voorkomt
Het grootste structurele probleem in productontwikkeling is contextverval. Elke handoff verliest informatie. Tussen discovery en design. Tussen design en engineering. Tussen het ene overleg en het volgende.
Een centrale context engineering-laag, gebouwd met agents en MCP servers, pakt dit direct aan. Agents koppelen aan discovery-tools, halen ongestructureerde sessiedata op en structureren die automatisch tot productbriefs, feature boards en prioriteitsmatrices. Die gestructureerde context stroomt door naar design-tools, waar agents echte componenten scaffolden vanuit het bestaande design system. Van daaruit gaat het door naar engineering-tickets met acceptatiecriteria en design-referenties.
Geen mens die informatie handmatig tussen tools kopieert. De context stroomt door in plaats van te verdampen.
Dit maakt ook parallelle exploratie haalbaar. Vijf oplossingsrichtingen kunnen tegelijkertijd worden geprototyped op basis van echte design system-componenten en discovery-data, waarna ze samen worden gereviewd. Vijf prototypes handmatig bouwen zou weken kosten. Agents regelen het scaffolding; engineers leveren het oordeel.
Spec-gedreven ontwikkeling
Hoe ontwikkelwerk wordt gedefinieerd, is veranderd samen met hoe het wordt uitgevoerd. Traditionele tickets beschrijven acceptatiecriteria: wanneer is dit klaar? Agentische teams stappen over op specs. In plaats van te beschrijven wat een feature moet doen, beschrijft een spec de beoogde uitkomst als een complete workflow, inclusief edge cases.
De agent werkt die spec af en valideert zijn eigen output ertegen. Dat lukt alleen omdat de context uit discovery en design al geladen is. De agent werkt naar een helder gedefinieerd doel toe. Lees ook: is prompt engineering nog relevant.
Wat er in de praktijk misgaat
De fout is niet dat agents slechte code schrijven. De fout is dat ze plausibele code schrijven. Code die werkt, code die een vluchtige review doorstaat, maar die ondertussen aannames doet die niet kloppen, verwijst naar APIs die niet bestaan in jouw versie, of één probleem oplost op een manier die drie andere problemen veroorzaakt.
Agents zijn waargenomen waarbij ze vol vertrouwen verouderde documentatie gebruikten, databasekolommen verzonnen, en elegante oplossingen bouwden die de bestaande architectuur volledig negeerden.
Het echte gevaar is dat naarmate de kwaliteit van agent-output verbetert, de reviewdiscipline daalt. Teams beginnen de agent te vertrouwen. Ze scannen in plaats van te lezen. Ze keuren goed in plaats van te bevragen. Dit wordt soms AI slop genoemd, en het voorkomen ervan is nu net zo'n onderdeel van de engineersrol als het bouwen van features. AI-gegenereerde code reviewen vereist actieve inspanning: drie lagen werken goed in de praktijk. De agent schrijft. Geautomatiseerde review filtert. Een menselijke engineer neemt de uiteindelijke beslissing. Voor meer over wat hier is veranderd, zie wat er veranderd is aan code review.
De beste engineers in een agentische workflow zijn niet de beste programmeurs. Het zijn de beste denkers.
Je organisatie is er mogelijk nog niet klaar voor
Alles hierboven werkt alleen als je fundament op orde is.
Geen design system betekent dat agents inconsistente designs produceren. Geen modulaire codebase betekent ononderhoudbare output. Geen gestructureerde documentatie betekent dat de contextlaag niets heeft om mee te werken.
Teams die agentic development willen invoeren maar een legacy codebase hebben, moeten eerst de bestaande code werkbaar maken. Een praktische aanpak: schrijf een grondige testsuite voor de oude codebase en laat agents daarna refactoren naar een moderne stack, terwijl ze valideren tegen die tests. De tests zijn dan de bron van waarheid. Slaagt de gerefactorde code, dan weet je dat het werkt. Dit is een vorm van human-in-the-loop engineering op architectuurniveau.
De organisaties die het meeste uit agentic development halen, hebben eerst geïnvesteerd in het fundament: een schone architectuur, gedocumenteerde conventies, modulaire code en een design system dat agents kunnen uitbreiden. Het gereedschap is niet beter dan het systeem dat eromheen is gebouwd.
In een AI-native team
AI-native engineers die werken in agentic pipelines besteden meer tijd aan het lezen en verifiëren van code dan aan het zelf schrijven ervan, omdat agents hele modules sneller kunnen opzetten dan een individu kan typen. Context engineering, niet alleen prompt writing, wordt een kernvaardigheid: de kwaliteit van wat een agent produceert hangt sterk af van hoe goed de omliggende documentatie, conventies en specificaties zijn gestructureerd. Teams hebben ook duidelijke eigenaarschap nodig over de reviewfase, want het volume aan door agents gegenereerde output kan de handmatige controle gemakkelijk overtreffen als niemand er expliciet verantwoordelijk voor is.
Waar we op testen
Bij het beoordelen van engineers voor agentic rollen doen we twee assessments, zoals beschreven in zo screenen we. Het eerste toetst de basis zonder AI-tools, zodat vaststaat dat een engineer zelfstandig code kan lezen en erover kan redeneren. In het tweede, de AI-native assessment, werkt de engineer met agents aan een realistische opdracht. Die tweede assessment test oordeelsvermogen onder realistische omstandigheden. Ziet de engineer een verzonnen API? Vangt die een architectuuraanname af die niet klopt? Controleert die gegenereerde code die hij of zij niet zelf schreef? Deze vaardigheden bepalen of een engineer effectief is in een agentic team. Pure codeersnelheid zegt daar weinig over.
