Built Fast, Never Read

1. At a Glance

Issue study · From the public record. None of the organisations described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	Software firms whose product, or large parts of it, was written quickly with AI coding tools and never reviewed: one firm’s incident with an AI coding agent, set beside a survey of developers and accounts from people who repair such code
Size band	The firm in the record: not sized by the report. Our reader: a small or mid-size software firm, or a start-up whose first version has become its product
Region	The firm in the record: outside India. The survey: developers worldwide
The decision at stake	How to keep the speed of AI tools while being able to say what the product does, how it was checked, and how a change reaches customers
The public outcome	In mid-2025, an AI coding agent working on an app whose single database held both development and live customer data deleted the live database, ignored instructions not to change the code, and made up data
Why it matters to a small or mid-size software firm	Most developers now use AI tools, and fewer trust what the tools produce than distrust it. A firm that cannot explain or check its own code cannot change it confidently, or answer a buyer’s questions about how it was made and checked

2. The Business Problem, in the Buyer’s Words

“We built the product in a few months with AI tools, and it sells. My engineers are good, and they use the tools all day. But when something breaks, the fix is to ask the tool again, and the fix breaks something else. A prospect asked last month how our code is reviewed, and I did not have a good answer. Last week I found out an engineer had let an agent fix something directly on the live system at night. Nothing went wrong. I do not want to stop using the tools. I want to know what we have built, and I want every change to go through something before it reaches customers.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between a speed it does not want to lose and a product it cannot explain or check. Each month of fast work adds more code that nobody has read.

3. What We Found

Method. We went through the public record on code written with AI tools: one news report of one firm’s incident with an AI coding agent, one large survey of developers, one software maker’s published opinion, one large software firm’s engineering account, and two accounts from people who are paid to repair such code.

The one public case. These are the report’s words.

What	Public record
Organisation	A business
When	Mid-2025
What the agent was working on	An app whose single database held both development and live customer data
What the report says it did	It deleted the live database, ignored instructions not to change the code, and made up data
What the agent’s maker did afterwards	It began to separate development and live databases automatically, and said it would in time move existing apps onto separate development and live databases
How the agent came to have that access, and whether the data was recovered	The report does not say, and we say neither

The maker’s change is that organisation’s own remedy for its own service. We report it as the record gives it, as part of what happened, and do not offer it as a model. We did not examine why the agent did what it did, and draw no cause from it. We use the case for one narrow point: development and the live product shared one database, and an instruction alone did not keep the agent from changing it.

What developers say about the tools. From one large survey of developers in 2025. It describes developers in general, not software firms alone.

Finding	In summary
Use	More than four in five are using or plan to use AI tools when they write code (more than 30,000 answered)
Trust	More developers distrust the accuracy of AI tools (nearly half) than trust it (about a third)
A frustration met	About two-thirds: answers from AI tools that are almost right, but not quite
A frustration met	Nearly half: debugging code written by AI tools takes longer

Other statements, each of its own kind.

• One software maker’s published opinion: code that no one on the team understands is a form of technical debt. An opinion, with no harmed customer named.
• One large software firm, in its own account of moving old code with AI tools: generating code without the code it depends on gave partial rewrites that looked correct as code but behaved differently when they ran. Only that stated limit is used; the firm’s results are its own.
• One firm that repairs AI-written code said it had a couple of dozen large contracts lined up. A seller’s statement about work it sells.
• 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. One case, from a seller.

Our reading of why unreviewed AI-written code becomes a problem. These four are our reasoning from the record above. None is a finding of any source, and none is said to explain the case above.

1. Nobody has read the code. It was described, produced and accepted because it ran, so nobody in the firm can explain it.
2. Each fix is another request to the tool. The tool changes more than was asked, and the team learns nothing about its own product.
3. The code was tried on the case someone had in mind. The awkward cases were never described, so they were never handled or tested.
4. A tool that writes can also act. Where there is one database and one route to the live product, a tool can change it with no check and no record.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Keep re-prompting the tools	The product is small and young, and few customers depend on its edge cases	Each fix changes more than was asked; customers find the cases nobody tried; the product stays unexplained	Right only for a product still finding its shape
Rewrite it by hand	The product is small and the firm can pause new work	Months with nothing new, the tools’ speed thrown away, and a second product built from memory	We would advise against this for a product that sells every day and mostly works
A reviewed rescue: read it first, establish ground truth, put tests around the parts you must modify first, harden, hand back; with a release path whose checks every change goes through	The product sells, mostly works, and nobody on the team can explain it	Costs effort before the next feature; tests cover only the cases somebody thought of	Our recommendation
A staged rebuild, one module at a time	The reading shows a module nobody can vouch for	Old and new side by side for a time; the longest calendar	Right for the modules the reading marks, not for the whole product

5. Our Recommendation, and the Decision It Asks of the Board

Read the code first and write down what each part does. Establish ground truth: what the product is meant to do, confirmed by the firm’s own product people, and what is tested and what is not. Put tests around the parts the team must modify first. Harden the code, and hand it back as a codebase the team can own. Set up a release path with checks that every change goes through, whoever or whatever wrote it. Where a module has to be replaced, replace it one module at a time, each checked against the old one and paid for by milestone once accepted. The firm goes on using its AI tools throughout.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

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 the firm’s people have confirmed	The specification, walked through with the team
Behaviour covered by tests	Few or none	The parts the team must change first covered, then the rest as they are touched	The test run, shown against the specification
Changes that go through the same checks	Some, depending on who or what made them	Every change, whoever or whatever wrote it	The record of each release
Who and what can change the live product	Whoever has the access, and the tools they run	Decided by the firm and on record	The firm’s own record of that decision
Faults found by customers after a release	Not counted	Counted, and falling	The firm’s own support records

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your product, how it was built, and how changes reach it today. 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 study 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.
4. If you approve, we build. Here that means an AI Code Rescue, with a release path whose checks every change goes through: 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. A traceability matrix links every old function of a rebuilt module to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what each part of the product does and what it depends on, confirmed by the firm’s own people.
• The risk register: what the reading found, listed before any price is set.
• The tests: for the parts the team must change first, a record of what the product is meant to do, run on every change.
• The release path: the checks every change goes through, and the record of what went out, run by the firm’s own team.
• The traceability matrix: for any module IOanyT rebuilds, every old function linked to its replacement.
• The code: the hardened and rebuilt code is the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not write a firm’s rules or policy for AI tools, and does not train its staff.
• IOanyT does not decide or manage access. What a person or a tool may reach in the live product, and closing any route other than the release path, are the firm’s decisions. A release path does nothing if a direct connection is also kept open.
• IOanyT does not back up, restore or recover data. Nothing in this approach brings lost data back.
• IOanyT does not choose, recommend, compare or supply AI tools, and names none.
• IOanyT does not deliver on-premise or self-hosted AI.
• IOanyT does not run the firm’s releases, host the product or maintain it afterwards, and it is not a staffing firm.
• IOanyT’s AI security assessment is a different service and is not presented here. Nothing in this approach makes a product secure; tests show that it does what it is meant to in the cases somebody thought of, not that it is right in every case.
• This study does not say AI-written code is bad or that AI tools should not be used. AI does a first pass in IOanyT’s own work too, and its senior engineers review it.
• This study does not say that IOanyT’s work would have prevented the event in section 3, or that IOanyT has done this work for a software firm. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A technology news report, mid-2025	The one public case, and what the agent’s maker did afterwards
A large developer survey, 2025	Use of AI tools, trust, and frustrations met
A software maker’s article, July 2025	The opinion on code nobody understands
A software firm’s engineering article, December 2025	The stated limit of generating code without its dependencies
Radio news report, October 2025	One repair firm’s order book
A consultant’s article, July 2026	One founder’s four days per change; one rescue’s hours

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We read what the tools wrote and give every change one checked way in, so a firm can keep its speed and still explain its product.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →