De meeste teams proberen AI-tooling. Weinig teams adopteren het echt.

Copilot geïnstalleerd, een paar weken gebruikt, weer terug naar de oude workflow. Dat is geen AI-probleem. Dat is een adoptieprobleem.

Ik werk dagelijks met Claude Code. Niet af en toe, maar als vast onderdeel van mijn workflow. Dit is wat ik daarvan leer.

Wat ik ermee bouw

Ik bouw momenteel Invullen.nl: een SaaS-platform voor coaches en trainers. Multi-tenant architectuur, vragenlijst-builder, respondent-flows, AI-gestuurde vragenlijsten en AI-responseanalyse.

Als solo-developer met Claude Code lever ik significant sneller dan zonder. Niet omdat de tool de code "schrijft", maar omdat ik sneller itereer. Ik beschrijf wat ik wil, review wat eruit komt, stuur bij, en focus mijn tijd op de architectuurkeuzes die ertoe doen.

Waarom het bij de meeste teams niet landt

Geen afspraken over wanneer je AI-tooling wel of niet gebruikt. Geen review-proces voor AI-gegenereerde code. Het resultaat: inconsistente kwaliteit en terecht wantrouwen.

Wat wél werkt:

  • AI-gegenereerde code door exact hetzelfde review-proces
  • Heldere afspraken: boilerplate en CRUD ja, core business-logica met extra aandacht
  • Het team leert prompts schrijven die bij hun codebase passen

En als je AI in je product bouwt: de EU AI Act

AI-tooling intern gebruiken voor development valt in de laagste risicocategorie. Maar zodra je AI-features in je product bouwt, gelden er op z'n minst transparantieverplichtingen. Afhankelijk van het domein kan het verder verschuiven. Dat onderscheid moet je als team bewust maken.

Het echte probleem is adoptie, niet technologie

Developers moeten vertrouwen opbouwen met de tooling. Dat kost geen demo van 30 minuten. Dat kost iemand die een paar maanden meedraait en het laat zien in hun eigen codebase, met hun eigen conventions.