AI mass-produces apps, and also lays hidden risks on a large scale

Over the past year, the most captivating narrative in AI-powered programming has been "everyone can build an App" — people with no coding experience can generate pages, connect databases, and deploy online with just a few prompts. For the first time, software development no longer seemed exclusive to a small group of engineers.

A product called Moltbook delivered the first bill for this euphoria.

It positions itself as a "social network dedicated to AI agents": agents can post, comment, and vote on the platform, building credibility through a reputation system, earning it the nickname "the homepage of the agent internet." The founder was candid that the entire product was vibe-coded — he did not write a single line of code, relying entirely on AI generation.

However, security research firm Wiz discovered that a misconfigured Supabase database allowed full read and write access, leaving the production environment completely open to anyone: 1.5 million API authentication tokens, 35,000 email addresses, and a large number of private messages between AI agents were all exposed unprotected on the public internet. Anyone could impersonate any AI agent account on the platform and tamper with all public content.

This is not an isolated case, but a phenomenon occurring in batches in 2026. There is a harsh truth in the software world: being able to run does not mean being usable; being deployable does not mean being responsible. AI is generating apps in bulk, but also planting hidden security risks at scale.

Hacking Moltbook: The AI Social Network Any Human Can Control

1. The greatest danger is not failing to build, but "seeming to be fully completed"

The most addictive part of Vibe Coding is that it turns software development into an instant feedback game: you put forward requirements, AI generates code; you say the button looks bad, it adjusts the style; you report a deployment error, it gives you a command. A lot of the frustration in traditional development processes is smoothed out through rounds of natural language conversations.

This experience creates a strong illusion: as long as the page loads, the product is considered finished. But real software is far more than a page — the page is just the most visible part. Whether a product can run securely depends on a host of invisible elements: authentication, permission isolation, key management, log desensitization, and attack protection. These elements are not as visually appealing as screenshots, nor do they automatically appear in demos.

A survey by Israeli security firm RedAccess laid out the cost of this illusion: they found around 380,000 publicly accessible assets, of which about 5,000 contained sensitive corporate information including medical records, financial data, internal documents, and customer service conversations. An Axios report also noted that these assets involve applications generated or hosted by AI/low-code platforms such as Lovable, Base44, Replit, and Netlify. The CEO of RedAccess put it bluntly: the privacy settings of these applications are "public access by default."

In other words, the barrier to building a functional app has been almost reduced to zero by AI. But the threshold for "knowing you are running unprotected" has not decreased at all. A batch of apps that look like finished products but are actually half-baked experiments have been directly pushed into the real world — they are not incapable of running, but they are launched far too early.

Vibe-Coded

2. The barrier to creation has fallen, but the barrier to accountability has not kept pace

AI programming tools solve the problem of "how to generate code," not the problem of "who bears the consequences" — this is the most easily overlooked point in this euphoria.

A vulnerability that Lovable itself encountered illustrates this point far more effectively than any argument. According to disclosures from the security community, in April this year, researcher weezerOSINT registered a free Lovable account and, with a small number of API calls, gained potential access to other users' source code, database credentials, and AI chat records. No offensive techniques were required; the problem stemmed from a lack of permission verification on interfaces, a typical BOLA (Broken Object Level Authorization) vulnerability, which was reported to affect projects created before November 2025, a considerable scale. The researcher stated that he had already reported this issue through HackerOne 48 days earlier.

Lovable initially emphasized that the platform had not suffered a data breach in the traditional sense, and attributed part of the problem to users' misunderstanding of public projects and permission settings. Later, the incident also exposed issues with the platform's backend permission adjustments and vulnerability report workflows. The company admitted that when unifying backend permission settings in February this year, it "accidentally re-enabled" access permissions to chat records of public projects; the researcher also mentioned that HackerOne had marked the report as a "duplicate submission."

A security vulnerability, after going through a full cycle, eventually turned into a tangled chain of responsibility among the platform, users, and the vulnerability response process. No one pointed out that from a design perspective, this product never prioritized "protecting users' code and data" as its top requirement.

This is not a moral issue, but a structural capability issue. An independent developer can simultaneously act as a product manager, designer, frontend, backend, and operations engineer, but they likely only understand the first two roles and have little concept of the latter several. AI can help them generate a login logic, but it will not proactively tell them whether this logic meets real security scenarios; it can help them connect to a database, but it will not design the principle of least privilege for them. More subtly, AI-generated code creates a psychological distance: "It runs, so it should be fine; it's generated by the model, so it probably knows better than me." AI does not eliminate the need for accountability, but it delays the moment when many people realize they need to take responsibility.

3. Half-success is more dangerous than being unused

In the past, independent developers feared most that no one would use their products. But in the AI programming era, another type of failure becomes more dangerous: people actually start using it. Because as long as there are users, data will be generated; as long as there is data, accountability will arise; as long as no one takes responsibility, it will turn into a risk.

The Verge reported a simple case: developer Bob Starr built a website with AI, and only discovered a SQL injection vulnerability several months after launch. The article made an accurate judgment — there is a clear line between amateur projects and software that processes real financial and medical data, but coders often do not realize when they have crossed that line.

The problem with many AI-generated products is not that they are total failures, but that they are half-successful. If no one visits, it is just an abandoned project; if people suddenly start accessing it, it may turn into an unattended data container. More and more such products will appear, because AI has driven the cost of trial and error extremely low — one person can build more than a dozen small tools in a month, most of which will never truly grow, but will all be briefly launched, briefly collect data, briefly connect to third-party services, and then be forgotten in a cloud platform or a database instance — dependencies are not updated, keys are not rotated, permissions are not checked, but the interfaces are still accessible.

The traditional internet left behind zombie websites; AI programming may leave behind zombie apps. The difference is that zombie websites are at most unvisited, while zombie apps may still hold data of real users — the batch of API tokens and agents' private messages exposed by Moltbook are essentially a data container left behind by the euphoric growth, with no one having time to wrap things up.

Moltbook

4. The pitfalls low-code has encountered are being revisited by AI programming

"Non-professional developers building software" is not a new concept. Low-code, no-code, and Excel macros have all promised similar capabilities, and they have indeed hidden dangers — many enterprises have systems that "no one dares to touch," whose original authors left years ago, with no documentation and chaotic permissions, yet still supporting critical workflows.

AI programming only pushes this scenario from enterprise intranets to the public internet: in the past, business users breaking an internal form only affected one department; now, people who do not understand security configurations building an AI tool, enabling public registration and binding a domain name, will affect all strangers who have uploaded data.

More troublesome is that these technical debts are not easily noticeable. A traditional poorly built system usually looks obviously crude; AI-generated products are different, with nice interfaces, smooth interactions, wrapped in modern UI. But a good-looking frontend cannot hide a fragile backend — the applications leaking medical records and bank data in the RedAccess report look no different from any normally launched product on the surface.

5. Platforms cannot just enjoy growth without taking on guardrails responsibilities

This issue cannot be blamed solely on users, let alone entirely on users.

AI programming platforms promote growth with the excitement of "everyone is a developer," and their selling point is that "the barrier has disappeared." But once an incident occurs, their first reaction is often to emphasize that "this is not a data breach in the traditional sense," and that it is "users' misunderstanding of permission settings" — which is equivalent to treating people with no engineering background as responsible subjects who should understand permission models on their own. This is platforms reaping the growth dividend of "zero barrier," while shifting the security costs that "zero barrier" should have entailed to the people least capable of bearing them. Lovable's response path is a ready example: first emphasize it is not a breach, then attribute the problem to users' misunderstanding, and finally reveal that the platform's own "accidental" permission adjustment in February changed the default value from private back to public — the platform's own responsibility is the last point mentioned after a long cycle.

If a platform's selling point is "no technical knowledge required," it has no right to demand that users understand permission risks on their own. Defaulting to private instead of public access, defaulting to scan for hard-coded keys, defaulting to alert users before launch — these are not optional fancy features, but the responsibilities that platforms should have bound when they claim to eliminate technical barriers. Most platforms today are still in a growth-first phase, preferring to showcase "building a beautiful app in ten minutes" rather than honestly telling users before they click "publish": your database is currently public.

It is worth noting that security and privacy are only part of this account. Issues around copyright ownership of AI-generated code, open source license obligations, and compliance requirements for third-party AI processing of user data are also being brought back to the table. For example, the Doe v. GitHub case is still ongoing in the US court system, with one of the disputes being whether Copilot-generated code has removed copyright management information from open source code; Apple has also required in App Store review rules that developers must clearly inform and obtain consent before sharing users' personal data with third-party AI. In other words, the risks of Vibe Coding are not limited to "whether there are vulnerabilities," but also include "where the code comes from, where the data goes, and who is responsible when something goes wrong."

6. The new moat for independent developers: not about being able to generate, but about being accountable

This does not mean that AI programming is not worth looking forward to. It has indeed opened up a huge space — many small demands that were never met in the past due to high development costs can now be quickly validated by one person to serve niche groups.

But precisely because the barrier has fallen, new differentiation will emerge faster. In the future, everyone will be able to write code with AI — the ability to generate pages or connect APIs will increasingly no longer be a scarce skill. What is truly scarce is: who can turn a demo into a sustainably running product. What separates the two is not inspiration, but engineering accountability — the ability to understand the sensitivity of user data, design permission boundaries, delete data, shut down interfaces, and notify users when the product is decommissioned.

In the past, the biggest difficulty for one person to build a product was failing to finish it; now, finishing it is just the beginning. The easier you launch, the earlier you step into the accountability zone. In the AI programming era, restraint will become a capability again — a stronger developer is not the one who writes the most dazzling prompts, but the one who knows which data cannot be collected carelessly, which functions cannot run unprotected, and which products cannot be opened to real users without a maintenance plan.

Software has not become simpler because of AI, its complexity is just delayed — hidden in permissions, hidden in databases, hidden in a forgotten but still open interface. In the next stage, truly valuable developers, platforms, and communities will no longer just teach people how to quickly build products with AI, but teach people how to safely deploy products into the real world. Because once software is launched, it is no longer just your own work, it begins to carry the trust of others — and trust is never generated in ten minutes.

(The author of this article, wiwi, is a contributor to Huxiu, TMTPost, and 36Kr, and the initiator of the Solo independent developer community.)

This article is from the WeChat Official Account "Beyond the Singularity", author: wiwi, published with authorization by 36Kr.