AI Coding Agents and Productivity: 5 Team Rules to Ship More

AI coding agents write more code. They don't, on their own, ship more software.

You rolled out Claude Code, Codex or Cursor, and the commit graph looks great. Meanwhile PRs keep growing, the review queue stretches for days, and the roadmap moves no faster. The data now backs that up: after agents arrive, time from PR to merge rises 49% and change requests nearly double.

Five team rules close that gap. You can adopt the checklist at the end this week: when an agent may one-shot a change (do it in a single pass, with no plan), how to plan bigger work so rework drops toward 0–10%, how to size PRs, and how to automate cleanup without burying reviewers.

More code, same output: what the data on AI coding agent productivity shows

Researchers analyzing engineering data from Jellyfish compared teams before and after they adopted agentic coding tools. Twelve months in, every engineer adds roughly 4,000 more lines a month.

But resolved Jira issues – a far better proxy for shipped work – rise only slightly, and that rise is not statistically significant.

So where does the time go? It shows up in review, the new bottleneck:

The data runs through March 2026. By then nearly 80% of the firms studied had adopted AI review in some shape, yet AI produced only 23.3% of review comments, and only 10.8% of pull requests got even one AI-generated comment. Humans still carried the load.

Two other findings explain why the speed-up evaporates. Even before AI, engineers spent only 30–40% of their time writing code, so accelerating that slice has a hard ceiling.

And in a METR study published in summer 2025, experienced open-source developers took 19% longer with AI assistants while believing they had sped up by 20%. Code that appears instantly feels like progress. The reading, fixing and re-reviewing that follow don't register the same way.

Why agent code makes a codebase worse over time

Most coding benchmarks hand the model the whole problem up front. SlopCodeBench works more like real product development: the model builds a project from scratch, then keeps adding features to that same codebase without knowing what comes next.

The results aren't pretty. The best of 15 agents passed only 14.8% of checkpoints, and code quality eroded in roughly three of four runs.

Repository data points the same way. GitClear found that copy-pasted code grew noticeably, while the share of existing code being refactored and tidied up fell.

In other words, bolting a new chunk on top is easier than understanding what's already there. Agents make bolting nearly free.

This is also why demos can't replace review. Screenshots and videos from an agent show whether a feature works. They say nothing about whether the code will be easy to change next quarter.

Linters and complexity limits block whole categories of slop – sloppy, low-value code nobody asked for. But no prompt or deterministic tool yet keeps a codebase maintainable when no human is involved.

So maintainability has to be built into how your team uses agents, not bolted on afterward.

Rule 1: Match the process to the size of the change

Not every change needs ceremony. One practitioner team lets the agent handle anything expected to stay under a couple hundred lines with no upfront planning at all.

For simple, routine work this is where agents shine: a senior engineer interviewed by the researchers gets a Claude Code draft in seconds that is right about 90% of the time.

Larger work follows a different path. First, a research session maps the parts of the codebase that matter for the request. Then a separate, fresh session builds the plan from that research without ever seeing the original ticket.

Why two sessions instead of one long chat? Because it keeps planning grounded in the research rather than in a single prompt.

So write the threshold down. “Under a couple hundred lines: one-shot. Anything bigger: research, then plan” is a rule a whole team can apply without a meeting, and it stops large features from sneaking through as one giant prompt.

Rule 2: Plan in zoom levels and review the design doc first

Planning isn't about a perfect spec, since the code remains the source of truth. What you want is to eliminate bad solutions before the agent commits to one.

Start with a one-page view of the problem, then zoom into a more detailed design. Teams working this way aim for 0–10% rework on the final code, compared with the 25–75% rework that's typical when a large agent PR is one-shot.

Then put the design in front of whoever guards the codebase, before any code exists. Debating a data model or an abstraction on one or two pages is far cheaper for both sides than discovering at PR time that the architecture is wrong and the agent has already built on top of it.

Rule 3: Keep pull request size small with checkpoints and pre-read agent code

Big PRs are where agent productivity dies. Senior engineers describe PRs that keep growing and get harder to review, to the point that simply opening one causes anxiety.

The fix is checkpoints: for a large change, verify the work roughly every thousand lines. A bug found at line 10,000 means a huge surface to debug. Caught after the first thousand, it's a small fix before you move on.

The second half of the rule is cultural: never send code for review that you haven't read yourself. Whoever prompted the agent owns everything it produced.

If you skip that personal pass, the reviewer becomes the first human to read the code. The queue then absorbs work that should have happened before the PR was opened.

Rule 4: Let AI code review take the first pass, within limits

AI review can shorten the wait. It doesn't replace the reviewer.

Yandex's internal reviewer, which handles thousands of PRs a day, uses two agents: one generates candidate issues, the other filters out noise before anything is posted. Its first comment lands on average 2–3 minutes after a PR is opened, while a human typically shows up hours later.

That leaves time to fix obvious defects before a person spends attention on them.

But know where it fails. AI reviewers struggle with very large PRs spanning hundreds of files, where useful context gets diluted. That's one more reason Rule 3 matters: small PRs help human and machine reviewers alike.

Keep expectations realistic, too. Even with nearly 80% of firms running AI review by March 2026, it produced less than a quarter of review comments. Think of it as a fast first filter in front of your humans, not as a way to remove them from the loop.

Rule 5: Automate cleanup in small PRs and limit work in progress

Slop accumulates continuously, so pay it down continuously. One small team defines the end state it wants for its codebase and runs janitor bots (scheduled agents that open small cleanup PRs) overnight to nudge the code toward it. About 10% of the team's merged PRs come from these bots.

Two constraints keep the bots from becoming another review flood:

• Size: every automated PR stays very small, so a human can digest and merge it quickly.
• Limit: each type of cleanup has at most one open PR at a time, enforced with labels, so bots don't stack up duplicate fixes for the same problem while yesterday's PR waits.

The same principle applies to people running agents: do fewer things in parallel. Ten tasks in flight feel efficient, but it's easy to lose track of several of them.

So keep one most important task, land it first, and use waiting time for the rest. End-to-end throughput goes up, even if each individual task feels a little slower.

Key terms

• SlopCodeBench – A benchmark that has a model build a project and then repeatedly add features to the same codebase, measuring how code quality degrades over time.
• Agentic coding tool – A tool such as Claude Code that takes a high-level task, plans it and writes code across multiple files, unlike autocomplete-style assistants.
• One-shotting – Giving an agent a task and accepting its first full output without an upfront planning step.
• Design doc – A short document describing the target end state and the planned changes, reviewed before the agent writes code.
• Janitor bot – An automated agent that runs on a schedule and opens small PRs moving the codebase toward agreed rules, such as refactors or migrations.
• Change request rate – The share of pull requests where a reviewer asks for changes before approval, used as a signal of initial code quality.

Checklist: team rules for agent-written code

• Write down a one-shot threshold (for example, under a couple hundred lines). Anything larger starts with a research session and a fresh planning session.
• Plan in two zoom levels, aiming for 0–10% rework.
• Review a one- or two-page design doc first.
• Check large changes about every 1,000 lines.
• Pre-read every agent PR yourself, because the reviewer shouldn't be the first human to see it.
• Add an AI first-pass reviewer, and keep PRs small enough for it to work, because it struggles once a PR spans hundreds of files.
• Janitor-bot PRs: tiny, one open per type.
• Limit parallel agent work and land the most important task first.

Check yourself

1. Your team adopted coding agents and lines of code per engineer jumped. What is the best next metric to check whether you actually ship more?

• A. Number of commits per engineer
• B. Resolved issues or epics in your tracker, plus PR review time
• C. Tokens consumed per week

2. An agent sends screenshots and a video proving a feature works. What does this NOT tell you?

• A. Whether the code is maintainable
• B. Whether the feature behaves as requested
• C. Whether the UI renders

3. A change will touch around 1,500 lines across several modules. Which approach best fits the rules in this article?

• A. One-shot it and fix issues in review
• B. Run a research session, plan in a fresh session, review a short design doc, then implement with checkpoints
• C. Launch ten parallel agents on sub-parts overnight and review in the morning

4. Which practices help keep automated cleanup PRs from overwhelming reviewers? (Select all that apply.)

• A. Allowing at most one open PR per cleanup type
• B. Keeping each bot PR very small
• C. Letting bots batch all fixes into one weekly PR

5. Your company already uses AI code review. Why might reviewers still be overloaded?

• A. AI review makes human review unnecessary, so the overload must come from elsewhere
• B. AI reviewers still produce a minority of review comments and struggle with very large PRs
• C. AI reviewers only work on human-written code