AI coding agent: van theorie naar meetbare team impact

AI coding agent: van theorie naar team impact

Een AI coding agent doet meer dan een regel aanvullen terwijl je typt. Geef het een doel, los deze bug op, voeg dit endpoint toe, refactor deze module, en het plant de stappen, bewerkt bestanden over je hele repository, voert je tests uit, en itereert op de fouten voordat je het eerste diff ziet. Die loop is het werkelijke verschil tussen een AI coding agent en een copilot die je zin afmaakt. Het verandert hoe je een sprint plant, niet alleen hoe snel je typt. Dit artikel meet wat die verschuiving werkelijk voor een echt engineeringteam van 5 tot 50 mensen betekent, niet wat een vendor op een slide claimt.

Wat maakt iets een AI coding agent en geen autocomplete

Inline suggestion tools voorspellen de volgende paar tokens terwijl je typt. Je blijft bij elke regel betrokken. Een AI coding agent werkt anders: het leest de relevante delen van je repo, ontwerpt een plan, bewerkt meerdere bestanden, voert de test suite uit, leest de foutmelding, en probeert opnieuw, vaak zonder dat je elke stap ziet.

Je kent de oude workflow al: grep, Ctrl+F, git blame, dan een Slack-bericht naar wie het bestand als laatst heeft aangepast. Een agent vervangt de eerste drie stappen met een tool die ze werkelijk sneller kan uitvoeren dan je de grep-opdracht kunt intypen. Het vervangt het Slack-bericht niet. Iemand moet het diff nog steeds vertrouwen.

Cursor's Agent-modus, GitHub Copilot's agent-modus, Claude Code, Devin en Replit Agent passen allemaal in deze definitie, met verschillende mate van autonomie. Cursor en Copilot blijven dichter bij de editor en verwachten dat een mens de meeste stappen goedkeurt. Devin werkt verder op zichzelf, in zijn eigen cloudumgeving, voordat het een PR teruggeeft.

Een ruwe versie van de loop ziet er in de praktijk ongeveer zo uit:

1. lezen: de bestanden relevant voor het doel lokaliseren
2. plannen: een reeks bewerkingen ontwerpen, niet slechts één diff
3. bewerken: wijzigingen toepassen op zoveel bestanden als het plan nodig heeft
4. uitvoeren: de test suite uitvoeren, of een gelimiteerde subset
5. opnieuw lezen: de foutmelding ontleden
6. stappen 3-5 herhalen tot tests slagen of een budget is bereikt

Stap 6 is waar marketing stopt en engineering begint. Een loop met geen limiet op pogingen zal blij weg een uur spenderen aan het vijf keer anders herschrijven van dezelfde functie. Een loop met een strak budget geeft je iets halfaf terug en zegt dat het af is. Geen van deze mislukkingsscenario's verschijnt in een benchmarkscores.

Waar de cijfers eerlijk worden: van 13,86% tot vandaag

Toen Cognition Devin's resultaten eerst publiceerde, loste de agent 13,86% van echte GitHub-issues van begin tot eind op, ongeleid, tegen de kunst van voor die onder de 2% zat. Dat was het hele verhaal in één getal: agents konden werkelijk end-to-end werk doen, alleen niet betrouwbaar nog niet. Het technische rapport is nog steeds openbaar, en het is het waard voordat je een huisvender's huisvende benchmarkslide vertrouwt, omdat het precies laat hoe de test werd ingesteld.

Twee jaar later behalen topagents 85 tot 90% op geselecteerde benchmarks als SWE-bench Verified, en de snelsten voeren uit met ongeveer 2,5x de token doorvoer van de vroege leiders van het veld. Dat is een echte sprong. Het is ook een geselecteerde benchmark, gebouwd uit issues die al een duidelijke oplossing en duidelijke test hebben. Je backlog is niet geselecteerd. De kloof tussen "lost een goed gespecificeerde GitHub-issue op" en "begrijpt waarom je auth middleware op de manier waarop het is bedraad" is de kloof die bepaalt of een agent je een middag bespaart of je er een kost.

Terminal-gerichte benchmarks vertellen een iets ander verhaal dan pure code-fix benchmarks, omdat ze een agent scoren op het uitvoeren van opdrachten en het correct lezen van hun output, dichter bij wat werkelijk gebeurt tijdens een debugging-sessie. Een tool kan goed scoren op de ene en middelmatig op de andere. Als een vendor slechts één getal publiceert, vraag dan welke benchmark het is voordat je het met het getal van een concurrent van een ander test vergelijkt.

De twee weken die werkelijk veranderen: onboarding met een AI coding agent

De duidelijkste meetbare overwinning is niet een senior engineer die sneller uitvoert. Het is de eerste twee weken van een junior engineer. Een nieuwe aanwerving op een 100K-LOC repo besteedde vroeger de eerste dagen aan lezen, niet schrijven: welke service eigendomhet deze tabel, waar wordt dit evenement gepubliceerd, waarom heeft deze ene functie drie call sites die niet gerelateerd lijken.

Een AI coding agent die "waar is refund logic geïmplementeerd" in seconden kan antwoorden, verwijdert die opstart helemaal niet. Het snijdt het onderdeel ervan af dat pure zoektocht was. Teams die een agent in onboarding hebben ingebouwd, rapporteren dat de eerste betekenisvolle PR in dagen landt in plaats van de tweede of derde week, vooral omdat de nieuwe aanwerving niet meer op het Slack-antwoord van een senior engineer wacht om een vraag te deblokkeren die de codebase zelf kon beantwoorden.

De mislukkingswijze is voorspelbaar: teams behandelen de agent als vervanging voor een geschreven architectuurdocument in plaats van een snellere manier om er één te verkennen. Een agent die "waar" vragen goed kan beantwoorden, kan een junior nog steeds niet "waarom we dit drie jaar geleden over het voor de hand liggende alternatief kozen" vertellen. Die context leeft in mensen, of in een ADR-bestand, niet alleen in de diff-geschiedenis.

Meet het in uren, niet in een gevoelspeiling. Volg de tijd tussen de eerste commit van een nieuwe aanwerving en hun eerste commit die een tweede service aanraakt. Dat getal dat van twaalf dagen naar vijf gaat, is een werkelijk resultaat dat u aan een manager kunt melden. "De onboarding-ervaring voelt soepeler" is dat niet.

Waarom multi-repo de vraag is die benchmarktabellen overslaan

De meeste openbare vergelijkingen testen een agent tegen een enkele repository met een enkele duidelijke taak. Teams van 20 of meer werken zelden op die manier. Een checkout-bug kan een frontend repo, een betalingsservice repo en een gedeeld types package aanraken, drie aparte plaatsen waar een agent over moet nadenken voordat het zelfs een oplossing kan voorstellen.

Single-repo autocomplete tools hoeven dit niet op te lossen. Codebase chat tools gebouwd rond natuurlijke taal zoeken doen het, omdat de vraag die een developer werkelijk stelt, "waar wordt dit gevalideerd," zelden respecteert de grens van een repo. Als uw agent alleen het bestand dat in uw editor open staat kan zien, veranderen multi-repo vragen in drie aparte, losgekoppelde sessies in plaats van één coherent antwoord.

Dit is de praktische reden om elke agent tegen uw eigen multi-repo setup te testen voordat u het uitrolt, niet tegen een demo repo die de vendor heeft gekozen. Een tool die identiek lijkt aan een concurrent op een single-repo benchmark kan zich heel anders gedragen wanneer het een aanroep over drie codebases met drie verschillende eigenaren moet traceren.

Een concrete test: kies een bug van afgelopen kwartaal die werkelijk twee repositories omvatte. Wijs de agent erop af, zonder hints over welke bestanden ertoe doen. Als het drie aparte sessies nodig heeft en een mens die de bevindingen aan elkaar naaien, dat is uw werkelijke multi-repo score, niet het getal op de landing page van de vendor.

Code review wordt de bottleneck, niet de code

Hier is het skip-voor-evident iedereen aanbeveelt maar weinig maatstaven: autonome modus van een agent inschakelen en het PRs vrijelijk laten openen. Een grootschalige analyse van 20.574 echte coding-agent sessies vond dat 91,49% van zichtbare agent resoluties nog steeds expliciete gebruikerscorrectie nodig hadden voordat ze werkelijk bruikbaar waren. De agent maakte iets af. Het was zelden het laatste iets.

Dat getal stelt de hele rollout-vraag opnieuw in. De beperking was nooit "kan de agent de code schrijven." Het is "heeft uw team de reviewcapaciteit om te vangen wanneer het 9 keer op de 10 correctie nodig heeft." Drie teams op de vijf onderschatten dit en eindigen met een review-wachtrij langer dan die ze hadden voordat een agent betrokken was.

De fix is de agent niet uitschakelen. Het gaat erom wat het zonder toezicht aan kan raken:

• Veilig om zonder toezicht uit te voeren: goed gespecificeerde bugs met een bestaande falende test, dependency bumps, dead code verwijdering, formattering en lint fixes.

• Altijd review voor samenvoegen, niet erna: iets dat auth, facturering, een database migratie of een openbare API contract aanraakt.

• Volg afzonderlijk: de correctiesnelheid in elke categorie. Als facturering-gerelateerde PRs correctie nodig hebben op het dubbele van de snelheid van lint fixes, dat is het signaal om het bereik van de agent verder in te stellen, niet om meer review-medewerkers toe te voegen.

De meeste teams slaan deze categorisering geheel over en passen één reviewbeleid toe op elke agent-geopende PR. De teams die het splitsen rapporteren consistent een kortere review-wachtrij binnen een maand, niet een langere.

Cursor, Claude Code, Devin, Tabnine: waar elk werkelijk voor is gebouwd

Deze vier worden constant vergeleken, meestal op de verkeerde as. Ze zijn niet uitwisselbaar, en de verschillen hebben meer belang dan enig enkel benchmarkscores.

• Cursor blijft het dichtst bij de editor. Sterke inline completion plus een agent-modus voor multi-file bewerkingen, met een mens die de meeste stappen goedkeurt. Goed geschikt voor een team dat agentic hulp wil zonder controle van het moment-tot-moment van de IDE te verliezen.

• Claude Code draait terminal-first, met brede repo context en minimale handhaving eenmaal u een taak bepaalt. Goed geschikt voor engineers die zich op hun gemak voelen met het delegeren van een heel feature branch en het resultaat als een diff beoordelen, niet een stroom van suggesties.

• Devin gaat het verst in autonomie, werkend in zijn eigen cloudomgeving op bepaalde taken als migraties of triage voordat het een PR teruggeeft. Goed geschikt voor goed gedefinieerde, herhaalbaar werk, niet dubbelzinnige productbeslissingen.

• Tabnine onderscheidt zich in implementatie, niet autonomie: on-prem of air-gapped opties en nulcode retentie voor teams die propriëtaire code niet kunnen naar een cloud van derden sturen, wat er van tabel verschilt.

Geen van deze vervangen het "waarom" dat een senior engineer in hun hoofd draagt. Alle snijden ze het "waar" en "wat" zoeken af dat ooit een ochtend at. Kiezen tussen hen gaat minder om welke deze maand slimmer is, omdat de onderliggende modellen snel convergeren, en meer om welke mislukkingswijze uw team kan tolereren: een Cursor-suggestie die u afwijst kost seconden, een Devin PR die u afwijst na te lopen zonder toezicht twintig minuten kost meer.

Wat u moet meten voordat u het uitrolt naar uw team

Sla de vendor-benchmark over en meet drie dingen op uw eigen repo:

1. Tijd tot het eerste juiste antwoord op vijf echte vragen die uw team vorige week stelde, niet een demovraag. Trek ze recht uit Slack-geschiedenis, ze zijn eerlijker dan iets wat een verkoopingenieur zal demo.

2. Correctiesnelheid op de eerste 20 door-agent geopende PRs, bijgehouden door wie ze ook review, niet zelf-gerapporteerd door de tool. Een PR die één kleine opmerking nodig had telt anders dan één die volledig moest worden herschreven, dus volg beide afzonderlijk.

3. Multi-repo nauwkeurigheid als uw codebase meer dan één repository omvat, expliciet getest, omdat de meeste agents op deze manier niet werden gebenchmarkt. Gebruik de koude-test methode uit de sectie hierboven en tim hoe lang een mens nodig heeft om het resultaat te verifiëren.

Sla dit over en je neemt aan op basis van een collegapost, niet uw eigen repo. Teams die eerst meten, eindigen meestal de agent strakker in te stellen dan de standaard van de leverancier, en blijven er een maand later gelukkiger mee.

Moet uw team er dit kwartaal een inschakelen

Als uw onboarding-pijn werkelijk en meetbaar is in verloren weken, ja, begin daar. Het is de meeste impactplek, laagste risicoplaats om een agent naar te wijzen, omdat een junior engineer-vraag toch al een senior engineer op de een of andere manier zou gaan onderbreken.

Als uw werkelijke bottleneck review-capaciteit is, autonome PR-modus inschakelen zal eerst die bottleneck erger maken voordat het iets sneller maakt. Bepaal het tot onboarding en goed gespecificeerde bug fixes eerst. Vouw uit eenmaal u een correctiesnelheid hebt gemeten die u kunt leven, niet eerder.