Van AI-copilot naar background agent: waarom ‘spec naar pull request’ vooral een workflowprobleem is
De belofte verschuift van autocomplete naar zelfstandig werk
AI-coding begon voor veel teams als snellere autocomplete: een suggestie in de editor, een functie in een chatvenster of een refactor die je zelf nog stevig moest begeleiden. Dat blijft nuttig, maar het is niet de grootste verschuiving. De volgende stap is de background coding agent: een systeem dat niet alleen een stukje code voorstelt, maar een afgebakende taak oppakt, de repository opent, context verzamelt, tests draait en een pull request voorbereidt.
Dat klinkt alsof het vooral een modelprobleem is: wacht op een slimmer model en de rest lost zich vanzelf op. In de praktijk is dat te simpel. De bottleneck zit vaak niet in één extra slimme prompt, maar in de omgeving waarin die agent moet werken. Een rommelige repo, ontbrekende documentatie, impliciete conventies, lokale afhankelijkheden en onduidelijke acceptatiecriteria maken zelfs een sterke agent onzeker. Het resultaat is dan geen productieve versnelling, maar extra reviewwerk.
Daarom is de betere vraag niet: welke AI-tool schrijft de meeste code? De betere vraag is: hoe maak je je engineeringproces geschikt voor werk dat door een agent kan worden voorbereid en door mensen kan worden beoordeeld?
Wat een background agent anders maakt dan een copilot
Een copilot werkt meestal naast de developer. De mens houdt de taak vast, kiest de richting en beslist telkens wat er gebeurt. Een background agent werkt meer als een tijdelijke junior uitvoerder binnen een strak kader. Je geeft een opdracht, de agent onderzoekt de codebase, past bestanden aan, draait controles en levert een voorstel terug. Dat voorstel is idealiter geen losse code in een chat, maar een pull request dat in het normale reviewproces past.
Daarmee verandert de vorm van samenwerken. De developer schrijft minder vaak instructies per regel code en vaker een compacte werkopdracht met context, randvoorwaarden en acceptatiecriteria. Dat vraagt een andere discipline. Een vage opdracht als ‘maak dit beter’ is zelden genoeg. Een goede opdracht beschrijft welk probleem moet worden opgelost, welke bestanden of modules relevant zijn, welke tests geraakt worden, welke stijlregels gelden en wanneer het resultaat acceptabel is.
De waarde zit dus niet alleen in codegeneratie. De waarde zit in het omzetten van terugkerende engineeringtaken naar kleine, controleerbare workflows. Denk aan eenvoudige bugfixes, testuitbreidingen, dependency-updates, documentatiecorrecties, kleine UI-aanpassingen of voorbereidende refactors. Juist die taken kosten teams veel contextswitches, maar zijn vaak goed af te bakenen.
Context engineering wordt de nieuwe bottleneck
Voor background agents is context geen bijzaak. Context is het werkmateriaal. Een agent moet weten hoe het project is opgebouwd, welke conventies het team gebruikt, hoe de applicatie lokaal draait, welke tests belangrijk zijn, welke onderdelen gevoelig zijn en welke beslissingen al eerder zijn genomen. Zonder die informatie gaat de agent gokken. En gokken in een productie-repository is duur.
Context engineering betekent dat je die informatie niet telkens opnieuw in een prompt probeert te proppen, maar structureel beschikbaar maakt. Dat kan via repo-documentatie, taaktemplates, architectuurbesluiten, testinstructies, code-eigenaren, voorbeeld-PR’s, setup-scripts en vaste beschrijvingen van domeinregels. Het doel is niet meer tekst, maar betere vindbaarheid van de juiste informatie op het juiste moment.
Een praktisch startpunt is een agent-instructiebestand per repository. Daarin leg je vast hoe de app gestart wordt, welke commando’s veilig zijn, welke tests minimaal moeten draaien, welke directories vermeden moeten worden en hoe een pull request beschreven moet worden. Voeg daarna taaktypes toe: ‘bugfix’, ‘test toevoegen’, ‘copy aanpassen’, ‘API-contract controleren’. Hoe duidelijker de taakvorm, hoe kleiner de kans dat de agent buiten de bedoeling gaat werken.
Repo-setup is minder saai dan het lijkt
Veel teams onderschatten repo-setup omdat developers de lokale eigenaardigheden inmiddels uit hun hoofd kennen. De ene service moet eerst draaien, de andere heeft een specifieke versie nodig, een derde vereist een seed-script of een lokale configuratie die nergens volledig beschreven staat. Voor een mens is dat irritant maar overbrugbaar. Voor een background agent is het een harde blokkade.
Docker of een vergelijkbare containeropzet helpt, maar is niet automatisch genoeg. Sommige projecten hebben meerdere services, browserafhankelijke tests, specifieke systeempackages, private dependencies of een vooraf ingestelde machine-state nodig. In die gevallen is een reproduceerbare ontwikkelomgeving belangrijker dan de vraag welke agent je kiest. Als de omgeving niet betrouwbaar start, kan de agent geen betrouwbaar werk leveren.
Teams die serieus met spec-to-PR willen werken, doen er goed aan om setup als productiewerk te behandelen. Maak een schone installatie herhaalbaar. Leg vast welke commando’s nodig zijn. Zorg dat testdata veilig en voorspelbaar beschikbaar is. Automatiseer waar mogelijk. Een agent-ready repo is vaak ook een developer-ready repo: nieuwe mensen zijn sneller ingewerkt, CI wordt stabieler en verborgen kennis verdwijnt uit individuele laptops.
Veiligheid: geef agents minder rechten dan mensen
Een background agent heeft toegang nodig om nuttig te zijn, maar onbeperkte toegang is een slecht uitgangspunt. Zodra een agent repositories, issue-systemen, chatkanalen, CI-processen of interne tools kan gebruiken, moet je nadenken over permissies. Niet omdat elke agent gevaarlijk is, maar omdat automatisering fouten op schaal kan maken.
De basis is scoped access: geef alleen de rechten die nodig zijn voor het taaktype. Een agent die tests schrijft, hoeft niet bij productiegeheimen. Een agent die documentatie aanpast, hoeft geen deploy-rechten. Secrets moeten beperkt, tijdelijk en controleerbaar zijn. Log bovendien welke acties de agent uitvoert, welke bestanden zijn aangepast en welke commando’s zijn gedraaid.
Ook de menselijke review blijft essentieel. Een pull request van een agent moet niet automatisch als minder of meer betrouwbaar worden behandeld dan werk van een collega. De vraag is: is de wijziging klein genoeg, getest genoeg en duidelijk genoeg om te beoordelen? Als het antwoord nee is, was de opdracht waarschijnlijk te breed of de context onvoldoende.
Meet mergebare pull requests, niet gegenereerde regels code
De slechtste KPI voor AI-coding is het aantal gegenereerde regels code. Meer code is niet automatisch vooruitgang. Soms is de beste bijdrage juist een kleine wijziging, een betere test of het verwijderen van overbodige complexiteit. Voor background agents is een betere maatstaf: hoeveel pull requests zijn klein, begrijpelijk, getest en zonder buitensporige reviewlast te mergen?
Kijk daarnaast naar doorlooptijd per taaktype, percentage mislukte runs, redenen waarom taken vastlopen, hoeveelheid menselijke correctie en herbruikbaarheid van context. Als agents vaak stranden op ontbrekende dependencies, dan heb je geen modelprobleem maar een setup-probleem. Als reviewers veel tijd kwijt zijn aan onduidelijke intentie, dan heb je een spec-probleem. Als agents te veel bestanden raken, dan zijn taken te groot of permissies te ruim.
Begin daarom met low-risk werk. Laat agents tests toevoegen voor bestaande bugs, kleine documentatieproblemen oplossen, eenvoudige lint-fixes voorbereiden of geïsoleerde componentaanpassingen doen. Verzamel patronen. Pas templates aan. Bouw een bibliotheek met goede opdrachten. Pas daarna ga je richting complexere taken.
Een praktisch adoptiekader voor AI-teams
Wie background agents wil invoeren, hoeft niet te beginnen met een groot transformatieprogramma. Begin met één repository en één taaktype. Kies iets dat waardevol is, maar beperkt risico heeft. Documenteer de ideale opdracht, de noodzakelijke context, de setupstappen en de minimale acceptatiecriteria. Laat de agent meerdere varianten proberen en beoordeel niet alleen het eindresultaat, maar ook waar het proces stokt.
Maak vervolgens een vaste workflow: taak selecteren, spec schrijven, context koppelen, agent laten draaien, tests controleren, pull request openen, review uitvoeren en leerpunten terugschrijven naar de instructies. Die laatste stap is cruciaal. Zonder feedbacklus blijft elke run een losse poging. Met feedbacklus wordt je repo steeds beter geschikt voor agentisch werk.
De nuchtere conclusie: de winnaar is niet het team met de meeste AI-tools. De winnaar is het team dat werk goed kan verpakken. Duidelijke specs, reproduceerbare omgevingen, veilige toegang, automatische tests en scherpe review maken van een background agent geen wondermiddel, maar wel een bruikbare hefboom. Dat is precies waar Funnel Adviseur naar kijkt bij automatisering: niet de tool als gimmick, maar het proces eromheen dat bepaalt of automatisering rendement oplevert.
