The number is real, and you can put your finger on exactly where it lives. v0 by Vercel published a report called The State of Vibe Coding. One spread is headed "Trends in individual vibe coding," and under the line "Who's using these tools" it reads: 63% non-developers, 37% developers. The regional chart in the same section 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. There is no sample, no margin of error, no stated method, and no definition anywhere of the word "non-developer." It measures the people using one company's product. That is a real thing to measure, and for a year it has been repeated as a fact about everyone who has ever vibe coded.
The direction it points in 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 they want to build, 80% would pursue it if it did not require coding knowledge, and only 13% have ever tried vibe coding at all.
So: we do not know the true share, and 63% is not it. What we can say is that the people building things this way are mostly not engineers. The wall they run into is not the code. The code is the part that works now.
Where the 63% actually comes from
The interesting thing about this number is not that anyone lied. Nobody did. 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, quoted above. 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, phrases it this way: "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 has quietly 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 in August 2026 — 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 entirely. It is simply vibe coding users, all of them.
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." Its reference list points not at Vercel but at Hostinger. Two things have been added that exist in no source: the job titles, and the phrase "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, unnamed. Vercel is not mentioned.
Hop six, the number changes owner. Taskade's state-of-vibe-coding page presents 63% under the heading of its own platform, Taskade Genesis, next to "Lovable: 60%," labelled platform aggregate data. Vercel appears nowhere on the page. The same figure now belongs to somebody else.
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. If a page presents 63% next to numbers drawn from polls without telling you which is which, it is treating two very different kinds of evidence as the same kind.
What the number does not say
Four things, all of which matter more than the number itself.
Nobody defined "non-developer." The report never states how it sorted people into two buckets. The one clue is its own observation about prompting styles: developers "tend to mention specific frameworks in the prompts," while non-developers "use more conversational, goal-focused prompts," with the examples given including "I need a reservation system for a restaurant." That reads like classification inferred from how people write. But the report does not say so, and neither will we.
The population is one product's users. v0 generates interfaces. A tool for generating interfaces should be expected to attract designers, product managers and marketers more heavily than it attracts backend engineers. That is a fact about v0's audience before it is a fact about anything else.
It is a single snapshot. One date, August 18, 2025. Anyone telling you the non-developer share is rising or falling 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%, with no explanation of what differs. It is a well-made piece of marketing, which is a different object from a dataset.
The same erosion happens inside the report itself. 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 post on social media, about somebody else's research. We could not reach that research at its origin, so we are not going to repeat 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. They are fewer and less exciting than a listicle, and you can check every one.
Stack Overflow Developer Survey 2025 — the largest independent measurement in this space. Published July 29, 2025, with more than 49,000 respondents across 177 countries. Nearly 77% said vibe coding is not part of their professional development work; Stack Overflow's own write-up splits that 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 those same professionals is close to universal, with 84% saying they use or plan to use AI tools in their development process, up from 76% the year before, while 46% said they do not trust the accuracy of what those tools produce, up from 31%.
That is not the same claim as v0's. It does not say who is vibe coding. It says professional developers, at work, mostly are not, which puts the activity somewhere else, with somebody else.
A survey of 1,000 Americans, run by All About Cookies in partnership 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 they want to build. 80% say they would pursue it if it did not require coding knowledge. 57% have heard of vibe coding, but only 13% have ever tried it. Asked what blocks them from starting something, 55% named a lack of technical or digital skills — ahead of not enough money (50%), not enough 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 this article is about: 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, which is why we are labelling it again: 44% interface generation ("build a form; design a component or layout"), 20% what the report calls sophisticated applications ("build an ecommerce site"), and 11% personal websites and portfolios. The same spread covers when it happens — 36% during the workday, 34% after it, 28% at the weekend — and notes that productivity "appears to be correlated with uninterrupted focus time."
Three measurements, three different populations, no two of them interchangeable. They agree on direction and on nothing else. That is an honest summary of what is currently known, and it 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 single one of those 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, essentially all of them need the same last step, and it is the step the AI tool does not take. Whether what you built is a site or an application changes that step completely, so that is its own question, and it is the first one worth answering.
What breaks after the code is written
The best account of this 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, and he describes his own position on the developer/non-developer 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." Elsewhere he lists what the gluing consisted of — "all these services, docs, API keys, configurations, dev/prod deployments, team and security features, rate limits, pricing tiers."
Note what is absent from that list. Not one item 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. The report names the underlying condition "capability mismatch": the new capability is that "anybody can vibe code, regardless of coding experience," and the new risk is 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 should carry that weight is the right one, and worth borrowing past the security context it was written for. Zeb Hermann, General Manager of v0: "It's a failure of the product to not automatically prevent security issues." The report puts the principle more broadly a line later, stating that the product must handle what users can't be expected to master.
The walls, named
For someone who has just watched a working page appear from a paragraph of English, there are three of these, 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 the question the Base44 and Lovable pages take apart. Getting them to a URL you can send someone is a reasonable request and a surprisingly unpopular one; most of the answers on offer are built for applications, not pages, and most of them begin by asking for a GitHub repository. The step itself is not complicated. Nobody just hands it to you.
The domain. Your site has an address; the domain is a second door onto it. One DNS record does it, and the reason this wall exists is that nothing tells you which record, what the difference between the root and www is, or why verification keeps failing when your provider proxies traffic. It is one record, once you know which.
The edit. This is the one that surprises people. You change a sentence and discover that "change a sentence" 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 as a build artifact.
There is more after that — taking enquiries, taking money — and those are real walls that this article is not going to pretend to solve. They are the next argument, not this one. The deployment gap makes it, wall by wall.
Where Birta stops
Birta is the step after the agent. The AI tool you already use — Claude Code, Cursor, a chat window — builds the pages; ask it to publish, and they go to a live HTTPS address. Change your mind and 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 to the last good one rather than by 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, and need to live at a public address of their own.
The honest limits: this is for commercial sites and landing pages, not applications with their own backend. Taking enquiries and taking payments are not things we offer today, and you should not pick a host for a feature that is not there. And nothing here inspects the AI-generated code your agent wrote. The security problems in v0's report are real, and 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.