Michael JohnsonJe kunt een agent een taak geven, wachten tot er wijzigingen in de repository staan en een concept-pull request ter beoordeling ontvangen. Maar naast de code rijst ook de vraag: voldoet het resultaat aan de opdracht en hebben de tests geen belangrijk probleem gemist?
Op 4 februari 2026 kondigde GitHub de openbare preview van Claude en Codex als codeeragents aan. Het bedrijf meldde dat je agents taken uit issues en pull requests kunt toewijzen en vervolgens hun voorbereide concept-PR kunt controleren. Dit bevestigt dat zo'n workflow beschikbaar is gekomen in de ontwikkelinterface, maar bewijst niet dat er tijd wordt bespaard of de codekwaliteit verbetert.
De vraag is dus niet alleen of een agent code kan schrijven. Het is ook van belang welk werk iemand rondom de gedelegeerde taak moet verrichten: beperkingen vaststellen, de voortgang volgen en het resultaat beoordelen.
Toezicht is meer dan alleen de eindcontrole
In een preprint die op 21 september 2026 op arXiv is gepubliceerd, stellen onderzoekers voor om toezicht op een codeeragent te zien als een doorlopend proces. Het onderzoek The Work Behind Delegation is gebaseerd op observaties en werkschema's van 19 ervaren ontwikkelaars. De auteurs beschrijven zeven fasen van toezicht en passen dit raamwerk toe op openbare gesprekken tussen ontwikkelaars op Reddit.
De benaderingen die de auteurs beschrijven omvatten meer aandacht voor planning, een deel van de toezichtstaken aan andere agents overdragen en terugkerende aanwijzingen omzetten in herbruikbaar materiaal. Dit is een analytisch raamwerk, geen meting van tijdsbesteding: het onderzoek stelt niet vast hoeveel tijd ontwikkelaars aan toezicht besteden of of dit proces sneller is dan handmatig werk. Op de arXiv-pagina staat dat de preprint in beoordeling is; de bevindingen moeten daarom als voorlopig worden beschouwd.
Voor de praktijk is het nuttig drie handelingen te onderscheiden. De taak formuleren bepaalt het doel en de beperkingen. Toezicht houden helpt vaststellen of de agent van de bedoeling is afgeweken. Controleren maakt het mogelijk te beoordelen of het resultaat aanvaardbaar is gezien de eisen, de code en de tests. Succes in de ene fase garandeert geen succes in de volgende: een patch kan aannemelijk lijken, maar de verkeerde taak oplossen of ingrijpende aanpassingen vereisen.
Ervaringen uit de community zijn geen statistieken
In een discussie op r/LocalLLaMA schreef een deelnemer dat zijn ervaring met lokale modellen en agents tegenviel: naar eigen zeggen moest hij de resultaten corrigeren en agents aan instructies herinneren. Andere deelnemers aan dezelfde thread beschreven een werkwijze die voor hen beter werkte: taken afbakenen, stapsgewijs werken en de code zorgvuldig controleren. Dit zijn afzonderlijke gebruikerservaringen, geen vergelijkende test van modellen of meting van de productiviteit van teams.
Deze uiteenlopende reacties laten zien dat ervaringen kunnen afhangen van de taak, het model, de omgeving en de werkwijze. Maar op basis van één discussie kun je niet bepalen welke praktijken gemiddeld effectiever zijn of hoe vaak problemen voorkomen. De thread gaat over lokale modellen; de ervaringen daaruit mogen dus niet automatisch worden doorgetrokken naar alle agenttools.
Menselijke betrokkenheid betekent op zichzelf niet dat delegeren zinloos is. Een ontwikkelaar kan een taak opsplitsen, wijzigingen controleren en eisen verduidelijken, terwijl diegene verantwoordelijk blijft voor het eindresultaat. Maar zonder de tijd mee te rekenen die nodig is voor het formuleren van de taak, correcties en review, valt niet te zeggen of de totale werklast is afgenomen.
Een concept-PR is nog geen geaccepteerde PR
In de door GitHub beschreven workflow kun je een issue aan een agent toewijzen en een concept-pull request ontvangen. Tussen het aanmaken en accepteren ervan blijven afzonderlijke vragen bestaan: voldoet de wijziging aan de eisen, zijn randgevallen meegenomen, zijn er voldoende tests en past de oplossing bij de architectuur van het project?
Deze criteria zijn niet terug te brengen tot één maatstaf. Het aantal aangemaakte wijzigingen is niet hetzelfde als het aantal bruikbare wijzigingen, en het slagen voor tests bevestigt niet noodzakelijk alle belangrijke eigenschappen van een patch. Zelfs een resultaat dat er kwalitatief goed uitziet, laat op zichzelf niet zien hoeveel werk nodig was om het voor te bereiden en te controleren.
Om het totale effect te beoordelen, moet de hele cyclus worden meegewogen: de taak formuleren, wachten op het resultaat, review, correcties en het verdere onderhoud van de code. De besproken bronnen bieden geen algemene vergelijking van die cyclus.
Wat we kunnen concluderen
De preprint biedt een raamwerk om over toezicht te praten, en GitHub meldde een workflow waarin je een taak aan een agent toewijst en de voorbereide PR controleert. De Reddit-discussie laat zien dat afzonderlijke gebruikers zowel moeilijkheden als nuttige werkwijzen met lokale modellen beschrijven. Samen zetten deze materialen de vraag op tafel hoe je de controle van gedelegeerde code organiseert, maar ze geven geen antwoord op de vraag naar de netto productiviteit.
Hieruit kun je niet concluderen dat ontwikkelaars over het algemeen al zijn overgestapt van code schrijven naar toezicht houden, dat agents steevast extra werk opleveren of dat ze de productiviteit in de sector verhogen. Voor zulke conclusies zijn vergelijkbare metingen van tijd en kwaliteit nodig bij uiteenlopende taken en in verschillende teams.
De praktische vraag voor een team is concreter: welke wijzigingen mag een agent zelfstandig voorbereiden, wat moet vóór het samenvoegen worden gecontroleerd en wie is verantwoordelijk voor de vraag of het resultaat de oorspronkelijke taak oplost? Delegeren neemt dit technische werk niet weg — het verandert waar het begint en waarop het zich richt.