Field notes · AI · Process

How to onboard your team to AI development

Most AI rollouts stall at the same place, licenses get bought, a Slack channel gets pinned, and three months later nothing has changed. Here's what I do instead.

9 min read·Jan 2026·AI / Process

I've now run this rollout four times across different teams at Vacuumlabs: backend Kotlin shops, frontend React teams, a full-stack tribe in wealth management. The playbook is largely the same. The order matters more than the tools.

The five stages, in order

1. Make it work on your own machine first

Before you put a single rule in front of the team, prove to yourself that the system is good enough to ship production code on the project you're about to onboard. Spend a week pair-coding with the AI on real tickets, not toy examples. If you can't comfortably ship a feature this way, you cannot ask the team to.

2. Write the rules, but write them small

Rule files (whether they're .cursorrules, repo-level AGENTS.md, or whatever your tool calls it) should be the team's shortest document, not the longest. The goal is to fit the project's actual conventions and a handful of non-negotiables: testing style, error handling, the one weird thing about your domain model. If the rules sprawl, the AI ignores them.

Rule of thumb

Rules under 60 lines. If you're past that, you're either documenting common sense (skip it) or compensating for a bad codebase (fix that instead).

3. Pick the right first ticket

Don't make the first AI-assisted PR a refactor or a green-field feature. Pick something boring but real: a CRUD endpoint, a form, a small bug fix in a system the team knows cold. The point is to build the muscle memory of review, refine, ship, not to impress anyone.

4. Run the workshop, then watch the code

I run one 90-minute hands-on workshop with the whole team, where everyone takes a real ticket and works through it together. Then I disappear for two weeks and review every AI-assisted PR personally. The two weeks of close review is where the rollout actually happens, not in the workshop.

Things I look for:

Tests that look right but don't actually assert the thing
"Defensive" code added to handle errors that can't happen in our system
New abstractions for problems we don't have
Imports from libraries we don't use
The model "agreeing" with bad first drafts the developer didn't push back on

5. Standardize the parts that paid off

After a month, look at what worked and codify it. Maybe it's a project-level template for new endpoints. Maybe it's a "review checklist" for AI PRs. Maybe it's just a Slack canvas with three commands the team actually uses. Whatever pays off, write it down so the next person doesn't have to discover it.

The mistakes I made the first time

I trained on demos, not work. The "wow" moment doesn't transfer.
I wrote 400 lines of rules. Nobody read them. The model didn't follow them either.
I let people opt out. "Use it if you want" becomes "nobody uses it" within three weeks. Make it the default; let people opt out individually with a reason.
I underestimated review time. AI-assisted PRs need more reviewer attention, not less, for the first month. Plan for it.

What you're really teaching

The skill isn't prompting. The skill is recognising, in 30 seconds, from a diff, when the model has gone off the rails, and pulling it back.

Once the team has that reflex, the productivity curve becomes interesting. Until then, you're just generating more code than you can review, which is worse than not using AI at all.