Van losse hulp naar agentteams
McKinsey onderscheidt vier niveaus waarop AI software development zich momenteel afspeelt. Op het eerste niveau schrijft een ontwikkelaar nog alles zelf. Op het tweede niveau suggereert een assistent de volgende regels code, als een snelle programmeerpartner naast je. Bij het derde niveau beschrijft iemand een feature in gewone taal en genereert een AI-agent de eerste versie van code, tests en documentatie. Het vierde niveau gaat verder: een klein team stuurt een samenwerkend stelsel van AI-agents aan dat een hele applicatie oplevert, van ontwerp tot test, en grijpt alleen in bij beslissingen die echt mensenwerk vragen.
De meeste bedrijven zitten nog op niveau twee of drie. Stack Overflow registreert dat 84 procent van de developers AI-tools gebruikt of van plan is te gaan gebruiken, tegen 76 procent een jaar eerder. 51 procent doet dat dagelijks. Tegelijk zegt 46 procent de nauwkeurigheid van AI-output te wantrouwen, tegenover 33 procent die er wel op vertrouwt. Het wantrouwen groeit dus sneller dan het gebruik daalt: teams zetten AI wel in, maar controleren de output strenger dan een jaar geleden.
Welk gereedschap wordt daadwerkelijk gebruikt
Bij deze tools zit het verschil vooral in de manier van werken, niet in de belofte. GitHub Copilot en Microsoft Copilot zitten dicht op de editor en werken grotendeels op basis van autocomplete. Cursor en Windsurf bouwen daar een agentlaag bovenop, waarbij het model na een korte opdracht meerdere bestanden tegelijk aanpast. Claude Code werkt vanaf de command line en kan hele takenreeksen afhandelen zonder dat iemand steeds hoeft te klikken. Nieuwere partijen zoals SynAI richten zich specifiek op agentische workflows binnen bestaande CI/CD-pijplijnen, een niche die twee jaar geleden nog nauwelijks bestond.
Voor kleine teams, tot een man of tien, is de meest gekozen combinatie een editor-integratie voor het dagelijkse werk, aangevuld met een apart te starten agent voor grotere refactors. Grotere organisaties kiezen vaker voor een centraal beheerd platform, met vaste afspraken over welke repositories AI-tools mogen aanraken en welke niet.
Wat onderbelicht blijft: recht, privacy en schuld
De meeste artikelen over AI software development gaan over snelheid en over bugs. Twee andere risico's krijgen veel minder aandacht.
Het eerste is auteursrecht. Wie code laat genereren door een model dat getraind is op publieke repositories, weet vaak niet zeker of het resultaat vrij is van licentieverplichtingen. Voor bedrijven die software verkopen of doorlicenseren is dat geen theoretische vraag.
Het tweede is regelgeving. Voor Europese bedrijven ligt naast de AVG ook de AI Act op tafel. Die wet richt zich vooral op AI-systemen die zelf besluiten nemen over mensen, maar development-tools die code genereren voor gevoelige sectoren zoals zorg, financiën of kritieke infrastructuur kunnen alsnog onder strengere classificaties vallen. Een flink deel van de Amerikaanse bronnen hierover besteedt geen woord aan die regelgeving, simpelweg omdat de wet daar niet geldt.
Daarnaast blijft technische schuld een terugkerend probleem. Veracode registreerde dat AI-gegenereerde code 2,74 keer zoveel kwetsbaarheden bevat als door mensen geschreven code. Modall meldt dat het aantal nieuwe CVE's dat aan AI-gegenereerde code wordt toegeschreven, opliep van zes in januari 2026 naar vijfendertig in maart van dat jaar.
Hoe teams het nu aanpakken
Bedrijven die AI software development structureel invoeren, beginnen zelden overal tegelijk. Een terugkerend patroon: eerst de twee fases met het meeste volume kiezen, meestal coderen en testen, en daar strikte reviewregels op zetten voordat de rest van de organisatie meedoet. Pas als die eerste fase meetbare cijfers oplevert, zoals foutpercentage, doorlooptijd en het aantal afgekeurde pull requests, wordt de scope uitgebreid.
Wat in de meeste statistiekenoverzichten ontbreekt, is een concreet intern beleid. Een aantal elementen komt in de praktijk telkens terug: welke repositories AI-agents mogen aanraken, wie verantwoordelijk is als gegenereerde code een productie-incident veroorzaakt, en welke gegevens nooit naar een extern model mogen worden gestuurd. Zonder die afspraken op papier ontstaat een grijs gebied waarin niemand eigenaar is van de fout, iets waar meerdere analyses rond datalekken bij AI-tools op wijzen.
Wat bij mensen blijft hangen
Ondanks die opmars wijzen meerdere bronnen op dezelfde kern: systeemontwerp, architectuurkeuzes en de historische kennis van een langlopende codebase blijven mensenwerk. Pace University noemt vier gebieden waar developers onmisbaar blijven: architectuur, context over eerdere beslissingen, controle op de output, en het oplossen van onduidelijke requirements.
Voor junior developers verandert de rol het meest. Wie alleen leert prompten zonder de onderliggende logica te begrijpen, bouwt geen diepgaande kennis op. Meerdere bronnen wijzen op hetzelfde risico: minder oefening met het opsporen van fouten in simpele code betekent minder intuïtie voor de complexe gevallen die later komen. Die kloof tussen snelheid nu en vaardigheid later is precies het punt waarop AI software development de komende jaren wordt getest, niet in de demo's, maar in de code die over vijf jaar nog draait.