In February 2025, Andrej Karpathy described a new way of working that he called vibe coding. Per Martin Fowler’s definition, which quotes the original post, Karpathy wrote: “I ‘Accept All’ always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension.” He was clear that it was fine for throwaway weekend projects. The trap is that the same loop that builds a weekend project in an afternoon also builds the internal tool that fourteen people now depend on, and nobody notices the difference until something leaks or something breaks.
For a founder, vibe coding is genuinely useful and genuinely dangerous, and the line between the two is not about talent. It is about what you put around the model.
What vibe coding actually is, and is not
The term has blurred, and the blur matters. Fowler draws a hard line. Vibe coding, per his definition, is “building a software application by prompting an LLM… but without looking at any of the code that the LLM generates.” The defining move, in his words, is to “forget that the code even exists.” That is what lets a non-programmer build something at all. It is also the source of every limitation.
The thing most working engineers do is different. When a programmer gets an LLM to write their code but still reviews it and pays attention to its structure, Fowler calls that agentic programming, not vibe coding, because they have not forgotten the code exists. He notes the term “vibe coding” caught on so hard that people use it for both, but the two differ in how they are used and in their consequences. The distinction earns its keep. Agentic programming with review keeps a human in the loop on internal quality. Pure vibe coding removes that human by design, which is precisely why its output is, per Fowler, “best used for disposable software written for a limited audience.”
The security path of least resistance
The sharpest account of what goes wrong at scale comes from Thoughtworks. In The VibeSec Reckoning, a team in Global Marketing led by Gautam Koul, with Lucian Moss, Neil Drew-Lopez, and Daberechi Ruth Edeokoh, describes being asked to scale a vibe-coded video-assembly prototype, built with Gemini, Replit AI, and Claude AI, for use across 10,000 employees. They hit two moments that stopped work cold, and both were security failures the AI proposed on its own.
In the first, the AI recommended making a cloud storage bucket public, “anyone with the link.” When challenged, per the article, it justified the choice by saying every company does it, and only a firm rejection produced a secure alternative. That single default could have leaked unreleased brand assets and audience data to the open internet. In the second, a service account was assigned the Access Token Creator role, far more power than the task needed, which would have let a compromised account move laterally through the entire cloud workspace. The team’s distilled insight is the one to keep: AI tools “often suggest the path of least resistance,” and that path is not always the secure one.
This is not an anecdote about one prototype. The same article cites 2026 research putting numbers on it: a 44 percent year-on-year rise in attacks exploiting application vulnerabilities, one in five enterprise breaches now caused by AI-generated code, 50 percent of organizations with no sensitive-data policies for AI, and 25 percent of AI-generated code carrying confirmed vulnerabilities. The 25 percent figure is attributed to AppSec Santa, 2026, and the 44 percent to SQ Magazine’s AI Coding Security Statistics, 2026. We have not independently audited those studies, so treat the exact figures as the sources report them rather than as settled fact. The direction they point is not in dispute: speed without guardrails produces exposure at a rate that shows up in breach statistics.
Fowler frames the underlying mechanism more generally. LLMs present “a large attack surface,” vibe-coded apps “can often expose sensitive information or worse, credentials,” and even non-programmers need to understand what he calls the Lethal Trifecta. The model is not malicious. It is agreeable, and agreeable is insecure by default.
Why prompting “be secure” does not work
The intuitive fix, telling the AI to write secure code, is the one the Thoughtworks team explicitly rejects in the subtitle of their piece: “Why prompting your AI to ‘be secure’ is not enough, and what actually is.” A prompt is non-deterministic. It nudges probability; it does not enforce a rule. The bucket stayed private in their case only because a human asked the right question at the right moment, and human vigilance does not scale to every prompt of every citizen builder in a company.
AI tools suggest the path of least resistance, and that path is not always the secure one.
Their proposed controls are structural rather than motivational: write a security context file that gives the agent technical security rules as context from the first prompt, be cautious with the AI’s permission requests, maintain a security intelligence feed, and give builders secure-by-default scaffolding and templates. The common thread is moving the control out of the prompt and into the workflow, where it runs every time regardless of who is typing.
Maintainability rots the same way
Security is the loud failure. Maintainability is the quiet one, and it compounds. Per Fowler, vibe-coded software “can rapidly produce many lines of code of a very low quality,” code that is hard even for an LLM to modify later. Birgitta Böckeler, a distinguished engineer at Thoughtworks, gives the concrete tell in her piece on maintainability sensors for coding agents: the first signs of cracks appear “when the number of files changed for a small adjustment increases,” or when changes start breaking things that used to work. A tidy codebase keeps a small change small. A vibe-coded tangle turns a one-line ask into a sprawling diff.
Crucially, Böckeler observes that internal-quality problems hurt the AI itself the way they hurt humans. An agent in a tangled codebase “might look in the wrong place for an existing implementation, create inconsistencies because it has not noticed a duplicate, or be forced to load more context than a task should require.” The hope that a smarter model will eventually swim through any bowl of spaghetti runs against this: well-structured software, Fowler notes, makes life easier for LLMs too. Maintainability debt does not just slow the next human. It degrades the next AI edit.
Sensors, not willpower
The durable answer in both Thoughtworks pieces is the same shape, and it is the part founders should copy. Böckeler describes building a TypeScript, Next.js, and React analytics dashboard from scratch with AI using Cursor, Claude Code, and OpenCode, deliberately providing almost no quality guides and relying instead on sensors: automated checks that give the agent feedback before issues reach a human.
Her in-session sensors run continuously alongside the agent: a type checker, ESLint, Semgrep as the SAST tool, dependency-cruiser for module-dependency rules, the test suite with coverage, incremental mutation testing, and GitLeaks in the pre-commit hook to catch committed secrets. The same computational checks run again in CI on clean infrastructure, and slower-cadence reviews (a security review derived from an AppSec checklist, a data-handling review, a dependency-freshness report) catch drift that accumulates over time. The test suite earns a specific role here as a regression sensor: it tells the agent, deterministically, when a change broke something that used to work, which is exactly the failure mode Böckeler flags as the early sign of rot.
For a founder, the practical translation is short. Vibe code the prototype; that is what it is good for. But before anything a customer touches goes live, put deterministic sensors in the path to production: a linter, a SAST scanner, a secret-scanner in the pre-commit hook, dependency rules, and a regression test suite the agent must keep green. Add a security context file so the agent starts every session with your rules instead of its defaults. None of this requires the founder to read every diff. It requires building the guardrails once so the guardrails read them instead.
The honest summary is that vibe coding did not lower the bar for shipping software. It lowered the bar for generating software, which is a different thing. The bucket the AI wanted to make public was one prompt away from a breach, caught only because a human happened to be watching. The teams that ship vibe-coded work safely are the ones that stopped relying on someone happening to be watching.