AI tools make one software failure mode much easier to miss: a bad product decision can now arrive wrapped in a working interface.

In a matter of minutes you can spit out something with a login page, a dashboard, a settings screen, maybe even a checkout flow. Because it all looks coherent, people start treating it as if the important decisions have already been made. They have not. Mostly you get a slick shell with a vacuum where product judgment should be. The system may look complete while still lacking data isolation, error recovery, access control, and basic operational boundaries.

This is where "vibe coding" becomes dangerous for anything beyond prototypes. The current generation of generative tools can produce software-looking things faster than teams can define ownership, privacy rules, failure behavior, and support boundaries. The Val Town essay gets at this: the builder may forget that the code exists. That can be fine for one-off projects. It is a bad trade for anything that has to live, change, and survive reality.

Code that a model writes and the builder cannot understand is legacy code on day one.

Programming is more than syntax. It is theory building. You need an internal model of how the pieces fit together, what assumptions they make, and where the boundaries are. A generative model can write code for you. It can generate believable implementations without generating understanding. So the UI can appear full, while the system is conceptually empty.

The tool will gladly choose default behavior. It will gladly disregard policy trade-offs. It will happily spit out something that demos well, then falls apart the second you ask it to behave like a real system.

Software teams already had a weaker version of this problem. A high-fidelity mockup could fool non-technical people, or at least cause enough confusion that engineers had to step in and say no, this is not done. In a Hacker News thread, developers talk about telling coworkers not to show polished designs to managers because it makes everyone think the feature is finished.

Today the prototype is often connected to a live database and deployed on a public domain. The surface behavior no longer says only "this looks real." It says "this is real enough to be dangerous."

That puts a lot of pressure on teams to skip engineering review. If the app works in a short demo, the natural reaction is to ship it. But a prototype is for proving a concept, not for handling hostile traffic on the public internet. Once you put a half-understood prototype into production, the missing product decisions are no longer theoretical. They become operational failures.

There is a page called "My Account," which sounds reassuring, but unless there are backend authorization rules, the label is just decorative text. The interface promises one thing. The system delivers another.

These security implications are not theoretical. Axios reported that an audit found 380,000 publicly exposed assets across deployment platforms, with 5,000 containing sensitive corporate data like financial and medical documents. CVE-2025-48757 describes a similar issue around insufficient database row-level security policies in applications generated by Lovable. A vulnerability scan found that the flaw affected more than 170 apps and allowed unauthenticated actors to read and write database tables.

Superblocks explains that row-level security was never configured on the backend and that client-side credentials were directly querying the database. That is what happens when the system is "finished" before the core policy decisions exist.

The AI can build the interface, but it does not decide who owns which record. It does not restrict one customer's access to another customer's data. It does not decide what to block, what to log, or what must never leave the server. These are product decisions, not code-completion tasks. They do not exist unless human beings force them into existence.

WIRED discusses this by comparing the risk to open-source dependency problems, but without the same clear line of accountability. It is a good analogy because the failure mode is familiar: something feels reusable and composable, but the danger sits in the hidden assumptions. The difference is that hand-written code often makes those assumptions more explicit than generated code does. Without a formal review, the omissions may not be detected until someone finds out the hard way.

This is also a delivery problem, not just a security problem. The DORA generative AI report says AI adoption improves individual productivity but can hurt delivery outcomes. Specifically, it finds that a 25% increase in AI adoption is associated with a 1.5% reduction in software delivery throughput and a 7.2% reduction in delivery stability. That should not be surprising. Faster code generation does not mean better software delivery. It can just mean more code before the organization gets a chance to think.

DORA also says highly user-centric organizations perform 40% better. That matters because without it, AI just creates a faster feature factory. More output, not necessarily more value. More features, more surface area to fail, and no clearer idea of what the user actually needs.

The useful response is discipline around the generated work. DORA's platform engineering guidance points to developer platforms that automatically enforce security checks, testing protocols, and deployment guardrails. That is the right way to work with large amounts of generated code. CyberScoop makes the same basic point: AI-assisted development is inevitable, but its speed demands more rigorous verification. A generated interface should start the product conversation, not end it.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com