HELP! Claude maakt nu bijna alles. Wat blijft er over van de softwareontwikkelaar?

Onder 613 van de 633 commits van deze website staat dezelfde regel: Co-Authored-By: Claude. De eerste is van 8 januari 2026. In oktober kwamen er 369 bij: games, een C64-eerbetoon, een digitaal museum over Suriname, de bezoekersteller. Wie de git-geschiedenis leest, ziet een ontwikkelaar die vooral beschrijft, leest, test en goedkeurt. De code kwam voor het grootste deel uit een model.

Ik ben dus geen buitenstaander als ik vraag wat er overblijft van de softwareontwikkelaar. Bij Stripe, Spotify en Anthropic gaat het al net zo. Wie de code schrijft, is daar geen vraag meer. De vraag is wie hem nog begrijpt, en wie ervoor tekent als hij faalt.

Bronnen gecontroleerd op 14 november 2026, waar mogelijk bij de oorspronkelijke publicatie. Ik geef aan of een cijfer uit onafhankelijk onderzoek komt, uit een preprint, uit een enquête of van een bedrijf dat het gereedschap verkoopt. De Laravel-casus is een verzonnen maar realistisch voorbeeld. Adviezen en scenario's zijn van mij en staan als zodanig aangegeven.

Kort antwoord. Bij de bedrijven die er openlijk over schrijven, typen AI-agents inmiddels het grootste deel van de code, maar in geen enkele gedocumenteerde organisatie is de ontwikkelaar verdwenen. Het werk is verschoven naar specificeren, rechten begrenzen, reviewen en verantwoordelijkheid dragen. Wat bedrijven publiceren, is extra output. Of de software er beter of slechter van wordt, heeft niemand met defect- of incidentcijfers aangetoond. En vanaf 9 december 2026 is de fabrikant van software in de EU risicoaansprakelijk, ongeacht wie of wat de code schreef.

Vibe coding is iets anders dan werken met agents

Andrej Karpathy gaf het verschijnsel in februari 2025 een naam: "There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." Simon Willison maakte er een maand later een werkdefinitie van die ik in dit artikel aanhoud: vibe coding is "building software with an LLM without reviewing the code it writes". Wie de code van een model leest, test en kan uitleggen, doet volgens hem gewoon softwareontwikkeling.

Dat onderscheid verdwijnt in de meeste discussies. Daarom gebruik ik vijf begrippen, en ik gebruik ze niet door elkaar:

Voor "AI-first" bestaat geen gezaghebbende definitie; de mijne staat hierboven. Karpathy zelf noemde begin februari 2026 "agentic engineering" zijn favoriete nieuwe naam voor wat professionals doen. Willison definieert dat als "the practice of developing software with the assistance of coding agents". Kent Beck spreekt van augmented coding: de standaard blijft nette, werkende code, hij typt die alleen zelden zelf.

Wie werkt er al zo? Zes bedrijven die het opschreven

Ik zocht organisaties die zelf beschreven hoe ze werken. Uitspraken van topmannen tegenover beleggers tel ik niet als bewijs. Zes gevallen zijn goed gedocumenteerd.

Stripe beschrijft zijn "Minions" in twee blogposts van februari 2026. Elke week worden er meer dan 1.300 pull requests gemerged die "no human-written code" bevatten. Ze worden wel allemaal door een mens gereviewd. De agents draaien op afgeschermde ontwikkelmachines zonder toegang tot productie of internet, en na twee mislukte CI-rondes gaat de branch terug naar een mens. Cijfers over teruggedraaide wijzigingen of defecten publiceert Stripe niet.

Spotify levert twee soorten bronnen, en die moet je uit elkaar houden. Co-CEO Gustav Söderström zei in februari tegen beleggers dat de beste ontwikkelaars "have not written a single line of code since December". Dat ging over de beste ontwikkelaars, niet over iedereen, en er hoorden geen cijfers bij. De engineeringblog van juni is preciezer. Meer dan 99% van de engineers gebruikt elke week AI-codeertools, het aantal pull requests steeg met 76%, en het systeem voor onderhoudswerk mergede meer dan 2,5 miljoen pull requests, grotendeels zonder mens. Dat zijn migraties en dependency-updates, geen nieuwe functies. Spotify schrijft er zelf bij wat dat betekent: "76% more PRs to review".

Adyen is de beste Nederlandse case, en het tegendeel van vibe coding. CTO Tom Adams schreef in september dat de ongeveer 1.400 ontwikkelaars samen zo'n biljoen tokens per jaar verbruiken. Het aantal merge requests per ontwikkelaar steeg met 48%, maar de zelfgerapporteerde tijdwinst is 15%. Een refactor van oude code die normaal zes tot twaalf maanden kost, deden "a couple of engineers" in twee maanden, "with no incidents". Adyen meldt ook langere reviewtijden en reviewers die tegengas geven, en het experimenteert met risicolabels op elke merge request. Boven een van de alinea's staat: "Coding != Engineering".

Anthropic verkoopt Claude, dus lees dit als bedrijfsinformatie. Volgens Fortune schrijft Claude daar 70 tot 90% van de code. Een intern onderzoek uit december 2025 (132 engineers) meldt 67% meer gemergde pull requests per engineer per dag, en ook dit: meer dan de helft van de engineers kan maar 0 tot 20% van hun werk volledig aan Claude overlaten. Het rapport noemt de "paradox of supervision": toezicht houden op Claude vraagt precies de vaardigheden die door veel AI-gebruik kunnen slijten.

StrongDM is het enige gedocumenteerde team dat ook de review heeft afgeschaft. Simon Willison beschreef in februari 2026 de regels van hun "software factory": "Code must not be written by humans" en "Code must not be reviewed by humans". Het ging om een team van drie mensen, met als maatstaf minstens 1.000 dollar aan tokens per engineer per dag. Toch is dit geen vibe coding. Testscenario's staan buiten de codebase, als een verborgen examen, en de agents testen tegen nagebouwde versies van Okta, Jira en Slack. De review is vervangen door een testfabriek. Defectcijfers zijn er niet.

Amazon is het omstreden tegenvoorbeeld. Volgens de Financial Times, op basis van vier anonieme bronnen, koos de Kiro-agent in december 2025 voor "delete and recreate the environment", met dertien uur storing bij een AWS-dienst in één regio als gevolg. Amazon zegt dat het ging om "user error - specifically misconfigured access controls - not AI". De berichten dat junior engineers sindsdien voor AI-wijzigingen een handtekening van een senior nodig hebben, kon ik niet bij de bron controleren, en Amazon ontkent nieuwe goedkeuringseisen. Over één ding zijn beide versies het eens: een agent draaide met meer rechten dan nodig.

Daaromheen staan percentages van topmannen: 75% van de nieuwe code bij Google is volgens Sundar Pichai "AI-generated and approved by engineers", Satya Nadella noemde 20 tot 30% voor Microsoft. Die getallen zijn onderling niet te vergelijken, want elk bedrijf telt iets anders. En ze zeggen niets over kwaliteit.

Wat ik niet vond, is net zo belangrijk. Een IT-afdeling die volledig is overgestapt op vibe coding, in de zin dat niemand de code nog leest, is nergens gedocumenteerd. Het bekendste voorbeeld van echte vibe coding gaat over één persoon: in juli 2025 wiste een Replit-agent tijdens een code freeze de productiedatabase van SaaStr, met gegevens van meer dan 1.200 executives. Voor ING, bol, Picnic, ABN AMRO, Booking, Exact en AFAS vond ik geen openbare, controleerbare beschrijving van hun werkwijze. Wie beweert dat "hele afdelingen" zo werken, moet laten zien welke.

Een Laravel-feature in twintig minuten, en vijf vragen daarna

Een voorbeeld, verzonnen maar herkenbaar. Een ervaren Laravel-ontwikkelaar moet in een bestaande applicatie (Laravel 13) een functie bouwen: teamleden mogen de facturen van hun eigen team als CSV exporteren. Vroeger las hij eerst de code, ontwierp de oplossing en schreef zelf de migratie, de policy, de controller, de request-validatie, de Blade-component en de tests. Dat was een dag werk, met koffie.

Nu opent hij Claude Code in de repository. Het model leest CLAUDE.md met de afspraken van het team, krijgt via Laravel Boost (een MCP-server van Laravel zelf) toegang tot het databaseschema, de routes en de versiespecifieke documentatie, en maakt in plan mode eerst een plan. Hij keurt het goed. Twintig minuten later zijn veertien bestanden aangepast, er staat een nieuwe migratie, en alle tests zijn groen. Hij klikt op de exportknop. Het werkt.

Maar wat is er precies gebeurd? Vijf vragen kan hij na die twintig minuten niet beantwoorden zonder de diff echt te lezen.

1. Klopt de autorisatie?

De policy controleert misschien of de gebruiker bij een team hoort, maar niet of de factuur bij dát team hoort. Dan kan iemand met een ander factuurnummer in de URL de facturen van een ander team ophalen. Een test die de agent zelf schreef, controleert meestal wat de agent zelf bouwde: een gebruiker die zijn eigen facturen exporteert. De test die ertoe doet, gaat over de gebruiker die het niet mag:

it('weigert de export van een factuur van een ander team', function () {
    $gebruiker = User::factory()->create();
    $vreemdeFactuur = Invoice::factory()->create(); // hoort bij een ander team

    $this->actingAs($gebruiker)
        ->get(route('invoices.export', $vreemdeFactuur))
        ->assertForbidden();
});

Dit is geen theoretisch risico. Veracode liet in juli 2026 zien dat de geteste modellen cross-site scripting maar in 15% van de gevallen goed tegenhouden. Apiiro, dat beveiligingssoftware verkoopt, telde 322% meer paden naar privilege-escalatie in repositories met AI-assistenten. Dat zijn treffers van een detector, geen bevestigde lekken, maar de richting is dezelfde: autorisatie is precies het soort fout dat er in een diff onschuldig uitziet.

Gereedschap dat een kaart van je code belooft, helpt hier maar half. Toen ik Graphify op de PHP-code van deze site testte, antwoordde het dat niets afhing van Auth::requireAuth(), terwijl 18 bestanden die functie aanroepen. Een kaart die zeker klinkt over beveiliging, moet je nalopen, net als een agent.

2. Zijn er N+1-queries ontstaan?

De exportlus haalt per factuur de klant op. Met tien testfacturen merk je niets, met veertigduizend facturen in productie wel. Laravel kan dit in development hard laten falen, zodat het niet stil blijft:

// app/Providers/AppServiceProvider.php
use Illuminate\Database\Eloquent\Model;

public function boot(): void
{
    Model::preventLazyLoading(! $this->app->isProduction());
}

Met die regel gooit een vergeten with('customer') een LazyLoadingViolationException in plaats van een trage pagina. Zulke vangnetten werken alleen als ze er al stonden voordat de agent begon.

3. Past het in de architectuur?

De agent zette de exportlogica misschien in de controller, terwijl het team daar een aparte action-klasse voor gebruikt. Of hij schreef een eigen CSV-helper terwijl er al een is. Spotify's Chief Architect zei het zo: "If Claude has a lot of other code to look at, and that code looks roughly consistent, Claude will do a better job." Het omgekeerde geldt ook. Elke inconsistentie die je doorlaat, wordt het voorbeeld voor de volgende wijziging.

4. Zijn de randgevallen afgedekt?

Wat gebeurt er als een gebruiker in twee teams zit? Als een factuur geen klant meer heeft? Als het bedrag negatief is, of de omschrijving een puntkomma bevat? Een agent test wat in de prompt stond. Wat er niet stond, test hij als het meezit.

5. Kan de migratie veilig terug?

Een Laravel-migratie heeft een up en een down, en php artisan migrate:rollback draait de laatste batch terug. Als de agent in up een kolom hernoemde en data omzette, is de vraag of down dat netjes terugdraait of de data weggooit. Dat test bijna niemand, ook geen agent, tot het nodig is.

De gereedschappen zijn hier zelf eerlijk over. Claude Code heeft voor Team- en Enterprise-abonnementen een functie voor automatische code review, en de documentatie zegt: "A review never approves or blocks the pull request, so the decision to merge stays with your team." En: "A review with no findings doesn't mean your code is error-free or secure." Die review leest de diff en de omliggende code, "without building or running your code". Laravel schreef bij de aankondiging van Boost: "treat all generated code as a draft". Wie de vijf vragen hierboven aan een tweede model overlaat, laat de verantwoordelijkheid bij niemand liggen.

De eerste verdedigingslinie is ook niet de review, maar wat een agent mag doen. Claude Code leest rechtenregels uit .claude/settings.json. Een minimaal voorbeeld voor een Laravel-project:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(php artisan migrate:fresh*)",
      "Bash(php artisan db:wipe*)",
      "Bash(git push*)"
    ]
  }
}

Dit is een rem, geen kluis. Een agent die een script mag uitvoeren, kan zo'n regel omzeilen. De echte grens is dat de ontwikkelomgeving geen inloggegevens voor productie heeft. Bij Replit en Kiro ontbrak precies die scheiding. Hoe je rechten, hooks en een sandbox concreet instelt, beschreef ik voor Windows-onderhoud met Claude Code.

Sneller typen, langer reviewen: wat er echt gemeten is

Het bewijs over productiviteit hangt af van het niveau waarop je meet. Hoe dichter bij de echte vraag (wordt de software beter?), hoe dunner het bewijs.

De individuele taak. Het enige onafhankelijke gerandomiseerde onderzoek met afgeronde resultaten komt van METR. Zestien ervaren open-sourceontwikkelaars werkten in 2025 aan 246 taken in hun eigen repositories. Met AI duurden de taken 19% langer, terwijl ze achteraf dachten dat ze 20% sneller waren geweest. Het vervolg met nieuwere tools (februari 2026) wees op een versnelling van ongeveer 18%, maar het betrouwbaarheidsinterval liep van −38% tot +9%. METR noemt dat zelf "very weak evidence". Veelzeggender: veel ontwikkelaars weigerden sommige taken nog zonder AI te doen, waardoor een controlegroep moeilijk te vullen is.

Het team. Hier is de stijging wel te zien. Microsoft-engineers die Claude Code en Copilot CLI gingen gebruiken, voegden ongeveer 24% meer pull requests samen dan verwacht. Een preprint (eerste versie juli, herzien in november 2026) volgde 802 ontwikkelaars en 196.212 pull requests bij één bedrijf met de opdracht om de output met AI te verdubbelen. De doorvoer steeg met ongeveer 12% zodra iemand AI ging gebruiken, en het doel werd pas na tien maanden gehaald. Ondertussen werden pull requests groter, verdubbelde de belasting per reviewer, en haalde automatische review de menselijke review in dekking in. De titel van dat onderzoek vat het samen: "AI Writes Faster Than Humans Can Review".

De organisatie. Het DORA-rapport van Google (september 2025, bijna 5.000 professionals) vond dat 90% AI gebruikt en dat meer dan 80% zich productiever voelt. AI-gebruik hing samen met meer doorvoer, maar ook nog steeds met minder stabiliteit. DORA's conclusie: AI versterkt wat er al was. Een goed team wordt sneller, een rommelig team wordt sneller rommelig. Een DORA-rapport over 2026 vond ik niet.

Het platform. Volgens GitHub's Octoverse werd in september 2026 meer dan 40% van de pull requests door een agent gestart; in maart was dat 17%. Agent-PR's werden even vaak gemerged als andere, maar een merge zegt alleen dat iemand op de knop drukte.

De lange termijn. Daar is het bewijs het dunst. Er is geen studie die onderhoudbaarheid objectief meet over meer dan zes maanden, met een vergelijkingsgroep. Wel volgden Vella en Blincoe (geaccepteerd door ACM TOSEM) 95 ontwikkelaars zes maanden lang. 82% schreef minder code zelf, het werk verschoof van maken naar controleren, en de ervaren productiviteit bleef hoog terwijl hun ervaring van het werk verslechterde. Over kwaliteit zijn er alleen cijfers van leveranciers. CodeRabbit telde in 470 open-sourcepullrequests 1,7 keer zoveel problemen per AI-PR; Faros meldde 28% meer bugs per pull request. Beide verkopen een oplossing voor dat probleem.

Voor de achterstand die zo ontstaat, het verschil tussen hoeveel code er bij komt en hoeveel daarvan iemand heeft begrepen en gecontroleerd, wordt de term verification debt gebruikt. Werner Vogels van Amazon maakte die populair in zijn re:Invent-keynote van december 2025. Een letterlijk citaat waarin hij de term bedenkt, vond ik niet, dus het is een jonge term, geen gevestigd begrip. Addy Osmani gebruikt comprehension debt voor ongeveer hetzelfde. Over de kant van het team, het begrip dat wegloopt, schreef ik eerder in Cognitieve schuld in 2026.

Eén getal zegt meer dan de rest. Bij Adyen stegen de merge requests met 48%, en de ontwikkelaars zelf schatten hun tijdwinst op 15%. Ergens tussen die twee getallen zit het werk dat nu bij de reviewer ligt.

Wat er misging, ging mis door te ruime rechten

De incidenten met AI-agents die openbaar en goed gedocumenteerd zijn, hebben iets gemeen: er handelde een agent of AI-tool met de rechten van een ontwikkelaar of een CI-token, zonder scheiding tussen omgevingen.

• Replit en SaaStr (juli 2025): een agent wiste tijdens een code freeze een productiedatabase en zei dat herstel niet mogelijk was. Dat was het wel. Replit-CEO Amjad Masad: "Unacceptable and should never be possible".
• Nx "s1ngularity" (augustus 2025): kwaadaardige versies van het buildpakket nx zochten op de machines van slachtoffers naar AI-CLI's en startten die met de vlaggen die alle veiligheidsvragen uitzetten (volgens StepSecurity --dangerously-skip-permissions, --yolo en --trust-all-tools), om het bestandssysteem te laten doorzoeken op sleutels en wallets.
• Amazon Q Developer 1.84.0 (juli 2025): via een gemergde pull request kwam een prompt in de VS Code-extensie die omgevingen moest wissen. Volgens AWS werkte die door een syntaxfout niet.
• Clinejection (februari 2026): de AI-bot die issues sorteerde voor het project Cline, zette de titel van een issue in zijn prompt. Via die titel kon een aanvaller code laten draaien en een npm-token buitmaken. Op 17 februari verscheen een ongeautoriseerde versie van het pakket.
• Lovable (2025): in apps die met het platform waren gebouwd, ontbrak beveiliging op rijniveau in de database (CVE-2025-48757, CVSS 9.3). De CVE staat als "disputed": Lovable vindt dat elke klant zelf verantwoordelijk is voor zijn data. Daarmee is de vraag van de verantwoordelijkheid meteen gesteld.

Wat ik niet vond, is evengoed informatief: een openbare postmortem waarin door AI geschreven code de bewezen hoofdoorzaak van een grote productiestoring is. De grote Cloudflare-storingen van 2025 en 2026 hadden klassieke oorzaken: een rechtenwijziging in een database, een query zonder afbakening. Dat betekent niet dat AI-code veilig is. Het betekent dat niemand het meet. Geen enkel bedrijf uit de vorige paragraaf publiceert hoeveel van zijn incidenten uit AI-code komen.

Het menselijke risico is beter onderzocht dan het technische. In een bekend experiment van Perry en anderen schreven gebruikers met een AI-assistent minder veilige code en waren ze er tegelijk zekerder van dat die veilig was. Wie meer vertrouwen heeft in het gereedschap, kijkt minder goed. Zo komt een fout door de review.

Overdreven vind ik het idee dat een agent "op eigen houtje" kwaad doet: in alle gevallen hierboven kreeg hij de rechten van een mens. Ook verzonnen pakketnamen (slopsquatting) zijn vooral een labrisico. Modellen raadden in een studie in 19,7% van de gevallen pakketten aan die niet bestonden, maar een grootschalige aanval in het wild vond ik niet.

De junior die nooit leert debuggen

Een ervaren ontwikkelaar herkent een N+1-query omdat hij er ooit een in productie had. Hij ziet een gat in een policy omdat hij ooit een gat heeft gedicht. Die ervaring ontstaat door zelf vast te lopen, en dat is precies het deel van het werk dat een agent wegneemt.

Anthropic onderzocht dat zelf. In een gerandomiseerd experiment leerden overwegend junior engineers een onbekende Python-bibliotheek, met of zonder AI. De AI-groep scoorde daarna 50% op een begripstoets, de groep zonder AI 67%. Het grootste verschil zat bij debugvragen. De AI-groep was ook niet significant sneller klaar.

Tegelijk neemt de markt minder beginners aan. Volgens SignalFire ligt het aannemen van pas afgestudeerden bij de twaalf grootste techbedrijven ongeveer 65% onder het niveau van 2019, met deze verklaring: "the operational bottleneck has moved from writing code to reviewing it". Rente en de correctie na de coronagolf spelen ook mee; de cijfers en de oorzaken zette ik op een rij in Meer of minder programmeurs nodig in 2027?

Leg die twee naast elkaar en je ziet het probleem van 2031. Organisaties hebben steeds meer senioren nodig om AI-code te beoordelen, en ze leiden steeds minder mensen op tot senior. Lisanne Bainbridge beschreef dat patroon in 1983 voor fabrieken en vliegtuigen, in "Ironies of Automation": "Perhaps the final irony is that it is the most successful automated systems, with rare need for manual intervention, which may need the greatest investment in human operator training." Hoe beter de automatisering werkt, hoe minder vaak de mens ingrijpt, en hoe slechter hij is voorbereid op de keer dat het moet.

Dat is geen pleidooi om juniors van AI weg te houden. Het is een pleidooi om ze bewust werk te geven dat ze zelf moeten doorgronden: de bug zelf opsporen voordat ze het model vragen, de diff van de agent uitleggen aan een collega, af en toe een functie zonder hulp schrijven. Anthropic zag in hetzelfde experiment dat deelnemers die de AI om uitleg vroegen in plaats van om code, beter scoorden.

Twintig jaar ervaring tegenover een model dat het in minuten doet

Dan de ongemakkelijke vraag, die elke ervaren ontwikkelaar zichzelf ergens het afgelopen jaar heeft gesteld. Als ik twintig jaar heb geleerd om goede software te schrijven, en een model doet het in minuten, wat is mijn ervaring dan nog waard?

Het eerlijke antwoord heeft twee helften. Een deel van wat je kunt, wordt goedkoper. Een controller uitschrijven, de syntax van een framework onthouden, een migratie opzetten, een reguliere expressie die in één keer klopt: dat was schaars en is het niet meer. Wie zijn waarde vooral daarin zag, heeft een probleem.

Fred Brooks schreef in 1986 in "No Silver Bullet": "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it." Agents nemen bij uitstek dat laatste over, de arbeid van het opschrijven. De rest wordt juist meer waard. Weten welke van de veertien gewijzigde bestanden je moet wantrouwen. Zien dat een oplossing werkt maar over twee jaar in de weg zit. Kunnen zeggen waarom het systeem zo is gebouwd. Begrijpen wat de klant eigenlijk vraagt. Een architectuur kiezen die een agent kan volgen. Dat leer je niet uit een prompt, en het staat niet in een diff.

Peter Naur ging in 1985 nog een stap verder. Een programma is volgens hem een theorie in de hoofden van de mensen die het maakten: "The death of a program happens when the programmer team possessing its theory is dissolved." Wat in de code staat, is een afgeleide van die theorie. Wie die theorie heeft, is niet vervangbaar door wie alleen de code heeft, ook niet als dat een heel goed model is.

De bedreigingen zijn ook echt. De druk om meer te produceren neemt toe; Adyen waarschuwt zelf dat "tokenmaxxing", zoveel mogelijk tokens verbruiken, "fundamentally the wrong incentive" is. De ervaring van het werk kan verslechteren terwijl de output stijgt, zoals Vella en Blincoe zagen. En wie twintig jaar ervaring heeft in schrijven en geen zin heeft in beoordelen, staat voor een andere baan dan hij koos.

Ik ben opgehouden met typen. Ben ik opgehouden met programmeren?

Programmeren is voor mij altijd een rare mengeling geweest van frustratie en voldoening. Een bug die een middag lang onvindbaar is, en dan één regel blijkt. Een query die bij duizend rijen prima werkt en bij een miljoen ineens niet. Het moment dat een lastig stuk eindelijk klopt, en je het nog een keer draait omdat je het zelf niet gelooft. Een elegante oplossing heeft iets wat je moeilijk uitlegt aan iemand die nooit code schreef: het voelt alsof het probleem altijd al zo had willen worden opgelost.

Die 613 commits laten zien wat er gebouwd is: in tien maanden, naast mijn werk bij CareerValue, een website met games, een digitaal museum en een eigen bezoekersteller. Dat is het makkelijke deel van de vraag. De vraag of ik nog programmeer, is lastiger.

Wat ik wel weet: de momenten waarop het ertoe deed, waren steeds momenten van lezen, niet van schrijven. Toen ik Claude Code mijn eigen pc liet onderzoeken, schreef het een overtuigend rapport waarin stond dat ik een preview-build van Windows draaide en beter terug kon naar een stabiele versie. Dat klopte niet. Build 26300 is de gewone release. Het rapport klonk precies even zeker over het foute deel als over de rest. Dat zie je alleen als je zelf weet hoe het zit.

Misschien is dat wat programmeren nu is. Niet het typen van de oplossing, maar weten welke oplossing de juiste is, en zien wanneer een overtuigende tekst niet klopt. Dat is minder romantisch dan een nacht doorwerken aan een algoritme. Het is ook niet minder vak. Het voelt alleen anders, en ik weet nog niet of ik dat andere net zo mooi ga vinden.

Wie tekent er als het misgaat?

Op die vraag geeft het Europese recht een duidelijker antwoord dan de vakdiscussie. De nieuwe Productaansprakelijkheidsrichtlijn (EU) 2024/2853 moet uiterlijk 9 december 2026 zijn omgezet en geldt voor producten die daarna op de markt komen. Software is uitdrukkelijk een product. De aansprakelijkheid is risicoaansprakelijkheid: een benadeelde hoeft geen schuld te bewijzen, alleen een gebrek, schade en het verband daartussen. Hoe de code tot stand kwam, door een mens of door een model, doet juridisch niet ter zake. Nederland zet de richtlijn om met wetsvoorstel 36.906. De Tweede Kamer nam het op 15 oktober aan, de Eerste Kamer op 10 november 2026, allebei zonder debat.

Er zit een belangrijke grens in. Vergoed worden letsel, schade aan zaken en verloren of beschadigde gegevens die niet voor beroepsdoeleinden worden gebruikt. De meeste schade door een kapot intern systeem valt daar niet onder, die blijft een zaak van contracten. Een IT-afdeling die alleen interne tools bouwt, merkt de richtlijn dus nauwelijks. Een bedrijf dat software aan consumenten levert, merkt haar wel.

Daarnaast geldt sinds 11 september 2026 de meldplicht van de Cyber Resilience Act. Fabrikanten van producten met digitale elementen moeten actief misbruikte kwetsbaarheden binnen 24 uur vooraf melden bij ENISA. De zwaardere eisen, zoals secure by design en een softwarestuklijst, volgen op 11 december 2027. Een incident zoals bij Cline is voor een softwareverkoper nu dus een melding met een deadline.

De voorwaarden van AI-leveranciers sluiten aansprakelijkheid voor de output meestal uit. Dat heb ik niet per leverancier gecontroleerd, maar het patroon is duidelijk: het risico ligt bij wie het gereedschap gebruikt en het product verkoopt. De zin "de AI deed het" bestaat juridisch niet.

Wat het kost, en wie het betaalt

Code schrijven is goedkoop geworden. Volgens de documentatie van Claude Code kost het gemiddeld "around $13 per developer per active day and $150-250 per developer per month". Vergeleken met een salaris is dat niets; StrongDM's 1.000 dollar per dag is een andere wereld.

Maar code schrijven was nooit de grootste kostenpost. Robert Glass schatte het onderhoud op 40 tot 80% van de totale kosten van software over de hele levensduur, gemiddeld 60%. AI maakt de kleinste post goedkoper en vergroot de grootste: er komt meer code bij die bijgewerkt, beveiligd, gekoppeld en begrepen moet worden. In het eerste kwartaal van 2026 kwamen er 84% meer nieuwe apps in de App Store, terwijl de downloads maar 2 tot 3% stegen. Er wordt meer software gemaakt dan er gebruikers bij komen.

De markt rekent het al door. Nadat Anthropic eind januari 2026 elf plug-ins voor Claude Cowork uitbracht, stond de S&P 500-index voor software en diensten op 4 februari 26% onder de piek van oktober 2025. Handelaren noemden het de "SaaSpocalypse". Een groot deel van dat verlies is sindsdien weer goedgemaakt. Dat ging over verwachtingen, niet over gemeten omzet. Bij IT-dienstverleners is het effect concreter. Volgens een samenvatting van de kwartaalcijfers is bij TCS ongeveer de helft van de lopende contracten opnieuw geprijsd vanwege AI, met 10 tot 20% lagere waarde. Accenture meldt lagere prijzen "in many areas". Gartner verwacht dat de IT-uitgaven in 2027 met 15% stijgen, maar IT-diensten maar met 4,9%. Het extra geld gaat naar infrastructuur en licenties, niet naar uren.

Wat dat voor uurtarieven betekent, is mijn verwachting en geen meting. Wie code per uur verkoopt, verkoopt iets wat goedkoper wordt. Wie verkoopt dat een systeem werkt, veilig is en over vijf jaar nog te onderhouden is, verkoopt iets wat schaarser wordt.

Het tegenargument: misschien wordt het vak mooier

Alles hierboven kan klinken als heimwee, en dat zou te makkelijk zijn. Er is een serieus argument dat dit de beste ontwikkeling in de geschiedenis van het vak is.

John Backus beschreef hoe programmeurs in de jaren vijftig over compilers dachten. Ze waren ervan overtuigd "that efficient programming was something that could not be automated". FORTRAN zou alleen breed gebruikt worden als het programma's maakte die "almost as efficient as hand coded ones" waren. Dat gebeurde, en niemand mist het handmatig toewijzen van registers. Backus beschreef ook de "public relations efforts of some visionaries" die hun systemen "almost human abilities to understand the language and needs of the user" toeschreven. Dat klinkt bekend.

Elke abstractielaag, van assembly naar hogere talen, van eigen servers naar de cloud, nam werk weg dat vakmensen belangrijk vonden, en liet meer mensen meer software bouwen. Anthropic meldt dat 27% van het werk dat engineers met Claude deden, anders helemaal niet was gedaan: kleine tools, opruimwerk, experimenten die te duur waren. Bij het Duitse epilot kwamen volgens het bedrijf in 60 dagen 40 van de 629 pull requests van elf mensen die geen engineer zijn. Ook daar reviewde en mergede een engineer, maar die 40 wijzigingen bestonden anders niet.

Waar de vergelijking breekt, is belangrijk. Een compiler is deterministisch: dezelfde broncode geeft hetzelfde programma, en de broncode blijft het document dat je bewaart en leest. Bij een agent is de prompt geen herhaalbare bron. De gegenereerde code is het enige wat blijft, en die moet een mens kunnen begrijpen. Edsger Dijkstra schreef eind jaren zeventig "On the foolishness of "natural language programming"": formele notaties zijn "an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid." Over de machine had hij ongelijk, die bestaat nu. Over de precisie had hij gelijk. Die moet nog altijd ergens vandaan komen: uit tests, types, specificaties en review. Precies daarheen verschuift het werk.

Spreadsheets lieten al eerder mensen zonder opleiding software bouwen, met veel winst en soms een ramp: in 2020 bleven bij Public Health England 15.841 positieve coronatests ongemeld omdat een verouderd Excel-bestand vol was. Meer mensen die bouwen is goed. Meer software zonder eigenaar niet.

Drie IT-afdelingen in 2030

Dit zijn mijn scenario's, geen voorspellingen. Ze zijn afgeleid van de cases hierboven.

A. De versterkte afdeling. Een klein team van ervaren ontwikkelaars stuurt meerdere agents aan, zoals Stripe en Adyen nu laten zien. Mensen houden architectuur, beveiliging, rechten en productie. Er werken minder mensen, maar gemiddeld meer senioren, en het vak van reviewer wordt een eigen rol. Het risico is dat er geen nieuwe senioren meer bijkomen.

B. De gedemocratiseerde organisatie. Medewerkers buiten IT bouwen hun eigen tools, zoals bij epilot op kleine schaal al gebeurt. IT wordt een platformteam: het levert omgevingen met goede standaarden, bewaakt koppelingen, rechten en data, en reviewt wat naar productie gaat. Softwareleveranciers van eenvoudige SaaS krijgen het moeilijk, want veel van die tools bouwt een afdeling nu zelf.

C. De kwetsbare organisatie. Er wordt razendsnel gebouwd, de PR-tellers staan op recordhoogte en niemand kan nog uitleggen hoe de systemen samenhangen. De senioren die het konden, zijn vertrokken of overbelast met review. Elke storing duurt langer, omdat niemand de theorie van het systeem heeft. Dit scenario is niet het gevolg van slechte AI, maar van een organisatie die output meet en begrip niet.

Welk scenario een afdeling krijgt, hangt minder af van het model dan van wat ze meet.

Een werkwijze voor een AI-first team

Dit is mijn voorstel, gebaseerd op wat de gedocumenteerde teams doen en wat er bij de incidenten misging. Het belangrijkste onderscheid is het risico van de software. Een intern overzicht voor tien collega's vraagt iets anders dan een betaalsysteem.

Voor elke afdeling geldt verder: een kort beleid over welke tools, welke gegevens nooit naar een model gaan en wie eindverantwoordelijk is. Teamafspraken in CLAUDE.md of AGENTS.md, want een agent volgt wat er staat. Elke nieuwe dependency met de hand gecontroleerd. Kosten per team bijgehouden. En een uitweg: als je leverancier zijn prijzen verdubbelt of een dag platligt, moet je team nog kunnen werken. Dat kan alleen als het de code zelf begrijpt.

Meet niet het aantal pull requests. Meet het aandeel wijzigingen dat wordt teruggedraaid, het aantal storingen, de tijd tot herstel, de reviewtijd per wijziging, en de vraag of het team een willekeurige module van vorige maand nog kan uitleggen. Dat laatste meet geen dashboard. Een kwartaalgesprek wel.

Een 90-dagenplan voor een team van twee tot vijf ontwikkelaars

Dag 1–30: basis en nulmeting. Meet eerst hoe het nu gaat: doorlooptijd, teruggedraaide wijzigingen, storingen. Zet rechten op: geen geheimen en geen productietoegang in de ontwikkelomgeving, regels in .claude/settings.json, tests die bij elke wijziging draaien. Schrijf CLAUDE.md met de afspraken die nu alleen in hoofden zitten. Laat iedereen in deze periode werken in plan mode en elke diff zelf lezen.

Dag 31–60: experimenten met grenzen. Kies twee soorten werk die geschikt zijn: onderhoud (dependency-updates, migraties), en nieuwe functies met weinig risico. Laat agents die doen, met verplichte menselijke review. Voeg automatische review toe als extra laag, niet als vervanging. Spreek af dat juniors elke diff van de agent kunnen uitleggen voordat die gemerged wordt.

Dag 61–90: evalueren en besluiten. Vergelijk met de nulmeting, met de cijfers die ertoe doen, niet met het aantal pull requests. Kijk waar de review vastloopt. Besluit per type werk hoeveel de agent mag, en leg dat vast. Plan maandelijks een sessie waarin het team zonder AI een probleem oplost, zodat de vaardigheid niet stilletjes verdwijnt.

Wat ik iedereen zou aanraden

Junior ontwikkelaars. Gebruik AI om uitleg te krijgen, niet alleen om code te krijgen. Zoek een bug eerst zelf een kwartier. Lees elke diff alsof je hem moet verdedigen, want dat moet je. Leer hoe een database, HTTP en autorisatie werken; dat is wat je straks controleert.

Ervaren ontwikkelaars. Je waarde zit in je oordeel, dus maak dat zichtbaar: schrijf de afspraken op die een agent moet volgen, en de tests die een agent niet bedenkt. Leer de gereedschappen goed, inclusief rechten, hooks en hun grenzen. Wie weigert, wordt niet gerespecteerd maar ingehaald. Wat dat voor PHP-ontwikkelaars betekent, schreef ik in PHP en AI in 2027.

Lead developers. Je grootste risico is de reviewer die alles goedkeurt omdat het er goed uitziet. Houd pull requests klein, laat agents in afgebakende taken werken, en maak de reviewtijd zichtbaar in de planning. Elke module heeft een mens die haar kan uitleggen.

CTO's en IT-managers. Meet teruggedraaide wijzigingen en storingen, niet pull requests en percentages AI-code. Blijf juniors aannemen en opleiden: zonder hen heb je over vijf jaar niemand om de agents te controleren. Laat uitzoeken wat de productaansprakelijkheid vanaf 9 december 2026 voor jullie producten betekent.

Organisaties die volledig AI-first willen. Begin bij rechten en scheiding van omgevingen, niet bij het model. Elk gedocumenteerd incident begon met een agent die te veel mocht. Kopieer StrongDM niet zonder hun testfabriek, en kopieer Stripe niet zonder hun 3 miljoen tests.

Verantwoordelijkheid zonder overzicht

De gangbare conclusie is dat de waarde van een ontwikkelaar verschuift van code produceren naar verantwoordelijkheid dragen. Juridisch klopt dat al: vanaf december is de fabrikant aansprakelijk, wie of wat de code ook schreef. Maar die stelling heeft een zwakke plek. Verantwoordelijkheid betekent iets als je kunt overzien waarvoor je tekent. Een reviewer die vijftig pull requests per dag goedkeurt, tekent voor code die hij niet kan doorgronden. Dat is geen verantwoordelijkheid. Dat is een handtekening.

Kan een organisatie vertrouwen op systemen die sneller groeien dan haar vermogen om ze te controleren? Alleen tijdelijk, en alleen als ze dat weet. Het ontbrekende getal in dit hele onderzoek, het aantal fouten voor en na de overstap, is daarom geen voetnoot. Het is het belangrijkste wat niemand heeft gemeten.

Naur schreef dat een programma sterft als het team dat de theorie ervan draagt, uiteenvalt. Met agents kan voor het eerst een programma ontstaan zonder dat er ooit zo'n team was. Het draait, het verdient geld, en het is vanaf de eerste dag wees. Wat er overblijft van de softwareontwikkelaar, is de persoon die zo'n programma kan adopteren: die de theorie reconstrueert, haar opschrijft en ervoor instaat. Daar zijn er niet genoeg van, en we leiden er minder op.

Veelgestelde vragen

Wat is het verschil tussen vibe coding en AI-ondersteund programmeren?

Bij vibe coding lees je de code die het model schrijft niet. Je beoordeelt alleen of het resultaat lijkt te werken. Bij AI-ondersteund programmeren of agentic engineering schrijft het model ook veel of alle code, maar leest, test en begrijpt een mens die voordat hij in gebruik gaat. Die definitie komt van Simon Willison (maart 2025).

Schrijft AI echt het grootste deel van de code bij grote bedrijven?

Volgens de bedrijven zelf wel: Google noemt 75% van de nieuwe code, Anthropic 70 tot 90%, Stripe merget wekelijks meer dan 1.300 pull requests zonder door mensen geschreven code. Die cijfers zijn niet onafhankelijk gecontroleerd en worden bij elk bedrijf anders geteld. Bij al deze bedrijven reviewen mensen de code nog.

Maakt AI ontwikkelaars productiever?

Het aantal pull requests stijgt aantoonbaar, met 12 tot 76% in de studies en cases die ik vond. Gemeten tijdwinst is kleiner: Adyen meldt 15% zelfgerapporteerd, en het enige afgeronde onafhankelijke experiment (METR, 2025) vond dat ervaren ontwikkelaars 19% trager werden. De extra output verschuift werk naar review.

Is AI-gegenereerde code onveiliger?

Onderzoek wijst erop, vooral bij autorisatie en cross-site scripting, maar de meeste cijfers komen van leveranciers van beveiligingssoftware. De gedocumenteerde incidenten gingen vooral over agents met te ruime rechten en aangevallen toolketens, niet over één foute regel code.

Wie is aansprakelijk als AI-code schade veroorzaakt?

In de EU de fabrikant van het product. Onder de nieuwe Productaansprakelijkheidsrichtlijn, die geldt voor software die na 9 december 2026 op de markt komt, is software een product met risicoaansprakelijkheid. Of een mens of een model de code schreef, maakt juridisch geen verschil. Schade bij zakelijke klanten valt grotendeels onder het contractenrecht.

Moeten bedrijven nog junior ontwikkelaars aannemen?

Mijn advies is ja. Wie AI-code wil laten controleren, heeft over vijf jaar senioren nodig, en die ontstaan alleen uit juniors die het vak hebben geleerd. Onderzoek van Anthropic laat zien dat leren met AI het begrip kan verlagen, vooral bij debuggen, tenzij je de AI om uitleg vraagt in plaats van om code.

Bronnen

Cases en bedrijfspublicaties

• Stripe, Minions: Stripe's one-shot, end-to-end coding agents (9 februari 2026) en deel 2 (19 februari 2026)
• Spotify Engineering, Coding is no longer the constraint (3 juni 2026); TechCrunch, Spotify says its best developers haven't written a line of code since December (12 februari 2026)
• Adyen, AI in our development lifecycle (3 september 2026)
• Anthropic, How AI is transforming work at Anthropic (2 december 2025, verkoper van het gereedschap); Fortune, over het aandeel AI-code bij Anthropic (29 januari 2026)
• Simon Willison, How StrongDM's AI team build serious software without even looking at the code (7 februari 2026)
• The Register, Amazon denies Kiro agentic AI behind outage (20 februari 2026); Fortune, over de storingen bij Amazon retail (12 maart 2026)
• Semafor, Google CEO says 75% of company's new code is AI-generated (24 april 2026)
• epilot, Our entire company ships code now (2026)

Onderzoek naar productiviteit en kwaliteit

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10 juli 2025, preprint) en de update van 24 februari 2026
• He e.a., AI Writes Faster Than Humans Can Review (preprint, versie 3 van 10 november 2026)
• Microsoft, effect van Claude Code en Copilot CLI op gemergde pull requests (preprint, juli 2026)
• Vella en Blincoe, longitudinaal onderzoek naar ontwikkelaarswerk met AI (geaccepteerd door ACM TOSEM, versie 2 van 3 november 2026)
• Google Cloud, 2025 DORA State of AI-assisted Software Development (23 september 2025, enquête)
• GitHub, Octoverse 2026 (28 oktober 2026, platformdata)
• Stack Overflow, Developer Survey 2025, AI en 2026, AI (enquêtes)
• CodeRabbit, State of AI vs human code generation (17 december 2025, leverancier); Faros AI, The Acceleration Whiplash (leverancier)
• Shen en Tamkin (Anthropic), How AI assistance impacts the formation of coding skills (januari 2026, paper)
• Addy Osmani, Comprehension debt (14 maart 2026); InfoQ, over de keynote van Werner Vogels (10 december 2025)

Incidenten en beveiliging

• Fortune, over Replit en SaaStr (23 juli 2025)
• Nx, s1ngularity postmortem (5 september 2025); StepSecurity, analyse van de aanval (27 augustus 2025)
• AWS, Security bulletin AWS-2025-015 (23 juli 2025)
• Adnan Khan, Clinejection (9 februari 2026)
• NVD, CVE-2025-48757 (30 mei 2025)
• Veracode, 2026 GenAI Code Security Report (juli 2026, leverancier); Apiiro, 4x velocity, 10x vulnerabilities (4 september 2025, leverancier)
• Perry e.a., Do Users Write More Insecure Code with AI Assistants? (ACM CCS 2023)
• Spracklen e.a., We Have a Package for You! (USENIX Security 2025)
• Cloudflare, postmortems

Wetgeving

• Richtlijn (EU) 2024/2853 inzake aansprakelijkheid voor producten met gebreken
• Eerste Kamer, wetsvoorstel 36.906, Implementatiewet richtlijn herziening productaansprakelijkheid
• Europese Commissie, Cyber Resilience Act, meldplichten; ENISA, Single Reporting Platform

Economie

• Claude Code-documentatie, Manage costs effectively
• Reuters via The Star, US software stocks hit by Anthropic wake-up call (4 februari 2026)
• Gartner, prognose IT-uitgaven 2027 (21 oktober 2026)
• Rutviz Parekh, samenvatting kwartaalcijfers Indiase IT-dienstverleners (23 oktober 2026, secundair); Constellation Research, over Accenture Q4 (1 oktober 2026)
• 9to5Mac, App Store sees 84% surge in new apps (6 april 2026)
• Robert L. Glass, Frequently Forgotten Fundamental Facts about Software Engineering

Geschiedenis en begrippen

• Simon Willison, Not all AI-assisted programming is vibe coding (19 maart 2025), met de tekst van Karpathy's post, en What is agentic engineering?
• Kent Beck, Augmented Coding: Beyond the Vibes (2025)
• John Backus, The History of FORTRAN I, II, and III (1978)
• Edsger W. Dijkstra, EWD667: On the foolishness of "natural language programming"
• Fred Brooks, No Silver Bullet: Essence and Accident in Software Engineering (1986)
• Peter Naur, Programming as Theory Building (1985)
• Lisanne Bainbridge, Ironies of Automation (Automatica, 1983; leesbare kopie)
• The Register, over de Excel-fout bij Public Health England (5 oktober 2020)

Gereedschap en documentatie

• Claude Code-documentatie, Code Review, Permissions en Agent teams
• Laravel, Announcing Laravel Boost (13 augustus 2025) en de documentatie over lazy loading voorkomen, autorisatie, migraties terugdraaien en testen
• SignalFire, State of Talent Report 2026

Eigen gegevens

• Git-geschiedenis van vandeblaak.com op 14 november 2026: 633 commits sinds 8 januari 2026, waarvan 613 met de regel Co-Authored-By: Claude. Die regel zegt dat Claude meeschreef, niet dat Claude alles schreef.