Authored by Paul Leasure
AI coding tools are now embedded in modern software development. They autocomplete functions, explain legacy code, generate tests, write documentation, summarize pull requests, and increasingly act like agents that can modify files across an entire codebase.
Yet experienced developers remain cautious. That caution is not fear of progress. It is professional judgment.
The developers who have shipped production systems, inherited fragile codebases, debugged weekend outages, and maintained software for years know something that demos often hide: code is not valuable because it was generated quickly. Code is valuable when it works, fits the system, survives edge cases, is maintainable by the next person, and does not quietly introduce risk.
That is why the real question is not, “Can AI write code?” It can. The better question is: when should developers trust AI-generated code — and when should they interrogate it, constrain it, or throw it away?
Key Takeaways
- AI can make developers faster, especially on repetitive, well-scoped, easy-to-verify work.
- Experienced developers are more cautious because they understand production risk, technical debt, security, and maintainability.
- The most valuable AI skill is not prompting. It is judgment: knowing when to accept, challenge, or discard the output.
- As AI gets cheaper and more integrated, teams will need stronger verification workflows, not weaker ones.
AI Can Make Developers Faster — But Not Automatically
There is strong evidence that AI coding assistants can improve speed in certain situations. GitHub’s research found that in a controlled experiment, “developers who used GitHub Copilot completed the task significantly faster—55% faster than the developers who didn’t use GitHub Copilot.” The study involved 95 professional developers writing an HTTP server in JavaScript, with the Copilot group completing the task faster on average.
Microsoft’s research publication on the same experiment similarly reported that the treatment group using GitHub Copilot “completed the task 55.8% faster than the control group.”
That matters. AI can reduce friction, especially for boilerplate code, test scaffolding, syntax-heavy tasks, documentation drafts, API usage examples, repetitive transformations, and exploring unfamiliar libraries.
But “faster” in a controlled task does not automatically mean “better” in a complex production system.
A professional codebase is not a blank coding challenge. It has conventions, business logic, deployment assumptions, security boundaries, weird historical decisions, half-documented edge cases, and implicit knowledge that often lives only in the heads of senior engineers.
That is where AI’s usefulness becomes conditional.
The Trust Gap Is Real
Developers are not refusing AI. They are using it while distrusting parts of it.
The 2025 Stack Overflow Developer Survey found that “more developers actively distrust the accuracy of AI tools (46%) than trust it (33%),” and only 3% reported highly trusting AI output. The survey also found that experienced developers were the most cautious, with the lowest highly trust rate and the highest highly distrust rate.
This is exactly what you would expect from people accountable for production software. Experienced developers understand that an AI answer can be syntactically correct but architecturally wrong, plausible but outdated, confident but insecure, locally functional but globally harmful, or passing simple tests while failing real edge cases.
This is why AI coding tools often feel paradoxical. They can save time in one moment and create extra review burden in the next.
The Stack Overflow survey captured this clearly: the biggest single frustration developers reported was dealing with “AI solutions that are almost right, but not quite,” cited by 66% of developers. The second-largest frustration was that “debugging AI-generated code is more time-consuming,” cited by 45%.
That phrase — almost right, but not quite — describes the core problem with AI-assisted development. Almost-right code is dangerous because it looks finished.
The METR Study: When AI Made Experienced Developers Slower
One of the most important recent counterweights to AI productivity hype came from METR, which ran a randomized controlled trial on experienced open-source developers working in their own repositories.
The finding was surprising: “when developers use AI tools, they take 19% longer than without—AI makes them slower.” METR also noted that developers expected AI to speed them up and still believed it had done so after the work, even though measured completion time moved in the opposite direction.
This result should not be overgeneralized. It does not prove AI is bad for all developers or all tasks. METR itself cautioned against that interpretation. But it does reveal something crucial: AI productivity is not automatic.
The benefit depends on the task, the codebase, the developer’s familiarity with the system, the quality bar, the tooling, the review process, and the developer’s skill at steering the AI.
For experienced developers working in large, mature codebases, the bottleneck is often not typing. It is understanding. AI can generate code quickly, but it may not understand why the existing abstraction exists, which legacy behavior must be preserved, which tests are missing, or which customer workflow depends on a strange edge case.
In those environments, AI can become a very fast junior developer: useful, energetic, occasionally brilliant, and absolutely in need of review.
Why Senior Engineers Are Right to Be Skeptical
Senior developers tend to be skeptical because they have learned that software quality is not just about output. It is about consequences.
A junior engineer may ask, “Does this code work?” A senior engineer asks:
- What happens when the input is malformed?
- What happens when the dependency fails?
- What happens when this runs 10 million times?
- What happens when a new developer changes it six months from now?
- What happens when the business rule changes?
- What does this do to security, observability, and maintainability?
AI tools are improving quickly, but they still often optimize for the visible request instead of the hidden context. That is why experienced developers do not treat AI output as finished work. They treat it as a proposal.
Sometimes it is a good proposal. Sometimes it is a useful starting point. Sometimes it is wrong in a way that only an experienced engineer will catch. And sometimes the best move is to delete it.
The Real Skill: Knowing When to Trust, Interrogate, or Discard AI Output
The next generation of developer productivity will not come from blindly accepting AI-generated code. It will come from better judgment.
Using integrated AI to write code makes you faster only if you develop the hard-won intuition for when to trust it, when to interrogate it, and when to throw its output away.
Trust AI More When the Task Is Easy to Verify
AI is most useful when success is obvious and testable. Good examples include writing unit test skeletons, generating simple helper functions, translating familiar syntax, creating documentation drafts, explaining error messages, producing examples from known APIs, refactoring small isolated functions, and generating repetitive boilerplate.
Interrogate AI When the Task Touches Architecture
AI should be questioned more aggressively when it affects authentication, authorization, payment logic, data migrations, distributed systems, performance-sensitive code, concurrency, production infrastructure, cross-service contracts, or long-term abstractions.
For these tasks, the right workflow is not “generate and accept.” It is to ask AI for options, list tradeoffs, identify failure modes, explain assumptions, produce tests, critique its own answer, and then review everything manually. The AI is not the decision-maker. The developer is.
Throw AI Output Away When It Fights the Codebase
Sometimes AI produces code that is technically plausible but wrong for the system. Discard it when it invents nonexistent APIs, ignores project conventions, adds unnecessary dependencies, over-engineers a simple change, fails to match existing patterns, hides complexity behind vague abstractions, produces code you cannot confidently explain, or requires more cleanup than writing it yourself.
One of the most valuable AI skills is recognizing when continuing with the generated answer is more expensive than starting over.
The Economics of AI Will Increase Usage, Not Reduce Risk
The broader AI market is moving toward cheaper, faster, more integrated models. That will make AI coding tools more common, not less.
“making AI cheaper and more efficient does not reduce total spending. It increases it, because the market for AI inference expands faster than costs decline.”
Omer Ansari, “Situational Awareness, Two Years Later”
That idea matters for software teams. As AI becomes cheaper, teams will use it more often and in more places: code editors, CI pipelines, pull request reviews, documentation systems, customer support tooling, security scanning, internal dashboards, data workflows, and DevOps automation.
Lower cost means higher volume. Higher volume means more AI-generated output entering real workflows. And more AI-generated output means teams need stronger review systems, clearer policies, and better engineering discipline.
AI does not remove the need for software engineering judgment. It increases the importance of it.
DORA: AI Adoption Is Rising, But Trust Remains Low
The DORA research team also found a meaningful trust gap. In its 2024 AI preview, DORA reported “a relatively low level of trust in AI-generated code,” with only 24% of respondents saying they trusted AI-generated code “a lot” or “a great deal.” DORA described this as evidence of “skepticism and cautiousness” among developers relying on AI-generated outputs.
That skepticism is not a failure of adoption. It is a sign that developers understand the stakes.
The healthiest teams will not be the ones that ban AI or blindly embrace it. They will be the ones that operationalize trust.
- Clear AI usage policies
- Secure handling of private code and data
- Required human review
- Strong automated test coverage
- Code ownership
- Static analysis and dependency scanning
- CI/CD guardrails
- Architecture review for high-risk changes
AI makes it easier to create code. Teams must make it harder for bad code to reach production.
AI Coding Tools Are Best Under Strong Engineering Cultures
AI amplifies the system around it.
In a strong engineering culture, AI can be a multiplier. Developers use it to move faster while tests, reviews, and standards catch mistakes. In a weak engineering culture, AI can accelerate chaos. It can generate more code than the team can understand, review, or maintain.
The difference is not the model. The difference is the workflow.
High-performing AI-assisted teams use AI for drafts, not unquestioned final answers. They require developers to understand code before merging it. They ask AI to generate tests, not just implementation. They keep humans responsible for architecture. They measure outcomes, not vibes. They treat AI as a tool inside the engineering system, not a replacement for the system.
The best developers will not be replaced by AI coding tools. But developers who know how to direct, constrain, and audit AI will outperform those who use it passively.
The Future Developer Is an AI-Aware Engineer
The future of software development is not “human versus AI.” It is human judgment plus machine acceleration.
Experienced developers are cautious because they know where software breaks. They know that production systems fail in the gaps between what was requested, what was generated, what was reviewed, and what was actually needed.
AI can help write code. It can help explain code. It can help explore solutions. It can help reduce repetitive work. But it cannot yet replace the situational awareness of a developer who understands the business, the architecture, the users, the risks, and the long-term maintenance burden.
That is why trust is the wrong default. The right default is verification.
AI should be welcomed into development workflows, but not worshiped. It should be used aggressively where it helps and constrained carefully where it can harm.
Experienced developers do not fully trust AI because they understand software. And that is exactly why their judgment matters more than ever.
FAQ
Do experienced developers trust AI coding tools?
Many experienced developers use AI coding tools, but they often do not fully trust their output. Surveys from Stack Overflow and DORA show that trust in AI-generated code remains limited, especially among developers responsible for production systems.
Can AI make developers faster?
Yes, AI can make developers faster on certain tasks, especially repetitive, well-scoped, and easy-to-verify work. However, studies also show that AI can slow developers down in complex, high-context environments.
Why can AI-generated code be risky?
AI-generated code can look correct while missing project-specific context, security requirements, edge cases, or architectural constraints. This makes human review essential.
What is the best way to use AI for coding?
The best approach is to use AI as an assistant, not an authority. Let it draft, explain, test, and suggest — but require developers to verify, understand, and own the final code.
Will AI replace software developers?
AI will change software development, but the most valuable developers will be those who can combine engineering judgment with AI-assisted speed. Human oversight remains essential for architecture, security, product reasoning, and long-term maintainability.
Reference Works
- Stack Overflow Developer Survey 2025 — AI section: https://survey.stackoverflow.co/2025/ai
- DORA Report Preview 2024 — AI in the workplace: https://dora.dev/research/2024/ai-preview
- GitHub Research on Copilot Productivity: https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness
- Microsoft Research — The Impact of AI on Developer Productivity: https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
- Omer Ansari, “Situational Awareness, Two Years Later”: https://medium.com/data-science-collective/situational-awareness-two-years-later-4b941d052ef9
