Coding agents went from novelty to default in eighteen months

Eighteen months ago, “AI coding assistant” was a category most engineering leaders watched with one eye. It surfaced in performance reviews as a discussion item: should we let people use this? Today the question has flipped. Teams that have not integrated coding agents into their daily workflow are now the outliers, and the gap is visible in shipped throughput, in pull-request quality, and in the kind of work senior engineers actually spend their time on.

We work with engineering organisations across a few dozen mid-market companies. Here is the honest field report on what changed, what did not, and where the teams pulling ahead are spending their effort.

The throughput shift is real and uneven

The teams we see with the cleanest integration story report pull-request throughput up 25–60% over a comparable 2024 baseline. That number hides a wide spread. Greenfield product work shows the biggest gains; legacy codebases with weak tests and inconsistent conventions show the smallest. The gap is not the agent — it is what the agent has to work against.

Where coding agents really earn their keep is not in writing the easy 80% of new code. It is in the boring engineering nobody wanted to do: writing the missing tests, paying down obvious lint debt, writing the migration script that touches forty-seven files, generating the OpenAPI spec from the controllers, regenerating the type definitions after a schema change. The agent is the new junior dev who actually does the unglamorous work.

The code-review pattern that survived

Six months in, most teams tried letting the agent generate the PR and the reviewer act as the human gate. Most teams have now walked that back. The pattern that survived is: a human owns the change, uses the agent as an accelerator, and submits a PR with their own name on it. The reviewer reviews the human, not the agent.

The reason is accountability. When the agent owns the change, nobody is on the hook for what shipped. When a person owns it, the existing review culture — and the existing on-call rotation — still has a target. That accountability shift is the single biggest organisational change we have seen, and it is the change most companies underestimate when they bring agents in.

Junior engineers are the dataset, not the casualty

Eighteen months ago the loud worry was “what happens to junior engineers when AI writes the code?” The answer turned out to be more interesting than expected. Junior engineers we work with now ship more code in their first six months than mid-level engineers shipped in twelve, two years ago. The trade-off is depth. They have more touch-points across the codebase and less time staring at a single function until it makes sense.

The teams that are managing this well have done one specific thing: they preserved deliberate “no-agent” days or projects, where juniors are expected to work through a problem without the assistant. Not because the assistant is harmful, but because the deep-comprehension muscle still needs to be built. Bringing an external delivery team in on these projects while juniors do the slower learning work is one pattern we have seen work — the agency engineers absorb the throughput pressure, the in-house juniors get the depth they need.

The security and IP story is calmer than expected

The 2024 panic about coding-agent IP leakage has mostly resolved into practical hygiene. Enterprise tiers from the major vendors now offer zero-retention configurations and contractually exclude customer code from training data. We still see two consistent failure modes worth naming: developers pasting production secrets into agent prompts on consumer tiers (a policy and onboarding problem, not a technology problem), and AI-suggested dependencies that pull in subtly-malicious packages with similar names to real ones.

The second one — dependency confusion via AI suggestions — is the underrated risk right now. The mitigation is unglamorous: a vetted package allow-list, automated dependency review on every PR, and a security engineer who reads the diff before any new top-level dep lands. None of this is new advice; it just matters more when agents are proposing dependencies the developer would not have searched for themselves.

The honest counter-argument

Not every team that has adopted coding agents has seen the productivity gains. About a quarter of the teams we have seen report broadly flat output and significantly higher review burden, because the agent generates plausible-looking changes that are subtly wrong, and the team’s review culture is not strong enough to catch them efficiently. For these teams, the agent is a net negative — it produces a lot of pull requests and a lot of review fatigue, and the rate of bugs slipping through has crept up.

The differentiator is not the agent. It is whether the team had a working test suite, a working code-review culture, and clear ownership before they introduced the agent. Coding agents amplify what is already there. A team with strong fundamentals goes faster. A team without them just generates more debt, more quickly.

What we recommend right now

• Stay on the enterprise tier. The retention and IP terms are meaningfully different from consumer plans, and the price difference is small compared to the cost of an incident.
• Keep a human’s name on every PR. The agent is a tool, not a contributor. Accountability is a load-bearing wall.
• Audit dependency suggestions specifically. The supply-chain risk is the highest-impact-lowest-likelihood failure mode right now.
• Invest in your eval suite before throughput. A team without tests scaling output 60% is a team building scaffolding for a problem the test suite will eventually have to clean up.
• Don’t outsource depth. Carve out non-agent learning time for junior engineers. The throughput gains are real but they are not free.

The agents have stopped being novel. The companies that will pull ahead in the next eighteen months are the ones who treat them as a normal part of the engineering stack — operated, monitored, governed — rather than as a magic productivity injection that solves the team’s problems on its own.

Wiring coding agents into a working engineering organisation is a software-engineering problem, not an AI problem. Cravings’s Software Development practice takes on the integration: enterprise tier rollout, PR-ownership policy, dependency review automation, and the operating model your engineering managers will need to maintain it after we leave. Two-week readiness audit, no-surprises proposal.