We now run coding agents against most of our projects. The interesting finding was not about the agents. It was that the projects which were already disciplined needed almost nothing done to them, and the ones that were not could not be fixed by better prompting. What an agent needs is what a competent new engineer needs, with none of the tolerance for ambiguity.
An agent cannot ask a colleague which environment variable is missing. If getting to a running application requires local knowledge, the agent will not get there, and neither will your next hire.
One command should produce a working application with realistic data and known credentials. That is the entry requirement, and it is worth noting how many teams cannot currently meet it.
This is the whole feedback mechanism. An agent proposes a change and needs to know whether it broke something - within seconds to low minutes, not twenty.
Determinism matters more than usual here. A flaky test is confusing to a person and actively destructive to an automated loop: the agent sees a failure, changes something unrelated to fix it, and now you have a spurious change alongside a real one. Retries paper over this and make it worse, because the signal is now noise with a filter on it.
Written conventions get followed inconsistently - by people and by agents. Enforced conventions get followed always.
Anything that genuinely matters should be a lint rule, a custom cop, a failing test, or a CI gate. Anything that only exists in a style guide will drift, and it will drift faster now because the volume of change is higher.
This is where the local rules earn their keep - the pattern this team has agreed not to use, the helper that must be used instead of the raw call, the scope that must not be bypassed. A rule that fails the build teaches an agent immediately. A rule in a document does not.
Every project should carry a document describing what it is, how it is structured, the decisions that are settled, and the things that look wrong but are deliberate.
That last category matters most and is almost never written down. Every codebase contains choices that appear to be mistakes and are not - the unusual index, the duplication that exists for a reason, the abstraction deliberately not introduced. Without that written down, an agent will helpfully "fix" them, and so will a new engineer in their second week.
The most valuable section is not what the code does. It is which apparent problems are actually decisions.
Tasks need to be shaped so success is checkable. "Improve performance" is not a task. "This endpoint issues N+1 queries when loading the list; make it constant and prove it with a query-count assertion" is.
The shape that works is the same one that works for delegating to a person: a defined outcome, a way to verify it, and a boundary. The difference is that a person will push back when the task is underspecified, and an agent will confidently produce something.
Across our projects the retrofit was small - writing down the deliberate-decisions section, promoting a few conventions from documentation into enforced rules, and tightening a handful of slow tests.
What we did not do is more instructive. We did not restructure code to be more agent-friendly, adopt different patterns, or add abstraction layers. The properties that make a codebase workable by an agent are the properties that make it workable at all, and a project that needs substantial changes to accept an agent is telling you something about itself rather than about the agent.
Worth being straight about the limits. Agents are strong on well-specified, verifiable, contained changes. They are weak exactly where the difficulty is deciding what should happen rather than implementing it - a payment structure that needs restructuring, a schema whose model of the business is wrong, a decision with commercial consequences.
Those are the parts worth a senior engineer's attention. The value of getting the mechanical parts automated is that there is more attention left for them.
We run agents against our own projects and prepare client codebases to accept them. If your team is trying and finding it more trouble than it is worth, the cause is usually in the four requirements above.