The remediation market is coming. Do not be its customer.
Gartner expects a market for auditing and refactoring AI-generated debt. The category will exist and it will be well funded. Most of what it sells is priced against a symptom by vendors with no reason to remove it.
Gartner expects a remediation market to form: specialist tools and consultants who will audit and refactor the technical debt organisations are accumulating from AI-generated code. I think that prediction is correct. I also think the product most of that market will sell is one you should decline to buy.
My position: the category is real, the demand is real, and the standard offering will be priced against a symptom by a vendor with no commercial reason to remove it. There is a narrow slice worth paying for, and it is not the slice with “remediation” in the name.
What the product is going to look like
I can describe the pitch before it exists, because this category has run before under other names. Static analysis in the 2000s. Application security posture in the 2010s. The shape is stable.
You will be sold a scan. It will produce a number, probably normalised to something like debt-days or a letter grade. It will rank your repositories. It will identify a percentage of your codebase as AI-generated, using heuristics it will not fully disclose. It will offer to fix a portion automatically, and the fixes will be real, and they will be the fixes that were easy to make safely.
Then it will run again next quarter, and there will be a new number, and the number will not be zero.
The incentive is pointed the wrong way
Here is the structural problem, and it is not a moral one. Nobody in this market is planning to defraud you.
A remediation vendor sells findings. Their renewal conversation goes better when the scan still finds things. A vendor whose product genuinely eliminated the class of problem it detects would be selling a declining service into a shrinking account, and no board approves that plan. So the product converges, without anybody deciding to, on detecting a category that regenerates as fast as it is cleared.
And this category regenerates unusually fast, because the input is a generator. If you are producing code at agent volume and remediating it at consultant volume, the remediation is a rounding error that produces a report. The report is the deliverable. It is genuinely satisfying to read, and it will describe last quarter.
What remediation sells
- A score for the codebase
- A percentage flagged as generated
- Automated fixes for the safe subset
- A quarterly delta
- Renewal when the number is still non-zero
What actually changes the position
- Which merges no human opened
- Which subsystems have one reader
- What criteria a change was accepted against
- A record of who authorised what
- A lower generation rate into risky paths
The measurement problem underneath it
There is a deeper reason to be sceptical, which is that nobody has a defensible way to price this debt.
CAST’s often-quoted figure of roughly 61 billion workdays of global technical debt gets cited in every deck in this category. It is a real piece of work and it is entirely unactionable for you. It cannot tell you which of your repositories to touch first, because it is not about your repositories. A vendor arriving with a global figure and a proprietary score is not measuring your exposure. They are establishing that a budget line is legitimate.
That is a service, and if you need help getting a budget approved it may even be worth something. Just be clear with yourself that it is what you are buying.
The honest local measurement is cheaper and less impressive. What fraction of merges to your default branch last month did no human open. How many areas of the system could exactly one person explain. What is the ninetieth percentile of your incident diagnosis time, not the median. Those three numbers cost you a weekend of query writing and they direct actual decisions.
The narrow slice that is worth buying
I do not want to argue that everything in this category is worthless, because that is lazy and it is not what I believe.
Buy inventory. A tool that tells you which parts of your system are unread, unowned and heavily changed is answering a question you cannot answer yourself at scale, and it is not a question that regenerates once you have acted on it. The finding is durable.
Buy provenance. A chain from a line of code back to the change, the criteria it was accepted against and the human who approved it is the only artefact that keeps working eighteen months later when the person is gone. It is also the thing that lets you answer an auditor without a forensic exercise, which matters more since the EU AI Act’s enforcement began on 2 August 2026 and Article 12 started asking for tamper-evident logs of events relevant to risk and traceability.
Do not buy refactoring as a service on code nobody has read. Refactoring is a transformation that preserves behaviour, and you cannot confirm behaviour was preserved in a subsystem where nobody knows what the behaviour is supposed to be. You will get a diff you cannot evaluate, produced by a party who will not be on call for it.
Where this breaks down
Some organisations genuinely cannot do this internally. I am arguing for building your own inventory queries, and that assumes a platform team with the time and the access to build them. Plenty of engineering organisations have neither, and for them a mediocre bought answer beats an excellent unbuilt one. My advice is easiest to follow for the people who need it least.
Consultants are frequently better at this than internal teams. Not because they are smarter, but because they are allowed to say the unpopular thing and then leave. An internal team that identifies a subsystem as unmaintainable has to keep working with the person who wrote it. That political fact does more damage to internal assessments than I have accounted for.
Recurring findings are not automatically a scam. Vulnerability scanning also regenerates forever, and nobody sensible argues you should stop scanning. Some classes of problem genuinely do require permanent monitoring, and I have not given a clean test for which is which beyond “does clearing it reduce the next count”, which is harder to evaluate than I made it sound.
We sell into this space, so discount me accordingly. Fastpace’s GroundTruth is an inventory-and-provenance product, and I have just written an article arguing that inventory and provenance are the good part of this market. That is convenient. Treat this piece as an argument to evaluate rather than a disclosure, and note that our own coverage is honest about the workflow record and much weaker at telling you which of your existing subsystems is dangerous, which is exactly the gap a remediation vendor will offer to fill.
Automated refactoring on well-tested code is genuinely fine. My objection is specific to code nobody has read. Where a module has a strong contract and a characterisation suite you trust, an outside party mechanically improving it is low risk and often good value. I have written as though the unread case is the only case, and it is not.
The takeaway
The remediation market will exist because the anxiety is real, and it will mostly sell scores because scores are what fund renewals. The parts worth paying for are the durable ones: knowing what you have, who owns it, and what each change was accepted against.
Refactoring is the wrong instinct for debt that consists of nobody having read something, and it is the instinct this market is built to sell you.
If you take one thing into next week: before you take the vendor call, write down the three numbers you would want the product to improve. If you cannot name them, you are not buying a tool. You are buying a budget justification.