AI Readiness Assessment: Is Your Codebase Ready for Agentic Coding?

Most AI readiness assessments measure the wrong things. They score your organization on strategy pillars, data readiness, AI skills, and change management, giving you a maturity score and an adoption roadmap that say nothing about whether AI can safely touch your actual product.

For a software company, readiness for AI lives in five engineering assets: the repository, the documentation, the test suite, the tickets, and the review process.

If those assets are not prepared for it, agentic coding will produce confident-sounding messes. No amount of organizational maturity can fix that.

At SWARECO, we manage this transition for our clients on Rails, React, and React Native. We published the full framework in Walls and rails for agentic coding. This is the version for buyers: what an assessment should check, what it required on real teams, and how long it takes.

What Is an AI Readiness Assessment for an Engineering Team?

An AI readiness assessment for an engineering team audits whether your codebase, docs, tests, tickets, and review process are structured for AI coding tools to produce work you can trust. It answers a single question.

If an AI agent opened your repository tomorrow, would it ship a safe change, or would it invent assumptions, ignore your conventions, and report success anyway?

This is a different exercise from the enterprise AI readiness frameworks sold by consultancies. A typical AI readiness assessment framework evaluates organizational pillars: AI strategy and business goals, data readiness and data quality, AI infrastructure, talent, governance, and security and privacy. It then assigns maturity levels and an AI readiness score, much like the Cisco AI Readiness Index or a TDWI checklist.

Those dimensions matter if you are deciding whether to fund AI initiatives. But they assess whether your organization is ready to buy AI. Our assessment determines whether your engineering assets are ready to use it. A company can score "mature" on every pillar and still watch its first AI-generated pull request break production. For software companies, that is where the business value of AI adoption is won or lost.

Why AI Fails on Pre-AI-Era Codebases

The failure mode isn't an agent that writes bad code. It is an agent that tells you something false in a completely reasonable tone.

Here is a real example from our own rules files. We had a repository with 204 spec files, and 29 of those were browser system specs running against headless Chromium through Playwright. A fresh AI session looked at the app, failed to find the test setup where it expected it, and concluded the project had no browser testing. It then articulately proposed the wrong kind of test for a JavaScript bug.

The fix was one sentence in the rules file.

"This repo HAS JS-driven system specs. Do not claim otherwise."

Teams without this kind of scaffolding tell us the same thing. They say their project isn't ready for AI coding without a human watching every line. AI-only pull requests ship with bugs, drift from the codebase's patterns, or miss the ticket's goal entirely. This is not a tooling problem. It is a readiness problem — the repo does not state its own facts, the tests cannot catch a wrong change, and the tickets do not define what "done" means.

The Five Assets an AI Readiness Assessment Actually Checks

This is the AI readiness checklist for an engineering team. It covers five concrete, measurable assets. Readiness gaps in these areas show up as failed AI projects, not as low scores on a survey.

1. A rules file the agent reads before touching anything.
SWARECO maintains eight CLAUDE.md files across client repositories for Rails, React, and React Native. The non-negotiable rules are identical in each one, while the rest is stack-specific. These files are living documents. Our largest Rails file grew from 33 lines to 252 across ten commits in 28 days, with every change attached to a ticket. The file explains itself through its git history.

2. Documentation that states facts, not just instructions.
About half of a good rules file contains facts about the codebase, not instructions. These facts are written down at the exact moment an AI session assumed otherwise, preventing the same mistake from being made twice. A model can only be as correct as what your repository tells it.

3. A test suite that makes AI changes safe to accept.
The rule is binary. Every change must ship with a test that exercises the real behavior. A bug fix ships with a test that fails before the fix and passes after. The full suite must run green before any merge. No placeholder or skipped specs are allowed — a file where every example is skipped reads as covered when it is not. Without this, you are approving AI output based on vibes.

4. Tickets an agent can actually execute.
One unit of work gets one ticket and one branch off a fresh main branch. Vague tickets produce drifting pull requests, a problem with humans that agents amplify. Our internal ticket-writing skill guide runs 402 lines, and most of it is tables of project facts: which issue types exist, which fields are never passed, and what a well-formed ticket for a specific project looks like.

5. A review bar that doesn't move.
CI is the only thing that can stop a merge. It was the gate before AI, and it remains the gate now. Our pull-request review workflow reads the same rules file a coding session does, so it enforces a written contract, not a reviewer's mood. Every review finding must be resolved before merging, either fixed or answered with a reason. Silence is not an answer.

How Long Does It Take to Make a Codebase AI-Ready?

The process takes weeks, not quarters. The work is incremental and per-repository, not a complete rewrite.

For one B2B SaaS platform we build and run — an API, a web frontend, and a mobile app — rules files went in across all three repositories in a single pass. We defined branch and commit rules, what a change must ship with, quality gates and how to run them locally, and which docs to read before touching an area. One improvement came from the engineering team within days: any change to behavior must update the rules file and docs in the same pull request. The documentation can never fall behind the code again.

For a legal-tech platform, readiness meant adding test-driven development sections to the rules files in both repositories. We also added an end-to-end testing section pointing to the Playwright suite's README as the single source of truth. This keeps the automated checks, the rules file, and the repository's real patterns consistent.

The honest sequence is this: the rules file and ticket shape come first and take days. Test coverage is the long pole. If a codebase has thin tests, that constitutes most of the readiness work, and it is worth it for reasons that predate AI. After that, scaling AI use is mostly copying the working contract and documenting each repo's facts. Successful AI adoption compounds, as every documented fact and every test makes the next AI-assisted change safer than the last.

That is also the honest metric. It is not how many engineers have an AI tools license, but what share of AI-assisted pull requests merge without a human rewriting them.

The Readiness Stack, Open-Sourced

SWARECO published its working setup as a public repository at github.com/SWARECO/dotclaude. It includes the CLAUDE.md skeleton with the working contract, a ticket-writing skill template, an audit command, and the pull-request review workflow.

This is the same structure running across our client repositories. It is tool-agnostic — the walls and rails shape any agent's behavior, whether the tool is Claude Code today or something else next year.

The same thinking applies to UI. A component library in Storybook gives an agent one place to see what already exists, so nothing gets invented twice. It also serves as the design source that AI design tools can build against accurately.

How SWARECO Runs an AI Readiness Assessment

Our assessment is read-only. We audit the five assets: repository facts, documentation, test coverage, ticket shape, and review gates. We score each against the framework we run in production to identify gaps, and we sequence them by what unblocks the most value.

The deliverable is a plan, not a report card. It outlines what to write down first, where the test suite needs scaffolding, and what your review process must enforce once code stops being typed by its author.

Then, unlike an advisory firm, we can build it with you. A discovery call ends with a scope, a timeline, and a budget, whether you choose to work with us or not.

FAQs

What is an AI readiness assessment?

For a software company, an AI readiness assessment audits whether the engineering assets — repository, documentation, tests, tickets, and review process — are shaped so AI coding tools produce trustworthy work. SWARECO scores each of the five assets against a framework it runs in production and sequences the gaps into a plan.

What are the pillars of AI readiness?

Enterprise frameworks typically measure six or seven pillars, including AI strategy, data readiness, infrastructure, talent, governance, and organizational culture, and grade each on maturity levels to identify gaps. For an engineering team, SWARECO's five pillars are more concrete: repository facts, documentation, test coverage, ticket shape, and review gates. The first set decides whether AI initiatives get funded; the second decides whether they work.

How is this different from an enterprise AI readiness framework?

Enterprise frameworks assess an organization's readiness to adopt AI. This assesses whether the codebase is ready to be worked on by AI — generative AI in general and agentic coding in particular. It prevents the common failure of AI-generated pull requests that ship bugs, drift from patterns, or miss the goal. Use cases and ROI models do not fix that, but the five assets do.

Do we need to rewrite our codebase to use AI coding tools?

No. Readiness is additive. You layer rules files, documented facts, test scaffolding, and ticket discipline onto the codebase you already have. SWARECO's largest rules file grew from 33 lines to 252 over 28 days of normal work. The codebase underneath was never rewritten. The only slow part is improving test coverage if it is thin, and that investment pays off regardless of AI.

Which AI coding tools does this prepare us for?

This prepares you for all of them, which is deliberate. The "walls" (no ticket no start, no test no merge) and "rails" (written facts about the codebase) shape any agent's behavior. SWARECO's engineers work with Anthropic's Claude Code under an unchanged review bar, and our open-sourced setup at github.com/SWARECO/dotclaude offers a tool-agnostic version of the same contract.