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.
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.
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.
At Invexa, we use these tools daily and hold the same review bar we always have. The assistant changes how fast a first draft appears; it does not change who is accountable for what ships, and our process is built around that distinction.