You Are One Step Lower Than You Think: Auditing Your Own AI Adoption

Ask a developer how deep they are into agentic coding and you will get an answer about tools. Which model, which editor, how many terminal tabs. Ask them whether they are getting more out of it than they were three months ago and the answer turns to vapour.

I had the same problem with my own work, and it was worse than vagueness — it was directional. I consistently believed I was one step further along than the evidence supported, because I was counting the things I had set up rather than the things I actually relied on. A scheduled agent existed, so surely that counted. A connector was configured, so surely context was flowing. The setup was real. The reliance was not.

So I wrote a small skill that answers the question by reading the repository instead of asking me. It takes about a minute and it has never once flattered me.

The ladder

The framing comes from Boris Cherny’s “Steps of AI Adoption,” and its value is that each step is defined by what breaks, not by what you own.

Step	Agents in flight	Your role	What the bottleneck becomes
0 Gated	0	—	approval processes
1 Assisted	~1	pair reviewer	your attention, and low trust
2 Parallel	~10	orchestrator	reviewing N streams of diffs
3 Supervised autonomy	~100	manager of managers	trust in the loop, decision throughput
4 AI-native	1000+	steer by intent, monitor by exception	per-work-type guardrails at scale

The interesting column is the last one. Moving up does not relieve the bottleneck, it relocates it — which is the whole reason the steps are worth distinguishing. At Step 1 you are rate-limited by how fast you can read code. At Step 2 you are rate-limited by how fast you can review several parallel diffs, which is why the transition is not “run more agents” but “build something that reviews for you.” At Step 3 the constraint stops being technical altogether and becomes trust: work starts without you dispatching it, and either you believe the results or the whole arrangement is theatre.

The transitions are concrete, which is what makes them auditable:

• 1 → 2: parallel agents in isolated worktrees, a self-verification loop you actually trust, auto mode, and automated review.
• 2 → 3: scheduled loops and routines, agents kicking off other agents, context pulled in rather than pasted in (tickets, docs, connectors), and a permission envelope wide enough that the agent is not blocked on you every four minutes.
• 3 → 4: domain-scale automation — migrations, fuzzing, remediation — with per-workflow cost caps.

And the role description at Step 3 is the line that reframed the most for me. The question you ask about a piece of agent work stops being “did you read the code?” and becomes “what context was the model missing?” That is a different job. It is the difference between reviewing output and improving the conditions that produce output.

Why this had to be a skill and not a checklist

I tried the checklist. I had it in a note for a while. The problem with a checklist is that you are the one filling it in, and you fill it in from memory, generously, at the end of a good week.

Three properties make the automated version worth the trouble.

It reads the repo, not your self-image. It checks the permission allowlist in the actual settings files and reports which file holds it. It checks .mcp.json for declared servers and then makes one cheap read-only call against each to see whether the auth is live — a connector that is configured and expired scores as open, because functionally it is. It greps the last fifteen commit bodies for agent trailers, not --oneline, which strips exactly the evidence you need. Where a signal genuinely leaves no artifact — parallel worktree use leaves no trace in git — it says so and asks, rather than inferring.

Banking is strict. A step is banked only when every one of its transition items scores done. Three out of four is not “Step 3, partial.” It is Step 2, and the report says so in that shape: “Step 2 banked; 2→3 3/4 done.” This sounds like pedantry and is the single most useful rule in the thing. Partial credit is how you end up believing you are somewhere you are not, because partial credit is the language of self-assessment and every unfinished item sounds nearly finished.

It remembers, per project. Each run writes back to that project’s memory: the status line with a date, the evidence snapshot, the open items. So the next run is a diff rather than a fresh guess, and the question “did anything move since June?” has an actual answer. That memory also carries a section titled Decided AGAINST — do not re-propose. If I have evaluated a practice and ruled it out for good reasons, I want it to stay ruled out. An assistant that re-pitches a rejected idea every month is not being helpful, it is being expensive to say no to.

The per-project part matters more than I expected. I am honestly at different steps in different repositories, and averaging them into a single personal “level” destroys the only information worth having. A mature service with test coverage and a wide permission envelope supports unattended work. A two-week-old prototype does not, and should not. Same developer, same tools, different rung.

What it actually catches

Infrastructure counted as progress. This was my own failure mode and it is the one the skill is most opinionated about. A scheduled routine existing is not Step 3. Step 3 banks on trusted unattended results. So the skill checks that the routine exists, is enabled, and has a sane next run — and then stops, because the remaining question is one only a human can answer: were the recent reports accurate and useful? Nothing in a repository can answer that. If nobody has graded them, it is not banked, and no amount of green configuration changes that.

Things that look configured and are not. The auth probe catches connectors that were set up once and have quietly stopped working. Cheaper to find this way than during the work you were counting on them for.

Scope leakage. MCP tools visible in a session might come from user-level config or another project entirely — they are not evidence about this repository. Restricting the audit to the current project’s own files, memory, and triggers is a constraint that had to be written down explicitly, because the tempting mistake is to let a well-equipped session flatter a bare repo.

There is also a failure mode in the other direction, which took a couple of runs to correct. Early versions treated a young project’s missing infrastructure as a deficiency and produced a report that read like a telling-off. That is useless. For a fresh repo the correct output is “Step 1, and here is the shortest path to 2” — a starting position, not a shortfall.

What you get out of it

An honest step, with evidence attached to each claim — a file path, a trigger ID, a git reference — so you can disagree with any individual line rather than with a verdict. A scored table of the next step’s requirements, so the target is a list of four specific things instead of a vibe about being behind. And three ranked next moves, ordered by trust earned per unit of effort, which is the right ordering because trust is what the upper steps are actually made of.

The reframe is worth more than the score. “I feel like I should be doing more with this” is an anxiety and cannot be acted on. “Automated review is open, and it is the last item between me and Step 2” is a task for Tuesday.

The skill is short — one Markdown file, the ladder embedded in it so it never wastes a turn re-fetching anything. It is public as a gist, with the install path and notes in the README. Drop it in ~/.claude/skills/adoption-check/ and it works in every project you open.

Run it somewhere you feel good about. That is where it is most informative.