Coding agents are good at chores. Give them chores

Most teams give coding agents the wrong work. Every agent demo ends the same way, with someone typing a sentence, the agent reading through the repo, and a green pull request a few minutes later. Then you hand an agent a real bug in a real codebase and the afternoon goes somewhere else entirely.

I don't think the demos are lying, but we grade agents on their best five minutes and then give them our worst problems. I've done it myself more than once, because the demo made the job look easy. Two studies published this year each looked at roughly 33,000 agent pull requests, and they point to a duller and more useful conclusion. Agents are good at chores, and we get more out of them when we give them chores instead of our hardest work.

What actually gets merged

Ehsani and colleagues, in a paper on arXiv accepted at MSR 2026, studied 33,000 pull requests written by five coding agents on GitHub and sorted them by the kind of task they were doing. Documentation, CI and build updates merged most often, performance work and bug fixes merged least.

The PRs that didn't merge looked alike. They were usually larger, touched more files and often failed the project's CI/CD checks. This is no surprise to anyone who reviews code for a living, a big diff spread across many files is hard to trust no matter who wrote it, and when it also fails the pipeline most reviewers stop reading right there.

A second study on arXiv, by Dao Sy Duy Minh and colleagues, analyzed 33,707 agent-authored PRs and found the same split from another angle. Agents did well at what the authors call narrow automation (28.3% of the PRs merged instantly), and struggled with iterative refinement. When a reviewer left subjective feedback, the agents often failed to follow through and the PR was abandoned. The authors call this ghosting, and they describe the extra review work it creates as a hidden "attention tax" on maintainers.

That second finding is the key one. A bug fix or a performance change is rarely a one-shot job, it's a conversation. You try something, someone pushes back, and you slowly learn what the code was actually for. An agent that does well on the first pass and goes quiet on the second is a good fit only for work that never needs a second pass.

The Dao paper also has an idea every team should borrow. The authors built a creation-time Circuit Breaker, a model that looks at a PR the moment it's opened and flags the ones likely to need heavy review, using simple static signals such as file types and patch size. It reached an AUC of 0.96, and at a 20% review budget it caught 69% of the high-effort PRs.

You don't need their model to use the idea. If a PR touches only docs, CI config or build files and the diff is small, it's probably safe to fast-track. If it's large, spans many files or touches the parts of the system people tend to argue about, a senior reviewer should see it first (or it goes back to be split into smaller pieces). Most teams could write that rule down this week without building anything new.

Where we actually point them

This would stay an academic point if it weren't for what people actually ask agents to do. Anthropic's Economic Index report from January found that the most common task in its November 2025 sample of Claude.ai conversations was modifying software to correct errors, at 6% of usage, and among API customers it was also the top task, at one in ten records. In the same report, Claude assessed personal tasks as successfully completed 78% of the time, against 61% for software development.

Yes, those success rates come from the model grading itself, and the report says its measures are directional rather than exact, so hold the numbers loosely. But the gap between them matters more than either figure on its own. Fixing errors is what we ask for most, software is where the success rate is lower, and next to the two PR studies the pattern holds up well. We keep sending agents the jobs that need the most back-and-forth.

What I'd suggest is a plain policy that sorts work by type before anyone gets their hopes up. There's nothing clever about it, which is partly why a team would actually stick with it.

Hand off documentation updates, CI and build config changes, and small mechanical edits where the right answer is obvious once you see it. You still review them, but you can reasonably expect them to merge.

Pair on bug fixes with a clear reproduction, tests for code that already works, and refactors limited to a few files. The agent drafts, a person drives. When the feedback turns subjective, the person takes over. Don't waste time waiting for the agent to come around.

Keep performance work, bugs nobody can reproduce yet, anything large that touches many files, and design decisions the team hasn't made with people. An agent can help someone explore these, but it shouldn't own the PR.

On top of that, put a check at the door that looks at file types and diff size before review, so the expensive PRs reach a senior reviewer first instead of last. It's the same reasoning behind how we build Workbricks, with one focused app per workflow, because narrow jobs are the ones automation does well, and most weeks have more of those jobs in them than we like to admit.

Give agents the chores, keep the conversations for people.