GitHub Copilot als AI coding agent: wat is er nieuw?

Je opent een issue, gaat lunchen, en als je terugkomt ligt er een pull request klaar. Dat is de belofte van GitHub Copilot als AI coding agent, en met een reeks nieuwe updates wordt die belofte conkreter dan ooit. Niet meer één standaardmodel voor alles, geen blinde output meer die je daarna zelf moet opschonen, en een beveiligingslaag die ingebouwd zit in plaats van er achteraf op geplakt. Hier is wat er nieuw is, en wat het betekent als je een team hebt dat dagelijks met code werkt.

Wat is een AI coding agent eigenlijk?

Een AI coding agent is een AI-systeem dat zelfstandig taken uitvoert in je codebase: bugs fixen, tests schrijven, technische schuld wegwerken. Je wijst een taak toe, de agent werkt op de achtergrond, en het resultaat is een pull request dat klaar staat voor review. Niet als suggestie in je editor, maar als volwaardige bijdrage die door een mens beoordeeld wordt.

GitHub Copilot doet dit al een tijdje, maar de tool was tot voor kort vrij beperkt: één model, geen zelfcontrole, en beveiliging als bijzaak. Dat verandert nu met een handvol concrete updates.

Modelkeuze: de juiste tool voor de juiste klus

Copilot draaide voorheen elke achtergrondtaak op hetzelfde standaardmodel. Nu kies je per taak welk model je inzet: snel en goedkoop voor eenvoudig werk, zwaarder voor complexe opdrachten. Of je laat GitHub zelf kiezen. Het directe gevolg: minder verspilling op routinetaken, meer rekenkracht waar het telt.

De eerste update is simpel maar impactvol. Routinewerk zoals unit tests schrijven en complexe refactors kregen voorheen dezelfde behandeling, wat ofwel te traag was ofwel te grof. Vergelijk het met hoe je in je eigen team ook niet je meest senior developer inzet voor elke kleine bugfix.

Volgens GitHub's eigen documentatie is modelkeuze nu beschikbaar voor Copilot Pro en Pro+ gebruikers, met Business en Enterprise-ondersteuning die binnenkort volgt.

Zelfcontrole voor betere pull requests

De pijnlijkste stap bij AI-gegenereerde code was altijd de review. Je opent de diff en ziet code die technisch werkt, maar die geen mens zo zou schrijven. Omslachtig, niet consistent met de rest van de codebase, vol kleine onlogische keuzes.

Copilot coding agent reviewt nu zijn eigen wijzigingen voordat het een pull request opent. Het systeem haalt feedback op, itereert, en verbetert de patch. Tegen de tijd dat jij een review-verzoek krijgt, heeft de agent al een eerste kwaliteitsronde gedaan.

Dit klinkt als een kleine verbetering, maar het is eigenlijk een fundamentele verschuiving. De bottleneck bij AI-gegenereerde code is zelden de generatie zelf, het is de opschoning achteraf. Als die stap deels geautomatiseerd wordt, verandert de verhouding tussen menselijke reviewtijd en AI-output significant. Vergelijk dit met wat er al mogelijk is bij GitHub Agentic Workflows, waar de workflow zelf steeds meer het werk overneemt.

Ingebouwde beveiligingsscan: handig, maar geen garantie

Copilot coding agent scant nu automatisch op beveiligingsproblemen voordat een pull request wordt geopend. Dat is een logische stap: als de agent code schrijft, moet hij ook controleren of die code veilig is.

Hier is het eerlijke verhaal: ingebouwde beveiligingsscanning is nuttig, maar niet waterdicht. Uit onderzoek gepubliceerd op arXiv blijkt dat statische analysetools, ook geavanceerde zoals CodeQL, AI-gegenereerde code regelmatig missen op runtime-kwetsbaarheden. De code ziet er structureel correct uit en passeert patroonherkenning, maar bevat toch exploiteerbare fouten.

Volgens Legit Security ontdekte het bedrijf een kwetsbaarheid waarbij Copilot privé broncode kon lekken via een aanval die ze CamoLeak noemden. De ingebouwde scanning helpt, maar vervangt geen aparte beveiligingsreview voor gevoelige code.

Dat is geen reden om de feature niet te gebruiken. Het is wel een reden om hem niet als eindpunt te zien. Meer over hoe AI-agents omgaan met beveiligingsrisico's lees je in dit stuk over AI agent beveiliging.

Eigen agents bouwen voor specifieke workflows

Een van de interessantere nieuwe mogelijkheden is het aanmaken van custom agents: gespecialiseerde profielen die je definieert voor terugkerende taken in jouw specifieke context. Denk aan een agent die altijd jouw stijlgids volgt, een agent die specifiek documentatie schrijft, of een agent die security checks uitvoert op een bepaald deel van je codebase.

Volgens GitHub's documentatie zijn custom agents op te slaan op gebruikersniveau, repository-niveau, of organisatieniveau. Dat laatste is interessant voor teams: je kunt gestandaardiseerde agents uitrollen die iedereen in de organisatie gebruikt, zonder dat elk teamlid die zelf hoeft te configureren.

Dit sluit aan op een bredere trend: AI-tools worden minder generiek en meer aanpasbaar aan de context van een specifiek bedrijf. De beste AI coding agent is niet de slimste in abstracte benchmarks, maar de agent die het beste past bij jouw codebase, jouw conventies, jouw workflow. Dat is precies wat custom agents mogelijk maken.

CLI-integratie: van browser naar terminal

De CLI-update verlaagt de drempel om een taak aan de AI coding agent te geven: je typt een opdracht in je terminal, de agent pakt het op, werkt op de achtergrond, en maakt een draft pull request aan. Geen browser, geen apart paneel, geen context-switch.

Wat dit in de praktijk betekent: de wrijving die je voelt bij het delegeren van een taak verdwijnt bijna volledig. Volgens GitHub's CLI-documentatie werkt dit via natuurlijke taal, niet via specifieke commando-syntaxis. Je beschrijft wat je wilt, de agent interpreteert en handelt.

Voor teams die snel willen schakelen is dit de meest onderschatte update van de reeks.

Wat betekent dit voor je team en je planning?

Als je een team van developers aanstuurt, verandert er meer dan alleen de tooling. De vraag is hoe je dit inpast in hoe je werk verdeelt en verwachtingen stelt.

Wat je nu anders kunt organiseren: routinetaken zoals tests schrijven, documentatie bijwerken en kleine bugfixes zijn steeds beter te delegeren aan een AI coding agent. Dat heeft gevolgen voor sprint planning. Taken die voorheen een halve dag kosten, worden kleiner in schatting. Maar dat betekent ook dat je als manager duidelijk moet zijn over wat de agent wel en niet aankan, zodat developers niet verrast worden door output die toch review vereist.

Interessanter is wat dit doet voor hiring-overwegingen. Als routinewerk structureel verschuift naar een agent, verschuift de waarde van een developer richting architectuurbeslissingen, codereview en het definiëren van context voor de agent. Dat is een ander profiel dan vijf jaar geleden. De vergelijking die ik hier zie is die met Claude Code: beide tools bewegen richting een model waarbij AI niet alleen suggereert, maar ook uitvoert. Het verschil zit in de integratie met bestaande workflows. Copilot is diep verweven met GitHub, en voor teams die daar al in werken is de drempel laag.

Wat goed werkt in de praktijk

Wat je uit deze reeks updates kunt meenemen, valt samen te vatten in drie observaties.

Beginnen met een afgebakende taak werkt het beste. Unit tests schrijven voor een bestaande module, of een bekende bug fixen: dat zijn de gevallen waar de agent het meest voorspelbaar presteert. Zo leer je de grenzen kennen zonder kritieke code te riskeren.

Een geconfigureerde agent presteert beter dan een generieke. Custom agents met instructies over naamgevingsconventies, stijlgids en gebruikte libraries leveren merkbaar betere output dan een agent zonder context. Dat is niet verrassend, maar het is wel iets wat je actief moet inrichten.

En de beveiligingsscan is een startpunt, geen eindpunt. De ingebouwde scan vangt veel, maar zoals de CamoLeak-kwetsbaarheid laat zien: er zijn gevallen die er doorheen glippen. Voor code die omgaat met authenticatie of gevoelige data blijft een aparte review nodig.

Wat dit pakket updates uiteindelijk laat zien: de AI coding agent van GitHub groeit van een slim autocomplete-systeem naar iets dat daadwerkelijk zelfstandig een stap in je ontwikkelproces kan zetten. De zelfcontrole-loop is daarin de meest significante verandering. Niet omdat de output perfect is, maar omdat het de vraag verschuift van "klopt deze code?" naar "past deze aanpak bij wat we willen bouwen?" Dat is een andere soort review, en een nuttigere.