June 11, 2026
By Anastasiia D.
Technical Debt,
AI in Production,
AI Engineering

In our previous article, we covered what technical debt in AI coding looks like, how it shows up, its business impact measured in dollars and sprint capacity, and the metrics that surface it early on. Read Technical Debt in AI Coding: Types, Impact, and How to Measure It if you missed it.
Diagnosis is an easy part. The harder question is what to do about it at the prompt level, at the CI/CD level, and in the governance framework that holds it all together.
This piece covers the action part:
So, without further ado, let’s start.
Reducing technical debt at the moment AI generates the code, before it gets committed, costs roughly 15× less than fixing it in production (per the IBM multiplier). Four layers of controls do most of the work.
Generic prompts produce insecure code. Specifically, "Create a login function" produces insecure code about 45% of the time. The exact same task, rewritten as "Create a secure login function with proper password hashing, rate limiting, and session management following OWASP guidelines," produces secure-by-default code up to 66% of the time. That's a 21-point security improvement from rewording.
Prompt scaffolds should be a maintained engineering asset: version-controlled in your repo, reviewed like code, and referenced explicitly when developers invoke AI tools for sensitive paths.
The reason LLMs clone code instead of reusing it is that they don't know about your existing helpers. Feeding the agent your architecture context, like interface contracts, linter config, and the relevant module's existing functions, reframes this AI code-generation problem. The agent stops inventing a new version of the code and starts importing the one you already have.
We covered the broader pattern of getting AI refactoring right in this earlier piece, How To Make AI Refactoring Work In Your Favor.
This is the same principle that underpins our work on the AI-powered data analytics platform for sports, where role-specific agents operate inside tightly scoped contexts rather than free-prompting against the whole codebase. The platform processes 6+ billion tokens per month, and we've measured 2-3× higher success in multi-step reasoning compared to the single-prompt baseline it replaced.
Building agent platforms with this kind of architectural discipline is one of the things our AI & MLOps team does day to day. Our ML engineers design context boundaries, agent roles, evaluation loops, and guardrails that decide what each agent can and can't reach. That's the difference between an agent platform that scales and one that hallucinates its way through your codebase.
Model Context Protocol (MCP) is the standard that lets AI coding agents read files, run commands, and query databases on your machine with whatever permissions you've granted.
A 2025 security review of over 2,600 public MCP implementations found 36.7% actively exploitable to Server-Side Request Forgery (SSRF). The most severe MCP vulnerability disclosed to date, CVE-2025-6514 in mcp-remote, carried a CVSS score of 9.6, allowing remote code execution at the high end of the severity scale.
Keep a list of MCP servers your team has reviewed and approved, and don't let developers install anything outside that list. Treat MCP servers like any other third-party dependency — except more carefully, because they execute with the local user's permissions.
Package hallucination is the pattern where an AI assistant confidently recommends a library that doesn't exist. Across 576,000 code samples, 19.7% of AI-recommended packages were hallucinated. Additionally, 43% of the fake names reappeared across reruns. This kind of predictability makes slopsquatting attacks viable – attackers register the fake names on public registries and wait for someone's AI to suggest them again.
Defending against package hallucinations takes three things working together:
These controls don't slow down your team, but they effectively curb bad output.
If prevention is the cheap half, reducing technical debt that's already accumulated is where the real work starts.
How to reduce technical debt that's already in your repo? It all comes down to one principle borrowed from the static-analysis vendors: vibe, then verify.
In plain terms: treat the act of generation and the act of validation as two separate workflows, not one merged step. Every AI-generated suggestion is untrusted by default until it clears an automated quality gate.
A serviceable gate enforces seven conditions on every merge:
Layered on top of the standard gate, four AI-specific checks make a difference:
Let’s overview each of them in detail.
Cyclomatic complexity is a measure of how many independent paths a function has, such as more branches, more nested conditionals, or higher numbers. The higher it gets, the harder the function is to test, and the easier it is to break.
The rule we set is: block any pull request that raises a single function's complexity by 3x or more in one go. It's the most reliable signal that the AI agent crammed new logic into an existing function instead of extracting a helper.
Code duplicates are one of the clearest signals of AI-generated debt. Tools like jscpd detect duplicated blocks across 150+ programming languages, not just exact string matches, but also structurally similar near-duplicates.
Set the tool to run on every pull request, calibrated to your current baseline. A reasonable starting threshold: block any PR that introduces duplicate blocks of five or more lines. Over time, as your team reduces the codebase's overall duplication rate, tighten the threshold.
GitClear tracked code duplication rates year over year and found that copy-pasted lines rose from 8.3% of all commits in 2021 to 12.3% in 2024. Anything materially above that signals a codebase accreting rather than evolving.
LLMs love to add scaffolding. Tools like vulture for Python, ts-prune for JavaScript/TypeScript, or your language equivalent catch these dead blocks. Run them in CI with a confidence threshold of around 80%. It’s high enough to avoid false positives and low enough to catch the patterns that matter.
Two reasons this is worth blocking, not just warning about:
Flag any PR that adds hundreds of lines without any associated refactoring or consolidation. These must route to architecture review.
In terms of security, the most effective pattern is what's now called agentic SAST. Static Application Security Testing (SAST) reads your code and flags vulnerabilities without executing it. "Agentic" means that an AI agent picks up the scan output and acts on it: it analyzes the flagged issue, writes a fix, runs automated tests against the fix, and delivers a ready-to-merge pull request with a confidence score attached.
GitLab Duo Agent Platform is the clearest implementation of this pattern in production. Removing humans from security review is not the point. Let agents fix the agent-generated debt at speed, and keep humans where their judgment matters most: the approval step.
On the governance side, the practical framework is to define which code paths require mandatory senior human review regardless of what the gates say. Our short list: authentication and authorization, encryption and decryption, input validation and sanitization, raw SQL or NoSQL query construction, Infrastructure-as-Code for production environments, and anything touching payments or PII. Everything else can be gate-cleared.
This is the heart of effective technical debt management in an AI-assisted engineering: automated gates handle volume, senior humans handle judgment, and the two never substitute for each other.
You can't fully eliminate technical debt. Anyone who claims otherwise is selling a tool. What you can do is keep debt below the level that eats your velocity. The durable technical debt reduction strategies that work in AI-assisted teams share a common ground: they treat debt as a managed quantity.
Five practices keep the quantity managed and turn ad-hoc cleanup into systematic technical debt reduction:
Allocate a fixed percentage of sprint capacity to debt remediation. Somewhere between 15% and 25% works for most teams.
The important word here is fixed. This allocation is non-negotiable, just as the security patching window is non-negotiable. It doesn't get traded away when product pressure rises, because product pressure is precisely what creates the debt in the first place. Skipping the budget when you're busy is how teams end up spending 65% of sprint capacity on bug fixes six months later.
For every sprint, publish two numbers side by side: how many lines the team added, and how many lines the team moved or consolidated (refactored). The ratio between them is your early-warning indicator.
When new lines start growing 10× faster than refactored lines, and the gap holds for three sprints in a row, you're watching debt accumulate. The metric won't tell you what to do, but it'll tell you to look closer. This way, you will be aware of the problem a sprint or two before the slowdown shows up in your delivery numbers.
We unpack why AI refactoring fails when teams don't watch this kind of signal in The 40% Problem.
Every quarter, senior engineers sit down and look at the codebase from the top down. They look at the modules where duplicated code is concentrated. They look at the functions where complexity has crept up. They look at the areas where AI agents have been most active. Then they redesign.
This is the part that minimizing technical debt depends on most, and that least lends itself to automation. Static analysis can flag a problem; it can't redesign the module to make the problem go away.
Architecture reviews and surgical debt remediation are core to our high-performance software engineering services. Our engineers handle highly technical work that pays off in the next 12 months of delivery velocity, including performance optimization, large-scale refactoring, codebase audits, multi-language porting, and senior-led remediation of AI-introduced debt.
Periodically ask the question: which AI assistants are producing which classes of debt?
Some assistants are better at some languages than others. A large 2025 study of AI-generated code showed vulnerability rates of around 41% in C and C++, 16–18% in Python, and well under 10% in TypeScript.
Match the tool to the surface. And when an AI assistant starts shipping too many problems, rotate it out the same way you'd rotate out a third-party library that keeps issuing CVEs.
By the way, we compared the two most-adopted AI coding assistants, Cursor vs. Copilot, across multiple development scenarios.
If your company is now selling and supporting a product that was originally built as a vibe-coded MVP, you need to decide what to do with it. Actually, it’s a decision tree:
That last point is uncomfortable for founders, but the math is consistent across cases: in 12 months, patching a vibe-coded foundation costs you more than rebuilding it. The Rework Tax almost always favors a rebuild once the integration count exceeds 3 or 4.
There's a thread running through every section above. In the long run, AI-assisted coding doesn’t work without engineers who carry systems-level judgment. And systems-level judgment is not something you pick up from six months with Copilot.
This level of expertise comes from years of shipping production code that mission-critical systems depend on. We wrote a longer take on this argument in another piece titled Human Engineering Skills Versus AI. Go check it out.
Janea Systems is made up of senior and lead engineers who ship at enterprise scale for companies like Microsoft, Intel, ARM, Broadcom, and Meta. A few recent engagements include:
All those engagements involved deeply technical expertise, multiple programming languages, more than three integrations, and no tolerance for the kind of debt that surfaces six months after launch.
If you're running a similar project and want senior engineering assistance with code audits, architecture reviews, CI/CD gate design, or hands-on remediation work on an AI-assisted codebase — let’s get in touch. Take a closer look at how we work through our AI & MLOps services and high-performance software engineering services.
Ready to discuss your software engineering needs with our team of experts?