De meeste teams ontdekken AI-CLI's via één enthousiaste collega. Die collega draait een terminal-agent, bespaart zichtbaar tijd, en de rest van het team kijkt geïnteresseerd toe. Een halfjaar later gebruikt nog steeds diezelfde ene persoon de tool, terwijl de rest is afgehaakt. Dat is geen kwestie van te weinig enthousiasme. Het is een adoptiepatroon dat zich in vrijwel elke organisatie herhaalt, en het is goed te doorbreken als je het als verandertraject behandelt in plaats van als toolkeuze.
Dit hoofdstuk gaat over dat traject: hoe je van een geïsoleerd experiment naar een werkwijze komt die het vertrek van één collega overleeft. Het is het sluitstuk van deze reeks over AI-CLI's, na de vraag wat een terminal-agent eigenlijk is, hoe je er veilig mee werkt en hoe je de juiste CLI kiest.
Key Takeaways
- •Losse experimenten stranden omdat de werkwijze in iemands hoofd zit, niet in gedeelde configuratie. Persoonsafhankelijke kennis is het echte adoptierisico.
- •Begin met een afgebakende pilot: een klein team, twee of drie echte werkprocessen, en een vooraf gemeten baseline waaraan je het resultaat afmeet.
- •Maak configuratie de teamstandaard. Bestanden als CLAUDE.md, AGENTS.md en gedeelde skills horen in versiebeheer, zodat de afspraak met de code meereist.
- •Automatisering wordt pas waardevol als ze structureel is: terugkerende taken via scheduled en cloud-agents, niet ad-hoc per persoon.
- •Borging zit in reviewafspraken, kennisdeling en gerichte training, niet in de hoop dat collega's het zelf wel oppikken.
Waarom losse experimenten stranden
Het kernprobleem is zelden de tool. Een AI-CLI levert vrijwel direct waarde op voor wie er handig in is. Het probleem is dat die handigheid niet overdraagbaar is zolang ze ongeschreven blijft.
Denk aan wat er feitelijk gebeurt bij een geslaagd experiment. De collega heeft door trial-and-error geleerd welke instructies werken, welke context de agent nodig heeft, en welke valkuilen te vermijden zijn. Die kennis zit in prompts die hij elke keer opnieuw typt, in een mentaal model van wat de tool wel en niet aankan, en in een werkwijze die nergens is vastgelegd. Vraag een nieuwe collega om hetzelfde te doen en die begint bij nul, raakt gefrustreerd door inconsistente resultaten, en concludeert dat de tool "niet voor hem werkt".
Dit is precies waarom AI-adoptie in bredere zin zo moeizaam verloopt. Uit het State of AI-onderzoek van McKinsey (2025) blijkt dat 88 procent van de organisaties inmiddels regelmatig AI gebruikt in minstens één bedrijfsfunctie, maar dat slechts ongeveer een derde daadwerkelijk verder is gekomen dan experimenteren en piloteren. De kloof zit niet in toegang tot de technologie. Die zit in het inbedden ervan in een gedeelde werkwijze. Voor AI-CLI's geldt dat in versterkte mate, omdat de configuratie waarmee een agent goed presteert tekstueel en deelbaar is, maar alleen als je hem expliciet maakt.
De pilot: klein, echt en meetbaar
Een pilot is geen vrijblijvende speeltuin. Het is een afgebakend experiment met een vooraf afgesproken vraag: levert deze werkwijze genoeg op om hem breder uit te rollen? Om die vraag te kunnen beantwoorden heb je drie dingen nodig.
Een klein team met de juiste mensen
Kies twee tot vier mensen, niet de hele afdeling. Liefst een mix: iemand die technisch sterk is en de tool snel doorgrondt, en iemand die representatief is voor de doorsnee gebruiker. Als de tweede persoon na de pilot enthousiast is, weet je dat de werkwijze overdraagbaar is en niet alleen werkt voor de vroege fanatiekeling.
Echte cases, geen demo's
Laat het pilotteam de CLI loslaten op werk dat ze toch al moeten doen: een terugkerende rapportage, het opschonen van een dataset, het genereren van standaarddocumenten. Demo-opdrachten geven een vertekend beeld, omdat ze de rommelige randgevallen van echt werk missen. Juist in die randgevallen blijkt of een agent in jouw context betrouwbaar is.
Een baseline die je vooraf meet
Dit is de stap die het vaakst wordt overgeslagen, en zonder die stap is je pilot niet te beoordelen. Meet voordat je begint hoe lang de gekozen processen nu duren, hoeveel correctierondes ze kosten, en hoe tevreden mensen erover zijn. Na een paar weken vergelijk je. McKinsey wijst er nadrukkelijk op dat het bijhouden van heldere KPI's de grootste impact heeft op of AI-investeringen daadwerkelijk waarde opleveren. Zonder baseline beslis je op onderbuikgevoel, en dan wint het experiment dat het hardst geroepen heeft, niet het experiment dat het meeste oplevert.
Gedeelde configuratie als teamstandaard
Hier ligt het scharnierpunt tussen een geslaagd experiment en een teamwerkwijze. Het verschil tussen "die ene collega kan het" en "ons team kan het" is of de kennis in versiebeheer staat of in iemands hoofd.
AI-CLI's lezen hun werkafspraken uit configuratiebestanden in je project. Bij Claude Code is dat CLAUDE.md: een markdownbestand in je repository waarin je vastlegt hoe de agent zich in dit project moet gedragen, welke conventies gelden en welke valkuilen te vermijden zijn. Een vergelijkbare, tool-overstijgende standaard is AGENTS.md, die door meerdere agents wordt gelezen. Zet je deze bestanden in je repository, dan reist de afspraak automatisch mee met de code. Iedere collega die het project opent, krijgt dezelfde context, zonder dat iemand iets hoeft uit te leggen.
Een laag dieper kun je veelvoorkomende taken vastleggen als herbruikbare bouwstenen. Agent skills bundelen een specifieke vaardigheid, bijvoorbeeld het opmaken van een rapport volgens jullie huisstijl, in een vorm die het team deelt en verbetert. Hetzelfde geldt voor gespecialiseerde subagents: in de documentatie van Claude Code staat letterlijk dat je projectsubagents in .claude/agents/ "into version control" zet "so your team can use and improve them collaboratively" (zie docs.claude.com). Dat is precies het mechanisme dat persoonsafhankelijke kennis omzet in teamkapitaal: niet één persoon die slim promptt, maar een gedeelde set afspraken die het team samen aanscherpt.
De praktische regel is eenvoudig. Alles wat het pilotteam handmatig steeds opnieuw doet, hoort thuis in een gedeeld configuratiebestand. Op het moment dat een nieuwe collega productief is zonder uitleg, is je configuratie volwassen.
Automatisering structureel maken
Zodra je werkwijze in configuratie vastligt, wordt de volgende stap mogelijk: taken die niemand meer hoeft te starten. Veel terugkerend werk, denk aan een wekelijkse samenvatting, een dagelijkse controle van data of het bijwerken van documentatie, leent zich voor automatisering zodra de agent er betrouwbaar in is.
Daar komen twee categorieën in beeld. Scheduled agents draaien een taak op een vast moment, bijvoorbeeld elke maandagochtend, zonder dat iemand op een knop drukt. Cloud-agents draaien niet op de laptop van een individu maar op infrastructuur die het team deelt, waardoor de automatisering blijft werken ook als die ene collega op vakantie is. Het verschil met ad-hoc gebruik is fundamenteel: een geautomatiseerde taak is per definitie niet persoonsafhankelijk, want er hangt geen mens meer aan vast die hem moet onthouden.
Een belangrijke nuance: automatiseer pas wat in de pilot bewezen betrouwbaar bleek. Een agent die taken zelfstandig uitvoert, hoort binnen heldere grenzen te opereren, zeker als hij dat ongezien doet. De afwegingen daarrond, van rechten en sandboxing tot reviewmomenten, staan in het hoofdstuk over veilig werken met AI-agents. Automatiseren is het sluitstuk van vertrouwen, niet het beginpunt.
Borging: zo blijft het hangen
Een pilot die slaagt en daarna doodbloedt, is het meest voorkomende eindstation. Borging is het werk dat ervoor zorgt dat de werkwijze onderdeel wordt van hoe het team functioneert, ook als de aandacht verslapt. Drie ingrediënten zijn daarvoor doorslaggevend.
Reviewafspraken. Spreek af wat door een mens wordt nagekeken voordat het naar buiten of in productie gaat. Output van een agent is een concept, geen eindproduct. Door review expliciet in het proces te zetten, voorkom je zowel kwaliteitsincidenten als het sluipende wantrouwen dat ontstaat na één zichtbare fout.
Kennisdeling. Maak ruimte waarin het team configuratie en prompts deelt en verbetert: een vast overlegpunt, een gedeelde map, een korte demo bij nieuwe inzichten. De configuratiebestanden uit de vorige secties zijn de drager, maar het gesprek eromheen houdt ze levend. Hier wordt de werkwijze collectief in plaats van individueel.
Gerichte training. Het verschil tussen een team dat AI-CLI's oppervlakkig gebruikt en een team dat er werkelijk meer mee doet, is grotendeels een kwestie van vaardigheid. Dat dit een serieus vak is, blijkt uit de cijfers: bij de aankondiging van zijn Series G-financiering op 12 februari 2026 meldde Anthropic dat de jaaromzet van Claude Code is doorgegroeid tot ruim 2,5 miljard dollar, en dat zakelijk gebruik inmiddels meer dan de helft van die omzet vertegenwoordigt (cijfers per begin 2026). Bedrijven als Netflix, Spotify, KPMG en L'Oréal namen de tool in gebruik in de eerste maanden na de publieke lancering. Dat is geen hobbymarkt meer; het is professioneel gereedschap waarvoor het loont om mensen te scholen.
Voor teams die deze stap begeleid willen zetten, in plaats van iedereen het zelf laten uitzoeken, bieden wij een Claude Code-masterclass waarin we precies dit traject doorlopen: van werkwijze tot configuratie tot borging. Het is geen verplichte route, je kunt het volledig zelf opbouwen met de hoofdstukken in deze reeks. Maar als snelheid en consistentie zwaar wegen, scheelt begeleiding maanden trial-and-error.
Tot slot
Het invoeren van AI-CLI's is geen toolimplementatie maar een verandertraject met een herkenbaar pad: een meetbare pilot, configuratie die de teamstandaard wordt, automatisering die structureel is, en borging die het laat beklijven. De rode draad door al die stappen is dezelfde: haal de werkwijze uit het hoofd van één persoon en leg hem vast op een plek die het hele team deelt.
Daarmee sluit deze reeks over AI-CLI's. Wil je dieper de techniek in, dan vormen wat een terminal-agent is en de juiste CLI kiezen de logische opstap. Wil je het begeleid in je team verankeren, dan is de Claude Code-masterclass de meest directe route.