If you have spent any time around software development lately, you have seen the demo.
A developer types a comment, a spinner flickers, and a few hundred lines of clean-looking code appear like the machine just remembered how capitalism ends. The clip is tidy. The cursor is confident. The future, apparently, is one prompt away.
And to be fair, the appeal is obvious. AI coding tools can be genuinely useful. They are good at scaffolding, explaining unfamiliar code, writing first-pass tests, translating examples between languages, and helping you get unstuck when your brain has started making Windows XP shutdown noises.
The problem is not that AI can write code. It can.
The problem is that writing code was never the whole job.
Fast output is not the same as fast delivery
One of the more useful reality checks came from METR’s 2025 study of experienced open-source developers. The researchers looked at developers working on real issues in large, mature repositories they already knew. When those developers were allowed to use AI tools, they took about 19% longer to finish the tasks.
That does not prove AI coding tools make everyone slower. METR is careful about that, and the distinction matters. The study was focused on experienced developers, mature projects, and real maintenance work. That is not the same as a greenfield demo, a coding interview puzzle, or a weekend script.
But that is exactly why the finding is worth paying attention to. Mature software is where the hidden costs live. The hard part is not usually producing more text. The hard part is understanding the existing system, respecting its weird edge cases, and making a change without quietly breaking something three modules away.
That is where AI can create a strange productivity illusion. The code appears quickly, so the work feels faster. Then the bill shows up during review, testing, debugging, and future maintenance. Very polite of the bill to arrive late. Very software.
The evidence is mixed because the work is mixed
It would be lazy to turn this into a sermon about how AI coding tools are bad. They are not. Plenty of developers are getting real value from them.
Google’s 2024 DORA report found that more than 75% of respondents were using AI for at least one daily professional task, and more than a third reported moderate to extreme productivity improvements. DORA also associated higher AI adoption with better documentation quality, code quality, and code review speed.
Then comes the catch, because software enjoys balance the way printers enjoy paper jams. The same DORA work also found that higher AI adoption was associated with lower delivery throughput and lower delivery stability. Individual speed and team delivery are not always the same metric.
That is the useful lesson. AI can help on bounded work. It can reduce friction. It can make repetitive tasks less miserable. It can explain code you do not understand yet. It can draft tests you should have written last week. Those are real wins.
But when teams treat generated code as finished code, the tool stops being an assistant and starts becoming a maintenance loan.
The maintenance loan always comes due
The risk with AI-assisted development is not simply “bad code.” Humans have been writing bad code with impressive dedication for decades. We should not pretend the robots invented the mess.
The newer risk is volume. AI makes it easier to add more code than the team can comfortably understand, review, and maintain.
GitClear’s 2025 analysis looked at 211 million changed lines from 2020 through 2024 and found warning signs around duplication, short-term churn, and declining refactoring. Their data suggests more copy-pasted code and less moved or reused code as AI assistants take on more code-writing work.
That should make teams cautious. Not panicked. Cautious.
More generated code means more review surface. More review surface means more places for a subtle assumption to sneak through. And because AI-generated code often looks clean, idiomatic, and confidently formatted, it can lower our guard at exactly the wrong moment.
Security has the same shape. Veracode’s 2025 GenAI Code Security Report found that 45% of tested AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities. That does not mean every AI suggestion is a breach wearing a hoodie. It means generated code deserves the same security discipline as any other code, and probably a little extra skepticism when it touches input handling, authentication, data access, or permissions.
If you would not deploy human-written code without tests and review, you should not deploy machine-written code because it arrived with good indentation.
Typing was never the bottleneck
The older version of the AI coding sales pitch quietly assumed that typing was the expensive part of software development. Remove the typing, unlock the future.
That was always a little silly.
The expensive part is context. What does this system already do? What assumptions are buried in the database? Which weird integration breaks if we change the shape of this response? Why does this function look wrong but somehow keep payroll alive?
This is the same reason long context windows are useful but still not a substitute for architecture. More context helps. It does not magically create judgment. A model can read a lot of files and still miss the one constraint that matters.
The best AI coding workflows are not built around accepting bigger blobs of generated text. They are built around tighter feedback loops.
A sane AI coding loop
If a team wants AI coding tools to help instead of quietly expanding the maintenance backlog, the workflow needs to make the tool earn trust.
- Keep the diffs small. Large generated pull requests are where review goes to die politely.
- Make the tool explain its assumptions. Which files did it inspect? Which constraints is it relying on? What did it not check?
- Require tests before approval. If the assistant writes behavior, it should help write or update the tests that prove the behavior.
- Run the boring gates. Build, lint, typecheck, static analysis, dependency checks, and security scans are not decorations.
- Review generated code more carefully, not less. Clean syntax is not evidence of correct intent.
- Keep humans responsible for architecture and consequences. The tool does not get paged at 3:00 AM. You do.
That last point matters. I made a similar argument in the post about AI agents touching production: useful automation still needs boundaries. The more capable the assistant becomes, the more important the guardrails become.
The useful middle ground
The future of AI-assisted development is not “never use it” and it is not “approve whatever the autocomplete goblin suggests.” The useful middle ground is more boring and much more durable.
Use AI where it is strong. Let it draft test cases, explain unfamiliar code, scaffold boring pieces, suggest refactors, and help explore options. Let it save you from staring at syntax you already understand but cannot quite remember before coffee.
But do not confuse output with ownership.
If the code lands in your repository, it becomes your code. Your team has to understand it. Your tests have to cover it. Your review process has to catch the weird parts. Your future self has to maintain it when the original chat window is gone and the model has moved on to confidently explaining sourdough starters to someone else.
AI coding works best when it is treated like a fast assistant inside a disciplined engineering process. Not a senior architect. Not a magic compiler for business intent. Not a shortcut around understanding the system.
Sometimes the fastest path is still to think through the problem and type the code yourself. Other times, the assistant really can help. The trick is knowing the difference — and making the machine prove its work before you inherit the mess.