The hard part of Claude Code wasn’t Claude. It was Git.

The plan for our firm’s Claude rollout said no build work. Documentation and analysis only. Within weeks, the delivery team was using Claude Code on real work.

The plan was behind what people had already found useful. So governance had to catch up with what was already happening.

What we put in place

Three things, once we saw where the work had gone:

• A rules repository for Apex, Flow and tests, so Claude Code works to the firm’s standards, not to the average of everything it has read.
• The same standard for everyone. AI-assisted work is reviewed and tested to the same standard as work built by hand. No separate, lighter path.
• Production data read in place. Read-only, never exported.

The team added a caveat of its own, and it is the best rule in the set. Treat every AI diagnosis as a lead to confirm against the real data. Keep asking Claude to pull the records, not to accept a plausible story. A confident explanation is not a diagnosis until the data agrees with it.

What was actually hard

None of that was the hard part.

The hard part was Git. Most of the team build with clicks, not code. Claude Code works in repositories, with version control, branches and peer review. So the team was learning two things at once: a new AI tool and a way of working that developers take for granted. Two learning curves, stacked.

The number: forty-odd

Skills now copy automatically into every new repository, from a template. New work starts with the rules in place.

Existing repositories are another matter. There are forty-odd existing client repositories still to bring into line. That work is open. It is also the honest measure of where we are. The new work is governed. The history isn’t yet.

The lesson

The tool didn’t cause the gap. It made it urgent.

The team would have needed version control and peer review sooner or later. Claude Code made it now, because the work people wanted to do with it happens in repositories, and repositories need both.

What we would do now

Assume the plan is wrong about build. If the tool can do build work, someone will try it within weeks. Write the rules for that before it happens, not after.

Budget for the second learning curve. If your team isn’t already working in version control, the Claude Code training is the smaller half of the job.

And put the skills in the template from the start, so every new repository begins governed. The settings at the top of each skill decide where it will work, so check those before you copy them everywhere.

One thing to try this week

Ask your team one question, in the channel where they already talk: is anyone using Claude for work the plan says we aren’t doing yet? Don’t ask it as an audit. Ask it because the answer tells you where your rules need to be next.