Het is maandagochtend. In Teams staat een bericht van de tester: “De registratie geeft een 500 sinds het laatste deployment.”

Je opent de logging en ziet een NullReferenceException met een stacktrace die drie lagen diep gaat. Ergens in de validatielogica van de RegistrationService. Vrijdagmiddag is er een PR gemerged die het registratieproces uitbreidde met een bedrijfsnaam-veld. De tests waren groen. Maar in productie gaat het mis.

Nu begint het zoekwerk.

De oude manier

Je opent de stacktrace en begint bestanden te openen. RegistrationService.cs — 200 regels. RegisterUserCommand.cs — het request model. RegisterUserValidator.cs — de FluentValidation rules. UserMappingProfile.cs — de AutoMapper config.

Je leest, scrollt, vergelijkt. Na twintig minuten heb je een vermoeden. Je opent ChatGPT, kopieert de relevante stukken code erin — drie berichten, want het past niet in één keer — en vraagt: “Zie je wat hier misgaat?”

ChatGPT zegt: “Het lijkt erop dat er een null check mist. Probeer een null-coalescing operator toe te voegen.” Technisch niet fout, maar het is een pleister. De echte oorzaak zit ergens anders.

Na een uur heb je het gevonden. Het nieuwe CompanyName-veld zit wel in het command, maar niet in de AutoMapper profile. De mapping faalt stil, de validator krijgt een onverwacht null-object, en gooit een exception.

Met Claude Code

Zelfde bug. Maar een andere aanpak.

Je opent je terminal in het project en start Claude Code. Je plakt de stacktrace en zegt:

“De registratie-endpoint geeft een 500 na het laatste deployment. Dit is de exception.”

Dat is alles. Geen bestanden kopiëren, geen context opbouwen. Claude Code pakt het vanaf hier op.

Het leest zelf

Claude Code volgt de stacktrace als een landkaart. Het opent RegistrationService.cs en ziet waar de exception vandaan komt. Het leest de RegisterUserValidator.cs en ziet dat de validator een property verwacht die null is. Het opent UserMappingProfile.cs en vindt het probleem: het nieuwe CompanyName-veld ontbreekt in de mapping.

Geen generiek advies over null checks. De daadwerkelijke oorzaak, gevonden door de code te lezen — niet door te gissen.

Het fixt en verifieert

Claude Code stelt de fix voor: de mapping uitbreiden in UserMappingProfile.cs.

CreateMap<RegisterUserCommand, User>()
    .ForMember(dest => dest.Email, opt => opt.MapFrom(src => src.Email))
    .ForMember(dest => dest.Name, opt => opt.MapFrom(src => src.Name))
    .ForMember(dest => dest.CompanyName, opt => opt.MapFrom(src => src.CompanyName));

Na je akkoord past het de code aan en runt dotnet build. Compileert. Dan dotnet test. Alle tests groen — inclusief de bestaande registratietests die nu ook het nieuwe veld meenemen.

Heeft de class die je fixt nog helemaal geen tests? Dan is dit het moment om Claude de eerste te laten schrijven. Een fix die je niet kunt herhalen, komt terug.

Het is 09:15.

Waarom dit sneller is

Het verschil zit niet in het oplossen zelf. De fix is één regel. Het verschil zit in alles wat eraan voorafgaat.

Bij de oude manier ben je het grootste deel van je tijd kwijt aan context verzamelen. Bestanden openen, code lezen, verbanden leggen, relevante stukken kopiëren naar een chatvenster. Dat is het saaie, tijdrovende deel — en precies het deel waar Claude Code je van bevrijdt.

Claude Code leest je codebase. Het volgt de stacktrace door je bestanden heen, van endpoint naar service naar mapping. Het hoeft niet te gissen welke bestanden relevant zijn, want het kan ze gewoon openen. En omdat het je hele project kent — zeker als je een goed CLAUDE.md-bestand hebt — begrijpt het ook hoe jullie dingen doen.

Wanneer het niet werkt

Eerlijkheid: Claude Code is geen wondermiddel voor elke bug.

Bugs die hun oorzaak buiten de code hebben — een verkeerde environment variable, een database die vol zit, een DNS-wijziging die nog niet is doorgevoerd — daar kan Claude Code weinig mee. Het leest code, geen infrastructuur.

En sommige bugs zijn inherent lastig, ook voor AI. Race conditions, timing-gerelateerde problemen, bugs die alleen onder specifieke load optreden — die vereisen een ander soort onderzoek dan code lezen.

De vuistregel die ik hanteer: als de oorzaak in de code zit, kan Claude Code het vinden. En dat is veruit het merendeel van de bugs die je als developer tegenkomt.

Volgende stacktrace, probeer dit

De volgende keer dat productie iets naar je toe gooit: onderdruk de reflex om bestanden te gaan openen. Start Claude Code in de repo, plak de exception, en zeg wat de gebruiker aan het doen was. Meer niet — niet wijzen naar het bestand dat je verdenkt, geen “volgens mij zit het in de validatie”.

Lees dan de eerste zin die terugkomt. Noemt het een bestand dat je zelf nog niet open had, en klopt de reden als je het nakijkt, dan heb je net het kwartier overgeslagen dat je normaal nodig hebt om bij diezelfde zin uit te komen. Komt er iets algemeens terug, dan droeg je stacktrace te weinig informatie — en dat is een loggingprobleem, geen AI-probleem.

Wat in beide gevallen van jou blijft is het laatste oordeel: beoordelen of de fix echt klopt.