Remote teams
Afspraken over AI-codeertools in een remote team
Laat je remote team Claude Code alleen met zakelijke accounts gebruiken, zet de regels in de repository en houd productiesleutels buiten bereik van de tool.
Voordat een remote team met Claude Code of een vergelijkbare tool aan jouw code werkt, leg je een paar dingen vast: met welke accounts het team werkt, wat de tool niet mag lezen, hoe AI-code door review gaat en wat je bijhoudt. Zet die afspraken in de repository zelf. Dan gelden ze voor iedereen die de code uitcheckt, waar die persoon ook zit.
Werk met zakelijke accounts
Het eerste besluit is wie de licenties regelt en onder welk account. Laat developers niet met een persoonlijk abonnement aan klantcode werken, want de voorwaarden verschillen per type account.
Anthropic gebruikt de invoer en uitvoer van zijn zakelijke producten, zoals Claude for Work en de API, standaard niet om modellen te trainen. GitHub gebruikt sinds 24 april 2026 de interactiedata van Copilot Free, Pro en Pro+ wel voor training, tenzij de gebruiker dat uitzet. Copilot Business en Enterprise vallen daar niet onder.
Spreek dus af dat iedereen met een zakelijk account werkt, bij voorkeur onder de organisatie van de klant. Dan kun je instellingen ook centraal afdwingen. Bij Claude Code gaat dat met managed settings, die een developer in zijn eigen bestanden niet kan overschrijven.
Zet de regels in de repository
Claude Code leest aan het begin van elke sessie het bestand CLAUDE.md in de repository. Daar zet je de conventies, de commando's voor build en tests en de mappen waar de tool vanaf moet blijven. Veel andere tools lezen AGENTS.md, en Claude Code kan dat bestand ook lezen.
CLAUDE.md geeft de tool context, maar dwingt niets af. Wat niet mag, leg je vast als permissie in .claude/settings.json. Een deny-regel als Read(./.env) houdt de tool weg van je env-bestand. Commit dat settingsbestand mee, dan geldt de regel voor het hele team.
Houd secrets buiten bereik
Een AI-codeertool leest bestanden en stuurt de inhoud naar het model, dus alles wat in de werkmap staat, kan in een prompt belanden. Houd productiesleutels daarom buiten de repository en buiten de lokale omgeving. Developers werken met eigen sleutels voor development, met zo weinig rechten als kan.
Spreek ook af dat niemand een sleutel in een chat met de tool plakt om even snel iets te testen. Gebeurt het toch, roteer de sleutel dan meteen. Onze developers werken op beheerde, versleutelde laptops met centraal beheerde accounts. Daarmee is het apparaat afgedekt, maar de sleutels zelf beheer je apart. Hoe je dat doet, staat in het stuk over secrets en API-keys.
Review blijft mensenwerk
Wie de pull request opent, is eigenaar van de code. Of die code met de hand is getypt of door een tool is gegenereerd, maakt voor de review niet uit. "Dat heeft Claude geschreven" is geen antwoord op een reviewvraag. Bij de screening vraag ik kandidaten daarom al hoe ze gegenereerde code controleren.
Met AI-tools is het makkelijk om veel tegelijk te veranderen. Spreek daarom een maximale omvang af voor pull requests en vraag bij grotere wijzigingen eerst om een plan. Let in de review op tests die niets testen en op wijzigingen die buiten het ticket vallen. Controleer ook of elke functie en elke optie die de code aanroept, echt bestaat. Erik schreef meer over code review op afstand.
Licenties en code van anderen
Bij licenties gaat het hier om twee dingen. Het eerste is de licentie voor de tool zelf, en die heb je met de accounts geregeld. Het tweede is de licentie van code die de tool voorstelt, want een model kan code teruggeven die sterk lijkt op bestaande open source.
GitHub Copilot heeft daar een instelling voor. Je blokkeert suggesties die overeenkomen met openbare code, of je laat ze toe en krijgt dan een verwijzing naar de bron, met de licentie erbij. Een organisatie kan dat centraal instellen. Bij andere tools ligt die controle bij de reviewer. Mijn advies is om een groot blok code dat opvallend compleet en algemeen oogt even op te zoeken voordat je het merget, en in CI een licentiecheck op je dependencies mee te laten draaien.
Wat je bijhoudt
Spreek af of je AI-hulp in commits zichtbaar maakt. Claude Code zet standaard een attributieregel in commits en pull requests, en met de instelling attribution pas je die aan of zet je hem uit. Kies één lijn voor het hele team, anders zegt de git-historie er niets over.
Houd ook gebruik en kosten bij. Claude Code kan via OpenTelemetry metrics exporteren, zoals sessies, tokens, kosten, commits en pull requests. De tekst van prompts zit daar standaard niet in. Dat vind ik een goede standaard: je ziet wat het kost en hoe het gebruikt wordt, zonder mee te lezen met elke vraag van een developer.
Komt er een bug in productie uit code die een tool schreef, noteer dat dan in de nabespreking en scherp de regels in CLAUDE.md aan, zodat de tool dezelfde fout niet nog eens maakt.
Bronnen
Veelgestelde vragen
Mag een developer Claude Code gebruiken op de code van een klant?
Ja, als de klant daarmee akkoord is en het team met zakelijke accounts werkt. Leg in de repository vast wat de tool niet mag lezen en laat alle code door dezelfde review gaan.
Hoe voorkom je dat een AI-codeertool secrets leest?
Houd productiesleutels buiten de repository en buiten de lokale omgeving. In Claude Code voorkom je met deny-regels in .claude/settings.json dat de tool bijvoorbeeld .env-bestanden leest.
Traint Anthropic of GitHub modellen op mijn code?
Anthropic traint standaard niet op de invoer en uitvoer van zijn zakelijke producten. GitHub gebruikt sinds 24 april 2026 interactiedata van Copilot Free, Pro en Pro+ voor training, tenzij je dat uitzet. Copilot Business en Enterprise vallen daarbuiten.
Over de auteur
Milos
Tech lead en vestigingsmanager, Novi Sad
Milos leidt ons kantoor in Novi Sad, technisch en als vestigingsmanager. Hij is software- en AI-engineer met tien jaar ervaring.
Meer van Milos
