DEV Community

Cover image for AI-Generated Code Without Tests Is Technical Debt at Machine Speed
M.T.Ramkrushna
M.T.Ramkrushna

Posted on

AI-Generated Code Without Tests Is Technical Debt at Machine Speed

#ai #programming #testing #softwareengineering

Here's my hot take for this Wednesday: if your team adopted AI coding tools and didn't change how it verifies code, you didn't get faster. You started borrowing faster.

Writing code used to be the slow part. A function took an hour, a feature took a week, and the time spent typing gave you time to think. AI assistants and agents have compressed that step to minutes. But the step after it, knowing the code is correct, did not get any cheaper. So the bottleneck moved. It's no longer "who writes this?" It's "how do we know this works?"

Code you can't verify isn't an asset. It's a liability you haven't been billed for yet. Generate it 10x faster without a verification layer and you're accumulating technical debt at machine speed.

The data already points this way

I'm not going to invent numbers, so here are three published sources I think every team using AI for code should read.

1. Google's DORA 2024 report. DORA found that a 25% increase in AI adoption was associated with a 7.5% increase in documentation quality, a 3.4% increase in code quality and a 3.1% increase in code review speed. Good news. But the same increase was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. Their explanation is the interesting part: improving the development process doesn't automatically improve delivery "without proper adherence to the basics of successful software delivery, like small batch sizes and robust testing mechanisms." The report also hypothesizes that AI makes changelists bigger, and bigger changes are slower and more prone to instability.

2. Stack Overflow's 2025 Developer Survey. The single biggest frustration with AI tools, cited by 66% of developers, is "AI solutions that are almost right, but not quite." The second, at 45%, is that "debugging AI-generated code is more time-consuming." And more developers actively distrust the accuracy of AI output (46%) than trust it (33%).

"Almost right" is the most dangerous kind of code. Obviously broken code fails loudly. Almost-right code passes a glance, passes a demo, and fails in production on the edge case nobody wrote down.

3. METR's 2025 randomized trial. In early 2025, experienced open-source developers working on their own mature repositories took 19% longer with AI tools allowed, while still believing AI had sped them up by 20%. METR itself now says those results are out of date and that developers are likely faster with current tools, so don't quote the 19% as a law of nature. The lasting lesson is the gap between perception and measurement: "it feels faster" is not a verification method.

Tests and specs are the real leverage

The tool vendors are saying the same thing. Anthropic's official Claude Code best practices put it bluntly: give the agent "a check it can run: tests, a build, a screenshot to compare." Without one, they write, "'looks done' is the only signal available, and you become the verification loop."

That sentence is the whole argument. If there's no executable check, you are the test suite, and you don't scale.

A good test does three jobs that matter more now than they did before AI:

  • It's a spec the model can read. "Write validate_email; user@example.com is true, user@.com is false" is a far better prompt than a paragraph of prose. Example cases remove ambiguity.
  • It's a stop condition. An agent with a failing test can iterate on its own until it's green. An agent without one stops when the output looks plausible.
  • It's a ratchet. Once a behavior is pinned by a test, the next generated change can't silently break it.

What I'd actually do

  1. Write the test before the prompt. For a feature, write two or three example cases first, including one edge case. For a bug, reproduce it as a failing test, confirm it fails for the right reason, and commit it before asking the AI to fix anything.
  2. Make "done" mean "the check passed." One command (make test, npm test, pytest) that exits non-zero on failure. Ask the agent to run it and show the output, not to say "I've verified it."
  3. Protect the check. "Fix the code, not the test." Treat any AI diff that weakens, skips or deletes a test as a red flag by default.
  4. Keep changes small. DORA's batch-size warning applies directly. One generated 2,000-line PR is harder to verify than ten 200-line PRs with tests each.
  5. Spend the time you saved on verification. If AI cut implementation time in half, put part of that dividend into tests, types and contracts. That's where the compounding happens.

The counterargument

"Writing tests slows down the speed AI gives us." For a throwaway prototype, sure, skip them. But anything that will be maintained, deployed or built on by someone else (including future you) gets paid for eventually. The only question is whether you pay with a test today or with an incident later.

AI made code cheap. It didn't make correct code cheap. The teams that win the next few years won't be the ones that generate the most code. They'll be the ones that can verify it the fastest.

Where does verification break down first on your team: missing tests, flaky tests, or tests nobody trusts?

References

Top comments (0)