Why coders should stop refusing to work without AI

Coders who refuse to work without AI are trading short-term speed for long-term maintenance debt.

Coders should stop treating AI as a mandatory part of the job because the habit is already distorting productivity, inflating costs, and hiding quality problems that surface later in production. The evidence is piling up: METR found in 2025 that developers using AI reported feeling faster even when the measured result was slower, and when the team tried to rerun the experiment in 2026, many developers refused to participate without AI at all. That is not a sign of maturity. It is a sign that the tool has become a crutch before teams have learned how to measure its real value.

AI makes code faster to write, not cheaper to own

The first mistake is confusing output speed with engineering productivity. AI can generate a function, a test scaffold, or a migration script in seconds, but software teams do not get paid for lines of code. They get paid for reliable systems that survive months and years of change. James Shore’s warning captured the economics cleanly: if AI halves writing time but leaves maintenance untouched, the team has only bought a temporary speed boost and signed up for permanent debt. That is the wrong trade for any serious codebase.

There is already evidence that the debt is real. Singapore Management University researchers warned in April that AI-generated code can introduce long-term maintenance costs into real software projects. That matters because maintenance is where most software budgets go after launch. A feature that ships quickly but keeps generating bugs, confusing abstractions, and brittle dependencies is not a win. It is a delayed bill, and the bill grows every time another engineer has to read, patch, or extend that code.

Measurement is breaking, and teams are congratulating themselves anyway

The second problem is that AI use is now warping how companies think about performance. Amazon reportedly shut down its internal token-tracking leaderboard after employees gamed it by overusing AI agents, which shows how quickly a proxy metric becomes a target. Once token counts become a badge of productivity, people optimize for visible AI activity instead of outcomes. That is how organizations end up rewarding the appearance of speed while shipping more expensive software.

Uber’s experience is even more telling. The company reportedly burned through its 2026 AI budget in the first four months of the year, and its COO said the spending had not produced a measurable increase in projects or productivity. That should end the fantasy that more AI use automatically means more value. If the budget spikes and the throughput does not, the tool is not making the organization stronger. It is simply making the expense line more dramatic.

The maintenance tax is the part everyone wants to ignore

AI defenders love to argue that the answer is to use AI for cleanup too, as if a faster code generator can be paired with a faster code janitor. In theory, that sounds neat. In practice, it shifts the burden onto teams that still need humans to review, understand, and own the result. Even Scott Wu, whose company sells the Devin coding agent, says the system currently performs somewhere between junior and mid-level depending on the task. That is useful, but it is not autonomous engineering.

And the bug-fix burden is not hypothetical. Entelligence AI’s CEO said companies are spending 44% of their tokens on fixing bugs generated by AI, while CodeRabbit said its analysis of open source pull requests found AI produced 1.7x more problems than human code. Those figures come from vendors with a stake in the market, so they should not be treated as neutral science. But they align with the broader warning from independent researchers and with the lived reality of any team that has had to untangle a plausible-looking but wrong AI patch at 6 p.m. on a Friday.

The counter-argument

The strongest case for AI-first coding is simple: developers are already using these tools, they like them, and the productivity gains are real in the right hands. For routine tasks, boilerplate, test generation, and quick prototyping, AI removes friction that used to slow teams down. In a talent market where senior engineers are scarce and deadlines are tight, refusing AI can look like refusing leverage. The pro-AI camp is right to say that teams that ignore the tools will fall behind teams that use them well.

That argument fails when it turns preference into policy. The problem is not AI assistance itself. The problem is the refusal to work without it, which makes teams less resilient, less measurable, and more dependent on a tool they do not fully control. The correct standard is not “use AI everywhere.” It is “use AI where it helps, and prove it helps.” If a team cannot review the output, cannot track maintenance impact, and cannot ship without the model, then the team has not adopted a productivity tool. It has outsourced judgment.

What to do with this

Engineers, PMs, and founders should treat AI coding tools like a junior teammate with a high output rate and uneven taste. Use them for drafting, scaffolding, and repetitive work, but require human review for architecture, security, and anything that will live for more than one release cycle. Track defect rates, review time, and maintenance cost, not token counts or self-reported speed. If AI is truly helping, the numbers will show it. If it is only making people feel faster, the software will eventually collect the debt.