Short answer: When a team has been shipping fast with AI coding tools, the codebase isn’t the problem to fix first, it’s a symptom to read. Five engineers asking an AI assistant the same question on five different days produces five slightly different implementations of the same function, and nobody notices the overlap. Auto-completed imports pull in dependencies nobody checks for actual use or version currency. The fix starts with the team’s process, not a refactor.
Resist the urge to start with the code
When an engineering leader suspects an AI-assisted codebase has gotten messy, the instinctive move is to dive into the code: open the files, start tracing duplication, begin refactoring. Sharma Vedula, Head of Solutions at Data Society, has seen this instinct lead teams astray often enough to name it directly as the first mistake to avoid.
“The first thing we do is resist the urge to start with the code. Don’t start with the code. When a team has been shipping fast with AI coding tools, the codebase becomes a symptom.”
Sharma Vedula, Head of Solutions, Data Society
That reframing matters because it changes where the real diagnosis happens. A codebase doesn’t generate its own duplication and dependency sprawl. A process does, specifically, the absence of review at the exact moments AI coding tools make it easiest to skip. Starting with the code means treating the output as the disease. Starting with the team means treating it as the symptom of something upstream, which is usually where the actual fix lives.
How the mess actually gets made
The pattern Vedula describes is specific, and it’s worth sitting with because it explains why AI-assisted codebases accumulate a particular kind of debt that looks different from traditional technical debt.
“You end up with five implementations of the same function, because five engineers asked the same question to an AI assistant, possibly different AI assistants, on five different days, and nobody reviewed the overlap that the AI tool would have generated.”
Each of those five implementations, taken alone, is probably fine. An AI assistant asked to write a date-formatting helper or a retry wrapper will generally produce reasonable code. The problem isn’t quality at the point of generation. It’s that five engineers had no visibility into each other’s prompts, so five reasonable answers to the same underlying question shipped as five separate, slightly inconsistent pieces of code, none of which any single reviewer ever compared side by side. A human engineer copying an existing utility function at least sees it exists. An AI assistant, asked cold, has no way to know a functionally identical helper already sits three files away, and the engineer prompting it often doesn’t think to check either, because the tool made producing new code so fast that reaching for existing code stopped feeling necessary.
The dependency problem compounds the same way. “Dependencies got pulled in because the tool auto-completed an import, and nobody checked whether the library was actually used, or whether it was the latest version of that library.” An import suggestion is a small, easy-to-accept moment, exactly the kind of low-friction decision that erodes review discipline fastest. Accepting an auto-completed import takes a keystroke. Verifying that the library is genuinely needed, actively maintained, and not a security or licensing liability takes real attention, and it’s the step that’s easiest to skip when the tool has already made the code appear to work.
Why this looks different from ordinary technical debt
Traditional technical debt usually has a traceable origin: a deadline that forced a shortcut, a design decision that didn’t scale, a system that outgrew its architecture. AI-assisted codebases can accumulate an equivalent amount of debt without any single decision that looks like a shortcut. Every individual AI suggestion was accepted because it looked correct, and often was correct in isolation. The debt isn’t a series of compromises. It’s a series of small, independently reasonable decisions that were never checked against each other.
That’s precisely why starting with the code is the wrong first move. Refactoring the five duplicate implementations down to one fixes today’s mess but does nothing to stop a sixth one from appearing next sprint, because the review gap that let the first five happen is still open.
What to look at instead
If the codebase is a symptom, the diagnosis has to look at where review disappeared.
Who reviews AI-generated code, and against what. If pull requests are approved by checking whether the code runs rather than whether it duplicates or conflicts with something else in the codebase, that gap is where five implementations of the same function come from.
Whether engineers have visibility into each other’s AI-assisted work. Five engineers hitting the same problem independently isn’t unusual. Five engineers having no way to discover that until after all five have shipped code is a process gap, not an individual failure.
How dependencies get approved, not just how they get added. An auto-completed import shouldn’t carry the same trust as a dependency a human deliberately chose after evaluating alternatives. Teams that treat every import the same way, regardless of how it entered the codebase, will keep accumulating unreviewed dependencies.
Whether “it works” has quietly replaced “it’s reviewed” as the bar for shipping. AI coding tools are very good at producing code that runs. They have no opinion on whether that code belongs, whether it duplicates existing logic, or whether the dependency it just pulled in is one the team actually wants to maintain.
The fix is a process change, not a cleanup sprint
None of this means AI coding tools are the problem. The tools did exactly what they were asked: answer the question in front of them, as well as they could, each time. The gap is that the questions were being asked in isolation, and the answers were shipping without the cross-checking that used to happen more naturally when writing code took longer and engineers were more likely to stumble across existing solutions along the way.
Closing that gap means building review checkpoints back into a process that got faster than the old checkpoints could keep up with: a habit of searching the codebase before generating new code, a lightweight way to surface when multiple engineers are solving the same problem, and a deliberate step where every new dependency, autocompleted or not, gets the same scrutiny. None of that requires slowing down. It requires deciding, on purpose, where review still has to happen even when the tool made it feel optional.
Frequently asked questions
Why do AI coding tools lead to duplicate implementations of the same function?
Because different engineers can independently ask an AI assistant the same question on different days, and the assistant has no visibility into what other engineers have already built. Each answer looks reasonable on its own, but nobody compares them, so duplicate, slightly inconsistent implementations end up shipping side by side.
Why is checking whether a codebase “works” not enough when AI coding tools are involved?
AI-generated code is often functionally correct at the point it’s written, which is exactly why duplication and unnecessary dependencies slip through. “It works” doesn’t catch whether the code duplicates existing logic or whether a dependency was ever actually needed.
Should a team refactor an AI-assisted codebase before fixing its process?
No. Refactoring addresses the current mess but doesn’t stop the same pattern from recurring, because the review gaps that allowed duplication and unchecked dependencies in the first place are still open. Diagnosing the process comes first.
How do unnecessary dependencies end up in an AI-assisted codebase?
Coding assistants often auto-complete imports as part of generating a solution. Because accepting the suggestion is fast and the code appears to work, engineers can skip verifying whether the library is actually used or whether it’s a current, well-maintained version.
What should engineering teams change first when adopting AI coding tools at scale?
Build in points where AI-generated code gets compared against what already exists in the codebase, and treat every new dependency, however it entered the code, with the same scrutiny a human-chosen one would get.
Next steps
An AI-assisted codebase that’s accumulated duplicate functions and unexamined dependencies is a record of where review used to happen and stopped. Data Society’s AI Advisory work helps engineering teams diagnose that process gap, and AI upskilling programs build the team-level habits that catch what any single tool can’t.
