Vibe coding on a professional team: where to draw the line

Vibe coding, the practice Andrej Karpathy named in a post on X in February 2025, means letting an agent write the code while you steer by outcome and never really read what it produced. By November, Collins Dictionary had made it its word of the year, and engineering leaders were left with a real question: does vibe coding have a place on a professional team, or is it a firing offense with good marketing?

Our answer, from running agents inside client teams: it has a legitimate place, and a sharply bounded one. Vibe coding is a fast mode for work whose failures are cheap. It becomes a liability the moment its output touches a production path. What draws the line between the two is verification, whatever the tool or the model.

Where vibe coding earns its keep

Prototypes exist to answer a question: will users click this, can these two systems talk, is this workflow viable. Once the question is answered, the code has done its job, and most of it should die. Reading every line of code that exists to be thrown away is a use of senior attention nobody can defend. The same logic covers spikes, demos for a sales conversation, one-off analysis scripts, and internal tools with three known users and no external surface.

In these settings vibe coding is a sensible allocation of attention. A defect costs a shrug, and speed has real value. A team that insists on full engineering rigor for a Tuesday prototype is spending money to feel disciplined.

Where it becomes a liability

Production is different. Authentication, payments, data handling, anything reachable by users or attackers: here, code nobody read is a stack of failure modes nobody owns, and three debts come due.

Security is the obvious one: unreviewed generated code ships vulnerabilities at rates that should settle the debate, as the research on AI-generated code security shows. Comprehension is the slower one: six months later, someone has to debug this under incident pressure, and with vibe-coded systems the answer to "who understands this" is nobody, which turns a two-hour incident into a two-day one. And diligence now sees it from outside. Acquirers and investors have learned to probe for it, and a codebase the founders barely wrote changes how a company gets valued.

Verification draws the line

Notice what appears in neither list: which agent, which model, how much of the code the AI wrote. The same agent, driven the same way, produced the disposable prototype and could produce the production change. What separates a professional vibe coding practice from a liability is whether anyone can vouch for the code when it matters, through tests that pin the behavior, review by someone accountable, and a diff a human read.

Engineering has always been the discipline of knowing why the system works, and typing was only the visible part. Agents made producing code nearly free, so verification is now most of the job. A team that understands this can use vibe coding aggressively wherever verification is not worth buying.

Run both modes, labeled

The teams that handle this well do something simple: they make the mode explicit. Prototype work lives in clearly labeled repositories or branches, is deployed nowhere near production, and everyone knows the code comes with no warranty. Production work follows the full path: tests, review, CI gates.

The rule that makes the split safe is the promotion rule. Prototype code never slides into production because the demo went well and the deadline is close. Promotion means a rebuild through the production path: tests written first, as the harness the agent works against, review by the owner of that surface, security checks. Sometimes the rebuild reuses most of the prototype code, and that is fine, because code that has been verified is no longer vibe-coded. The failure mode to police is silent promotion: the Friday prototype that is load-bearing by Monday. Every horror story we have been called into started there.

So write it down for your team: two modes, both allowed, labels required, and a one-way door between them that only verification opens. Setting up that door, with the guardrails, the review discipline and the habits around it, is the substance of our agentic engineering work, and it lets a team keep the speed of the first mode without paying for it in the second.