Vibe Coding Domain Expertise Building Production Platforms 2026

Andrej Karpathy coined the term "vibe coding" in a February 2025 post on X. The idea: describe what you want in plain English, let an AI write the code, accept the output, move on. "Fully give in to the vibes, embrace exponentials, and forget that the code even exists."

By November 2025, Collins Dictionary had named it Word of the Year. By early 2026, platforms like Lovable, Bolt, Base44, and Replit had turned the concept into a product category. Industry data suggests 63% of vibe coding users are non-developers, building UIs, full-stack applications, and personal tools through natural language prompts.

The promise is real. The barrier to creating functional software has collapsed.

So have some of the things people built with it.

Moltbook, an AI social network whose founder publicly stated he "didn't write a single line of code," exposed 1.5 million API authentication tokens within three days of launch. A misconfigured database. No row-level security. The platform worked. It also gave unauthenticated access to every user's data. Lovable, a vibe coding platform now valued in the, saw roughly 10% of its sampled applications exposed to critical data leaks because the AI omitted basic Row Level Security. Worse, a featured app on its showcase was found with an inverted authentication logic implemented by the AI,blocking logged-in users while granting anonymous visitors total administrative access. The AI had implemented security. It just got the logic backwards.

Georgia Tech's Vibe Security Radar tracked 35 CVEs directly attributed to AI-generated code in March 2026, up from 6 in January. Veracode's research found that 45% of AI-generated code introduces security vulnerabilities, with the rate higher in Java and consistent across Python and JavaScript.

Karpathy originally described vibe coding as suitable for "throwaway weekend projects." That caveat disappeared from the conversation roughly around the time venture capital arrived.

The gap that tools cannot close

The security failures share a common root. The AI generates code that satisfies the prompted requirement. And it can do this well. What it cannot do is apply the unstated requirements: the assumptions an experienced builder carries about authentication scope, data residency, access control hierarchy, and what happens when things go wrong.

A useful frame comes from LSE researchers who spent eight months building a research tool entirely through AI prompts. Their conclusion: "Vibe coding does not remove the need for technical knowledge; it redistributes it from computational thinking to systems thinking." The skill shifts from writing syntax to understanding architecture. From typing code to knowing what questions to ask before a single line is generated.

This redistribution is the entire story.

A build that required domain knowledge at every turn

A recent platform build illustrates the pattern. Propiaterra is a done-for-you video course platform, built entirely on no-code tools (Webflow, Outseta, Bunny.net, Make) with AI-assisted JavaScript. No traditional backend. No server. Airtable as the data store. The AI wrote the code. What it needed to be told, at every stage, came from commercial and technical domain knowledge the AI did not possess.

The platform required video progress tracking with resume functionality, auto-enrolment on first play, real-time student dashboards, and membership-gated access. Eight versions over three weeks. Each version addressed a problem identified through testing that the AI could not have anticipated. Unless asked.

Version one tracked progress. It worked. But the webhook URLs were visible in client-side JavaScript, meaning anyone with browser developer tools could query or manipulate other users' data. The AI did not flag this. Why would it? The code did what was asked. The security implication required understanding that a no-server architecture exposes endpoints differently from a traditional backend, and that this exposure needs a specific mitigation pattern.

The solution: JWT token validation on every request, using the authentication provider's own profile endpoint as the verification layer. Every API call sends the user's access token. The automation platform validates it before processing anything. Invalid tokens get rejected. Users can only access their own data.

That architectural decision required knowing three things: that the exposure existed, that the authentication provider could serve as the validation layer, and that the automation platform could execute HTTP validation as a processing step. None of these were prompted by the AI. All of them were specified by the builder.

Where the questions came from

The same pattern repeated throughout the build. A caching layer was needed because the automation platform - Make - charges per credit. Knowing this required understanding the cost model. A 90% completion threshold for marking lessons as "done" required understanding how people actually watch educational video: they skip the last few seconds. Composite database keys using a specific format required understanding how the data store handles lookups and upserts without a relational database engine.

At each point, the AI produced the implementation. The specification came from experience: years of working with teams building commercial platforms, understanding SaaS economics, knowing how course creators operate, and recognising the security patterns that separate a live product from a demo.

An IEEE-ISTAS controlled experiment found a 37.6% increase in critical vulnerabilities after just five rounds of AI-assisted code refinement. Iterating on AI output does not self-correct security flaws. It compounds them. The instinct to "keep prompting until it works" produces functional software with accumulating risk. The fundamental in vibe coding, is knowing what to look for before asking the AI to build it.

The conversation about vibe coding is stuck between two poles. Enthusiasts see a democratised future where anyone builds software. Critics see a security disaster unfolding. Both are right.

The toola are extraordinary. The ability to describe a system in plain language and receive working code in minutes is a miraculous shift in how software gets made. The Propiaterra build would have taken months and tens of thousands in development costs using traditional methods. It took three weeks with AI assistance.

This shift however, does not eliminate the need for expertise. It concentrates it. The value moves from implementation to specification. From "can you write this function" to "do you know which function needs writing, and do you understand what will happen if it's written wrong."

For scaling businesses evaluating whether to build internal tools, customer-facing platforms, or operational infrastructure using AI-assisted development, the question is straightforward. The person directing the AI needs to know the domain: the commercial logic, the security architecture, the data flows, the cost models, and the failure modes. The AI handles the syntax. Everything else is still a human job.

That boundary is where automation infrastructure either compounds advantage or compounds risk. The tools have never been more capable. The judgment about what to build with them has never mattered more.