We use AI tools every day. This is not an article about how they are ruining software.
It is an article about an asymmetry that almost nobody priced in:
The cost of writing code collapsed. The cost of owning code did not change at all.
Writing was never the expensive part. Reviewing, testing, securing, maintaining, and being able to change something two years later without breaking three other things — that was always where the money went, and none of it got cheaper. What changed is that a great deal more code now exists, produced faster than anyone's capacity to review it, and a share of that code is now sitting under your business.
The evidence, with sources
This is not a vibe. Three independent bodies of work point the same way.
Veracode tested more than 100 large language models across 80 real-world coding tasks. When a model had to choose between a secure and an insecure implementation, it chose insecure 45% of the time. Broken down: 86% of samples failed to defend against cross-site scripting (CWE-80) and 88% were vulnerable to log injection (CWE-117). Java was worst at over 70% failure; Python, C# and JavaScript sat between 38% and 45%. The finding that should worry buyers most: as the models got better at writing code that works, they did not get better at writing code that is safe — Veracode's own report.
Georgia Tech runs a project called Vibe Security Radar, scanning security advisories for vulnerabilities attributable to AI coding tools. Across more than 43,000 advisories it confirmed 74 vulnerable cases — 14 critical, 25 high risk. The trajectory matters more than the total: 18 cases across the second half of 2025, 56 in the first three months of 2026, and 35 in March 2026 alone. The flaws were command injection, authentication bypass and server-side request forgery — Georgia Tech Research.
And the structural insight from that work is the one to carry with you:
Because AI models repeat similar errors, an attacker only has to find a bug once to potentially exploit it across thousands of repositories built with the same tools.
That is a genuinely new risk shape. Historically, a small business's obscurity was a defence — nobody was looking for you specifically. If your site shares a generated pattern with ten thousand others, obscurity stops working. You are not a target; you are a match.
Scanning of production applications reported by OX Security, citing Escape.tech's review of 5,600 applications, found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 instances of exposed personal data. Exposed secrets — API keys, database passwords, payment credentials committed into code — are the cheapest catastrophic failure available.
The question that has changed
The instinct is to ask a vendor: did a human write this?
That is the wrong question, and it will get a useless answer. Every serious studio uses these tools, including us. Provenance is not the variable.
The variable is reviewability. Ask instead:
If you disappeared tomorrow, could another developer understand this well enough to fix a bug under time pressure?
Code written by a person who did not understand it and code written by a model that had no concept of your business are the same liability. Both are unowned. The defining property of unowned code is not who typed it — it is that nobody can explain why it is the way it is.
A due diligence checklist for a non-technical owner
You do not need to read code to run these. Every one is a question with an answer you can evaluate.
1. Where are the secrets? Ask: "Show me how the production database password reaches the server." The correct answer involves environment variables or a secret manager, never a file in the repository. On Bronjoy a deploy fails before running migrations if a production secret is missing — the system refuses to start half-configured rather than starting insecurely.
2. What do the tests cover? Ask for the number and what happens when one fails. The number is not the point; the existence of a habit is. Knigopoisk runs 171 tests and 898 assertions in parallel, including a regression test that fails the build if an admin column ships without a label. BiliMind has 164 backend tests. Those are not impressive numbers in absolute terms. They are evidence that someone decided failures should be loud.
3. Are the rules enforced in the database or only in the interface? This is the single best technical question a non-technical person can ask. On Xceed, the live football platform we built, Postgres row-level security enforces three roles and database triggers enforce tournament rules — so invalid states are rejected even if the interface is bypassed entirely. If the answer is "the button is disabled for those users", your rules do not exist; your decoration does.
4. Can the same mistake happen twice?Nomadeo isolates tenants in three layers: request context, a branded transaction type that makes a missing tenant a compile error, and Postgres row-level security. The interesting one is the middle layer — a design where the dangerous mistake will not build. Ask what class of error your system makes impossible rather than merely unlikely.
5. Has anyone read it? Ask whether the code was reviewed, by whom, and whether that person could explain the parts they did not write. "It passed the tests" is not a review.
6. What does the dependency list look like? Every package is a third party who can break or compromise you. Ask how many there are, when they were last updated, and whether anyone is watching for advisories.
7. Can you leave? Is the source in your Git organisation, are the cloud accounts in your name, and could another developer pick it up? We put this in writing: you own the code and every account from day one — if we vanished tomorrow, another developer could pick it up. Source code is included on every plan, from the $99 landing page upward. We cover the wider version of this in the case against your page builder.
What a good answer sounds like
The questions only help if you can tell a real answer from a confident one. Three examples.
"Where are the secrets?"
- ⚠️ "Don't worry, it's all secure." — no information. Ask again.
- ⚠️ "They're in the config file, but the repo is private." — that is a secret in your codebase. Private today, shared with the next contractor tomorrow, and present in every historical commit forever.
- ✅ "Environment variables set on the host / in a secret manager. Nothing sensitive is in the repository, and here is how you'd rotate one."
"Are the rules enforced in the database or only in the interface?"
- ⚠️ "Users can't see that button." — that is not enforcement, that is a curtain.
- ⚠️ "The API checks permissions." — better, and worth one follow-up: does every endpoint check, or only the ones somebody remembered?
- ✅ "Roles are enforced at the data layer, and the constraints are in the database, so an invalid state is rejected even if the API is called directly."
"Can you leave?"
- ⚠️ "We'll give you the files if you need them." — you do not have it, you are being promised it.
- ⚠️ "It's in our repository, we can transfer it." — same problem, later.
- ✅ "It is already in your organisation. Here is your access. The infrastructure accounts are in your name and you hold the billing."
The pattern across all three: a good answer describes a mechanism; a weak one describes an intention. You do not need to evaluate the mechanism. You only need to notice which kind of answer you got, and that is a skill anyone can apply in a meeting.
If you get three intentions out of three, you have learned something important without reading a line of code.
What to do if the answers are bad
Do not panic-rebuild. Sequence it.
Rotate the secrets first. If credentials were ever in the repository, assume they are public. This is a day of work and it is the highest-value day available.
Get an independent read. A performance and code audit from $90 tells you what you actually have. The point is a written finding you can act on, not a sales pitch — and you should be able to take that finding to any developer, including a different one.
Fix by blast radius, not by severity label. Anything touching payments, personal data or authentication comes first. A cosmetic bug on a marketing page can wait a year.
Then decide. Sometimes the answer is a targeted fix. Sometimes it is a rebuild, and the honest version of that conversation includes what it costs and what it does not fix.
Why we take this personally
One of the five commitments on our about page is this:
No tricks, no bad code. "In this industry it is easy to fool a client who cannot read code. We will never do that."
That commitment is older than this problem, and it has become more load-bearing since. The reason it matters commercially rather than just morally is simple: the client cannot verify the thing they are buying. Software is one of the few purchases where the buyer's only protection is the seller's standards.
The practical expression of it, beyond the checklist above, is that we send fixes back to the projects we depend on rather than patching privately — merged fixes to Filament, a Chart.js plugin change for reactive frontends, upstream bug reports. Code we cannot show is code we have not thought hard enough about.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Should I ask my agency not to use AI tools?
No, and any agency that agrees is either lying or slower than it needs to be. Ask instead what their review process is, what their tests cover, and where their business rules are enforced. The tool is not the risk; the absence of a check is.
How do I know if my current site has these problems?
The seven questions above, asked of whoever maintains it, will tell you most of it in an hour. If nobody can answer them, that is itself the answer.
Is a small marketing site really at risk?
Less than an application handling payments, but not zero — exposed credentials, contact form abuse and outdated dependencies affect everyone. The concrete exposure is usually a form that sends email, a plugin nobody updates, and an API key in a JavaScript file.
What does a proper security review cost?
Far less than the incident. For a typical marketing site it is a contained piece of work; for an application handling money or personal data it should be a scheduled, repeated exercise rather than a one-off.
Is any of this going to get better?
The models are improving at writing correct code faster than at writing secure code — that gap is the specific finding in Veracode's work. Assume the review burden stays with you, and build the habit rather than waiting for the tools to remove the need for it.
