What to Ask Before You Ship AI-Generated Code

The spec sheet was spotless.

Every resource budgeted, every edge case spelled out, every version pinned. No tired developer writes like that at 4 p.m. on a Thursday.

The CTO at an auto parts distributor sent me the sheet so I could size a development environment. His team wanted somewhere safe to test their new fitment tool — the thing the counter clerk pokes at to see what brakes fit your 2018 Silverado pickup.

I read it twice, then asked who wrote the app.

Claude Code wrote the app.

Over a few weeks, their developer had prompted his way through the whole thing. No security reviews, no frameworks, no unit testing. Prompt, fix, prompt again. Roughly 35,000 lines of code later, they had a working app.

The lookup returned the right parts. The demo was smooth. Everyone was ready to test.

The CTO could have told me just to get the test server ready. He sent me the code for review instead.

TL;DR — 35,000 lines of AI-written code, working perfectly. Nobody had read it. And it could reach every customer record in the business. The five questions at the end would have caught it before anyone wrote a line.

Security Problems Everywhere

I ran the code through Snyk, a security scanner. It came back with:

SQL injection
Authentication bypass
Cross-site request forgery
Cross-site scripting

This was not surprising.

Generate code by prompt with nobody owning security and this is what you get.

Critical vulnerabilities everywhere.

The research agrees. In April 2026, Cobalt AI ran 3,500 code samples from seven frontier models through a formal verification pipeline (Broken by Default):

55.8% carried at least one provable vulnerability
Six commercial scanners, combined, missed 97.8% of what the formal prover caught

Cobalt sells the prover, so discount that second figure. Discount it hard and the lesson still holds: scanning after the fact catches a fraction of what’s in there. Security has to be part of how the code gets written.

35,000 Lines of Code?

Thirty-five thousand lines of custom code for a simple parts lookup tool. That’s what the AI produced.

It had reinvented the wheel, over and over. Thousands of lines of custom database handling. A hand-rolled authorization system deciding who could see what. Custom routing, custom session logic, custom input handling. All built from scratch.

Every one of those is a solved problem. Mature frameworks handle database access, authorization, and routing with code thousands of developers have hardened over a decade.

Building it yourself when a proven version exists costs you twice. You have to maintain it, and you have to secure it.

Point the AI back at it and you’ll find it has no memory of writing any of this. Months on, the context is gone and the models have changed. Those thousands of lines are as unfamiliar to it as they are to you.

Small Tool, Big Reach

The CTO wanted assurances. They had never shipped AI-written code before, and they had bigger plans behind this one. Something surfaced on our call.

The fitment tool was low stakes. No proprietary data, no customer information, no payment details. A simple internal lookup.

What they missed was where it lived. The tool shared a database with their live e-commerce store.

That single decision changed everything. The tool held nothing sensitive of its own. But it could reach customer orders, account records, and payment-adjacent data for the public storefront. The authentication bypass I found in the boring internal tool opened a door into all of it.

An app’s blast radius isn’t defined by what it’s for. It’s defined by what it can reach.

I’ve Made the Same Mistake

Knowing better doesn’t seem to help.

A few months back I needed to process some server logs. All I wanted was a bash script for one specific task. I fired off a prompt and walked away.

Two hours later, Claude Code was still churning.

It had turned my bash script into a full log-correlation engine. Handlers for formats I never mentioned. Timestamp normalization across systems I don’t run. Parsers for edge cases that will never occur in my environment. Thorough, impressive, and about ninety percent of it solved problems I don’t have.

My instruction was loose. Meanwhile the tool was building stuff I would never need. A little more oversight would have gone a long way.

My Recommendation

After meeting with their team I had a clearer picture of what they were doing. This was their developer’s first production app built with Claude Code. He’d been using it to clear legacy code that was holding up other infrastructure work, and the speed was real. That’s why nobody questioned the approach.

I still couldn’t work out why a database lookup and search tool needed that much code. So I pointed my own AI tooling at the repo to see which libraries and frameworks they had used. None.

That explained the reinvented wheel. Nobody told it not to.

What they needed was structure:

A PHP framework
Security built into the process that writes the code
Testing as they went, where it mattered

After talking to their devs, I recommended Symfony, since they already knew it. Snyk for security, wired into the build — the easiest to use of the ones I tested. And unit and security tests on every commit.

They refactored on that basis. Security problems went from hundreds to dozens.

More impressively:

35,000 lines became 6,000.

Whatever security issues were in those 29,000 lines disappeared with them.

With that structure in place, the AI stopped reinventing and pulled in trusted modules instead. Snyk caught security problems as they appeared, and the tests confirmed each change worked.

Someone Has to Manage AI

Strip away the technical jargon and the problem has little to do with AI.

Their developer worked the way AI encourages you to work — racing down the highway without a seatbelt.

AI is powerful, but it needs guardrails.

After the refactor and the warning lights were out, the CTO asked how they should be using AI.

Use it anywhere, was my answer, as long as someone manages it.

I’m not going to tell a business to ban a tool that lets them build what their business needs.

Five Questions to Ask

“Someone manages it” needs teeth. These are the questions worth asking before you ship AI-written code. Every one of them came out of that engagement.

Question	A weak answer	A real answer
1. Do we trust AI with this data, or this process?	“It’s just an internal tool.”	We know what it touches: our data, our code, our infrastructure.
2. What do we need besides the AI?	“Our developer knows what he’s doing.”	We will use this framework, this security process, and this quality control during the build.
3. How do we know what it built is secure?	“It passed the scan.”	We’ve identified the core risks and how we mitigate them, including what a scanner won’t flag.
4. How do we know what it built is maintainable?	“We’ll have the AI fix it later.”	We are using proven libraries to minimize the custom code anyone has to maintain.
5. Who sets the guardrails?	“We’ll sort that out as we go.”	I will, with our team.

If nobody manages the process, the AI agent will determine your security. That’s how you end up with thousands of lines of code with the security flaws to match.

Any good developer can answer the first four. The fifth takes someone who understands how building with AI changes the risk to your business.

I caught this because I’ve read a lot of spec sheets. Asked at the start, those five questions would have spared them the refactor.If you’re hitting pause on an AI project of your own, reach out. I may be able to help you get it back on track.