AI readiness is a spectrum across five stages — quality tools, clarify work, harden guardrails, reduce friction, accelerate. Most teams are at stage two or three and deploying stage-five tools. AI amplifies whatever it is applied to: a disciplined codebase gets faster delivery, a broken one gets faster defect generation. The readiness score tells you which one you have and what the next stage requires.
Every team we talk to says yes to AI agents. That is not the question that determines whether they see leverage or chaos. The real question is whether the codebase is in a state where agents will improve things — or just make existing patterns louder, faster, at a scale no reviewer can catch.
This post is about how to measure which one you have — and what it takes to move to the next stage.
The Question Teams Skip
"Should we use AI agents?" is not the question. Almost every team says yes, and they should. The question that actually matters: "What stage of readiness is our codebase at, and are we deploying tools appropriate for that stage?"
Most teams skip this. They go from "we should use AI" to "let's add seats, deploy an agent, run it in CI" without a readiness assessment. Then they wonder why lead time is going up while AI spend is going up simultaneously. The answer is almost always the same: stage-five tools on a stage-two foundation.
If your team ships slower since adding AI, fixes more bugs than before the tools arrived, or debates requirements mid-implementation — you are not at stage five. You are not even close.
The Five Stages
The sequence below is not a maturity model for its own sake. Each stage creates the preconditions for the next. Skip a stage and the next one either fails or actively makes things worse.
Stage 1 — Quality Tools. Before anything else: choose models that minimise rework. A model with a 20% error rate carries a hidden rework tax on every use. If rework exceeds 20% of AI-generated output, the tool is a net negative regardless of how fast it generates code. This stage is about measurement as much as selection — you need a rework rate number before you can make a defensible tool choice.
Stage 2 — Clarify Work. Use AI to improve requirements before code is written, not to generate code from vague requirements. Ambiguous requirements are the single largest source of defects. If your team is prompting agents with tickets that a human engineer would need three clarification questions to implement, the agent generates plausible-looking code that solves the wrong problem, consistently. The diagnostic: can you generate test cases from a ticket before writing any code? If not, the ticket is not ready for implementation.
Stage 3 — Harden Guardrails. Before accelerating code generation, the safety net must be in place. The diagnostic question: "If an agent violated our standards, would our pipeline catch it?" Ask that for each standard — style, architecture boundaries, security scanning, test patterns. If the answer is no for any of them, fix the guardrail before expanding agent use. An agent that can violate a standard without the pipeline catching it will do so — at the rate it generates code.
This is also where test design matters more than most teams expect. Agents copy existing patterns. A codebase with hundreds of tests that construct domain objects inline will produce the next test the same way. When the domain model changes, every one of those tests breaks at compile time — not because behaviour broke, but because test setup was welded to the current shape of the model. The agent can fix the failures, but you lose the signal on whether behaviour is actually preserved. Guardrails at this stage are not just pipeline gates. They are the patterns that make agent-generated changes verifiable.
Stage 4 — Reduce Friction. Remove the manual steps that create bottlenecks when code moves faster. Manual approval gates. Fragile environments causing intermittent failures. Branches that live longer than a day. Deployment that requires a runbook or a specific person. Each of these is a bottleneck that becomes acute when agents start generating code faster than the pipeline can process it.
Stage 5 — Accelerate. Now — and only now — expand agent use to code generation, refactoring, and autonomous contributions. The guardrails are in place. The pipeline is fast. Requirements are clear. The outcome of every change is deterministic regardless of whether a human or an agent wrote it.
One constraint stays human at this stage: test scenario definition. Humans define what to test. Agents generate the test code from those specifications. An agent that defines its own test scenarios will write tests its implementation passes — which is not the same as tests that verify behaviour.
Reading Your Score
A readiness score is not a grade. It tells you which stage you are at and what the next stage requires. Even a high-scoring codebase — 9.2 out of 10, for instance — has specific gaps worth closing before expanding agent scope. Those gaps matter more than the overall number, because agents exploit individual patterns at scale, not averages.
Most teams think they are at stage three or four. Most are not. Answer these honestly:
Stage 1: What is your rework rate on AI-generated code this sprint? If you do not have a number, you are not past stage one.
Stage 2: What percentage of tickets include acceptance criteria before development starts? Can an agent generate test cases from your average ticket without clarification?
Stage 3: Which standards in your codebase are enforced by the pipeline versus enforced by convention? For each convention-only standard: would the pipeline catch an agent violating it?
Stage 4: What is your lead time for a one-line change? What is your average branch lifetime? Is deployment automated or gated behind a person?
Stage 5: Are humans defining test scenarios before agents generate test code? Does every agent-generated commit go through the same pipeline as human commits?
Where you cannot answer with a specific number, that stage is incomplete.
Starting From Your Stage
The common mistake is trying to fix all five stages simultaneously. Pick the lowest stage where you have gaps and close one thing.
If stage one is incomplete: pick the AI tool your team uses most and measure the rework rate on what it generates — the percentage of output that requires non-trivial correction before it can be merged. That number is your baseline. Without it you cannot make a defensible tool choice or tell whether anything is improving.
If stage two is incomplete: start requiring acceptance criteria before any ticket enters development. Use AI to review them — if the AI cannot generate test cases, the criteria are not ready.
If stage three is incomplete: run the diagnostic question on every standard in your codebase. Add the first pipeline gate that answers "no." One gate added is a defect category agents can no longer exploit at scale.
If stage four is incomplete: measure branch lifetime and lead time first. The fix for slow pipelines is almost always reclassifying checks to a later stage, not optimising the existing ones.
If stage five has gaps: identify which specific patterns agents are copying that lack corresponding guardrails. Add the guardrail before expanding agent scope.
The principle: fix the lowest incomplete stage before expanding agent use. Adding more AI budget to a stage-two codebase does not solve a stage-two problem. It amplifies it.
The Bottom Line
Most teams are at stage two or three. Most teams are paying for stage-five tools. The gap between those two things is where AI ROI goes missing.
The question is not whether to use agents. The question is whether your codebase is at the stage where agents help or hurt. The five-stage framework tells you where you are. The diagnostic questions tell you what to fix next.
Start there.
