Adoption without a mandate
How this actually spreads through a team, and the three ways organisations get it wrong.
Individual practice is most of this course. Teams are different, because the constraint stops being your own skill and becomes shared standards, review capacity and trust between people.
The three failures
1. The mandate. Leadership announces that everyone will use agents, sets a usage target, and measures adoption. What follows is compliance rather than practice: people run a session to satisfy the metric, learn nothing, and the sceptics get evidence for their position. Usage is not a goal; it is a side effect of the tool being useful.
2. The prohibition. The opposite, usually on security or quality grounds, and usually made without answering the four data questions from module 08. People use it anyway, on personal accounts, outside any policy — which is the worst of both worlds: no shared standards, no review, and no visibility.
3. The free-for-all. No standards at all. Everyone develops their own practice, the codebase fragments into several styles, review burden rises, and within a quarter somebody proposes a mandate or a prohibition.
What works instead
Make the good path the easy path. The toolkit from module 03 is the mechanism: a fast check command, a project brief, a /task command, hooks that block the obvious mistakes. A newcomer who runs an agent in that repository gets your conventions without being told anything, because the repository enforces them.
This is the whole strategy in one sentence: put the practice in the repository, not in people's heads. It scales, it survives turnover, and it requires no mandate.
The sequence that works
1. one person gets good at it, quietly, on real work 2. they build the repo toolkit because it helps them 3. others use the repo and inherit the practice by accident 4. someone asks how a diff got produced that fast 5. show them - one session, on their task, not a demo 6. the standards conversation happens because it is now needed, not because someone predicted it would be
Step 5 is the one that converts people. A demo on a toy repository persuades nobody; twenty minutes on the thing they are actually stuck on persuades most people.
The standards worth agreeing early
Not many. Four, and they are all about the code rather than about the tool:
- Review requirements, by area rather than blanket — the narrowing from module 08.
- The definition of done is unchanged: a green check and a reviewed diff, regardless of who or what wrote it.
- Authorship is irrelevant to standards. Generated code meets the same bar as typed code. No special exemption, no special suspicion.
- Data handling, answered once, in writing.
Everything else — which harness, which model, how someone structures their sessions — is personal and should stay that way.
The disclosure question
Teams ask whether agent-written code should be labelled. The practical answer is no, and the reason is principled: if generated code needs a warning label, it is not meeting the bar. Either it is the author's work, reviewed and understood and owned, or it should not be merged.
What is worth recording is the opposite: when someone has not fully reviewed something, and why. The honest review note from module 06 is more useful than a blanket authorship label.
Where the friction actually appears
Not in adoption. In review. One person going from three pull requests a week to eight does not change much; four people doing it saturates everyone's review capacity in a fortnight, and the symptom is rubber-stamping rather than complaint. Watch review depth, not adoption, and the rest of this module is about what to do when it falls.
Exercise
Do the repository half rather than the conversation half: build the toolkit in a repo your team shares, commit it, and say nothing about it.
After two weeks, check whether anyone's sessions improved without being told. Then have the standards conversation, using what you both observed rather than what you predicted.
Worked solution
A team of six. One person had been working this way for a few months; nobody else had a consistent practice.
npm run check 3m40s -> 9s, split into fast and full tiers AGENTS.md 41 lines, written from my own correction log /task command the seven-part opening pre-commit hook blocks suppressions and skipped tests 3 lint rules the conventions I corrected most often
Two weeks later, without being told anything: - three people's agent diffs stopped violating the Result convention, because the lint rule caught it in their own check loop - one person found /task by typing "/" and had been using it daily - the pre-commit hook fired 14 times across the team; every time the person fixed the underlying problem rather than bypassing it - one person asked, in the team channel, "why is check so much faster now" - which was the opening for the conversation
Agreed in 25 minutes, because it was about things people had observed:
- review required on auth, payments, migrations, public API
(enforced by CODEOWNERS, not by policy)
- definition of done unchanged
- no authorship labelling; the honest review note instead
- data: no production data in sessions, and the anonymised dev
dataset became a shared piece of work
Not agreed, deliberately: which harness, which model, how anyone
structures their own sessions.The contrast worth noting: a colleague at another company ran the mandate version in the same period — a target of "three agent-assisted PRs per week per engineer" — and six weeks later had hit the target, had no shared conventions, and had two engineers who were now firmly against the whole idea.
The difference is not the tooling. It is that in one case the repository made the good path easy and the conversation followed the evidence, and in the other the conversation came first and the evidence was manufactured to satisfy it.
Takeaways
- Put the practice in the repository, not in people's heads — it spreads without a mandate and survives turnover.
- Agree four things: review by area, definition of done, no authorship exemption, and data handling.
- Do not label generated code; record instead what was not fully reviewed.
- Watch review depth, not adoption. Saturation shows up as rubber-stamping, not complaint.
Check yourself
Why does a usage mandate reliably produce worse practice than a well-tooled repository?
Usage is a side effect of the tool being useful, not a goal. Measuring it inverts the causality: people produce the measured behaviour without the underlying practice, and the resulting bad experiences become evidence against the whole approach.
A course by Pieter Zandbergen