Syntic
All posts

Published October 4, 2026 in Software

From Prompt to Product: The New Way Software Gets Built

By Syntic AI

The first version of a piece of software used to be the expensive part. Turning an idea into something a person could click took a developer, a few weeks and a budget. That cost acted as a filter: most ideas never got built.

Prompt-to-app tools have removed most of that cost. A founder, an operations lead or a product manager can describe an application in a sentence and have a working interface, a database and a deployed URL before lunch.

What has not become cheap is everything that separates a demo from a product: who may see which data, where the secrets live, what happens when something fails, and how the system changes safely next month. The evidence is consistent. AI has largely solved the part of software you can see. The part you cannot see is where the risk now sits, and it is where the people who succeed with these tools spend their attention.

The first version got cheap

In February 2025, Andrej Karpathy named the practice. "Vibe coding," he wrote, is where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He accepted every change without reading the diffs, pasted error messages back without comment, and admitted the code had grown "beyond my usual comprehension." His verdict was precise: "It's not too bad for throwaway weekend projects."

The phrase spread faster than the caveat. A month later, Y Combinator managing partner Jared Friedman said that for a quarter of the Winter 2025 batch, 95% or more of the codebase was AI-generated. The detail that travelled less widely was his description of those founders: "Every one of these people is highly technical, completely capable of building their own products from scratch."

Prompt-to-app builders go a step further. The code editor disappears. The user describes an outcome; the platform generates the front end, provisions a database and hosts the result. For someone who has never opened a terminal, that is a real change. They can test an idea with real users or replace a fragile spreadsheet with a tool their team actually uses.

A demo is the happy path

A prototype answers one question: does this idea make sense when someone uses it? It is built for the case where the user is who they claim to be, enters sensible data and clicks the buttons in roughly the intended order.

A product has to answer different questions. Who can read this record, and how does the server know? What stops a user from changing someone else's data by editing a request in the browser? Where are the API keys? What happens when the payment provider times out? How do you change the data model in March without breaking the customers who signed up in January?

None of this shows up on screen. A login page that looks correct and one that is correct are visually identical. That is the core difficulty of building software by describing it: the builder checks what is visible, and the obligations that make software safe to depend on are almost entirely invisible.

What the evidence says about generated code

Syntax is solved; security is not

Veracode tests more than 100 language models on security-relevant coding tasks in Java, JavaScript, Python and C#. Its first report, in July 2025, found that models introduced a known class of vulnerability in 45% of tasks, and that newer and larger models were not meaningfully more secure than smaller ones.

The 2026 edition, published in July, is notable for what did not change. The average security pass rate moved from 55% to 56%. Veracode's summary is blunt: models now produce syntactically correct code almost every time, but "syntax is solved, security is not." Models defended against SQL injection in 83% of relevant tasks, but against cross-site scripting in only 15% and log injection in 12%. The best model tested still failed close to a third of security tasks.

These are a security vendor's controlled benchmarks, not measurements of deployed apps. But the pattern held through a year of otherwise sharply improving models.

Confidence rises faster than care

The human side shows the same gap. In a controlled study at ACM CCS 2023, Stanford researchers led by Neil Perry found that participants given an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. Output that works on the first try removes the friction that would otherwise prompt a second look.

The dependencies may not exist

At USENIX Security 2025, Joseph Spracklen and colleagues generated 576,000 code samples with 16 models. On average, at least 5.2% of package references from commercial models, and 21.7% from open-source models, pointed to packages that did not exist: more than 205,000 unique invented names. Anyone can register such a name and wait. A 2026 re-evaluation of five newer frontier models measured rates of roughly 4.6% to 6.1% and still found 127 invented names that all five produced identically. The risk is smaller, not gone.

Where real apps break

Production incidents match the benchmarks, and they cluster in the invisible layers.

In March 2025, security researcher Matt Palmer scanned 1,645 projects built with Lovable, a popular prompt-to-app platform. He reported 170, roughly 10%, whose database rules let anyone holding the public key embedded in the page read or modify records, including emails, phone numbers, payment details and third-party API keys. The browser talked directly to the database, and row-level security policies were the only thing keeping data private. Where those policies were missing or wrong, the app worked normally and leaked anyway. The issue became CVE-2025-48757. Lovable added a security scanner, which Palmer said checked that policies existed rather than whether they were correct.

In July 2025, Wiz Research disclosed a flaw in Base44, a builder Wix had recently acquired. An app's identifier, visible in its public URL, was enough to register a verified account on private applications, including enterprise tools for HR and internal knowledge. It was fixed in under 24 hours, and Wix reported no evidence of abuse. This was a platform bug, not a builder's mistake, and it carries its own lesson: when a platform hosts thousands of apps, one flaw in its shared authentication layer is inherited by all of them.

Wiz later catalogued what it kept finding in vibe-coded applications: authentication checked in the browser, sometimes against a password written into the JavaScript; API keys for paid services shipped to every visitor; missing or permissive database policies; internal tools on the public internet with no login.

Who succeeds with these tools

Generated code is equally available to everyone, yet some builders ship durable products and others ship incidents. The research points to expertise being redistributed, not removed.

Advait Sarkar and Ian Drosos analysed more than eight hours of recorded vibe-coding sessions for a 2025 study. The practice, they concluded, "does not eliminate the need for programming expertise but rather redistributes it" towards managing context, evaluating output quickly and knowing when to stop prompting and edit by hand.

A review of 101 practitioner accounts by Ahmed Fawzy, Amjed Tahir and Kelly Blincoe found the other side. Speed was the dominant motivation, and much of the reported quality practice amounted to skipping tests, trusting output uncritically or asking the AI to check itself. The authors describe an emerging group of "vulnerable developers" who can build an application but cannot fix it when it breaks.

Professional developers are sceptical in the same direction. In the 2025 Stack Overflow Developer Survey, 84% were using or planning to use AI tools, yet 46% distrusted the accuracy of the output and only about 3% highly trusted it. The top frustration, cited by 66%, was "AI solutions that are almost right, but not quite." Asked if vibe coding was part of their professional work, 72% said no.

When experienced people steer, the code holds up. In a preregistered experiment with 151 participants, nearly all professional developers, Markus Borg and colleagues found that AI assistance cut median task time by about 31%, and that developers who later extended that code without AI were not slowed down by it.

The builders who get the most from these tools understand the problem precisely, test behaviour rather than appearance, and have enough technical literacy to know which questions to ask, even when they cannot answer them alone. The tools amplify judgement. They do not supply it.

Crossing from prototype to product

The answer is not to stop non-engineers building. It is to change what happens when a prototype starts to carry real users, real data or real money.

Treat the prototype as a specification

A working prototype is the clearest requirements document most teams have ever had. Whether the next step is hardening the generated code or rebuilding parts of it, the prototype has settled most of the arguments that used to consume a project's first month.

Draw the line at data and identity

The decisions that most need an expert are the ones generators handle worst: the data model, record-level access, server-side authentication, where secrets are stored and how external services are called. A short review at this boundary, before real users arrive, costs far less than a breach or a migration.

Expect secure defaults from the platform

Because builders cannot see these layers, platforms have to own them by default: database access that denies everything until a rule allows it, secrets that never reach the browser, authentication enforced on the server, and scanners that test whether a policy is correct, not just whether it exists.

Plan for the second year

A generated app still needs dependency updates, schema migrations, monitoring and someone who can read the code when the model cannot fix a bug. Teams that keep it in version control, write a few tests for the flows that matter and name an owner will be able to keep changing it. Teams that do not will eventually start again.

Where engineers remain essential

These tools change the shape of engineering work more than its necessity. Fewer hours go into the first screen of an internal tool; more go into what those tools depend on: data models, access control, integrations with systems of record, review, and the infrastructure that lets many small applications run safely.

That is a different job from the one engineers are taking on inside large codebases, where agents work across repositories under tests and review, which we examine in the future of coding is agentic. Both meet at the same point: someone has to define "correct" and check it. The same tension appears for people using software, as we argued in software is moving from interfaces to intent.

Syntic builds one of these tools. Its App Builder starts from a plain-language description or a template, so the question of what happens after the first version applies to us as much as anyone.

The cost moved

The first version is now nearly free. More ideas get tested, and more tools get built by the people who need them. That is a genuine gain, and part of a broader pattern in which the cost of intelligence keeps falling while the cost of being wrong does not.

But the expensive part of software was never typing it. It was knowing what must never happen and making sure it does not. Prompt-to-app tools have moved that work from the start of a project to the moment it gets real users. Builders and platforms that see where the work went will turn prototypes into products. Those that mistake a working demo for a finished system will learn the difference from their users' data.

Sources