The AI Readiness self-assessment

Your repository setup is the map an agent works from: how many repositories there are, where the boundaries between them run, and whether anything except somebody's memory keeps work on the right side of them. It has no picture of your estate other than the one it can read.

At its best the machine holds the shape, whichever model you run: scoped builds and enforced module boundaries in a monorepo, versioned and enforced contracts across many repositories, so crossing a boundary fails rather than merely being noticed. At its worst the structure accumulated rather than being chosen, is written down and nothing more, and holds only for as long as the right person reads the pull request.

This is how much of your system somebody has to read in order to change one thing. A module that needs five others read first costs a new engineer a week, and costs an agent its whole context window every session, because unlike your engineers it never builds the familiarity that makes a tangled module survivable.

At its best coupling and complexity carry a budget the build enforces, and that budget survives the release that wants to breach it. At its worst there is no number, and the only signal is which parts of the system people quietly avoid.

This is whether one concept has one name. An agent learns your vocabulary from your code and from nowhere else, so when four services call the same thing four different things, it learns all four as equally correct and then produces a fifth.

At its best the glossary is machine-checked: a banned synonym fails a lint rule, and a new public name is checked against the vocabulary before it merges. At its worst there is an accurate glossary that took real work, sitting on a wiki page nothing in the pipeline has ever opened.

Names fragment under change, in every system, always. Refactoring is the work that used to slow that down, and it is the first thing dropped when a deadline approaches. So this dimension is about the rate rather than the state: not how consistent the names are today, but which way they have been moving since last year.

At its best drift is tracked over time and the trend is what gets consolidation scheduled as delivery rather than requested as a favour. At its worst nobody could say whether the system is more coherent than it was a year ago or less, so the question gets settled by whoever sounds most certain.

A pipeline is a safety net only while people believe it. When red sometimes means broken and sometimes means unlucky, teams learn to press rerun, and they learn it long before AI arrives. Then the volume of changes goes up and that habit is the last thing standing between generated code and production.

At its best the flake rate is measured, driven down and enforced, so a red build is treated as information. At its worst nobody knows the flake rate, reruns are uncounted, and green gets rerun too, because the signal is not trusted in either direction.

A test does two things: it runs the code, and it says what the answer should have been. Coverage measures the first. Protection comes from the second, and that is the half a model cannot supply, because it can read what your code does and not what it was meant to do.

At its best something mechanical checks whether the tests catch faults, and the suite is judged on that rather than on how much code it touched. At its worst coverage is high, generated tests assert whatever the implementation happens to return, and the dashboard stays green over a regression.

Absorption is what happens after the merge: whether the change stays, whether a reviewer understood it, whether anyone outside engineering found out it happened. AI raises the amount of change arriving and leaves the capacity to absorb it exactly where it was, so the share of work that has to be done again is the first thing to rise.

At its best churn and revert rates are tracked on a cadence, and the number is allowed to stop a plan. At its worst code goes in, some of it quietly comes back out, and the effort spent on the second part is invisible to everybody deciding how much more to generate.

Technical debt is the work you already owe on the system you already have. AI does not pay it down. It draws on that debt faster, because generated code lands in the same tangles and the refactor that would have cleaned them up is the first thing dropped under delivery pressure.

At its best the debt is quantified in money, and that figure sits inside the plan for the acceleration rather than beside it. At its worst it is an engineering complaint, real to everyone who touches the code and absent from every document where the money is decided.

Every day a branch stays open, the distance between it and the trunk grows, and the cost of closing that distance grows with it. AI raised how much code changes in a day and left most branching strategies exactly where they were, so the merge that used to be fine is now a two-day job with real logic in it.

At its best branches live hours, because feature flags and fast tests make that possible and a rule makes it required. At its worst nobody knows the oldest branch, integration is an event near a deadline, and the conflicts arrive long after the person who wrote the code stopped remembering it.

Your delivery pipeline is a chain of stages and one of them has the least capacity. Double what arrives and that stage saturates first. Relieve it and the limit moves to the next. Waiting does not grow in proportion to load either: once a stage is busy, a modest increase produces a queue out of all proportion to it.

At its best the constraint is named, work in progress is capped by tooling that refuses new work past the line, and the cap moves when the constraint does. At its worst every stage looks busy, nobody can say which one is the limit, and capacity gets added where it is easiest rather than where it would help.

Your org chart decides which changes are cheap and which need three handoffs. AI raises what each team produces on its own, and it does nothing at all to the seams between them, so a feature crossing four teams gets faster inside each team and no faster between them.

At its best the boundaries are watched with numbers, they move when the numbers say so, and anyone who understands the domain can review a change inside it. At its worst ownership is fixed, every crossing waits for the one team allowed to touch that component, and the structure is revisited only in a reorganisation.

Review is where generated code meets human judgement, and routing decides whose. When every change in an area goes to the one person who owns it, tripling the volume does not triple that person. It lengthens a queue, and then it lowers the standard of what comes out of the queue.

At its best routing spreads review across people who genuinely know the area, and queue depth is watched, so a growing wait is caught before review becomes approval without reading. At its worst one name sits in a file, the queue behind it is invisible, and nobody learns how narrow it was until that person is suddenly unavailable.

An architectural decision is two things: the shape of the system, and the reason it has that shape. Only the first survives in the code. An agent asked to add a feature takes the cheapest route, straight across the boundary you drew, and it has no way to know the boundary was expensive, because the reason lived in a meeting.

At its best decisions sit in the repository beside the code, dated, superseded when they change, and a reviewer can point at one. At its worst they exist as slides, a chat thread and one person's memory, and the first change that finds them inconvenient quietly reverses them.

This is what a written work item leaves an agent to invent. An agent does not ask clarifying questions the way a developer does: it fills the gap with the most likely reading and writes confident, plausible code against it. The vaguer the item, the more confidently wrong the output, and the faster it arrives.

At its best an item cannot be pulled until it is a testable spec, and the check runs before the work starts rather than at review. At its worst items are a title and a sentence of context, and what finished means lives in a conversation that has not happened yet.

Most security lives in people. The engineer who knows tokens never go in local storage, the architect who remembers why this service signs its own requests. A model has no onboarding and no corridor conversations. It reads your code, and if three patterns for the same thing are in there, one secure and two historical, it treats all three as examples.

At its best the assumption exists once, as a canonical pattern with a scan that fails the build when something deviates. At its worst it is genuinely believed, genuinely important, and written nowhere a machine could find it.

Documentation used to have a repair mechanism built into its reader. A person who hit a step that no longer worked asked somebody, and the asking quietly held the whole thing together. An agent cannot ask. It reads your instructions as ground truth and generates confidently against a description that stopped matching reality in March.

At its best the load-bearing instructions are executed in the pipeline from a clean checkout, so drift turns the build red. At its worst the README is plausible, confident and four months stale, and nothing in the organisation would notice.

Every organisation has standards. Some are walls: the build fails, the merge is refused, the commit never lands. The rest are agreements, living in a wiki, in review habits and in what people remember on a good day. An agent absorbs none of the second kind, because it never sat in your standup and never read your wiki.

At its best the sort is a live practice, and the agreed column keeps getting shorter because the expensive entries move into the pipeline. At its worst nothing separates the two, so a documented standard and an enforced one feel identical in a meeting, and only one of them still holds during a night-time incident.

Architecture is a set of rules about what may depend on what. For decades a senior person held those rules in review, and it worked because of a ratio nobody had to think about: one human could read what one human could write. That ratio is gone. A clean change with green tests can invert a dependency your design forbids, and nothing refuses it, because the boundary was never in the build.

At its best a scoped check fails the build on a boundary breach, and the rule it enforces is small enough that people keep it rather than switch it off. At its worst the diagram is accurate, the reviewers are diligent, and the structure erodes one reasonable commit at a time.

Somebody used to choose every import. They weighed the licence, the maintenance, whether the project was alive. That habit made an import line boring, and reviewers learned to read it as plumbing. Now the import line is written by a model working from a frozen snapshot of the world, which sometimes names a package that does not exist and can be registered by somebody else tomorrow.

At its best imports are checked against the live registry and gated before they land, with a person accountable for the decision. At its worst the review reads the forty lines of logic carefully and approves without reading the one line that added an unknown package to production.

A release is where a change stops being yours and starts being someone else's problem. Your consumers depend on what they observed, not on what you documented, so a change that breaks nothing in your contract can still break them. Code generation raised how much you publish and left everyone downstream reading at the rate they always did.

At its best the visibility is engineered into the runtime: deprecation signals, alerts on a changed signature, notice that reaches consumers ahead of the change. At its worst the release note is accurate, clinical and useless, and the first person to notice a break is a customer.