The number is real and you can put your finger on where it lives. v0 by Vercel published The State of Vibe Coding. One spread is headed "Trends in individual vibe coding," and under "Who's using these tools" it reads: 63% non-developers, 37% developers. The regional chart beside it is stamped "Data as of August 18, 2025."
At the top of that section sits a box most people citing the figure have never quoted: "The following insights are based on internal v0 usage data and user analytics, unless otherwise noted." So it is not a survey. No sample, no margin of error, no stated method, and no definition of "non-developer." It measures the people using one company's product, and for a year it has been repeated as a fact about everyone who has ever vibe coded.
The direction does survive contact with evidence Vercel had nothing to do with. Stack Overflow asked more than 49,000 developers across 177 countries and found nearly 77% saying vibe coding is not part of their professional work. A separate survey of 1,000 Americans found 59% have an idea for an app, tool or website, 80% would pursue it if it did not require coding knowledge, and only 13% have ever tried vibe coding.
So we do not know the true share, and 63% is not it. What we can say is that the people building this way are mostly not engineers, and the wall they hit is not the code.
Where the 63% actually comes from
Nobody lied. The caveat was printed. It just did not survive being passed along, and you can watch it come off one hop at a time.
Hop one, the source. v0's report. Internal product analytics, v0 users, August 18, 2025.
Hop two, the publisher's own blog. Vercel's post "What you need to know about vibe coding", by Zeb Hermann and Keith Messick, September 18, 2025: "About 63% of users exploring vibe tools are non-developers, using tools like v0 or Cursor to streamline tasks and create custom solutions to their problems." The population widened from v0's users to people using tools like v0 or Cursor. Cursor has never published a comparable split.
Hop three, the top of the search results. Hostinger's vibe coding statistics page, the first result for the phrase when we checked, renders it as "63% of vibe coding users are non-developers, building products and tools without a programming background," sourced to "(Vercel)." The qualifier is gone.
Hop four, the citation of the citation. Keyhole Software's 2026 trends piece says "Sixty-three percent of vibe coding users identify as non-developers: product managers, marketing directors, startup founders, and designers," and its reference list points at Hostinger rather than Vercel. Two things have been added that exist in no source: the job titles, and "identify as," which implies people were asked to self-describe. Nobody was asked anything.
Hop five, the source dissolves. A 13Labs guide advertising "84 verified data points" attributes the figure to "usage data from major AI coding platforms," plural and unnamed. Vercel is not mentioned.
Hop six, the number changes owner. Taskade's state-of-vibe-coding page presents 63% under its own platform, Taskade Genesis, next to "Lovable: 60%," labelled platform aggregate data. Vercel appears nowhere.
By the time it reaches LinkedIn it reads: "63% of vibe coding users aren't developers at all. That's the one." No provenance left, just the moral.
No sample size, no fieldwork, no questionnaire, no confidence interval. A page that presents 63% next to poll numbers without telling you which is which is treating two different kinds of evidence as one.
What the number does not say
Four things, all of which matter more than the number.
Nobody defined "non-developer." The report never states how it sorted people. The one clue is its own observation on prompting styles: developers "tend to mention specific frameworks in the prompts," while non-developers "use more conversational, goal-focused prompts," the example given being "I need a reservation system for a restaurant." That reads like classification inferred from how people write, but the report does not say so.
The population is one product's users. v0 generates interfaces, so it should be expected to attract designers, product managers and marketers more heavily than backend engineers. That is a fact about v0's audience first.
It is a single snapshot. One date, August 18, 2025. Anyone telling you the non-developer share is rising is describing something the data cannot support.
The report is not always consistent with itself. On one spread a globe labels Latin America "23.3% of all users" while the chart beside it puts LATAM at 13.8%, unexplained. It is a well-made piece of marketing, which is a different object from a dataset.
The same erosion happens inside the report. Its most quotable statistic, "AI-assisted developers produced three to four times more code than their unassisted peers, but also generated ten times more security issues," carries the source note "X, on security findings from research conducted by Apiiro." A social media post about somebody else's research, which we could not reach at its origin, so we are not repeating the numbers as though we had.
The vibe coding statistics that survive an independent check
Here is what is left when you keep only figures whose method is published. Fewer and less exciting than a listicle, and every one is checkable.
Stack Overflow Developer Survey 2025, the largest independent measurement in this space. Published July 29, 2025, more than 49,000 respondents across 177 countries. Nearly 77% said vibe coding is not part of their professional work, split into roughly 72% who say it is not part of their work and a further 5% who "emphatically do not participate." Adoption of AI coding tools among the same professionals is near universal, 84% using or planning to use them, up from 76%, while 46% said they do not trust the accuracy of the output, up from 31%.
That is not v0's claim. It does not say who is vibe coding. It says professional developers, at work, mostly are not.
A survey of 1,000 Americans, run by All About Cookies with Base44, fielded in May 2026 through Prolific and published July 28, 2026. Nearly six in ten (59%) have an idea for an app, tool or website. 80% would pursue it if it did not require coding knowledge. 57% have heard of vibe coding, 13% have tried it. Asked what blocks them, 55% named a lack of technical skills, ahead of money (50%), time (45%) and fear of failure (35%).
Base44 is a company in this market, so this is vendor-backed too. The difference is that it tells you the sample size, the country, the month and the panel. That is the entire distinction: vendor data with a published method is evidence, vendor data without one is a claim.
What people build, from v0's report, carrying the same internal-analytics caveat: 44% interface generation ("build a form; design a component or layout"), 20% what the report calls sophisticated applications ("build an ecommerce site"), 11% personal websites and portfolios. The same spread covers when it happens, 36% during the workday, 34% after it, 28% at the weekend.
Three measurements, three populations, no two interchangeable. They agree on direction and nothing else, which is a long way from "63% of vibe coders aren't developers."
What non-developers are actually building
Look at that build mix again, because it is the bridge to the part nobody writes about. Interfaces, storefronts, personal sites. Every one needs to end up somewhere a person can reach.
An interface with no address is a mockup. A storefront with no address is not a storefront. A portfolio living in a chat window is a folder. Whatever share of these builders are non-developers, they need the same last step, and it is the step the AI tool does not take. Whether you built a site or an application changes that step completely, so that is its own question.
What breaks after the code is written
The best account comes from the person who named the thing. Andrej Karpathy coined "vibe coding" in February 2025. In April he wrote up building MenuGen, an app he made for himself, describing his own position on the line as "someone who tinkers but has little to no actual web development experience."
His verdict: "Vibe coding menugen was exhilarating and fun escapade as a local demo, but a bit of a painful slog as a deployed, real app." And on where the work went: "I didn't even spend all that much work in the code editor itself. I spent most of it in the browser, moving between tabs and settings and configuring and gluing a monster." The gluing was "all these services, docs, API keys, configurations, dev/prod deployments, team and security features, rate limits, pricing tiers."
Not one item on that list is code. The generation worked. The assembly is what hurt, and it hurt the man who invented the term.
v0's report draws the same shape without commenting on it. Its diagram of how things go wrong runs Idea → AI code → Deployment → Breach, and it names the underlying condition "capability mismatch": the new capability is that "anybody can vibe code, regardless of coding experience," the new risk that "users with no experience can jump into projects without safety expertise." Then it spends its remaining pages on security and says nothing further about the deployment box in the middle of its own diagram.
Its conclusion about who carries that weight is worth borrowing past the security context. Zeb Hermann, General Manager of v0: "It's a failure of the product to not automatically prevent security issues."
The walls, named
For someone who has just watched a working page appear from a paragraph of English, there are three, in this order.
The address. You have files, on your machine, in a chat, or in a preview that dies with the tab. The tools this group reaches for next are usually builders, and whether one is needed at all is what the Base44 and Lovable pages take apart. Getting files to a URL you can send is a reasonable request and a surprisingly unpopular one: most answers on offer are built for applications, not pages, and most begin by asking for a GitHub repository. The step itself is not complicated.
The domain. The site has an address; the domain is a second door onto it. One DNS record does it, and the wall exists because nothing tells you which record, what the difference between the root and www is, or why verification fails when your provider proxies traffic. It is one record, once you know which.
The edit. The one that surprises people. You change a sentence and discover that means publishing the entire site again, or worse, that your host has no memory of the version that worked. Editing a live page in place is possible, but only where the host keeps your site as files rather than a build artifact.
There is more after that, taking enquiries and taking money, and those are real walls this article is not going to pretend to solve. The deployment gap makes that argument wall by wall.
Where Birta stops
Birta is the step after the agent. The AI tool you already use builds the pages; ask it to publish and they go to a live HTTPS address. Ask again and the one file you touched is updated in place rather than the site being rebuilt around it. The last ten published versions are kept, so a bad edit is undone by going back rather than re-prompting your way out. Point your own domain at it when the name matters. Images and fonts travel with the site; video and PDFs do not.
The honest limits: commercial sites and landing pages, not applications with their own backend. Taking enquiries and taking payments are not things we offer today. And nothing here inspects the code your agent wrote, because publishing a site is not auditing one.
Give the page an address without leaving the conversation
The agent that built the site publishes it: a live address, HTTPS, and versions kept in case the next edit is wrong.