What Is Agent DevEx? Developer Experience for AI Coding Agents

Your team has spent years making the repository pleasant for people to work in. Then coding agents started opening a growing share of the pull requests, and the usual developer experience work stopped predicting which tasks go well. A confusing test harness that a new hire absorbs in a week costs an agent something on every single run, because each run starts from a fresh context window and rebuilds its understanding from whatever the repository makes available. Agent DevEx is the work of closing that gap, and you can measure whether a change closes it.

What agent DevEx means

Agent DevEx is the practice of making a repository, its toolchain, and its feedback loop cheap for an autonomous coding agent to work in. It covers three jobs the agent does on its own. It has to find the context a task needs, run the project, and learn whether its change was right.

The term is new and people use it loosely. Agent experience, or AX, usually points at the same idea. Treat the definition above as a working one rather than a settled industry standard, and expect the vocabulary to keep moving for a while.

Prompt engineering and model selection are separate concerns. Agent DevEx covers the repository and the environment around it, which your team controls and which stays the same whichever agent your engineers run.

Agents and people want the same repository, right up until the session starts

Most of the foundations carry over. Fast builds let an agent check a change sooner, the same way they help a person. Reliable tests give both a trustworthy signal. A predictable project layout shortens the search for the right file. If your builds are slow and your tests are flaky, that is still the first problem, for both audiences.

The split shows up in four places.

Each run starts from a fresh context window. A developer who spent last quarter in the billing code carries that around. Coding agents can carry some learned context forward through their own memory features, but those are scoped to the tool and usually to one developer's machine. Anything your team knows and has recorded nowhere still gets rebuilt, or guessed at, on every run.

An unattended run needs an escalation path. Interactive coding agents can ask a person to clarify an undocumented constraint. A run with no available human and no configured escalation path cannot rely on that answer, so record the constraints that matter and decide when the agent should stop rather than guess.

An agent reads far more than it writes. Across 112 replayed sessions on the cal.diy repository, Dosu measured Claude Code moving about 198 tokens through its context window for every token it produced, and Codex about 134. Separately, that study attributed 67% of estimated cost to planning and context gathering. It does not establish how much of that work a repository change could remove.

An unstated requirement produces confident output. A person blocked by an unstated requirement can raise it. Code written against a requirement nobody wrote down can pass every test you have and still miss it. So a condition your team holds informally has to be encoded, as a test, a build check, or a recorded convention, before an agent can act on it.

Four surfaces your team controls

Agent DevEx improves when you change what the agent finds, what it can run, what it learns from running it, and what survives to the next session. Four surfaces cover most of it.

Instruction files. The file your agent reads on startup, AGENTS.md or CLAUDE.md depending on the tool, is where the build command, the test command, and the rules about generated code belong. Which file a given agent reads is a convention worth verifying per tool rather than assuming. The failure mode here is drift: an instruction file that describes last quarter's commands sends every session down a path that no longer works, which is why keeping it current matters more than making it long.

Environment setup. An agent that cannot install dependencies or reach the service it needs spends its session proving that. Take a clean checkout and see whether an agent can start the application and run one test without inventing a missing step.

Build and test output. A failure that names the file and the assertion gives an agent its next action. A command that exits zero while quietly skipping half the suite teaches it that a broken change is finished. Read what the agent saw after a test run before you conclude the agent reasoned badly.

Durable memory across sessions. Everything above is static. The decisions your team reaches while working are not, and they tend to stay in one developer's session history or a tool's local memory, which is not the same as the team sharing them. Giving a later session access to a verified convention is a separate problem from writing a good instruction file, with its own question of where that memory should live. The Model Context Protocol gives agents a standard way to reach an external source of that kind, which settles how an agent connects but not what you put there or who keeps it true.

How to tell whether it is working

The useful signal is how much of a session goes into orienting before the agent's first edit, measured against what it spends changing code. Watch that split across comparable tickets, and treat it as a baseline to move rather than a number to hit.

In the cal.diy replay, 46% of the money was spent before a single line of code was written, splitting as 43% for Claude Code on Opus 4.8 and 52% for Codex on GPT-5.5. Claude Code's orienting share also held near 44% as tasks got harder, while its average run grew 4.5 times from self-contained to cross-cutting tasks, from $1.11 to $4.96. In that sample, the cost of comprehension scaled with how much of the codebase a change required understanding. The study binned its tickets by that scope and did not separate it from diff size.

A second replay of 49 pull requests from vercel/ai, on Opus 5.5 and GPT 6.1 Sol, split each session at the first detected file edit and attributed 40.8% of Claude Code's estimated cost and 31.8% of Codex's to the stretch before it. Both studies are cost measurements on replayed public tickets rather than correctness benchmarks, and the numbers move with the model and the task mix. They establish the shape to look for, not a target for your repository.

So measure your own. Take a batch of comparable tickets, record the orienting split, change one surface, and run a comparable batch again. Check that pre-edit cost fell without a rise in failed tests or review corrections, since a cheaper session that produces worse code is not an improvement. If you want a fuller set of signals to instrument, coding agent metrics covers what to track beyond output counts.

FAQ

Is agent DevEx just prompt engineering under a new name?

No. Prompt engineering shapes one request to one model. Agent DevEx changes the repository and environment that every request lands in, so the improvement holds across tools, across engineers, and across model upgrades. The two complement each other.

Who owns this on an engineering team?

In practice it lands where developer experience and platform work sit, because it pulls the same levers, such as build times, test signal, environment setup, and repository conventions. Give it an owner who reviews agent sessions the way they review CI times.

Does improving agent DevEx help human developers too?

Usually, because most of it is ordinary hygiene that agents make expensive to ignore. Clear failures, a working clean checkout, and current documentation were always worth having. An agent pays for their absence on every run, so the cost shows up in your token bill.

How do we know a repository change helped and not a model upgrade?

You do not, unless you hold one of them still. Compare comparable tickets on the same model before and after the repository change, and re-baseline when you move models. Both Dosu replays found the orienting split shifting with the model and the task mix, so a comparison that changes several things at once will not tell you which one moved the number.

Start with your own sessions

Before you change anything, find out where your agents spend their time. On a machine with sessions in ~/.claude/projects or ~/.codex, these commands index those sessions into an unencrypted SQLite archive at ~/.decant/decant.db, covering prompts and tool inputs and outputs. Decant's README notes that whatever your agents read lands there too, including file contents and any credentials pasted into a session, and that an existing transcript-retention policy applies to it. Check that policy before running them on work sessions:

npm install --global @dosu/decant@latest
decant economics
decant files --group path --op read

If economics puts most of your spend in context and planning, files shows the paths your agents keep reopening. A path at the top of that list is a lead rather than a finding, so open a couple of the sessions behind it and read what the agent was doing before you take it to the team.

Then fix one of them properly. Pick a convention your agents keep re-deriving and verify it against the code. Create a Library and connect that repository, configure your coding agent with npx @dosu/cli setup, and ask it to record the convention with write_knowledge. In a later session on the same repository and branch, confirm that read_knowledge returns it before the agent starts exploring. Then re-run comparable tickets on the same model and read the cost alongside test results and review corrections.