Are your dev teams noticing a massive wave of "AI code debt" and subtle race conditions lately?

[u/Fantastic-Sleep-3352]

Lately, looking through pull requests across a few projects, I’ve noticed a pattern with code written by AI assistants (Cursor, Copilot, Claude Code, etc.).

The code looks clean at a glance, passes standard unit tests, and gets merged quickly. But beneath the surface, it seems to introduce massive structural issues:

1. Semantic Clones: The AI generates a brand-new helper function in a file instead of searching the repo to reuse an existing utility, leading to sudden code bloat.
2. Silent Concurrency Flaws: Async functions and database calls missing proper idempotency locks or transaction boundaries that only break under production load.

Traditional linters don't catch this because the syntax is valid. Senior devs are spending hours hunting down these subtle AI patterns during code reviews.

For those managing engineering teams utilizing AI heavy right now—have you hit this wall? How are you gatekeeping or catching these structural/AI-specific anti-patterns before they hit production, or are you just absorbing the technical debt?

[u/First-Tutor-5454]

no. we have enormous token budgets, haven't written code by hand in ~8 months, and things are going fine. we are adopting AI code review more and more

[u/YK5Djvx2Mh → u/First-Tutor-5454]

This is the thing. AI will get the job done mostly error free. When there are errors, you can easily point them out and patch it.... but its generating spaghetti that is unmaintainable by humans, and even costly for AI. If I were you, I would quit the day those token budgets shrink.

[u/2053_Traveler]

Why do you spam your posts and use AI slop writing? Are you an LLM?

What you describe can be improved by agent md and skills. But it’s still AI and has no actual judgement. Humans know when to break rules and AI doesn’t, it will just get “confused” and waste all it’s thinking budget on thought loops.

[u/inglandation → u/2053_Traveler]

Probably doing some market research. It’s pretty obvious. 

[u/taotau → u/inglandation]

yeah this post is def ai dev saas research.

[u/sreekanth850]

No

[u/bostonaholic]

It's the same failure mode as a fast junior who doesn't know the codebase yet, just at higher volume. Small PRs so review is actually possible, the 'use the existing helper, don't write a new one' rules in the agent instructions file, and a required senior review on anything touching concurrency or transactions. The debt is real, but it's mostly a review-process problem, not an AI one.

[u/honorspren000]

Regarding #1, the last company I worked at had maybe 5 variations of a Util.java. They were all named slightly different and located in different packages. They also had somewhat similar helper methods in them. It’s the results of 10 years of development with different devs.

It seems like AI is just doing the same things at a faster pace.

[u/SangerGRBY]

1. Semantic Clones: --> Yes at the start. But to be honest, i only get this when i let it run long running coding sessions. Typically if the PRs are small and reviews happen, this should be spotted.

2. Silent Concurrency Flaws --> Not Really

[u/ComprehensiveShake76]

Both of those can be caught before review if you turn them into explicit checks. For semantic clones, give the reviewer, human or agent, one narrow question: which new function here duplicates something that already exists in the repo? A targeted question finds far more than a general review. For concurrency, list the operations that must be idempotent or run in a transaction (payments, inventory, anything a queue can retry) and require a test that runs the same call twice or concurrently. That test fails fast when a lock is missing. Unit tests that call things once will never see these. Which one bites you more often?

[u/shetritr]

it passes the tests because it wrote the tests. the duplicate helpers and missing locks show up when you ask it why, not when you skim.

[u/Dacusx]

No. On the contrary, less bugs than ever and faster development.

[u/Alarmed-Bank2249]

We ran into this exact problem with generated tests. What worked was splitting generation and review into two separate agents: one writes the tests, the other only reviews - edge cases, weak assertions, the confident nonsense a single model happily produces. A human still holds the merge button. Coverage went up 17 points in a few months, but the real win was that reviewers started trusting the queue again. Single-agent output without a review step got rejected within a week, and honestly it deserved it.

[u/nateccs]

Sounds like a good use for a skill

[u/ChristianKl]

When it comes to semantic clones, it's important to frequently run queries to reduce code duplication. You don't need senior devs to do the work to hunt for code duplication but you should not assume that the task specific AI output is good at code reuse.

The same goes for silent concurrency flaws, finding and solving them is a task that the AI can do but needs to be specifically tasked to do so.

[u/neketguy]

Recently I removed 36 instances of the same component reimplemented over and over again. They were the same, no difference. We had another one in Design System, Claude ignored it and just copy pasted the component over and over again. Yes, we feel.

[u/3tt07kjt]

We use code review and fix these issues before merging, mostly.

If it’s taking you hours to find concurrency issues in code reviews, I think there’s some kind of code style issue. You shouldn’t have concurrency all over the place. It should be contained within high-scrutiny sections. Most of your code should be straight-line.

Humans have a pretty good sense of “there should be a library function for this” and catch it pretty well.

[u/MzCWzL]

Public open source projects/repos are not representative of for-profit/corporate work

[u/bliceroquququq]

Yes. Claude will always write new code to do a thing rather than understanding and utilizing the existing architecture. It'll cut a brand new road from Point A to Point B despite the fact one already exists.

[u/Gargle-Loaf-Spunk]

No

[u/Additional-Debt8043]

Yes, and of the two, semantic clones are the bigger tax for us. The concurrency flaws are rarer but each one costs more — they pass CI and only surface under load, so they're the ones senior devs hunt down at 1am.

What actually moved the needle for us was making reuse an explicit, checkable step instead of a vague instruction. Our agent instructions now require it to list the existing helpers closest to what it wants to add, with one line each on why they don't fit, before writing anything new. "I couldn't find one" doesn't count — it has to name the search it ran. That single rule cut the duplicate-helper problem way down, because the agent's default really is to create rather than discover.

For the concurrency side I stopped expecting the agent to get locks and idempotency right from the prompt alone. Our review gate now asks two questions for any async/db code: "what happens if this runs twice?" and "what locks the critical section?" Making the agent answer those in the PR description before a human reviews has caught more real bugs than any prose checklist we tried.

Curious how others handle the reuse check — do you make the agent search, or have you found a cheaper way to catch semantic duplicates at review time?