The Agent Writes Half the Code, and Your Metrics Still Count Lines

The volume on your engineering dashboard went up this year, and almost none of that increase means what it used to.

When an agent writes the code, lines shipped and PRs merged stop measuring effort. They measure the agent.

The fix is not a better dashboard. It is counting solved problems instead of produced code.

Sometime in the last year, the chart that engineering leaders trust most quietly stopped working. Velocity is up. Commits are up. Pull requests per week are up and to the right. And a growing share of teams cannot tell you whether any of it produced more value than last year.

The reason is simple once you say it out loud. Roughly 41 percent of code being written now comes from an AI assistant, by most 2026 estimates. Adoption sits around 84 percent of developers. When a machine is generating close to half the output, the numbers that used to track how hard your team worked are now tracking how fast a model types.

The proxy floated free

Lines of code, commits, and PR counts were always proxies. Nobody believed more lines meant better software. What made them useful was a hidden anchor: a human being spent time producing each one. The time was the real thing you cared about, and the output was a rough stand-in for it.

The agent cut that anchor. Output is no longer bounded by anyone's working hours, so the proxy drifts loose from the thing it was standing in for. You can double the commit count on a Tuesday afternoon and learn nothing about whether the product got better.

Worse, the drift is not neutral. Code churn, the share of code rewritten or deleted shortly after it lands, is on track to roughly double in 2026. Code duplication has climbed about 4x with AI assistance, because a model will happily regenerate a helper that already exists three directories over. Google's DORA research already measured delivery stability dropping 7.2 percent as AI adoption rose. And only about 30 percent of AI-suggested code actually gets accepted in the first place.

So the volume metric is not just meaningless now. It is anti-correlated with some of the things you want. A team can post its best velocity quarter ever while shipping more churn, more duplication, and slightly less stable releases. The dashboard shows a win. The codebase disagrees.

A product category showed up to fill the gap

You can watch the market notice this in real time. On June 30, a company called Journi launched a platform named DevOS whose entire pitch is measuring, managing, and optimizing AI-assisted development. It records what happens inside agent sessions so a manager can see where the tools are being used well, where they are being wasted, and where someone is letting an agent run unsupervised on work it should not touch.

Set aside whether that specific product wins. The interesting signal is that a category is forming around a single question: what did the agents actually do, and did it help. That question did not need a product two years ago, because a senior engineer glancing at a PR could answer it. At current volume, nobody can eyeball it anymore.

The frameworks people already trust bend the same direction. DX Core 4 splits its view into speed, effectiveness, quality, and business impact, deliberately refusing to let speed stand alone. SPACE was built years ago on the premise that activity is the weakest of its five dimensions. Both were quietly preparing for a world where activity got cheap. That world arrived.

Count outcomes, not artifacts

The move is not to find a cleverer way to count code. It is to stop treating code as the unit at all.

Pick an outcome unit your business actually cares about. A support ticket that closed and stayed closed. A feature that shipped and was still in use a month later. A defect class that stopped recurring. A migration that completed. Then measure how many of those your team produces per unit of time and money, and let the line count fall where it may.

This lands on a distinction worth making sharp. Cost per solved task matters. Cost per token, or per line, or per commit, does not. When generation is nearly free, the scarce and valuable thing is a problem that is genuinely resolved, verified, and does not come back. That is the number worth putting on a wall.

It also reframes what your senior people are for. Their job was never to produce the most lines. In an agent-heavy team it is to set the bar, say clearly what "solved" means before work starts, and hold the bar, confirm the work actually cleared it before it ships. Verification is where value now gets proven, because generation stopped being the bottleneck. A metrics program that measures produced artifacts is measuring the part of the pipeline that got cheap. A program that measures verified outcomes is measuring the part that stayed hard.

The instrument broke on a specific day

None of this happened gradually. There was a day, for each team, when an agent went from a novelty a few people tried to a tool committing real code into the mainline. On that day the velocity chart changed meaning, and the axis label did not update to warn anyone.

Leaders who keep steering by that chart are flying on a broken instrument that still looks fine. The needle moves, the trend looks healthy, and it is reporting a quantity that no longer connects to whether the software is getting better.

You do not need a dashboard that counts faster. You need one that counts a different thing. Start with a single outcome your customers would recognize as valuable, count how many of those you deliver, and treat every lines-shipped chart as what it now is: a measure of how much your agents typed, and nothing more.