Ik schrijf minder code dan ooit. En toch ben ik productiever dan ik in jaren ben geweest. Dat voelt paradoxaal, maar het klopt: mijn rol is verschoven. Ik typ minder, maar ik denk meer. De vraag is niet meer “hoe implementeer ik dit?” maar “wat moet hier gebouwd worden, en waarom?”

Dat is geen kleine verschuiving. Voor de meeste van ons is onze identiteit als developer nauw verbonden met code schrijven. Het vakmanschap om een complex algoritme goed te krijgen, de voldoening van een schone refactor, de flow-state als alles klikt. En nu komt er een tool die dat deel voor je doet — vaak sneller en soms beter.

De echte vraag is: wat blijft er over? En het antwoord, denk ik, is interessanter dan je zou verwachten.

De oude workflow vs. de nieuwe

Een jaar geleden zag het bouwen van een nieuw endpoint in onze ASP.NET Core API er zo uit: ik bekeek een bestaand endpoint, kopieerde de structuur, schreef de controller of minimal API handler, voegde de validatie toe, registreerde de DI-dependencies, schreef de tests. Meestal wist ik precies wat er moest gebeuren. Het werk zat in het typen.

Nu begint diezelfde feature anders. Ik beschrijf wat het endpoint moet doen, hoe het request en response eruitzien, en hoe het past bij de bestaande patronen. Claude Code leest de codebase, ziet dat we Minimal APIs gebruiken met een specifieke mappenstructuur, en genereert het endpoint inclusief validatie, foutafhandeling en tests. Mijn taak is te reviewen of het past.

Dat klinkt sneller. En dat is het ook — voor het implementatiedeel. Maar hier is wat ik niet verwacht had: het denkwerk duurt nu langer. Niet omdat AI het moeilijker maakt, maar omdat ik me niet meer kan verschuilen achter het typen. Als je zelf code schrijft, kun je beginnen met een vaag idee en het laten uitkristalliseren terwijl je typt. Met AI moet je precies weten wat je wilt voordat er iets gegenereerd wordt.

Die precisie is de nieuwe vaardigheid.

Wat je kunt delegeren — en wat niet

Na maanden dagelijks werken met Claude Code heb ik een redelijk helder beeld van wat ik uit handen kan geven en wat niet. De grens ligt niet waar ik hem verwacht had.

Wat goed te delegeren is:

  • Boilerplate: CRUD-endpoints, DTO’s, mapping-code, DI-registratie
  • Tests: unit tests volgens een bestaand patroon, vooral als je naar een voorbeeld-testbestand verwijst
  • Refactoring: een klasse extraheren, consistent hernoemen, een grote methode opsplitsen
  • Standaardpatronen: repository-implementaties, event handlers, middleware — alles waar het patroon duidelijk is

Wat niet te delegeren is:

  • “Moet dit een aparte service worden of onderdeel van de bestaande?” — architectuurbeslissingen die afhangen van je domein
  • “Is eventual consistency hier acceptabel, of hebben we een transactie nodig?” — afwegingen die begrip van de businesscontext vereisen
  • “Past dit bij hoe ons team werkt?” — teamconventies die nergens vastliggen

Een concreet voorbeeld. Ik vroeg Claude om caching toe te voegen aan een service. Het genereerde een perfect geïmplementeerde IMemoryCache-integratie. Schone code, correct gebruik, zelfs met goede cache-invalidatie. Maar wij gebruiken Redis in productie omdat onze API op meerdere instanties draait. IMemoryCache was de verkeerde keuze — niet omdat het niet werkt, maar omdat het niet past bij onze infrastructuur.

Claude kon dat niet weten. En dat is het punt: de implementatie was technisch correct, maar architecturaal fout. Dat opmerken is jouw taak. Niet het typen — het denken.

De vaardigheden die er nu toe doen

Drie vaardigheden zijn belangrijker geworden in mijn dagelijkse werk. Geen van drieën gaat over code schrijven.

Systeemdenken

Als Claude code genereert, lost het het lokale probleem op. Endpoint toevoegen? Klaar. Test schrijven? Klaar. Maar software is geen verzameling losse onderdelen. Het is een systeem waar alles samenhangt: de DI-container koppelt services aan elkaar, middleware handelt cross-cutting concerns af, events stromen door handlers.

Jouw taak is het overzicht houden. Moet deze nieuwe service scoped of singleton zijn? Moet deze event handler idempotent zijn omdat de message broker mogelijk herhaalt? Moet dit endpoint rate limiting krijgen omdat het publiek toegankelijk is?

Dit zijn geen implementatievragen. Het zijn architectuurvragen. En ze vereisen begrip van het hele systeem, niet alleen het bestand waar je naar kijkt.

Code review als kernvaardigheid

Code review was altijd belangrijk. Maar het was iets dat je deed voor collega’s. Nu is het iets dat je doet voor elk stuk gegenereerde code — en je doet het tientallen keren per dag.

Dat verandert de vaardigheid. Je zoekt niet alleen bugs. Je vraagt: past dit? Volgt het onze naamgevingsconventies? Komt de foutafhandeling overeen met wat we elders doen? Is het abstractieniveau juist, of is het over-engineered?

Ik heb gemerkt dat mijn reviews scherper zijn geworden sinds ik met AI werk. Doordat ik meer code review, heb ik een beter oog ontwikkeld voor inconsistenties. Dat is een onverwacht voordeel.

Helder specificeren

Dit is de grote. De kwaliteit van je output hangt volledig af van hoe goed je kunt beschrijven wat je wilt. Niet in code — in woorden.

Dat betekent: precies zijn over gedrag, niet over implementatie. Constraints expliciet benoemen. Verwijzen naar bestaande patronen in plaats van hopen dat Claude ze vindt. Weten hoe “klaar” eruitziet voordat je begint.

Dit is, in zekere zin, de nieuwe vorm van code schrijven. In plaats van if (order.Status == OrderStatus.Cancelled) schrijf je: “Als een order wordt geannuleerd, stuur een notificatie via ons bestaande IEventHandler-patroon. Kijk naar hoe we OrderShipped afhandelen voor de structuur.”

De precisie is dezelfde. Het medium is anders.

De ongemakkelijke waarheid

Niet iedereen vindt dit comfortabel. En ik denk dat het waard is om dat te zeggen.

Als je identiteit als developer gebouwd is op “ik schrijf schone, elegante code”, voelt het vreemd om dat uit handen te geven. Er is een echt gevoel van verlies als je beseft dat het vakmanschap waar je jarenlang aan hebt geslepen nu geautomatiseerd kan worden.

Maar ik ben gaan geloven dat de waarde nooit in het typen zat. Het zat in het begrijpen. Weten waarom een bepaald patroon de juiste keuze is. Weten wanneer een abstractie helpt en wanneer het schaadt. Weten welke vragen je moet stellen voordat er één regel code is geschreven.

Dat begrip wordt niet minder belangrijk met AI. Het wordt belangrijker. Want nu ben je niet alleen verantwoordelijk voor de code die je schrijft. Je bent verantwoordelijk voor de code die je accepteert. En slechte code accepteren omdat het snel gegenereerd is, is erger dan het langzaam zelf schrijven.

De developers die ik het meest zie worstelen met AI zijn degenen die de review overslaan. Niet omdat ze lui zijn, maar omdat de code er goed uitziet. Het compileert, de tests slagen, de structuur lijkt vertrouwd. Maar “ziet er goed uit” en “is goed” zijn verschillende dingen — vooral als het gaat om hoe code past in een groter systeem.

Je titel verandert niet. Je werk wel.

Ik noem mezelf nog steeds een developer. Ik bouw nog steeds elke dag software. Maar wat dat betekent is verschoven. Minder tijd in de editor, meer tijd nadenken over ontwerp. Minder typen, meer reviewen. Minder “hoe”, meer “wat” en “waarom”.

De beste developers van de komende jaren worden niet de snelste typisten. Het worden de scherpste denkers. Degenen die naar gegenereerde code kunnen kijken en niet alleen zien of het werkt, maar of het thuishoort.

De volgende keer dat je aan een feature begint, probeer dit: schrijf — in gewone taal — wat je wilt bouwen, waarom, en hoe het moet passen bij wat er al staat, voordat je ook maar één prompt typt. Beschrijf het alsof je een ervaren collega briefed die je codebase niet kent. Die oefening is het werk nu. De implementatie volgt.