Most teams now have someone who has run a coding agent on something real. Far fewer have review and testing that hold for AI-written code, a way for a second person to do it, and an honest position on what it's good for here. That's the difference between a demo and a capability — and this guide is how to build it.
Haven't taken the check yet? Do that first — 14 questions, about four minutes. It scores you on the three areas below and tells you which one to fix first. Already have your result? Jump to your weakest area: Workflow · Guardrails · Fit & spread.
Three things to get right. A slick workflow with weak guardrails ships fast, unreviewed risk; strong guardrails with no workflow just add friction nobody uses. The rule underneath all of it: the person who prompted it owns the diff.
The check scores each and gives a combined grade from Experimenting to Fluent. The engagement, in a sentence: find the weak one and reinforce it first.
Workflow is whether directing the agent is a repeatable practice or one person's party trick. The test: could a second person start a session and get useful work out without re-explaining the codebase?
Get the basics in place: the agent installed and used by more than one person, and an agent-facing doc in each repo (conventions, how to run tests, what not to touch). Then run a short session on when to reach for it — and when not to.
The agent is used but the workflow is folk knowledge. Make "share what works" deliberate — a place for prompts and patterns — and teach the skill of stopping and redirecting the agent when it drifts, rather than starting over.
Keep the agent-facing docs current as the codebase moves, keep the shared patterns alive, and keep teaching new people the judgement of when to prompt versus when to type.
This is the risky one. Guardrails are what stop fast, confident output from becoming unreviewed risk in the codebase. They are non-negotiable, not optional.
Non-negotiables first: every AI-generated change reviewed by a human who understands it, the same test bar as hand-written code, and "the person who prompted it owns the diff" — its correctness and its security. Add scope control so the agent can't wander into secrets or prod config.
Review and testing happen but aren't consistent. Make AI-written PRs get extra scrutiny, make test coverage part of "done" for agent work, and add a standard security pass — injection, secrets, unsafe dependencies — not just for sensitive areas.
Keep the ownership rule enforced in review as speed tempts shortcuts, keep the security check standard, and keep scope control tight as more people use the agent.
Fit is whether this is a team capability or one leaver away from gone. The test: is there a shared, written view of what agentic coding is good for here — and what it isn't?
Right now this leaves if one person leaves. Get a second and third person capable, write down what the team has learned, and pull agentic coding into the real process — branching, review, CI — rather than a side channel.
It's spreading but not yet dependable. Open a safe path for non-technical people to use it for the right things (internal tools, prototypes) with guardrails, and agree an explicit position on what agentic coding is good for here and what it isn't.
Keep the shared "what it's good for" position revisited as the tools change, keep the non-technical path supported, and keep it inside the normal delivery process, not a fast lane around it.
If the weak area won't move — review keeps going light on AI PRs, it stays stuck with one person, it never joins the real process — that's the point to bring Jon in. Set up the workflow (agent installed, agent-facing docs, shared patterns), put the guardrails in (review rule, test bar, diff ownership, scope control, security pass), then spread it: pair-building on the live codebase until it lives in normal delivery.