The last two weeks of September were rough for anyone who believed AI writes production software. Researchers disclosed a vulnerability — dubbed Plugin4Shell — affecting four of the biggest AI coding agents on the market: Anthropic's Claude Code, OpenAI's Codex, GitHub Copilot, and Google's Gemini CLI. The flaw could let an attacker trick the agent into installing malicious plugin code onto a developer's machine, even when the developer believed the plugin was pinned to a previously reviewed version. The agents weren't actually verifying the version they downloaded — and with auto-updates enabled by default in two of the four, the path to code execution on a developer's machine reportedly required zero clicks.
That was the security story. The productivity story landed a day later. A poll of 300 software developers and engineering leads across the UK and US, published September 28, found that 93% of teams have experienced AI hallucinations causing incorrect diagnoses in their code. More than half say coding agents introduce incorrect code too frequently. Ninety-four percent admit they're losing productivity having to analyze AI-generated code at least once a month. Developers now spend an average of 16.9 hours a week — roughly twice as long as they spend writing code — debugging. And more than a third of AI-generated code reaches production before the team fully understands what it does.
Read those two stories together and they say the same thing: generating code got cheap. Software didn't. The part of software that costs money was never the typing. It was everything after the typing — and that bill is arriving now, made out to whoever owns the system.
If you run a business and you're thinking about custom software — or if you already have an app that an AI tool, a freelancer, or a former employee put together — this is the conversation you need before the 2 AM version finds you.
The free-code illusion
Here's the honest accounting that the "AI built my app in a weekend" stories leave out. Code is a draft. Software is a product. The distance between those two things is where the real money lives, and it's the same distance it's always been.
Writing the code was never the expensive part of software. The typing was always the cheapest phase. What costs money is making the code correct, keeping it correct as everything around it changes, protecting the data it touches, and being there when it breaks. None of that got automated. The models generate the draft faster; every phase after the draft still needs a human who knows what they're looking at — and the September poll suggests those humans are now spending more time, not less, cleaning up after the generator.
Think of it this way. A house frame goes up fast. The framing crew is not the expensive part of the house. The expensive parts are the foundation engineering, the electrical that won't burn the place down, the plumbing that doesn't leak in year three, the inspections, and the roofer you can call when the storm hits. AI just gave everyone a faster framing crew.
You're not paying for the code. You're paying for the part after the code — the three bills that arrive after the demo.
Bill #1: The security nobody reviewed
This is the scariest of the three, because it's the one that can end a business.
AI-generated code fails at security at stubborn, measurable rates. Veracode's Summer 2026 evaluation put 11 frontier models through 80 coding tasks and reported an average security pass rate of 56% — meaning nearly half the tasks produced a known vulnerability. A broader Veracode evaluation across more than 100 models and four languages found AI-generated code carries 2.74 times the vulnerabilities of human-written code and fails secure-coding benchmarks 45% of the time. Their 2026 update found that newer, larger models scored no better than smaller ones. Capability went up; the security gap didn't close.
Real codebases tell the same story. Apiiro, studying actual Fortune 50 repositories, found 322% more privilege escalation paths and 40% more secrets exposure in AI-assisted codebases.
Then there's the supply-chain angle, which is sneakier. Researchers from the University of Texas at San Antonio, Virginia Tech, and the University of Oklahoma tested 16 code-generating models across 576,000 samples and found that 19.7% of the time, the model referenced a package that doesn't exist. That's why security researcher Seth Larson coined the term "slopsquatting": an attacker observes which fake names the models suggest, registers them on the package registry, and waits for a developer — or an autonomous agent — to install one. Your app's dependencies can be poisoned by a hallucination that happened months ago, on someone else's machine.
And Plugin4Shell showed the tools themselves are attack surface, not just the code they produce. The agents millions of developers now rely on weren't verifying the integrity of the plugins they installed. The vulnerability class is almost embarrassingly basic — check that the thing you downloaded matches the hash you were given — and four flagship products missed it.
Now bring this down to your business. Your app holds customer names, phone numbers, addresses, payment records, maybe health or legal information. If that app was generated and never security-reviewed by someone who does security for a living, you're holding your customers' data in a container with a 2.74x vulnerability multiplier. You won't know there's a problem until someone else finds it — and "we generated it with AI and nobody reviewed it" is not a defense your customers, your insurer, or a regulator will accept.
This is not an argument against AI-assisted development. It's an argument against unreviewed development. The models are drafting tools. Drafts need editors — specifically, editors who think adversarially about what could go wrong with your customers' data.
Bill #2: The maintenance nobody owns
Software rots. Not metaphorically — literally, measurably, on a schedule.
The code your app is built on depends on libraries, frameworks, APIs, and platforms that all change on their own timelines. Payment processors update their APIs. Apple and Google change app-store requirements. Certificates expire. The AI model your app calls gets updated and starts behaving differently. Every one of these is a maintenance event, and the app doesn't care that nobody's watching. It just breaks.
The September data shows the maintenance burden is growing. GitClear's analysis of 211 million lines of committed code found duplicated code blocks up 81% since AI tools went mainstream, while refactoring — the disciplined work of keeping a codebase healthy — fell sharply. Code that gets moved and restructured dropped from 24.8% of changed lines in 2023 to 9.5% in 2024. Duplicated code is future bug surface: fix it in one place, miss it in the other three, and spend next quarter wondering why the same bug keeps coming back wearing a different hat.
Here's what that means for a business owner with an AI-generated app and no developer: the app works today. In three months, a dependency updates and a feature silently breaks. In six months, an API you depend on deprecates the endpoint you're calling. Each event is small. Together they're a slow-motion collapse — and there's no one to call, because the thing was never anyone's job to maintain.
This is the failure mode I see most often in rescue conversations: the app isn't broken today, it's abandoned. It was built in a burst of enthusiasm — by the owner on a weekend, by a freelancer who delivered the files and disappeared, by an employee who's since left the company — and now it sits in production with no owner, accumulating risk. The business depends on it. Nobody maintains it. Everyone assumes someone else is watching.
Maintenance isn't glamorous, which is exactly why it gets skipped right up until the outage. But it's the difference between software you own and software that owns you.
Bill #3: The 2 AM problem
This is the one that keeps me up at night — literally, because in my business, I'm the one who gets the alert.
Every production system fails. The question is never whether; it's what happens in the minutes after. A system built to be operated fails loudly: monitoring catches it, alerting pages someone, automatic retries absorb the transient blips, complete logs show exactly what happened, and a rollback path restores the last known good state. A prototype has none of this. It fails silently, corrupts data quietly, and waits for someone to notice at month-end — or for a customer to call and ask why their invoice is wrong.
The most damning number in that September poll: more than a third of AI-generated code reaches production before the team fully understands what it does. A third of the code running in production — handling real customer data, real money, real operations — is code the team that shipped it doesn't fully understand. When that code fails at 2 AM, there is no one who knows it well enough to fix it.
This is why "who fixes it at 2 AM" is the single most important question in custom software, and why it's the question almost nobody asks before commissioning a build. Demos don't have 2 AM. Prototypes don't have 2 AM. Production does, every night, forever.
The reliability stack that answers the 2 AM question has four parts, and I consider them non-negotiable for anything a business depends on. Real-time monitoring and alerting — the builder knows something needs attention before you do. Automatic retries — transient failures like API timeouts and rate limits handled without human intervention. Complete logging — every action recorded with full context, so nothing is a black box. And rollback and recovery — the ability to revert to the last known good state, so your operations are never left in limbo. That's the standard. It's not exotic. It's what "working software" has always meant.
Notice what that list doesn't include: the AI model. The model is the easy part now. The other eighty-five percent — the part that determines whether your business keeps running on a Tuesday night in February — is operations. And operations is a service, not a file. You can't download it. You have to hire someone to do it, every day, for as long as the software matters.
The three ways businesses end up with unowned software
I've watched this movie enough times to know the three scripts.
Script one: the owner built it themselves. A capable business owner spends a few weekends with an AI coding tool and produces something genuinely impressive — a quoting tool, a dashboard that pulls from three systems. It works. Then it becomes load-bearing: the team depends on it, customers touch it. Then it breaks, or the platform changes something underneath it. The owner is running a business, not a software shop, and the weekends run out. The app that was a triumph becomes a liability, and there's no graceful handoff because it was never built to be handed off.
Script two: the freelancer delivered and disappeared. The files arrived. The invoice got paid. The app launched. Six months later it needs an update and the freelancer is gone. The new developer you hire opens the codebase and finds generated code with no documentation, no tests, and architectural decisions nobody can explain. Rescue quotes come back higher than the original build, because untangling someone else's undocumented system is harder than building clean.
Script three: the employee built it and left. A sharp operations person builds internal tooling the whole company comes to depend on. They leave. The tooling stays, unmaintained, understood by no one. IT is afraid to touch it; the business is afraid to lose it.
All three scripts share one root cause: the software was acquired as a product and never assigned an operator.
What production-grade actually includes
So what does the alternative look like — software that's built to be owned and operated, not just generated?
It starts before a line of code is written. A real scoping phase: requirements, user flows, wireframes or mockups, a feature list, a technology recommendation, and a fixed-price quote. You should be able to take that plan and compare it against other quotes, because a builder confident in their scoping isn't afraid of comparison. The planning work should be credited toward the build if you proceed — you're paying for thinking, not for a sales document.
The build itself should be transparent: working software you review every week, deployed to a staging environment — not mockups and status reports. Fixed price, so the number you agreed to is the number you pay. Delivery in weeks, not quarters — most business applications should ship in 2 to 4 weeks, because the scope was defined properly up front.
Then the part that actually matters: someone operates it. 24/7 monitoring. Security patches applied. Backups running. Bugs fixed as they appear. New features built when you need them. Infrastructure that scales when you grow. And the relationship structured so the incentives align — month-to-month after launch, so the operator has to keep earning your business instead of locking you in.
And ownership has to be explicit: you own the product and your data. The builder owns the infrastructure and the operations. That split is the whole model — you get the asset, they carry the 2 AM problem. If a builder won't state plainly that you own what you paid for, that tells you everything about the relationship you're entering.
None of this is new. It's what professional software delivery has always looked like. What's new is that AI made the undisciplined version so easy that the disciplined version started looking expensive by comparison. It isn't. The undisciplined version is just billing you later, with interest, in the form of breaches, outages, and rescue projects.
Ask these before anyone builds your software
Whether the builder is a person, a shop, or an AI tool with a human supervising it, run through these questions before you commit. The answers tell you whether you're buying software or buying a future problem.
Who monitors it after launch? If the answer is "you'll get an email if something breaks" or a shrug, you're looking at a prototype with a price tag. You want a named party watching it around the clock.
Who applies security patches, and on what schedule? Dependencies have vulnerabilities. The answer should be a process, not a person you hope is available.
What's the rollback plan? If a deploy goes wrong on a Friday afternoon, how does the system get back to working? "We'd figure it out" is not a plan.
Do I own the code, the data, and the exit? You should be able to leave with your product and your records. Anything less is a hostage clause wearing a service agreement.
What's the monthly number after launch? Software has an operating cost. A builder who won't name it is either hiding it or hasn't thought about it. Neither is good.
Show me something running. Not screenshots, not a demo video — a live product, in production, that real users depend on right now. An app on the App Store. A platform handling real traffic. Then check that it's monitored, maintained, and still standing. Anyone can show you a demo. Ask to see what's running.
If the answers are solid, the price is almost always fair — because you're comparing the full cost of owned, operated software against the fantasy price of a file that generates itself. The fantasy always wins on the quote. It never wins on the total.## The bottom line
September 2026 taught the industry a lesson it keeps having to relearn: the bottleneck in software was never how fast you can produce code. It's how well you can stand behind it. The Plugin4Shell disclosure, the Veracode numbers, the Undo poll, the slopsquatting research — they're all the same story told four ways. Code is cheap now. Responsibility isn't, and it never was.
Here's what working with me looks like, straight from the published terms. It starts with a free fit call and a free scope and estimate — twenty minutes, and I'll tell you straight if we're not the right fit for your project. If we are, the Blueprint phase is $1,500 one-time: requirements, user flows, wireframes, a feature list, technology recommendations, and a fixed-price quote. That fee is credited directly off your build cost if you proceed, and if the Blueprint isn't delivered within 14 days of kickoff, it's free. You keep the plan either way — compare quotes if you want.
The build — App Launch — is fixed-price starting from $10,000, delivered in 2 to 4 weeks, with weekly working demos, managed hosting included, and data migration and setup. After launch, App Care starts from $500 a month, month-to-month, cancel anytime: 24/7 monitoring, security patches, backups, bug fixes. The Growth Partnership runs $1,000 to $2,000 a month on top of care for ongoing development. Most first versions land in the $10K to $20K range. Third-party services — payment processors, SMS, email — are pass-through costs billed separately.
I'm Zach Vorsteg, a technical founder in West Palm Beach, and I do the work myself — no junior developers, no account-manager telephone. My track record is verifiable, not asserted: Trusenda, a full-featured CRM I designed, built, and shipped, is live on the Apple App Store right now, running with production-grade monitoring and uptime discipline. Web platforms in production. Marketing systems managing real ad budgets for real businesses today. No testimonials — just links you can click. Verify it yourself.
Code is free now. The question was never the code. It's who fixes it at 2 AM — and whether anyone's watching before it gets that far.
Get a free scope and estimate — we'll plan it together. Reply within one business day.