Your codebase was not written for agents.

A team carries its codebase in its head. Where things live. Which command runs the tests. Which folder is dead and which one only looks dead. What not to touch. A coding agent arrives with none of that. It reads what is written down and works from there.

That is why the same agent does well in one repository and badly in the next. The agent did not change. What it was given to work with did.

The model is not the problem.

When agent work disappoints, the model gets the blame, and the fix people reach for is a newer model or a longer prompt. Both help at the margin. Neither changes what the agent can find out about your project.

Picture one task in two repositories: add a field to an API response. In the first, the README names the entry point, an instruction file says how routes and tests are laid out, and one command runs the test suite. The agent reads, edits three files, runs the tests, and reports a result it has checked.

In the second, there are two folders that both look like the API, no instructions, and tests that only pass on one engineer's laptop. The agent picks a folder, copies the nearest pattern it can find, cannot run anything, and reports success anyway. A person then spends an hour finding out which half of that was true.

Same model. Same prompt. The repository decided the outcome.

AI readiness and agent readiness.

"AI readiness" usually describes a whole organization: its data, its skills, its policies. For an engineering team, it comes down to something much more concrete. Can an AI coding agent do useful work in this repository without a person standing behind it filling in the gaps?

That property is agent readiness. It belongs to the codebase, so it can be inspected, improved, and checked again. It also carries over. A repository that is ready for one coding agent is ready for the next one, whichever tool your team picks up next year.

What an agent needs from a repository.

A way in. What the application is, how to set it up, and where execution starts. Folder names that match what is inside them. One obvious place for each kind of code. When there are two plausible places, an agent has no way to know which is current, and it will not ask.

Written instructions. An AGENTS.md or similar file that states the conventions, the commands, and the boundaries: how things are named, where new code goes, what must never be edited by hand. Instructions also have to be true. An agent follows a stale instruction exactly as faithfully as a correct one.

A way to check its own work. Build, lint, type, and test commands that exist and run. This is the part that turns an agent from a writer into an engineer. With a working check, it can try something, see it fail, and fix it before you ever look. Without one, every claim of "done" is a guess that you have to verify yourself.

The codebase underneath.

Navigation and instructions get an agent started. What it produces depends on what it finds, because agents learn a project by imitation. They copy the patterns already in the code.

If the same job is done three different ways, the agent picks one, and now it is done four ways. If a feature is a stub that returns fake success, the agent builds on it as if it were real. If errors are swallowed in the code it reads, they are swallowed in the code it writes. If a credential sits in a source file, that pattern gets repeated too.

So readiness reaches past the entry points into the things a careful engineer would check anyway: system design and the boundaries between services, documentation, tests behind what the application claims to do, security, how failures are handled, and whether a failure leaves any signal behind. Gaps in the foundation become gaps in everything built on top of it, and an agent builds quickly.

What it costs when the repository is not ready.

The costs are easy to miss because each one looks small.

The agent rediscovers the project on every task, spending tokens to work out where things are before it does anything. It takes wrong turns that look reasonable. It produces changes that nobody can verify, so review moves from "is this a good idea?" to "does this even work?", which is the slowest kind of review there is. And some of the work gets thrown away and done again.

None of that shows up as a failure. It shows up as agents being slower and less trustworthy than the demos promised.

Where to start.

Order matters, and most teams start in the wrong place by writing a long instruction file first.

Start with the feedback loop. Make the build, lint, type, and test commands run from a clean checkout. Until an agent can check itself, nothing else you improve can be confirmed.

Then write the instructions. Keep them short and specific: the commands you just fixed, the conventions that are not obvious from the code, and the things that must not be touched.

Then clear the way in. Setup steps, entry points, and any place where two folders compete to be the real one.

Then work down the deeper gaps, highest risk first: the stub that pretends to work, the missing error handling, the tests that do not cover what the product claims.

Find out where you stand.

Most teams do not know how ready their repository is. They find out one bad agent run at a time.

Agent readiness reads your source. Nothing is executed. It reports what is in place, what is missing, and what it could not see, and each finding points at the file and line it came from.

Then it gives you an ordered plan: what to fix first, what to confirm, and what is optional, written so you can hand it to your coding agent. Run it again after the changes and compare.

What's still yours.

Readiness does not decide what to build. It removes the reasons an agent gets it wrong.

"What should this product do?" is a human question.
"Where is the test command?" should never be one.