Hoe Claude Code mijn .NET development-workflow versnelt

In augustus 2025 stapte ik als .NET developer over naar Claude Code in de CLI. Niet als slimmere autocomplete, maar als een assistent die zelfstandig in mijn codebase werkt. Ik stuurde en reviewde. De AI deed het werk. Dat veranderde hoe ik bouw.

Wat bouw ik ermee?

Ik gebruik Claude Code dagelijks voor twee producten.

Invullen.nl, een SaaS-platform voor trainers en coaches. Multi-tenant architectuur, vragenlijst-builder, respondent-flows, AI-gestuurde vragenlijsten en groepsanalyse. Dit bouw ik volledig met Claude Code.

Factuur-Assist.nl, een facturatie-app die al 7+ jaar in productie draait met 135+ klanten. Hier gebruik ik Claude Code voor onderhoud en migraties. Een recente migratie van een belangrijke microservice van .NET 2.2 naar .NET 10 had ik op vijf werkdagen ingeschat. Door Claude Code in te zetten voor analyse, omzettingen en tests was het technische werk in één dag rond. Review en validatie bleven natuurlijk mijn verantwoordelijkheid.

Niet omdat de tool de code “schrijft”, maar omdat de iteratiesnelheid veel hoger ligt. Ja, reviewen kost meer aandacht dan voorheen. Maar in mijn ervaring is de balans positief: ik besteed nu ongeveer een derde van mijn tijd aan review en bijsturing, waar ik voorheen het merendeel kwijt was aan schrijven. Dat reviewen is mentaal zwaarder: je wisselt de flow van bouwen in voor de kritische blik van beoordelen. Dat is een andere spier. De doorlooptijd van een feature is korter, ook met die extra review-last. Hoe die balans uitpakt hangt af van het type werk. Bij een migratie is de winst enorm. Bij een complex domeinprobleem soms nihil.

En soms duurt het lánger: AI bouwt regelmatig iets te groot en te complex. De kunst is dan snoeien, niet blind accepteren.

Soms bouw je een feature in 2 uur die niemand gebruikt. Snel bouwen maakt het niet automatisch waardevol.

Het dagelijkse ritme: specificeren, delegeren, reviewen, bijsturen

Claude Code voelt voor mij minder als autocomplete en meer als een assistent die echt meewerkt in de codebase. Mijn rol verschuift van schrijven naar sturen en beoordelen. In de praktijk draait dat als een ritme:

• Specificeren: goede context-files (CLAUDE.md, .cursorrules), heldere specs, duidelijke guardrails. Hoe beter de opdracht, hoe beter de output
• Delegeren: de AI werkt in de codebase, genereert code, draait tests. Ik paralleliseer bewust: meerdere threads tegelijk
• Reviewen: AI maakt andere fouten dan collega’s. Vaak subtieler. Als je een wijziging niet in 2 minuten kunt doorgronden, moet de opdracht kleiner
• Bijsturen: “vereenvoudig dit” werkt beter dan eindeloos lokaal repareren. De eerste output is zelden goed genoeg, maar de iteratiesnelheid is hoog

Wat voor mij het verschil maakt: een context-file voor je AI-tool (CLAUDE.md, .cursorrules, copilot-instructions.md). Daarin leg je richtlijnen, guardrails en architectuurkeuzes vast. Veel daarvan hoort ook in je CONTRIBUTING.md of ADR’s, maar de context-file vertaalt het naar iets dat je AI-agent begrijpt. Dat bepaalt voor een groot deel of de output bruikbaar is of rommelig.

Met een dubbele Definition of Done: één voor de AI (code compileert, tests slagen) en één voor mij (architectuur klopt, edge cases afgedekt, security bekeken).

Waarom lopen teams hier vaak vast?

Mijn eigen producten bouw ik solo, maar ik werk ook in teamverband. En daar hoor en zie ik steeds dezelfde patronen: in een team moet je het samen doen. Context opbouwen, guardrails afspreken, reviewnormen vaststellen. En daar wringt het. Verschillende voorkeuren, geen gedeelde aanpak, en weerstand of wantrouwen die je niet wegtraint.

De bottleneck verschuift van schrijven naar begrijpen. Teams die dat snappen, winnen.

Veel kun je als team zelf oppakken. Maar als niemand het voordoet in jullie manier van werken, helpt het als iemand meedoet die het al dagelijks toepast.

De vraag is niet of AI je workflow verandert. De vraag is of je team klaar is om mee te veranderen.