Stack Overflow’s 2025 developer survey put the tension plainly. Around 84 percent of developers said they use or plan to use AI tools in their workflow, while the share who actively trust the accuracy of those tools fell to roughly 33 percent, down from 43 percent the previous year. Usage went up and trust went down at the same time.
That is not a contradiction. It is what maturity looks like. Developers have moved past the demo phase and now know exactly where these tools are strong and where they quietly waste an afternoon.
Where The Leverage Actually Shows Up
The gains are real but unevenly distributed across the kinds of work a team does.
Assistants are strongest on work that is well specified and tedious: writing test cases against an existing function, translating a data structure between formats, scaffolding a new endpoint that matches fifteen existing ones, writing the migration, drafting the regex, explaining an unfamiliar file. In this territory a good assistant genuinely compresses hours into minutes. The same shape holds outside the editor, which is why the business document backlog is the other place these models tend to pay for themselves quickly.
They are weakest exactly where the difficulty is not typing. Decisions about system boundaries, changes that ripple across services, performance work that depends on knowing the production data distribution, and anything touching a subtle domain rule that lives in someone’s head rather than the codebase. Here the output looks correct, reads confidently, and takes longer to verify than it would have taken to write.
The most cited frustration in the same survey is telling: solutions that are almost right. A wrong answer is discarded in seconds. An answer that is 90 percent right sends a developer debugging code they did not write and do not have a mental model for. It is the same failure as a handoff that arrives without context: whoever picks it up starts from behind.
The Practices That Separate Good Teams
- Small diffs, always. Teams that ask for one function at a time review effectively. Teams that accept 400 line generations end up merging code nobody understands. Cap the unit of generation at what a reviewer can hold in their head.
- Tests written or reviewed by a human. If the assistant writes both the implementation and its tests unsupervised, the tests encode the same misunderstanding. At minimum a person specifies the cases; ideally the human writes the test and the model writes the code to pass it.
- A checked-in context file. A repository level instructions file covering conventions, the ORM in use, error handling patterns and things never to do removes most of the repetitive correction. It is the highest return hour a team can spend on tooling.
- Explicit rules for dependencies. Assistants invent plausible package names and reach for a library where six lines would do. Require justification for any new dependency in review, regardless of who or what proposed it.
- No unreviewed generated code in security sensitive paths. Authentication, authorisation, cryptography, payment handling and anything parsing untrusted input get human authorship and human review.
Review Is Now the Bottleneck
The economics of a team have shifted. Producing a plausible change is nearly free; deciding whether it is correct costs the same as it always did. Teams that only measured throughput saw their pull request queues grow and their defect rates hold steady or worsen.
The adjustments that help are unglamorous. Stronger continuous integration, since automated checks scale with generated volume in a way that human attention does not. Property-based tests and contract tests that catch the class of subtle error a reviewer skims past. And a cultural norm that whoever submits a change owns it fully, regardless of what produced the first draft.
An assistant changes how fast a first draft appears and nothing else. That is why the adjustments worth making are to review, continuous integration and dependency policy rather than to the editor, and why the same discipline carries straight over to shipping AI agents: a plausible output is cheap in both cases, and a correct one still has to be demonstrated by someone who will answer for it.