Geschreven vanuit mijn eigen situatie: meerdere opdrachtgevers, code die niet van mij is. Als je in loondienst aan één codebase werkt, is dit minder urgent — maar lees de eerste twee kaarten wel.
1. Waar Claude Code wel en niet bij mag
Verplicht als je met klantcode werkt. Het gaat over het rechtenmodel en over prompt injection: inhoud die je binnenhaalt — een issue, een webpagina, een logbestand — kan instructies bevatten. Behandel dat als invoer van een vreemde, niet als opdracht. Bij mij komt dit neer op: geen productiecredentials in een sessie, punt.
2. Rechten regelen in settings.json
Als je bij elke `npm test` opnieuw toestemming moet geven, ga je op den duur alles goedkeuren zonder te kijken. Dat is het echte risico. Zet daarom bewust een lijst neer van wat zonder vragen mag, zodat de vragen die je wél krijgt betekenis houden. Projectinstellingen deel je met je team, persoonlijke houd je voor jezelf.
3. Alles toestaan, maar dan in een doos
Wil je zonder onderbrekingen werken, dan is een container met beperkte netwerktoegang een beter antwoord dan alles goedkeuren op je eigen machine. Ik werk zelf via SSH naar een aparte workspace, wat op hetzelfde neerkomt: gaat er iets mis, dan gooi ik hem weg. Op je laptop is dat geen optie.
4. Wat het kost, en waar het weglekt
Nuchtere uitleg over wat je verbruik bepaalt. De twee grootste lekken in mijn ervaring: sessies die uren doorlopen, en hele mappen die de context in gesleept worden omdat de vraag te breed stond. Beide los je op met de gewoonte uit de vorige kaart — kortere sessies, preciezere vragen. Niet met een instelling.
5. Claude in je pull requests
Claude Code als stap in je CI, zodat hij op een PR kan reageren of er een kan openen. Werkt goed voor kleine, duidelijk afgebakende klussen. Ik zou er geen architectuurbeslissingen aan overlaten en ik lees elke diff. Let op je rechten en op wie er commentaar mag plaatsen dat de actie kan starten.
