Vibe-coded apps ship fast and break security

Bob Starr launched his website and only months later discovered it carried a hidden SQL injection risk, a basic web security flaw that can let attackers tamper with or extract data if input isn't handled safely.

That detail matters more than the novelty of the project. Starr's site, called Boomberg, was built through what the industry now likes to call vibe coding: telling an AI system what you want, getting working code back, and shipping before anyone has done the dull, necessary audit. Silicon Valley loves that story. Security people usually don't.

Starr had been pleased with the result. Boomberg showed how much US tax money is going to tech companies, and he published it immediately after making it, according to reports. The problem, as he later realized, wasn't whether the site worked. It did. The problem was what else the code allowed.

And that's the piece a lot of the AI coding hype keeps trying to skip. Generative coding tools are very good at producing software that looks finished. They are much less reliable at producing software that is actually safe, maintainable, or even fully understood by the person deploying it. Those are different things. The market keeps pretending they are the same.

The old bugs are still here

SQL injection is not some exotic frontier threat. It's one of the oldest web application failures in the book, described for years by security guidance from groups including OWASP and discussed broadly in software security standards from the US National Institute of Standards and Technology. If a coding assistant still helps users ship code with that sort of weakness, then the sales pitch needs a little less magic and a lot more honesty.

Here's the thing: vibe coding doesn't invent new security problems. It revives old ones at speed. A user prompts a model, gets a polished-looking app, sees it run, and mistakes functional for safe. That's an easy trap for beginners. It's also an easy trap for experienced people moving too fast, which is more of the industry than anyone wants to admit.

The danger isn't that AI writes weird code. It's that it writes ordinary bad code fast enough for people to trust it.

The pattern should feel familiar to anyone who has watched the last two years of AI product launches. Tools are sold as accelerants, which they are. But acceleration without review just means errors travel faster. We've seen the same split before in adjacent corners of tech: capability first, controls later, cleanup after the fact. That's been true in consumer AI, enterprise copilots, and, as BreakWire has already reported in security coverage, in the broader race to bolt automation onto systems that were already messy.

Why the pitch lands anyway

People keep vibe coding because it feels incredible. A blank page turns into a usable product in minutes. For a founder, hobbyist, or analyst with an idea and no patience for frameworks, that's intoxicating. It also lines up neatly with the current AI marketing line: software creation is becoming conversational.

Some of that is real. Large language models can generate code, explain libraries, and connect pieces of a stack well enough to get an application running. A large language model, in one clean sentence, is software trained on huge amounts of text so it can predict the next token and produce plausible language or code on demand. Plausible is doing heavy lifting there.

Still, plausible output is exactly why these systems can be risky. They don't understand an application's threat model, business logic, or deployment context the way a careful engineer does. They predict patterns. If those patterns include insecure examples scraped from the public internet, rushed shortcuts, or brittle assumptions, the model can reproduce them with confidence. Confidence, annoyingly, is free.

That's also why the labor story around AI coding has been overcooked. This isn't a clean swap where a model replaces a software engineer. It's closer to shifting work around. You save time on scaffolding and repetitive tasks, then you spend time reviewing, testing, and fixing what was generated. If you skip the second part, you aren't efficient. You're just borrowing trouble.

The gap between demo and deployment

Starr's case lands because it is so ordinary. There was no dramatic breach in the signal, no movie-plot exploit chain, no nation-state intrigue. Just a website, a quick launch, and a latent flaw that should have been caught before production. That's not an edge case. That's the most believable outcome of mass-market AI coding tools placed in the hands of people told they can move straight from idea to internet.

And the gap between a demo and a dependable product is where most of tech history lives. Silicon Valley has always glamorized the first half and outsourced the second. AI coding compresses the front end even further. It doesn't compress responsibility. If anything, it raises it, because more people can now publish software without absorbing the habits that older development cultures drilled in through pain.

That matters beyond hobby projects. If vibe coding spreads inside companies, the risks stop being personal and start becoming institutional: internal tools with weak authentication, customer-facing apps with injection flaws, dashboards connected to real databases, automations touching payroll, health records, or procurement systems. A semiconductor fab is a factory that prints circuits onto silicon wafers in tightly controlled clean rooms; nobody would run one on vibes alone. Yet software that touches money and data is still being pitched that way.

We've seen a similar mismatch in other corners of AI, where splashy capability gets treated as proof of maturity. It isn't. A breakthrough changes what is possible. A product launch changes what is being sold. Those are not synonyms, and a lot of companies would prefer you stop asking which one you're looking at. The same skepticism applies whether the subject is scientific prestige, as in BreakWire's reporting on AI talent moves, or consumer policy pressure, as in its coverage of platform controls in India.

What careful teams will do now

The sensible response is not to panic and ban AI-assisted coding outright. It's to treat generated code like junior code written very quickly by someone who won't be on call when it fails. That means code review, security scanning, input validation, least-privilege database access, and testing before deployment. The boring checklist is still the checklist. You don't get to skip it because the code arrived in a pleasant chat window.

External guidance on secure development has not changed because chatbots got better at autocomplete. Resources from OWASP's Top 10, general software assurance work at NIST's Computer Security Resource Center, and long-running public explanations of SQL injection all point to the same conclusion: the vulnerabilities are known, the mitigations are known, and speed is not an excuse.

But that requires a cultural shift in how these tools are sold. The current framing flatters the user: you had an idea, the machine made it real, look how productive you are. The less glamorous framing is truer. You now have the power to create attack surface at the pace of a prompt. That's not liberation — it's liability dressed up as convenience.

Watch what the AI coding vendors emphasize next. If the next wave of launches leans hard on auditing, guardrails, and security review, they will be admitting the obvious. If they keep leading with speed alone, expect more stories exactly like Starr's, because the underlying math won't change.