AI Tools Wrote the Code Quickly. Nobody Was Given the Time to Read It.

A customer reports that their invoice total is wrong. The engineer who built the billing module opens the file to look.

It is two thousand lines long, and the engineer recognises little of it. Six months ago they described what they wanted to an AI coding tool, and the tool wrote it. It worked, the customers were waiting, and nobody read it closely.

So the engineer does the sensible thing and asks the tool to fix the total. The tool rewrites three functions. The total is right now. The tax line, which was right this morning, is not.

What We Found

For this article we went through the public record on code written with AI tools: one large survey of developers, one software maker’s published opinion, and two accounts from people who are paid to repair such code.

Four findings stand out.

The tools are now ordinary. In one large survey of developers in 2025, more than four in five said they were using or planning to use AI tools when they write code. More than 30,000 people answered that question. Whatever a software firm thinks of these tools, its engineers are very likely already using them.

Use runs ahead of trust. In the same survey, more developers distrusted the accuracy of AI tools, nearly half, than trusted it, about a third. The people who use the tools most are the ones saying their output needs checking. The survey is about developers in general, not about software firms alone.

Unread code is recognised as a cost. One software maker, writing about code produced by describing what you want to a tool, put it plainly: code that no one on the team understands is a form of technical debt, and it builds up as fast as the tool can produce code. That is one firm’s opinion, with no harmed customer named. We think it is a fair one.

Repairing such code has become paid work. One firm that does this work told a radio news report it had a couple of dozen large contracts lined up. One consultant who sells such repairs quotes an anonymous founder for whom each small change cost days of debugging things that broke elsewhere, and says one rescue took dozens of hours over a few months. Both are sellers’ own statements about work they sell, and the second describes one case. We take them as a sign that the problem exists, and no more.

Our reading is that the tools are not the problem. They write working code quickly, and that is useful. What goes missing is the step that used to come with writing code by hand: a person who has read it and can say what it does. When nobody has, every change is a guess, and the quickest guess is to ask the tool again.

What Waits While Nobody Can Explain the Product

Code nobody has read does not stop a product from selling. It stops the firm from changing the product with confidence, and from answering questions about it.

The first cost is every change. An engineer who does not know a module cannot tell what a change will touch. So changes are made by asking the tool, the tool changes more than was asked, and something else breaks. The founder in the consultant’s account lost days to each small change. Our reading is that this is the usual shape, though nobody has measured how usual it is.

The second cost is the questions. A buyer, an investor’s adviser or a new engineer asks how the product was made and how it was checked. The honest answer is “an AI tool wrote it, and it works”. That answer does not say what the product does, what it depends on, or who has looked at it. What buyers ask about this was not researched; we expect the question to come.

The third cost is where the knowledge sits. The reasons behind the code are in chat histories with a tool, on individual accounts. When an engineer leaves, the reasons leave too, and the code itself explains nothing.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Deal With Code Nobody Has Read, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Keep re-prompting the tools	The product is small, young and changing fast, and few customers depend on its edge cases	Each fix changes more than was asked, the team learns nothing, and the questions about how the product works stay unanswered
Rewrite it by hand	The product is small and the firm can pause new work while it is rewritten	Months with nothing new for customers, a second product built from memory, and the speed the tools gave the firm thrown away
A reviewed rescue: read it first, establish ground truth, put tests around the parts you must modify first, harden, hand back	The product sells, works mostly, and nobody on the team can explain it	It costs time and money before any new feature, and it may show that parts of the product do not do what everyone believed
A staged rebuild, one module at a time	The reading shows a module that cannot be repaired with confidence	Old and new run side by side for a time, and the calendar is longer than one big rewrite

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Parts of the product someone on the team can explain	Few, and only by asking the tool	Every part, from a written record your own people have confirmed	The specification, walked through with your team
Outside packages the product depends on	Added by the tools, not listed or chosen	Every package listed, with the part that needs it	The map of the system as it stands
Behaviour covered by tests, for the parts you must change first	Few or none	Each such part covered, including the cases customers rely on	The test run, shown against the specification
Changes that go through the same checks	Some, depending on who made them	Every change, whoever or whatever wrote it	The record of each release
Who and what can change the live product	Not written down	Decided by the firm and on record	The firm’s own record of that decision

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a software firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your product, how it was built and the questions you cannot yet answer about it. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code, and for code written with AI tools the reading is done as an AI Code Rescue assessment: we read it first and establish ground truth about what is tested and what is not. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. Here that means an AI Code Rescue: we put tests around the parts you must modify first, harden the code, and hand back a codebase your team can own. Where a module has to be replaced, we replace a system one module at a time while the old one keeps running. We never do a single cutover. Each rebuilt module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits. We do not write your firm’s rules or policy for AI tools, and we do not train your staff. We do not decide or manage access: what a person or a tool may reach in your live product is your decision. We do not back up, restore or recover data. We do not choose, recommend, compare or supply AI tools, and we name none. We do not deliver on-premise or self-hosted AI. We do not maintain the product afterwards, and we are not a staffing firm. Our AI security assessment is a different service and is not what this article describes. A written record shows what the code does, not whether it is right, and tests do not make code secure. And we are not saying AI-written code is bad: AI does a first pass in our own work too, and our senior engineers review it. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	The firm holds an account of how its own product works, and does not depend on a tool to explain it afresh each time.
CTO or CIO	A written record of what the code does, checked by senior engineers, so the team changes it knowingly and does not simply ask a tool to write it again.
Head of product	Product can find out how a feature really behaves, and plan a change with some idea of what it touches.
CISO	The firm knows what its product does with customers’ data, and which outside packages the tools brought in, so its own security work has somewhere to start.
Head of people	The firm’s knowledge of its product is in a record, and not in engineers’ chat histories.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. Its figures come from one large survey of developers, one software maker’s opinion and two accounts from sellers of repair work.	We read code written with AI tools, write down what it does, put tests around the parts you must change first, harden it and hand it back. We do not write your rules for AI tools, manage access, recover data or maintain the product afterwards.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by reading what your tools wrote, so that someone can explain your product before anyone is asked to change it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →