🤖 AI

Agentic Coding Needs Proactivity, Not Just Autonomy

Dit artikel betoogt dat de volgende generatie coderingsagenten moet evolueren van louter autonomie naar echte proactiviteit door een duidelijke taxonomie te definiëren, acceptatiecriteria te stellen en specifieke maatstaven zoals Insight Decision Quality in te voeren om hun vermogen te evalueren om behoeften te anticiperen en softwareontwikkeling te verbeteren via mixed-initiative interactie.

Oorspronkelijke auteurs: Nghi D. Q. Bui, Georgios Evangelopoulos

Gepubliceerd 2026-05-11

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Nghi D. Q. Bui, Georgios Evangelopoulos

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een hoogopgeleide, supersnelle assistent hebt die je helpt bij het schrijven van software. Op dit moment zijn de meeste van deze assistenten als zeer gehoorzame bibliothecarissen. Als je naar het bureau loopt en vraagt: "Kun je een boek over katten voor me vinden?", vinden ze het direct. Als je zegt: "Schrijf een verhaal over een kat", schrijven ze het. Ze zijn autonoom omdat ze het werk kunnen doen zonder dat je hen bij de hand hoeft te houden, maar ze zijn reactief omdat ze alleen bewegen wanneer jij het hen zegt.

Dit artikel betoogt dat de volgende generatie coderingsassistenten meer moet zijn dan alleen gehoorzame bibliothecarissen. Ze moeten proactieve partners worden.

Hieronder volgt een uiteenzetting van de belangrijkste ideeën uit het artikel, met behulp van eenvoudige analogieën:

1. Het verschil tussen "Autonomie" en "Proactiviteit"

Autonomie (De Gehoorzame Bibliothecaris): De assistent wacht tot je een vraag stelt, en gaat dan het werk doen. Het is geweldig, maar het spreekt nooit uit eigen beweging tenzij jij eerst spreekt.
Proactiviteit (De Inzichtelijke Co-Piloot): De assistent houdt de hele bibliotheek (jouw code, je agenda, de chat van je team) in de gaten terwijl je werkt. Het merkt dingen op voordat je het vraagt.
- Voorbeeld: Je schrijft code voor een betalingssysteem. De assistent ziet een nieuwsmelding dat het betalingsbedrijf volgende week zijn regels wijzigt.
- Het Moeilijke Deel: Een proactieve agent schreeuwt niet direct "Hé, kijk hier!". Het moet beslissen: Is dit het juiste moment om te onderbreken? Is dit belangrijk genoeg? Moet ik stil blijven en wachten tot je je huidige gedachte hebt afgerond?

2. De Drie Niveaus van "Slimme" Assistenten

De auteurs hebben een "verkeerslichtsysteem" ontwikkeld om te beschrijven hoe slim deze agenten zijn:

Niveau 1: Reactief (Het Rode Licht)
- Hoe het werkt: De agent zit stil totdat je op een knop drukt (een prompt geeft).
- Analogie: Een rekenmachine. Het doet niets totdat je cijfers invoert.
Niveau 2: Gepland (Het Gele Licht)
- Hoe het werkt: De agent wordt wakker op specifieke tijden of wanneer een bepaald evenement plaatsvindt (zoals een geplande vergadering of een code-update). Het kan je een rapport sturen, maar het "denkt" niet echt na over of je druk bent of of het rapport op dit moment echt nuttig is.
- Analogie: Een krantbezorging. Het komt elke dag om 07:00 uur aan, of je nu wakker bent, slaapt of midden in een douche zit. Het weet niet of je het nodig hebt.
Niveau 3: Situatiesensitief (Het Groene Licht)
- Hoe het werkt: De agent observeert alles continu. Het berekent: "Als ik deze ontwikkelaar nu onderbreek, zullen ze geïrriteerd raken? Is deze informatie kritiek? Als ik stil blijf, missen ze dan iets belangrijks?"
- Analogie: Een persoonlijke assistent die weet dat je haat om tijdens diep werk te worden onderbroken. Als er brand uitbreekt, schreeuwt hij. Als er een pakketje aankomt, wacht hij tot je een koffiepauze neemt om het te vertellen. Ze leren ook van jou: "Oh, je hebt mijn suggestie over het budget vorige keer genegeerd? Ik zal je tot volgende maand niet lastigvallen over budgetten."

3. Het "Inzicht" is het Eigenlijke Product

Het artikel stelt dat we deze agenten niet moeten meten aan de hand van hoeveel taken ze voltooien. In plaats daarvan moeten we hun "Inzichtbeleid" meten.

Denk aan een Inzicht als een hypothese: "Ik denk dat je nu over X moet weten."
De agent heeft vier keuzes voor elk inzicht:

Melden: "Hé, kijk hier!" (Hoge urgentie).
Vragen: "Bedoelde je dit?" (Onzekerheid).
Opstellen: "Ik heb een oplossing voor je geschreven, wil je het zien?" (Laag inspanning, hoge waarde).
Stil blijven: "Ik zag dit, maar het is niet het juiste moment om iets te zeggen."

De grote claim van het artikel: De belangrijkste vaardigheid voor een agent op Niveau 3 is weten wanneer stil te blijven. Als een agent te veel praat, wordt het een last. Als het stil blijft wanneer het moet spreken, is het nutteloos.

4. Hoe Testen We Dit? (De Nieuwe Scorekaart)

Momenteel testen we coderingsagenten door ze een taak te geven en te kijken of ze die voltooien. De auteurs zeggen dat dit verkeerd is voor proactieve agenten. In plaats daarvan stellen ze drie nieuwe manieren voor om ze te beoordelen:

IDQ (Kwaliteit van Inzichtbeslissingen): Heeft de agent de juiste actie op het juiste moment gekozen?
- Heeft het je onderbroken toen je in je flow zat? Bleef het stil toen je hulp nodig had?
CGS (Contextonderbouwingsscore): Had de agent het juiste bewijs?
- Als het zei "Je code is kapot", liet het je dan de specifieke foutmelding zien, of raakte het alleen maar gissen?
LL (Leerverbetering): Is de agent slimmer geworden nadat je feedback gaf?
- Als je tegen hem zei: "Hou op me hiermee lastig te vallen", stopte hij er dan later echt mee?

5. De Huidige Realiteitscheck

De auteurs keken naar de beste coderingstools die vandaag beschikbaar zijn (zoals GitHub Copilot, Cursor, Claude Code, enz.). Ze ontdekten dat:

De meeste vastzitten op Niveau 2 (Gepland). Ze draaien op timers of triggers.
Geen van hen heeft momenteel een duidelijke manier om de "kosten van onderbreking" voor jou te berekenen.
Geen van hen behandelt "stil blijven" expliciet als een slimme, geleerde keuze. Ze wachten meestal gewoon tot je het vraagt.

Samenvatting

Het artikel is een oproep tot actie. Het zegt: "Stop met het bouwen van agenten die alleen maar werk kunnen doen. Begin met het bouwen van agenten die weten wanneer ze werk moeten doen, wanneer ze moeten spreken en wanneer ze moeten zwijgen."

Om daar te komen, moeten we stoppen met het meten van "voltooide taken" en beginnen met het meten van "goed oordeel", "bewijs" en "leren van feedback". Het doel is een coderingspartner die zich minder aanvoelt als een robot en meer als een doordachte teamgenoot.

Technische Samenvatting: Agentische Coding Vereist Proactiviteit, Niet Alleen Autonomie

1. Probleemstelling

Het landschap van softwareontwikkeling verschuift van inline code-aanvulling naar autonome coding agents die in staat zijn repositories te bewerken, pull requests te beheren en geplande routines uit te voeren. Hoewel huidige systemen aanzienlijke autonomie tonen (het vermogen om zonder toezicht te handelen), ontbreekt er een duidelijke definitie en evaluatiekader voor proactiviteit.

Het kernprobleem is het ontbreken van een mechanisme waarmee agents kunnen beslissen wanneer ze moeten handelen, wat ze moeten tonen en wanneer ze stil moeten blijven. Huidige agents opereren vaak op expliciete prompts of vaste schema's (Niveau 2), en maken geen onderscheid tussen "actief zijn" en "nuttig zijn". Er is geen duidelijk verslag van:

Wat proactiviteit betekent in de context van softwareontwikkeling.
Hoe het verschilt van eenvoudige autonomie.
Welke acceptatiecriteria proactieve taken op lange termijn moeten voldoen.
Welke metrieken bepalen of ongevraagd agentgedrag nuttig is in plaats van louter storend.

Zonder deze definities kan het vakgebied niet evalueren of het "inzichtbeleid" van een agent – het besluitvormingsproces over wat als nächst belangrijk is – effectief is.

2. Methodologie en Kader

De auteurs stellen een theoretisch kader voor dat gebaseerd is op mixed-initiative interactie (Horvitz, 1999) en autonomie-taxonomieën (Händler, 2023). De methodologie bestaat uit drie hoofdcomponenten:

A. Beslissingstheoretische Formulering

Het artikel modelleert proactief gedrag met behulp van een beslissingstheoretische vergelijking waarbij een agent een actie $a^*$ selecteert om de verwachte nuttigheid te maximaliseren en de onderbrekingskosten te minimaliseren:
$a^* = \arg\max_{a \in A} \mathbb{E}_{p(o|a,s_t,E_t)} [U(o; \theta)] - \text{Cost}_{int}(s_t, a; \theta)$

Actieruimte ( $A$ ): Omvat notify (melden), question (vragen), draft (opstellen) en cruciaal stay silent (stil blijven).
Toestand ( $s_t$ ): Ontwikkelaarsstatus (open buffers, agenda, sprintdeadlines).
Eventstroom ( $E_t$ ): Continue stroom van code-, project- en communicatiegebeurtenissen.
Kosten van Onderbreking ( $\text{Cost}_{int}$ ): Een variabele kost gebaseerd op focus van de ontwikkelaar, fase van de workflow en hersteltijd.
Inzicht: Gedefinieerd als een contextgebonden, tijdgevoelige hypothese gekoppeld aan een besluit om te handelen of stil te blijven.

B. Drie-niveau Taxonomie van Proactiviteit

De auteurs categoriseren agentische codingsystemen in drie niveaus op basis van hun vermogen om de termen in de beslissingsvergelijking te berekenen:

Niveau 1 (Reactief): Agents draaien alleen wanneer expliciet geprompt. Ze hebben geen aanhoudende aanwezigheid in de omgeving of tijdmodel tussen verzoeken.
Niveau 2 (Gepland): Agents draaien op schema's of vooraf gedefinieerde triggers (bijv. webhooks, GitHub-events). Ze kunnen output filteren of rangschikken, maar leren geen onderbrekingsbeleid per ontwikkelaar over verschillende contexten heen. Stilte is geen geleerde keuze; het is simpelweg de afwezigheid van een trigger.
Niveau 3 (Situatiebewust): Agents monitoren continu eventstromen, berekenen nuttigheid en onderbrekingskosten over de volledige actieruimte (inclusief stay silent), en updaten hun beleid ( $\theta$ ) op basis van feedback van de ontwikkelaar. Ze beslissen wat ze tonen, wanneer, en of iets tonen de juiste actie is.

C. Evaluatieprotocol

Het artikel stelt voor Active User Simulation (Nathani et al., 2026) aan te passen aan softwareontwikkeling. In plaats van het scoren van de uiteindelijke taakvoltooiing (zoals in SWE-Bench), richt de evaluatie zich op de inzichtstroom.

Trace-verzameling: Met tijdstempel voorziene, afspeelbare traces van ontwikkelaarswerkflows die repository-diffs, CI-logs, communicatie en IDE-status in lijn brengen.
Scenariostructuur: Scenario's op lange termijn bevatten zwakke signalen, afleidingen, bevestigend bewijs en momenten waarin stilte de juiste actie is.
Metrieken:
1. Insight Decision Quality (IDQ): Scoren of de agent op het juiste moment de juiste actie koos (melden, vragen, opstellen, stilte).
2. Context Grounding Score (CGS): Meet of getoonde inzichten worden ondersteund door herstelbaar bewijs (bestanden, diffs, logs) en of het bericht trouw is aan dat bewijs.
3. Learning Lift (LL): Meet de verbetering in IDQ wanneer een beleid zich aanpast aan feedback van de ontwikkelaar, vergeleken met een bevroren beleid.

3. Belangrijkste Bijdragen

Het artikel levert vier specifieke bijdragen:

Een Drie-niveau Taxonomie: Een formele scheiding van autonomie en proactiviteit, waarbij onderscheid wordt gemaakt tussen reactieve, geplande en situatiebewuste agents.
Vergelijkende Audit: Een analyse van vijf hedendaagse coding agents (Cursor, GitHub Copilot, Jules, Claude Code en een LangChain-referentiearchitectuur) tegen vijf praktische criteria (O1–O5).
- Vondst: Huidige ingezette agents clusteren rond Niveau 2. Geen enkele documenteert publiek betekenisvolle berekening van onderbrekingskosten (O1), expliciete stilte als een geleerde actie (O2), of beleidsupdates op basis van feedback per ontwikkelaar (O3).
Prototype Niveau 3 Engine: Een conceptuele architectuur gecentreerd rond de eenheid "inzicht", die een mentaal model van de ontwikkelaar bijhoudt en leert van respons.
Evaluatiemetrieken: Het voorstellen van IDQ, CGS en LL als de primaire eenheden voor het meten van proactief gedrag, waarbij de focus verschuift van taakvoltooiing naar de kwaliteit van het inzichtbeleid.

4. Resultaten en Vondsten

Het artikel presenteert geen gemeten experimentele resultaten van een ingezet Niveau 3-systeem; het is een positie- en meetvoorstel. De audit van bestaande systemen levert echter de volgende bevindingen op:

De "Proactiviteitskloof": Hoewel systemen zoals Cursor Automations en Claude Code Routines ondersteuning bieden voor geplande taken (Niveau 2), ontbreekt het bewijs van het berekenen van onderbrekingskosten of het behandelen van stilte als een expliciete, geleerde actie.
O1-O5 Audit:
- O1 (Kosten van Onderbreking): Geen enkele ingezette agent documenteert het berekenen hiervan.
- O2 (Expliciete Stilte): Geen enkele agent documenteert stilte als een geleerde actie in de actieruimte.
- O3 (Feedback-updates): Het bewijs is zwak; sommige systemen blootgeven geheugen, maar het effect op het blootleggen van beslissingen is onduidelijk.
- O4 (Over Context): Er bestaat gedeeltelijk bewijs voor het opnemen van meerdere contextcategorieën.
- O5 (Initiatiekanaal): Breed vervuld; agents kunnen berichten tonen zonder aparte tools.
Conclusie over Huidige Stand: De grens ligt niet in het uitvinden van nieuwe capaciteiten, maar in het aanpassen van bestaande interactiepatronen aan de specifieke kenmerken van softwareontwikkeling, met name het oordeel over wanneer te onderbreken en wanneer stil te blijven.

5. Betekenis en Beweringen

Het artikel beweert dat de volgende generatie coding agents niet moet worden geëvalueerd op hoeveel werk ze voltooien, maar door de kwaliteit en verbetering van hun inzichtbeleid.

Verschuiving in Paradigma: Proactiviteit moet worden gezien als "mixed-initiative samenwerking" in plaats van alleen automatisering. Een agent is proactief als het leert welke bijdragen aandacht verdienen, welk bewijs ze geloofwaardig maakt en hoe het zich aanpast na feedback.
Verantwoordingsplicht: Het kader maakt proactiviteit testbaar. Door "inzichten" te definiëren en IDQ, CGS en LL te meten, kan het vakgebied voorbij productlabels gaan naar meetbaar gedrag.
Ontwerprichtlijnen: Een echt Niveau 3-agent vereist een interface die uitgestelde inzichten inspecteerbaar maakt, waardoor ontwikkelaars suggesties kunnen accepteren, bewerken of afwijzen, en zo de feedbacklus bieden die nodig is voor leren.
Bescheidenheid: De auteurs erkennen dat dit een voorstel is. Gesimuleerde ontwikkelaars kunnen afwijken van echte gebruikers, en bevindingen over onderbrekingen uit real-time werk kunnen niet netjes worden overgebracht naar asynchrone berichten. Het artikel pleit voor het rapporteren van onzekerheid en het behandelen van proactiviteit als een eigenschap die echte ontwikkelaars betreft, in plaats van een enkele benchmarkscore.

Kortom, het artikel betoogt dat agentische coding om te rijpen, moet evolueren van "meer doen" naar "beter beslissen", met een specifieke focus op de strategische waarde van stilte en de continue aanpassing van onderbrekingsbeleid.