Coding agent

Wat is een coding agent?

Een coding agent is een programma dat een large language model een set tools geeft en het die tools in een loop laat gebruiken. Het zijn de tools die een ontwikkelaar de hele dag gebruikt: een bestand lezen, een bestand aanpassen, zoeken in de code, een commando uitvoeren in de terminal, een webpagina ophalen. Het model kiest welke tool het wil, het programma voert ze uit, het resultaat gaat terug in het gesprek en het model beslist wat de volgende stap is. Het stopt als het vindt dat de taak klaar is, of als jij het stopt.

Simon Willison omschrijft het kort en juist: een coding agent is een harness rond een LLM, die het model uitbreidt met mogelijkheden die als oproepbare tools gebouwd zijn. De meeste agents hebben een dozijn tools of meer, en de belangrijkste zijn de tools die code uitvoeren, zoals een Bash-tool voor terminalcommando's.

Die loop is het verschil met de twee dingen waar een coding agent vaak mee verward wordt. Autocomplete stelt de volgende paar regels voor terwijl je typt en voert nooit iets uit. Chat antwoordt op een vraag met een blok code dat je zelf kopieert, plakt en test; loopt het mis, dan plak jij de foutmelding terug. Een coding agent draait de test zelf, leest de fout zelf en probeert opnieuw, en hij kan dat een uur volhouden zonder dat jij ertussen zit.

Claude Code, Codex van OpenAI, Gemini CLI van Google en de agent mode van Copilot in de IDE zijn de bekende voorbeelden van de interactieve soort. Codex cloud, Jules van Google, Copilot cloud agent, de cloud agents van Cursor en Claude Code op het web zijn de achtergrondsoort: je geeft ze een taak, ze werken in een sandbox op afstand en geven een pull request terug.

De loop, stap voor stap

Neem een klein, alledaags karwei. Elke nacht exporteert een Python-script de bestellingen van de dag uit het ERP naar een CSV voor de boekhouder. Sinds gisteren crasht het. Je opent een coding agent in de projectmap en typt: het exportscript valt sinds gisteren uit, hier is de foutmelding.

1. Lezen. De agent zoekt het script, leest het en leest de foutmelding die je geplakt hebt. Hij ziet een KeyError op een kolomnaam.

2. Uitvoeren. Hij draait het script op het voorbeeldbestand in de testmap om de crash na te bootsen. Zelfde fout.

3. Aanpassen. Hij stelt vast dat het ERP de kolom sinds kort anders noemt, en past de mapping aan zodat beide namen aanvaard worden.

4. Opnieuw uitvoeren. Deze keer geen fout. Hij draait ook de twee bestaande tests in de map, omdat ze er nu eenmaal staan.

5. Rapporteren. Hij vertelt wat hij veranderd heeft, toont de diff en de testuitvoer, en vraagt of hij mag committen.

Elke stap is één rondje naar het model, met het volledige gesprek tot dan toe erbij. Willison wijst op het gevolg: hoe langer het gesprek, hoe duurder elke prompt, want de invoer groeit bij elke beurt. Een sessie van tien minuten kost bijna niets. Een sessie van vier uur op een grote codebase is waar de factuur vandaan komt. Daarom vatten agents hun geschiedenis samen, en daarom hebben de achtergrondvarianten een uitgavenplafond.

De loop werkt alleen als de agent zelf geslaagd van mislukt kan onderscheiden. Een testsuite, een script dat zonder fout moet afsluiten, een build, een screenshot naast het ontwerp: geef hem één daarvan en hij blijft doorgaan. Geef hem niets, dan stopt hij zodra de code er af uitziet.

Toestemmingen en sandboxing

Een agent die eender welk commando in je project mag uitvoeren, kan je project ook wissen, je .env-bestand lezen of naar je productiebranch pushen. Twee lagen houden dat tegen, en het zijn twee verschillende dingen.

Toestemmingen bepalen welke acties de agent mag doen zonder het te vragen. In de manuele modus van Claude Code mag hij binnen de projectmap lezen en draait een vaste lijst read-only commando's zoals ls, cat en grep zonder vraag; voor elke aanpassing of elk ander commando vraagt hij eerst toestemming. Andere modi verschuiven die grens: in plan mode mag hij lezen en verkennen maar niets aanpassen, en in auto mode kijkt een tweede model elke actie na in jouw plaats. Codex werkt met hetzelfde idee en drie instellingen: read-only, auto en volledige toegang. Die regels worden afgedwongen door het programma, niet door het model, dus een prompt kan de agent er niet voorbij praten.

Sandboxing wordt afgedwongen door het besturingssysteem en beperkt wat elk commando dat de agent draait kan bereiken, wat het model ook beslist. Claude Code en Codex gebruiken allebei het Seatbelt-framework van macOS en op Linux bubblewrap met een seccomp-filter, om het bestandssysteem en het netwerk af te schermen. Gemini CLI biedt Seatbelt op macOS en Docker- of Podman-containers op andere systemen. De standaard sandboxmodus van Codex houdt het netwerk dicht tot jij het openzet.

De reden dat die twee lagen bestaan, is prompt injection. De agent leest bestanden, webpagina's, issues en commentaren op pull requests omdat dat zijn werk is, en in elk daarvan kan een instructie staan die het model misschien opvolgt. Toestemmingen vangen het geval waarin het model iets ongewoons vraagt. De sandbox vangt het geval waarin het niet vraagt. Elke leverancier heeft ook een modus die alle vragen overslaat. De documentatie van Claude Code zegt die alleen te gebruiken in een container of een VM waar de agent geen schade kan aanrichten, en Codex noemt zijn tegenhanger afgeraden. Die afgeschermde opstelling is precies wat de background agents standaard meekrijgen.

Interactieve tegenover background coding agents

Beide vormen draaien dezelfde loop. Het verschil zit in wie meekijkt terwijl hij werkt.

Interactief: jij kijkt mee

De agent draait op jouw machine, in jouw checkout, met jouw toegangsrechten. Je ziet elke tool-call voorbijkomen, je beantwoordt de toestemmingsvragen en je kan halverwege onderbreken met een correctie. Dat maakt het de juiste vorm voor werk waar de opdracht nog vorm krijgt en je verwacht bij te sturen: een codebase die je niet kent, een refactor waar je een mening over hebt, een bug die nog niemand kan nabootsen. Het betekent ook dat één taak tegelijk je aandacht opeist.

Background: niemand kijkt tot de pull request er is

De agent draait in een cloud sandbox die de leverancier per taak opzet: hij kloont de repository, installeert de afhankelijkheden, werkt zo lang als nodig en pusht een branch. Codex cloud geeft elke taak een afgeschermde container, doet de setup met netwerktoegang en laat de agentfase daarna offline draaien tenzij je internet aanzet. Copilot cloud agent werkt in een tijdelijke omgeving op GitHub Actions, opent een draft pull request en zet jou als reviewer zodra hij klaar is. Jules schrijft eerst een plan dat je kan goedkeuren voor er één regel code verandert. De cloud agents van Cursor leveren bij de pull request ook screenshots, video's en logs van hoe de agent zijn werk gecontroleerd heeft. Claude Code op het web houdt de git-credentials buiten de sandbox en laat een proxy in naam van de sessie inloggen.

Omdat niemand de vragen beantwoordt, draait een background agent met aanpassingen en commando's vooraf goedgekeurd, en doet de sandbox het inperken. Je kan er meerdere tegelijk laten lopen: Jules laat 3 taken parallel toe in de gratis versie en 15 op Pro, en de websessies van Claude Code en de cloud agents van Cursor draaien er zoveel als je er start. De prijs daarvoor is dat je het resultaat pas ziet als de pull request af is, dus de taak moet goed genoeg beschreven zijn om uren zonder vraag te overleven. De leveranciers weten dat: Codex laat je een taak starten vanuit een GitHub pull request, een GitLab-issue, een Linear-ticket of een Slack-draad, Copilot vanuit een issue op je backlog. Dat duwt je in de richting van eerst een deftig ticket schrijven.

Wat je als zaakvoerder ervan ziet

Je zal zelf zelden een coding agent draaien. Je ziet wat eruit komt.

Pull requests van je leverancier. Een ontwikkelaar die met een agent werkt, levert meer branches, vaker, elk met een geschreven uitleg en een testrun erbij. Stel twee vragen: wie heeft dit gelezen voor het verstuurd werd, en waar draaide de agent. Een leverancier wiens agent op een laptop met volledige rechten tegen jouw live databank werkt, is een ander risico dan een leverancier wiens agent in een sandbox tegen een kopie werkt.

Interne tools die vroeger te klein waren om te bouwen. Een formulier dat een gedeelde spreadsheet vervangt, een script dat de facturen van je scanner een deftige naam geeft, een pagina waar planners leveringsslots verslepen. Werk dat geen offerte waard was, kost nu een namiddag met een agent, op voorwaarde dat iemand het resultaat kan lezen.

Agents die onder een mensennaam antwoorden. De auto-fix van Claude Code kan reviewcommentaren op GitHub beantwoorden via het account van de ontwikkelaar zelf, met een label dat het van Claude Code komt. De agent van Copilot zet in elke commitboodschap een link naar het sessielog. Als je nagaat wie wat veranderd heeft, kijk dan naar die labels.

Review en kost

Bij de pull request komen de twee vragen samen. De agent typt; de review is het werk waar je een mens voor betaalt.

Bij de interactieve vorm zit de kost meestal in een abonnement of een API-factuur, en ze groeit mee met de lengte van de sessie en de grootte van de codebase. De gratis versie van Gemini CLI met een persoonlijk Google-account laat 60 verzoeken per minuut en 1.000 per dag toe, genoeg om uit te vissen of de tool je ligt voor je iets uitgeeft.

De achtergrondvorm verandert de vorm van de factuur. Je betaalt per taak of per sessie in plaats van per persoon. Copilot cloud agent verbruikt GitHub Actions-minuten plus een gemeten AI-eenheid die afhangt van het model en het aantal verwerkte tokens. Cursor rekent zijn cloud agents aan tegen de API-prijs van het model dat je kiest en verplicht je een uitgavenlimiet in te stellen voor de eerste run. Jules telt taken per dag: 15 in de gratis versie en 100 op Pro. Claude Code op het web put uit dezelfde limieten als de rest van je Claude-gebruik, zonder aparte kost voor de VM. Parallelle taken vermenigvuldigen dat allemaal.

De achtergrondvorm verandert ook de review. Bij een interactieve agent zag je de redenering terwijl ze gebeurde. Bij een background agent krijg je een diff en een samenvatting, en die samenvatting is geschreven door het ding dat je aan het beoordelen bent. Lees de diff. GitHub maakt dat concreet: workflows op een pull request die Copilot geopend heeft, draaien pas als iemand met schrijfrechten op goedkeuren klikt, omdat een workflow secrets kan bevatten, en de documentatie zegt extra scherp te kijken naar elke wijziging onder .github/workflows. Twee gewoontes gelden bij elke leverancier: hou branch protection aan zodat een agent niet zelf kan mergen, en geef de agent een kopie van de data, nooit het live systeem, tot een mens gelezen heeft wat hij gedaan heeft.