AI Readiness Assessment for Engineering Organizations

TL;DR: "Is my organization ready for AI?" is not a survey question - it's a repo question. Readiness is your org's capacity to absorb AI-generated volume: whether review, tests, knowledge distribution, and docs can catch what generation multiplies. All seven factors below are measurable from git and delivery history today, at zero adoption, and they compose into a verdict you can defend to a board. That beats a maturity-model workshop by every metric except billable days.

The question boards are actually asking

When a board or CEO asks "are we ready for AI?", they're rarely asking whether the team has licenses. They're asking whether the money about to be spent will compound - or whether it will land on an org that turns generated volume into rework, incidents, and a codebase nobody can explain.

That fear is well-founded in the data. DORA's 2024 report estimated that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, even while individual productivity and satisfaction rose. Faros AI's 2026 AI Engineering Report found bugs per developer up 54% where AI adoption ran high. Same tools, wildly different outcomes across orgs. The variable is the org the tool lands in.

So the readiness question has a precise form: can this organization absorb AI volume? Absorption is measurable.

Readiness is not adoption

The most common failure mode in "AI readiness" content is measuring enthusiasm: seats, active users, survey sentiment, a maturity ladder with "AI-first culture" at the top. All of that measures appetite. None of it measures digestion.

The honest split:

• Adoption - how much of your shipped work involves AI. Measurable, useful, and covered in how to measure AI adoption.
• Readiness - whether your quality system survives what adoption multiplies. AI's documented failure pattern is volume-shaped: GitClear's 623-million-change dataset shows duplication up 81% and refactoring line-moves down about 70% as generation scaled. Volume-shaped problems are caught by exactly the systems readiness measures: review, tests, ownership, docs.

An org can be highly adopted and dangerously unready - that's the DORA/Faros signature above. It can also be fully ready at zero adoption, which is the best possible position to buy from.

The seven factors you can score from your repo today

Each factor is a repo- or delivery-level stat. No surveys, no self-assessment, no workshop.

1. Review safety net

What share of merged PRs got a real review? Review is the layer that catches generated code before it ships, and it's the first thing volume overwhelms. If review coverage is already porous at human volume, AI volume will not improve it. This is the heaviest factor in any honest weighting.

2. Reviewer bench depth

How many distinct reviewers does a typical author actually have? A review system that routes everything through one senior is a single point of failure that AI volume converts into a bottleneck or a rubber stamp - usually both, in that order.

3. Regression discipline

What share of recent work is regression-shaped rework, meaning code shipped and then re-edited shortly after? This is your baseline churn hygiene, and it predicts what happens when generation accelerates. An org already on the rework treadmill is about to buy a faster treadmill.

4. Knowledge distribution

If AI writes code nobody deeply owns, in a codebase where knowledge is already concentrated, you're compounding two bus-factor problems. The truck-factor research found 34% of 133 studied systems had a truck factor of one, where a single person's departure orphans the system. Check your bus factor and the blast radius of your most critical person before adding a code author who can't be pulled into an incident channel.

5. Documentation readiness

Two parts. Classic docs coverage and freshness, because docs are how humans absorb code they didn't write. And a new, AI-specific stat: AI context files (CLAUDE.md, agents.md, cursor rules). Coding agents read these to learn your conventions; a repo without them makes every agent a new hire with no onboarding, forever. Documentation is the only readiness factor that got more important because of AI.

6. Test safety net

What share of changes touch tests? Tests are the automated half of the absorption system: the layer that scales with volume for free, which review does not. Generated code merging into an untested area is unreviewable in the only sense that matters: nothing will notice when it breaks.

7. Delivery observability

Do you actually deploy often enough to notice damage quickly? A team shipping monthly finds out what AI volume did to them monthly. Deploy frequency is the feedback-loop speed of every other factor on this list: the DORA logic, applied to AI absorption.

Turning seven factors into a verdict

A pile of stats is not an assessment; an assessment takes a stance. The method that works:

1. Judge each factor against explicit bands. Write down what "healthy review coverage" or "acceptable regression share" means, so the judgment is inspectable rather than vibes.
2. Weight the factors and say the weights out loud. Any weighting is an editorial stance. Reasonable experts put review first and observability last; what matters is that the stance is disclosed and arguable instead of hidden inside a black-box score.
3. Cut the composite into a verdict (ready / nearly / not yet), so the output is a decision aid instead of another dashboard tile.
4. Refuse to guess. If too few factors are measurable (no deploy data, no docs signal), the honest output is "not enough evidence," listing what's missing, never a score laundered from partial data.

What a readiness assessment is not: a screen of individuals (readiness is a system property; no factor above is a person score), and not a maturity-theater survey where the org grades its own homework.

If the verdict comes back ready, your next questions are operational: measure adoption as it climbs and check whether the code is holding. If it comes back not yet - congratulations, you just saved a year of seat spend from landing on an org that would have converted it into rework. Fix the red factors first; the tactical pre-flight list for the team level is in the AI coding readiness checklist.

Running the assessment without building it

Everything above is computable from git plus your delivery data, if you want to build the pipelines, band the stats, and defend the weights yourself.

Or connect your repos and get it computed: Busfactor's AI-readiness verdict scores exactly these seven factors from your actual history - review safety net, reviewer bench, regression discipline, knowledge distribution, documentation (including AI context files), test touch, deploy frequency - judges each against disclosed bands, and returns ready / nearly / not yet with every underlying number quoted and linkable. It's answerable at zero adoption, which is precisely when it's worth the most. It sits on the same surface as the adoption and impact metrics, so the day you do scale AI, the before/after is already instrumented.

The honest limits: the factor weights and verdict cuts are an expert-set editorial stance, disclosed on the surface, not an industry-certified standard, and calibrated against early data rather than a thousand-org benchmark. And if your org doesn't produce enough signal to measure at least a minimum set of factors, you get the missing-factor list instead of a verdict. We'd rather tell you what we can't see than invent a score.

Readiness before spend. It's the least exciting AI decision you'll make this year, and the one most likely to survive the postmortem.