The most quoted number from the last year of developer surveys is not about productivity. It is about distrust. The 2025 Stack Overflow Developer Survey found that 84% of developers now use or plan to use AI tools, up from 76% the year before, and that 51% of professional developers use them daily. The same survey found that trust in those tools collapsed. As ByteIota’s summary of the survey data lays out, trust in AI accuracy fell to 33%, down from 43%, while 46% of developers said they actively distrust it and only 3% said they highly trust the output. Adoption went up. Confidence went down. A year of agents in production explains why both happened at once.
The short version: agents are a real gain on new code and a real liability on old code, and the thing that decides which one you get is not the model. It is the system you build around it.
What actually changed
The adoption curve is not a marketing claim anymore. GitHub’s Octoverse 2025 report, drawing on platform data from September 2024 through August 2025, recorded the fastest growth in the platform’s history: more than 36 million new developers in a single year, roughly one per second, against a base now over 180 million. The itsfoss summary of the report notes a detail that matters for any production discussion: 81.5% of contributions happened in private repositories, which is where the legacy systems and the real maintenance burden live.
The agent-specific shift is newer. Anthropic released Claude Code, GitHub shipped its coding agent, and Cursor became a default editor for a large slice of developers. In a July 2025 post, Anthropic described how its own teams use Claude Code: the Security Engineering team cut infrastructure debugging from 10 to 15 minutes down to about 5 by feeding stack traces directly into the agent, the Product Engineering team calls it their “first stop” for identifying which files a bug touches, and non-engineering teams started building their own tools. The pattern Anthropic drew from this is that agentic coding “isn’t just accelerating traditional development,” it is “dissolving the boundary between technical and non-technical work.”
That framing is honest about the upside. It is also a description of greenfield and glue work, which is exactly where agents are strongest.
Where agents demonstrably ship
The clearest wins share a property: little or no existing context to get wrong. New code, throwaway prototypes, test coverage, one-off automations, and unfamiliar-codebase exploration are the tasks the public accounts return to.
The Stack Overflow data points the same direction. As the dev.to breakdown of the survey reports, developers use AI most for research, learning, and documentation, with over half of heavy users relying on it to look up answers and troubleshoot. These are the parts of the job where being approximately right and fast beats being slow and exact, and where a wrong answer costs minutes rather than a production incident.
The complexity ceiling shows up in the same data. The dev.to summary notes that only around 4% of respondents think AI tools handle complex coding tasks very well, and that the share of professional developers saying AI struggles with complex tasks barely moved year over year, from 35% to 29%. The phrase the survey surfaced as the top frustration is the tell: code that is “almost right.” Almost-right is cheap to fix in a fresh file you wrote yourself five minutes ago. It is expensive, and easy to miss, in a system you did not write and do not fully hold in your head. The same output quality lands as a time-saver in one context and a liability in the other, which is why averaging agent performance across a whole codebase produces a meaningless number.
Anthropic’s own examples fit the shape. The high-value uses it described, getting new hires up to speed on a codebase, automating pull-request comments through GitHub Actions, generating ad variations, building internal phone-tree tools, are either net-new artifacts or comprehension tasks. None of them is a surgical change to a load-bearing legacy system with twelve years of accumulated assumptions. That distinction is the whole game.
Where they reliably break things
The failure mode is not that agents write syntactically broken code. They mostly do not. The failure mode is that they degrade the maintainability of code that already works, and they do it in ways that pass review.
Birgitta Böckeler, a Distinguished Engineer at Thoughtworks, named the mechanism precisely in Maintainability sensors for coding agents, published on martinfowler.com in May 2026. She writes that the first signs of cracks in an AI-generated codebase show up “when the number of files changed for a small adjustment increases,” or “when changes start breaking things that used to work.” An agent in a tangled codebase, she notes, “might look in the wrong place for an existing implementation, create inconsistencies because it has not noticed a duplicate, or be forced to load more context than a task should require.” The internal-quality problems that slow human developers slow agents too, except the agent has no instinct to stop.
The deeper reason is in her earlier piece, an April 2026 essay on engineering the scaffolding around coding agents. A coding agent, she writes, has “no social accountability, no aesthetic disgust at a 300-line function, no intuition that ‘we don’t do it that way here,’ and no organisational memory.” A human engineer carries all of that implicitly. The agent carries none of it, which means in a legacy system the things that keep the code coherent are exactly the things the agent cannot supply. The cruelest part, in her words: the scaffolding “is most needed where it is hardest to build,” because legacy teams with accrued technical debt are the ones who most need the guardrails and have the least structure to hang them on.
This is why the survey’s trust number and its adoption number both moved. Experienced developers, per the survey data, are the most skeptical group, with the highest rate of high distrust. That is not resistance to new tools. It is the population most able to recognize a maintainability regression reacting to seeing them.
The scaffolding is the product
The most useful frame to come out of the year is that an agent is two things, not one. Böckeler uses the shorthand that has spread across the field: an agent is the model plus everything around it, and the part around it is what teams actually build. She splits that surrounding system into guides, which steer the agent before it acts, and sensors, which let it self-correct before problems reach a human. The guides are feedforward; the sensors are feedback. With only one or the other, she writes, “you get either an agent that keeps repeating the same mistakes” or “an agent that encodes rules but never finds out whether they worked.”
Crucially, she distinguishes computational controls, the deterministic ones like linters and tests, from inferential controls, the LLM-based semantic judgments, and argues you need both. A linter catches a formatting violation. It does not catch overengineering, a misdiagnosed bug, or a misunderstood instruction, which are, in her assessment, among the higher-impact problems and the ones neither category catches reliably. The behaviour dimension, whether the code does the right thing, remains the hardest unsolved problem and still requires human judgment.
A coding agent has no aesthetic disgust at a 300-line function and no intuition that we don’t do it that way here. In a legacy system, those are exactly the things that keep the code coherent.
The discipline this forces
If that surrounding system is what matters, then the review process and the guardrails are not overhead. They are the engineering work.
Anthropic’s own infrastructure makes the point in an uncomfortable way. In How we contain Claude across products, the company reports that its telemetry showed “users approved roughly 93% of permission prompts.” The conclusion it draws is blunt: human-in-the-loop approval is “fallible,” because “the more approvals a user sees, the less attention they pay to each.” This is the single most important finding for any team relying on a human clicking approve as their safety layer. People rubber-stamp. The defense that exists on paper does not hold under volume.
Anthropic’s answer was to stop relying on supervision of what the agent does and instead constrain what it is able to do, through sandboxes, virtual machines, and egress controls, capping what it calls the blast radius. That is a containment strategy, and it generalizes. For a normal product team, the equivalent is not reviewing every diff more carefully. It is building sensors that catch the regressions automatically: dependency rules that fail the build when the agent reaches across a boundary it should not, test suites treated explicitly as regression sensors, and static analysis tuned for the shortcuts agents take. Böckeler’s maintainability piece walks through exactly these, from basic linting to dependency rules to coupling data, as a working system rather than a wish list.
The teams getting net-positive results are doing the unglamorous version of this. They point the agent at greenfield work and tightly bounded tasks, they keep humans on the high-judgment behaviour questions the scaffolding cannot answer, and they invest in automated sensors precisely so the 93% rubber-stamp problem never becomes their problem.
What a year of this actually taught
The thesis held up. On new code, prototypes, comprehension, and test coverage, agents are a clear gain, and the public record from Anthropic to the Stack Overflow usage data supports it. On legacy refactors and load-bearing systems, they are a maintainability risk that survives casual review, and the people who write code for a living are the ones flagging it.
What the year settled is that the model is not the variable. Cursor, Claude Code, and Copilot all draw on frontier models that are individually impressive, and yet the outcomes diverge wildly by team. The difference is the surrounding system, the guides and sensors and containment around the agent, and as Böckeler puts it, building that system is “an ongoing engineering practice, not a one-time configuration.” The 33% trust number is not a verdict on the models. It is a measurement of how many teams have built the structure the models need to be trusted, and right now that number is low.