Insight · July 16, 2026
Vibe coding
meets the enterprise.
AI writes the first version in an afternoon. The enterprise question is not whether it runs. It is whether it holds when the traffic, the audit, and the attacker arrive.
01 · The premise
Anyone can produce working software now.
Andrej Karpathy named it in February 2025. A new kind of coding, he wrote, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. He described his own method plainly. Accept every suggestion. Stop reading the diffs. When an error appears, paste it back and let the model try again. Collins made vibe coding its word of the year for 2025.
The method is real and it works, for a certain kind of output. A weekend prototype. An internal tool with three users. A demo that has to exist by Friday. The trouble starts the moment that same output is asked to carry a business, because the thing that made it fast is the thing it skipped.
02 · The gap
Working and safe are two different tests.
Carnegie Mellon ran the measurement most people avoid. They pointed an AI agent at 200 real feature requests and scored two things separately. Did the code work. Was the code safe. The agent produced functionally correct solutions 61 percent of the time. Only 10.5 percent were secure. More than 80 percent of the solutions that worked still carried a vulnerability. Adding explicit hints about the flaws to the prompt did not close the gap.
Read those two numbers together. For every ten features that pass their tests, roughly nine ship something exploitable. The code runs. The demo is convincing. The gap is everything the demo never checks, and the demo never checks it because it only ever calls the code the one way that works.
The one line to keep
“A prototype proves the idea can exist. Production proves it can be trusted.”
03 · What production asks that a demo never does
The checks a demo skips are the ones a business runs on.
01
Authorization
Not who is logged in, but what each person is allowed to touch. Generated code signs the user in and then forgets to ask whether they own the record they just requested.
02
Input it did not expect
A demo runs on clean input. Production gets the malformed, the hostile, the injection. Veracode found 86 percent of samples failed to defend against cross site scripting.
03
Secrets
Models embed API keys and credentials directly in the code they write. In a demo that line is invisible. In a repository it is a breach waiting to be noticed.
04
Failure
What happens when the database is down, the call times out, the disk fills. A demo never fails on cue. Production fails on schedule, and the code has to fail safely.
05
The next person
Code no one reviewed is code no one understands. When it breaks at two in the morning, someone has to reason about logic they never read. That gap is the real debt.
04 · Review is the work now
When the writing gets cheap, the reviewing gets expensive.
The economics inverted. Producing a first draft of software used to be the bottleneck. Now it is nearly free. What stayed scarce is judgment about whether the draft is correct, safe, and something a team can maintain. That judgment did not get cheaper. It got more important, because there is far more code arriving and far less certainty about any single line of it.
The 2025 Stack Overflow Developer Survey put numbers on the mood. 80 percent of developers now use AI tools. Trust in their accuracy fell to 29 percent. The single most common frustration, named by 45 percent, was output that is almost right but not quite. Almost right is the most expensive kind of wrong. It passes a glance and fails under load, and the person who has to find it is rarely the person who generated it.
The answer is not less AI. It is more review, run by people who are accountable for the result, applied as a standing gate rather than a favor someone does when there is time.
05 · One example that holds the whole problem
The endpoint that works and leaks.
Ask a model for an endpoint that returns a customer's invoices. It writes a clean handler. It checks that the request is signed in, queries the invoices, returns them. It runs. It passes the path you test it on. Now read it closely. It never confirms that the signed in user owns the invoices it is about to return. Pass a different id and it hands over someone else's billing history.
This is among the most common flaws in generated code, and it is invisible in a demo, because the demo only ever calls the endpoint with the right id. The prompt asked for invoices, so the model returned invoices. It did not ask who is allowed to see them, so the model did not check. A person reviewing for production asks the question the prompt forgot. That question, asked every time, is the discipline.
Before this ships, confirm for every endpoint: · the caller is allowed to touch this exact record, not merely signed in · untrusted input is validated and escaped, never trusted · no key, token, or credential is written inline · failure paths return safely, they do not leak or crash Ship only when a person who did not write it has checked all four.
A review gate · the demo never runs it, production always does
06 · Where it belongs
The method is not wrong. The placement is.
Vibe coding earns its speed at the front of the work. Prototypes that test whether an idea is worth building at all. Internal tools with a handful of trusted users. The throwaway script that answers one question and is deleted the same day. On that work, reading every diff is waste, and the speed is the entire point. Using it there is not the mistake.
The mistake is letting the prototype become the product without anyone deciding it should. The demo that works quietly turns into the thing customers depend on, carrying none of the checks a product needs, because no one examined it again once it ran. The failure is never the first prompt. It is the promotion that nobody signed off on.
07 · What the enterprise adds
Same speed on the way in, a gate on the way out.
The enterprise version of vibe coding keeps the generation and adds a boundary. Generate fast. Then treat every line as unreviewed until a person accountable for security and correctness has read it. Decide what done means before you start, in terms a reviewer can actually check. Keep the model on the drafting. Keep the judgment with the human who has to answer for the result.
It is tempting to wait for the next model to fix this. The evidence says do not. Veracode tested more than 100 models on 80 coding tasks and found that 45 percent of the code introduced a known vulnerability, and that larger models did not produce safer code than smaller ones. The security gap is not a scaling problem the next release quietly solves. It is a review problem. Review is a discipline a company installs, not a feature it waits to receive.
Closing
The code was never the hard part. Trusting it was.
Take the last thing an agent built for you that shipped. Open it. Read it as if someone hostile will. Find the check the prompt forgot to ask for. That check, run every time before anything reaches a customer, is the whole difference between a demo and a business.
Andrej Karpathy's coinage, February 2025 · Veracode 2025 GenAI Code Security Report · Carnegie Mellon SusVibes benchmark, 2025 · 2025 Stack Overflow Developer Survey
Share this perspective
More insights
Adjacent perspectives.
Bttr. Field Brief
The brief Bttr. writes for senior buyers.
Monthly. One signal worth your time on Brand Operating Systems, AI search visibility, and the infrastructure buildout. No filler.