Somebody built you something in a fortnight for a fraction of what an agency quoted. It worked. That was six months ago, and now it holds real customer data, three people in your business depend on it daily, and the developer you asked to add one feature has gone quiet.
This article is about that situation. It is not about whether the tools are good, and it is emphatically not about whether you were foolish to use them. Quite often the fast version was the right call and the only thing that has changed is what the software is now being asked to carry.
Two siblings cover the adjacent questions: whether AI tools can replace an agency, and whether your supplier should be using them on your product.
Somebody official has written about this, which surprised us
We expected to write this article from experience and vendor documentation. Instead, a security architect at the UK's National Cyber Security Centre published a post in June 2026 on AI-assisted development that is directly on point [1]. It is a signed blog post rather than a formal guidance collection, which is worth knowing when you weigh it, and it is still the most relevant thing any national body has published on this specific question.
Two things about it are worth knowing. First, it takes a risk-tiered position rather than a blanket one: prototypes and internal tools sit at one end, and anything touching authentication, personal data or secrets sits at the other [1]. Second, it prescribes a sequence before relying on AI-assisted code, which is to review it, understand it, check it for vulnerabilities, and verify it [1].
That framing is more useful than any general argument about whether generated code is good, because it puts the question where it belongs: not on how the software was made, but on what it touches.
We should also be honest about what does not exist. There is a lot of published material on building and operating AI systems, and it is not the same subject as code written with an AI assistant. Conflating the two would let us pad this article with impressive-looking references that do not actually address the question. The NCSC guidance is the genuinely on-topic authority source we found, and we would rather say that plainly.
The failure modes, specifically
Not "the code is bad". These are checkable, and most of them are checkable by you.
No tests. This sounds abstract until you need to change something. Without tests nothing tells you what you broke except a customer, so people stop changing things, and the software calcifies. The cost is not a defect. It is that the thing becomes unalterable while your business keeps moving.
Credentials in the code. A database password or API key sitting in a file that was pushed to a repository. This is the most urgent item on the list because it is silent, and because deleting the line does not fix it: the value remains in the version history. The fix is rotation, and it is the step people skip.
Untracked dependencies. Every package pulled in is somebody else's code running with your permissions, carrying its own vulnerabilities and licence obligations. Published vulnerability records for widely used packages are searchable in NIST's National Vulnerability Database [4], so the exposure is knowable once a list exists. OWASP's current top ten includes software supply chain failures as a named category, ranked most significant by a large share of respondents [2]. The problem is not that dependencies exist. It is that no list does.
No error handling. OWASP's current list also includes mishandling of exceptional conditions [2], which is precisely this. Building for failure rather than retrofitting it later is the principle CISA promotes under secure by design [3], and it is the one fast-built software most reliably skips. Code written quickly handles the path where everything works. The visible failure is an unhelpful message. The invisible one is a half-finished operation leaving your data in a state nobody designed.
Access control by pattern. Permission checks assembled by copying the shape of similar code, rather than designed once and enforced in one place. They work for the cases somebody thought of. The gap surfaces when a user does something nobody anticipated, and at that point it is a disclosure rather than a bug.
One thing we will not do is quote you a statistic about what proportion of AI-generated code contains vulnerabilities. Every version of that figure we traced came from a company selling a scanner. Paraphrasing it as "some studies suggest" would launder the same unverifiable number, so we are leaving it out entirely.
Why nobody wants to take it over
Suppliers decline this work or price it high for a commercial reason rather than a snobbish one, and it is worth understanding before you take it personally.
Reading unfamiliar code with no tests and no documentation is slow, risky work, so quotes come back higher than you expect and occasionally higher than a rebuild. We are not going to attach a multiplier to that, because no credible source publishes one. Our guide to changing development agency sets out the full reasoning, since it is really a handover problem rather than an AI one.
A pattern we see. A business asks three suppliers to take over a small system and receives one refusal, one quote that seems absurd, and one that seems reasonable. The reasonable one has not read the code. Six weeks later it is in variations, because the parts that were going to be difficult were difficult, and nobody had looked.
Why it is nobody's fault, which matters for fixing it
Nobody did anything wrong here, and starting from blame makes the problem measurably harder to fix.
The person who built the thing usually did exactly what was asked: produce something that works, quickly, cheaply. They delivered that. What nobody specified was that it would still be running in a year, holding customer records, with three people depending on it. Had that been the brief, the build would have been different and the quote would have been higher.
So the gap is not competence and it is not the tooling. It is that the requirement changed after delivery and nobody revisited the decision. That happens with software built by large agencies too. It is simply faster and cheaper to reach that point now, which means more businesses reach it.
This matters practically because blame makes people defensive, and defensive people do not tell you where the bodies are. If you approach whoever built it asking what they would warn you about, you will get a far more useful answer than if you approach them asking what they got wrong. In our experience the original builder usually knows exactly which parts are fragile, and will say so if the conversation allows it.
The cleanup order, which matters more than the cleanup
Doing these out of sequence wastes work, and the wasted work is usually the expensive kind.
1. Understand it. Get it running in a fresh environment using only whatever instructions exist. This immediately reveals what the instructions are missing, and it is the cheapest diagnostic available. Resist improving anything at this stage.
The ordering is adapted from the sequence the NCSC prescribes before relying on AI-assisted code, which is to review it, understand it, check it for vulnerabilities and verify it [1]. We are applying it retroactively to something already running, which is not quite what it was written for, but the logic holds: you cannot safely change what you have not understood.
2. Get it under proper version control. If the only copy is on somebody's laptop or in a zip file, nothing else on this list is safe to attempt.
3. Rotate anything exposed. Before you write a line of anything. If a credential was ever committed, assume it is compromised regardless of whether it was later deleted. This is the one item that is genuinely urgent, and everything else can wait a week.
4. Add tests where it matters. Not everywhere. Around money, permissions, and anything that writes to your data. Comprehensive coverage of an inherited system is a project nobody will fund, and it is not the goal. The goal is making change survivable where a mistake is costly.
5. Then change things. Not before.
When keeping it is the right answer
Leaving it exactly as it is will often be the right decision, and we want to be plain about that before listing everything that could be improved.
Something small, working, and touching neither payments nor personal data may be entirely fine left alone. If a script has been reformatting your weekly report for eight months without incident, the correct action is nothing. Auditing it would cost more than replacing it, and replacing it would cost more than living with it.
For that category, a proportionate check is an afternoon: find out what it depends on and whether any of that is unmaintained, confirm no credentials are sitting in the code, and make sure somebody other than the original author can run it. That is it.
The case for rebuilding strengthens as the answers to four questions change:
- Does it hold personal data or take payments? This one moves the needle fastest
- Does the business depend on it daily?
- Is there a change you now need that nobody can make safely?
- Is anyone willing to maintain it?
Four noes and a yes to the last: leave it alone. As those flip, the calculation flips with them.
The UAE angle, stated carefully
If the software holds personal data, treat it as within scope of the data protection law, and our PDPL guide sets out our position including the parts we could not confirm.
We are deliberately not publishing a notification deadline in hours or a penalty figure, because no executive regulation establishing either has been published and a confident wrong number here is worse than none.
What is unambiguous is more useful anyway: not knowing where your personal data is stored, who can reach it, or which third parties receive it is not a defence, and it is a question you can answer this week rather than a legal position you need advice on.
What this actually costs you, in the parts nobody invoices
The bill arrives as four costs that never appear on an invoice: decisions nobody will make, dependence on one person, quiet drift, and a weaker position with your next supplier.
Decision paralysis. Changes stop being made because nobody is confident about the consequences. The feature your sales team asked for six months ago is still not built, not because it is hard, but because nobody wants to be the person who broke the thing.
Key-person dependency. One individual understands it, and that person becomes unable to take a proper holiday. This is the cost that shows up as a resignation rather than an invoice, and it is a genuine business risk sitting inside what looked like a saving.
Compounding drift. Dependencies age, platforms change underneath, and the gap between what the software assumes and what the world does widens quietly. Nothing breaks, until something does, and by then the update that was small a year ago is not small any more.
A weaker negotiating position. When you eventually do need a supplier, you approach them holding something they cannot assess quickly, which makes every quote higher and every timeline longer. The cheap build has raised the price of everything that comes after it.
None of that argues against having built the thing quickly. It argues for knowing which of those four you are currently paying, because you probably are paying at least one.
What you can check yourself, in an hour
Before paying anybody, four questions with no expertise required:
- Does it run on a machine that has never run it?
- Are there any tests at all?
- Does searching the code turn up anything that looks like a password or a key?
- When were its dependencies last updated?
Those four answers give you most of what an audit would tell you, and they tell you whether you need one. If everything runs, tests exist, nothing looks like a credential, and the dependencies are current, your situation is better than you feared.
What an audit costs
A codebase and dependency audit starts from around AED 4,000 with us. That covers getting the system running, mapping what it depends on, identifying exposed credentials and missing error handling, and a straight answer on keep or rebuild. These are our own figures rather than a market survey, since no official body publishes rates for this work.
The value of that engagement rests entirely on being told when the answer is to do nothing. Ask for that answer explicitly and hold us to it, because an audit that always concludes rebuild is a sales document with a fee attached. What you actually want is somebody willing to tell you your weekend project is fine.
For context on the neighbouring services, our QA guide puts a focused test pass from around AED 4,000, and our website security guide puts a hardening review from around AED 2,500 and a security assessment from around AED 5,000.
Getting a straight answer from whoever built it
Whoever built it is the cheapest source of information you have, and how you ask determines whether you get anything useful.
Ask what they would warn you about. Not what is wrong with it, which invites defensiveness, but what they would tell somebody taking it over. Almost everyone who has built something knows which parts are fragile, which shortcuts they took under time pressure, and which bit they were never happy with. That knowledge is free and it evaporates the moment the conversation becomes adversarial.
Ask three specific things while you have their attention. Which parts would you not touch without testing carefully. What did you leave unfinished or work around. And what would you do differently if you built it again.
Write the answers down. This is the handover documentation you never commissioned, and an hour of it is worth more than a week of somebody else reading the code cold.
If the original builder was you, do the same exercise honestly and write it for whoever comes next, including a future version of yourself who will not remember why any of it is the way it is.
The honest summary
The tools are not the problem and neither is whoever used them. Plenty of software built fast works and keeps working.
What causes the trouble is a mismatch: something built in a fortnight, with a fortnight's care, quietly becoming something the business depends on. Nobody decides that. It accumulates, and the care never catches up with the importance.
So sort what you have by consequence rather than by how it was made. Most of it is fine. Some of it needs an hour. A small amount needs proper attention, and knowing which is which is the entire exercise.
If you have inherited something and want a straight answer on whether it is worth keeping, contact us.
References
[1] National Cyber Security Centre, blog post on the vibe coding spectrum and AI-assisted software development, 18 June 2026. ncsc.gov.uk
[2] OWASP, Top 10:2025. owasp.org
[3] CISA, Secure by Design. cisa.gov
[4] NIST, National Vulnerability Database. nvd.nist.gov
