The Risks of AI-Generated Code and How to Avoid Them

When AI first made it possible for engineering teams to write code significantly faster, our team at Making Sense saw early on that the same speed was going to create a real risk for a lot of companies. That's when we started building a catalog to review AI-generated code internally, so we could catch these risks with our own teams before they got expensive.

Often called vibe coding, this kind of AI-assisted coding keeps becoming more common. Our CRO, Fernando Florez, already touched on this in a recent piece, focused specifically on solutions built by people who don't know how to code, and what stance companies should take on that.

As Chief AI Architect at Making Sense, though, the main concern that lands on my plate is what happens when it's the development teams themselves applying AI-coding. This happens so naturally, and it carries its own risks once there's no control in place.

That's actually where a lot of our client engagements start: we get pulled into working directly with a client's development team, and pretty quickly we find ourselves asking their CTO the same question, are you actually controlling this code? More often than not, the answer is no. So we ask them directly: what should you actually be controlling that you weren't controlling before?

What to control to reduce AI-generated code risks

To answer that, I put together a catalog of every failure mode tied to AI-generated code that I could find real evidence for. I prepared scores on two things: how bad it gets if it happens (severity), and how often the conditions for it actually show up in a normal engineering team (probability), not in a worst-case scenario.

For those not used to vulnerability scoring, those two questions don't always point to the same risks. Some issues are minor on their own, like a duplicated block of code or a missed edge case, but if they show up constantly, the combined cost adds up fast. Then there are issues severe enough to threaten a project, like an autonomous agent deleting production data, but because they are rare enough we can say it's unlikely to happen in most cases.

You can download the full catalog if you want every risk in detail, but what follows is a quick summary of the findings.

Check these because they will happen

Four risks in the catalog are both high severity and high probability, over 50% likely to show up in a normal codebase, which makes them the non-negotiable core of any policy.

Injection flaws (SQL injection, cross-site scripting, server-side request forgery, log injection) are the clearest case, and the mechanism is simple even if the name sounds technical. Generated code often takes something a user typed and drops it straight into a database query or a webpage without checking what's in it first. If that input contains code instead of plain text, the application runs it. An attacker can read or rewrite the database, or run a script inside another user's session, without needing a sophisticated exploit. Frameworks solved this problem years ago with parameterized queries and auto-escaping templates. AI-generated code keeps reintroducing it because the model optimizes for code that runs, not code that resists a hostile input. While models are getting better at avoiding these kinds of problems, they are still prevalent as the research shows.

Missing rate limiting and input validation follows the same pattern. AI builds the feature itself, but not the guardrails around it. An endpoint with no limit on how many requests it accepts, and no check on what the input should look like, is easy to abuse: scraping, repeated login attempts, or, when the app calls a metered API like OpenAI's or Stripe's, letting an attacker rack up charges on someone else's account without anyone noticing. A Q2 2026 scan of nearly 4,800 deployed AI-coded apps found this happening at real scale, including apps with several fully public endpoints and no authentication at all, some of which could delete or modify data on request.

Regulatory compliance gaps (the specific logging, retention, encryption, and consent behaviors GDPR, HIPAA, and SOC 2 require) belong here for a different reason: nothing breaks visibly when they're missing. AI builds what it's told to build, and compliance requirements are rarely part of the prompt, so the boilerplate it generates simply doesn't include them. Most teams find out during an audit, not during development, which is the worst possible time to discover the gap.

Automation bias, meaning reviewers giving AI-written code less scrutiny than it needs because it reads as confident and complete (or sometimes, just convenient), is the risk that makes the other three worse. It also has the clearest research behind it. Research by application security company Apiiro, based on data from Fortune 50 enterprises, found that AI-assisted developers produced 3–4x more commits while generating 10x more security findings. 

Common, non-severe pitfalls

Below that top tier sits a wider band of risks that are individually less severe but clear the same high-probability bar. Together, they explain why AI-generated code becomes expensive to maintain when nothing catches these patterns before they ship:

• Duplicate, near-identical code. AI regenerates similar logic instead of reusing what a team already has, so near-duplicate code piles up faster than anyone can clean it up. That extra code doesn't just sit there: it adds weight to what the browser has to load, can slow pages down enough to hurt search ranking, and often triggers more backend requests than the feature actually needs. On top of that, a fix applied to one copy doesn't reach the others, so the same bug keeps resurfacing somewhere else in the app.
• No scalability, and no visibility when something breaks. In the codebases I've reviewed for clients, this pattern shows up constantly: no database indexes, no pagination, no caching, and no logging of what happened when something breaks. None of that stops the app from working in a demo. It does mean that once the app has real users and something goes wrong, there's no way to see what happened, so the first real incident is also the first time anyone can actually diagnose the system.
• Outdated dependencies with unclear ownership. Models suggest libraries based on what they saw during training, which means the version they recommend can already be behind by the time it ships, sometimes with known vulnerabilities already documented against it. On top of that, code generated by AI likely can't be copyrighted by the company that ships it, even though it can still infringe someone else's copyright: real legal exposure with no ownership protection to offset it.
• Nobody can explain the code anymore. When AI-generated code ships without anyone reviewing it closely enough to explain why it works the way it does, that gap catches up with the team later: there's no design reasoning documented anywhere, and every future bug takes longer to track down because there's no mental model to start from.

Check these because you can't afford them even once

The catalog also flags a separate group of risks: ones that are rare in a normal codebase, but severe enough that "it probably won't happen" isn't a good enough reason to skip checking for them. This is where a policy built only around frequency falls short.

Access and exposure is the clearest cluster. It comes down to three ways a door gets left open:

1. Login and permission checks that seem to work in testing, but actually let one user see another user's private information.
2. Secret keys or passwords left sitting in the app's public code, visible to anyone who knows how to look at a webpage's source or inspect the network.
3. Databases shipped without their basic security settings turned on, so anyone who finds the address can read or change everything inside them.

None of this happens in most apps. But Infosecurity Magazine's reporting on the Moltbook incident, an AI-agent social network, shows what happens the one time it does. Security researchers found the app had shipped with a single database security setting turned off. That one gap let outsiders read and write the platform's entire database: 1.5 million access keys, tens of thousands of email addresses, and private messages between agents, all reachable by anyone who knew where to look. Nothing exotic caused it. One setting, never turned on.

Supply chain risk is the second cluster, and it takes the least effort from an attacker. Sometimes an AI coding tool recommends installing a code library that doesn't actually exist, because the model guessed a name that sounded plausible. Attackers know this happens, so they register that exact name themselves and fill it with malicious code (slopsquatting, a name I still find funny but accurate), waiting for the next developer whose AI assistant suggests installing it. In a similar way, instructions hidden inside a webpage or a document can trick a coding agent into writing harmful code, without anyone ever asking it to. Hallucinated packages, and hijacked agents all share the same root cause: something the AI trusted turned out to be the thing that caused the damage.

Autonomous and systemic risk is the smallest cluster, and the hardest to forgive when it happens. An AI agent with access to a live production system can delete real data or overwrite working code in a single action, sometimes even after being told directly not to. Code can also get a little less secure every time a model is asked to "improve" it further, so a long AI-assisted session ends up worse off than where it started. And people with no security background sometimes build and launch apps that handle real user data, with nobody in a position to catch what the AI got wrong.

Each of these is rare, but also is the kind of mistake a company doesn't get a second chance to prevent.

Turning this into policy

This is the answer I'd give to that CTO's question now: build an internal policy that focuses on the two risk groups covered above, the ones that trigger high risk for the company, and the mistakes that, even without carrying much risk, happen far more often. The two groups describe different problems, and they call for different kinds of defense.

The high-probability group belongs in automatic checks built into the development pipeline: security scanning that runs every time code changes, secret detection on every commit, checks that flag outdated dependencies, and required tests on anything touching login, payments, or user data. These need to run on their own, without anyone deciding to look, because the whole point of a high-probability risk is that it's common enough to show up whether or not someone remembers to check for it.

The high-severity, lower-probability group needs the opposite kind of defense: a short, mandatory checklist that a person reviews by hand on any deploy that touches production data, credentials, or AI agent permissions, every time, regardless of how the last ten deployments went. No agent gets production database access without a named person signing off on it first. No new code library gets installed without a quick check that it's real and maintained. No app ships without a scan for keys or passwords left in the public code. None of these checks take long to do. What they need is to stay on the list permanently, because a failure that only happens once a year is exactly the kind a team stops remembering to check for.

That's the real shift this catalog is meant to support: moving from reviewing based on how the last few weeks went, to deciding in advance what gets checked no matter what. It's also the groundwork for a question we're picking up next: what it actually takes to turn a working AI-assisted prototype into software a business can run on long after the first demo.

If your team is shipping AI-assisted code faster than your review policy can keep up with, complete the form to get in touch with Making Sense's Agentic AI Solutions team. We'll help you map these risks against your own codebase and build the policy before the gap gets expensive.