Vibe Coding Is Not Engineering
Vibe coding shipped fast and broke things. Engineering ships fast and keeps things running. The difference is discipline—and AI makes discipline more important, not less.
In February 2025, Andrej Karpathy posted on X about a new way of building software. He called it "vibe coding"—an approach where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." You describe what you want. The AI writes it. You run it. If it works, you ship it.
A year later, 92% of US developers use AI coding tools daily. 46% of all new code is AI-generated. And developer trust in that code has dropped from 77% to 60%.
The trust gap tells the story. Vibe coding is a real practice with a real place in the world. But when people conflate it with software engineering, teams get hurt—and so do the users who depend on what those teams build.
What Vibe Coding Is (And Isn't)
Karpathy's original definition is precise: you accept AI-generated code without closely reviewing its internal structure. You iterate by testing outputs and adjusting prompts, not by reading the code itself. If you review and understand every line, you're using a large language model as a typing assistant—not vibe coding.
This distinction matters because the term has been stretched until it lost meaning. Every developer using Copilot or Cursor calls themselves a vibe coder now. But there is a meaningful difference between a developer who uses AI to accelerate work they understand, and a builder who ships code they cannot read.
The Spectrum of AI-Assisted Development
None of these are inherently wrong. A weekend prototype, a proof of concept, a personal tool that only you use—vibe coding is perfect for those. The problem starts when vibe-coded software gets deployed to production, handles user data, or underpins a business.
The Numbers That Should Concern You
The data on vibe-coded software in 2026 paints a consistent picture:
of AI-generated code contains top-10 web application security vulnerabilities that pass undetected because nobody reads the code to audit it.
more time spent debugging AI-generated code than writing the equivalent by hand—the "AI speed" advantage vanishes on contact with reality.
failure rate for cross-site scripting (XSS) protection in AI-generated code— one of the most common web application security vulnerabilities.
of developers trust AI-generated code in 2026, down from 77% in 2023. The more teams use AI code, the less they trust it.
These numbers come from teams using AI to write code without the engineering practices to verify it. The AI is not the problem. The absence of engineering around the AI is the problem.
The Casualties
The documented failures from vibe-coded production software are not edge cases. They are the predictable result of shipping code nobody understands.
Enrichlead: Client-Side Security as Architecture
A vibe-coded startup put its entire authorization logic on the client side. Users bypassed it in minutes. The company collapsed—not because the feature didn't work, but because nobody read the code to notice that security decisions were happening in the browser.
Replit's AI Agent: Deleting Production Data
An AI coding agent, operating autonomously with database access, deleted a production database during a routine task. The agent followed its instructions correctly—the instructions just never accounted for destructive operations because no human reviewed the execution plan.
The Pattern
What Engineering Adds That Vibes Don't
Engineering is not "coding but slower." Engineering is a set of practices that exist because software fails in ways you cannot predict by running it once. The practices survive because they work.
Specification Before Implementation
Engineers define what the system should do before writing code. A spec catches requirement gaps, conflicting behaviors, and missing edge cases—before any code exists. Vibe coding skips this step and discovers gaps in production.
Code Review as Security Gate
Every line of code is read by someone who didn't write it. This catches not just bugs but architectural mistakes—like putting authorization logic on the client side. Vibe coding eliminates review by definition.
Testing as Contract
Tests encode what the system promises to do. When AI generates code, tests verify the promises are kept—regardless of how the code achieves them. Without tests, the only contract is 'it worked when I tried it.'
Standards as Institutional Memory
Coding standards encode lessons learned from past failures. They prevent teams from repeating mistakes—even when the person who made the original mistake has left the team. AI agents need these standards even more than humans do.
AI Makes Engineering More Important, Not Less
This is the core argument that the vibe coding movement gets backwards. The claim: AI writes code so well that engineering practices are overhead. The reality: AI writes code so fast that engineering practices are the only thing preventing catastrophe.
When a human writes code slowly, the pace itself provides a natural review window. You read what you wrote because you wrote it line by line. You notice the hardcoded credential because you typed it. You catch the missing null check because you thought about the variable as you declared it.
When AI generates 500 lines in 30 seconds, that natural review window disappears. The code arrives fully formed, and the cognitive effort required to review it is higher than the effort to write it would have been. This is why the 63% debugging overhead exists—reviewing unfamiliar code is harder than writing familiar code.
The Velocity Paradox
Our team uses AI to generate the majority of our code. We also maintain over 40 Cursor rules, run exhaustive compliance reviews on every task, write specs before implementation, and require type-checking and linting to pass before any work is considered complete. We ship fast because of the engineering practices, not in spite of them.
The Discipline Stack for AI-Assisted Engineering
If you are using AI to write production code—and you should be—here is the discipline stack that separates engineering from vibes.
Spec First, Prompt Second
Before you tell the AI what to build, write down what the feature should do. Requirements. Edge cases. Success criteria. The spec is a forcing function for thinking—and it becomes the standard the AI's output is measured against.
We call this Spec-Driven Development. Teams that plan before prompting see 6x better results than teams that prompt first and fix later.
Codified Standards (Cursor Rules)
AI agents start every session with zero project history. They don't know your naming conventions, your framework patterns, or the architectural decisions your team made six months ago—unless you tell them.
Cursor rules encode accumulated team wisdom into machine-readable instructions. They are the difference between an AI that generates generic code and an AI that generates code that belongs in your codebase. We maintain rules for communication standards, framework patterns, and compliance review.
Automated Verification
Type-checking, linting, and tests are not optional add-ons. They are the automated gates that catch what human review misses. When AI generates code at volume, these gates become load-bearing—they are the only consistent verification layer between generation and deployment.
The rule is simple: no task is complete until typecheck, lint, and build pass. AI output that doesn't compile is not a draft—it's not done.
Exhaustive Compliance Review
Before declaring any task complete, the AI agent scans every rule in the project, assesses which ones apply based on what it did (not where the files live), reads each applicable rule, and verifies compliance. The cycle repeats until a full pass finds zero violations.
We wrote about this in detail: Obey The Rules or Die. The name is deliberate. Compliance is not optional.
Human Review of Architecture, Not Syntax
When AI handles code generation and automated tools handle compliance, human code review shifts upstream. Reviewers focus on architectural decisions, security boundaries, data flow, and system design—the questions that require domain expertise and business context. The result: faster reviews, higher-value feedback, fewer nitpick comments.
Governance Is the Equalizer
Here is where the vibe coding conversation goes wrong most often: people hear "non-engineers shouldn't ship code without review" and interpret it as "non-engineers shouldn't touch the codebase." That is the opposite of what we believe.
Every team member should be contributing to the system—regardless of discipline. A product manager who uses AI to fix a copy string, a designer who adjusts a component's spacing, a marketer who updates a blog post. These are not distractions from "real engineering." They are the team operating at full capacity. When every person on the team is empowered to contribute directly, the entire organization moves faster.
The discipline stack makes this possible. When codified standards tell the AI how your codebase works, when automated verification catches type errors and broken builds, and when compliance review enforces team conventions—the contributor's discipline becomes less relevant than their intent. A designer working with AI inside this governance structure produces code that meets the same standards as a senior engineer. The rules do not care who prompted them. They care whether the output complies.
The Real Unlock
This is a strictly better outcome than vibe coding. Vibe coding says "anyone can ship code because the AI wrote it." Governed AI-assisted development says "anyone can ship code because the system verifies it." The first trusts the AI. The second trusts the process. The process is more reliable.
Vibe Coding vs. AI-Assisted Engineering
- Prompt → generate → run → ship
- Verification: "it works when I try it"
- No spec, no tests, no review
- Builder cannot debug what they shipped
- Speed measured by time-to-first-demo
- Spec → prompt → generate → verify → review → ship
- Verification: types, tests, lint, compliance review
- Spec defines success, rules define quality
- Engineer understands the architecture
- Speed measured by time-to-reliable-production
Both use AI. Both generate code fast. The difference is what happens between generation and deployment. One trusts the vibes. The other trusts the process.
Where Vibe Coding Belongs
This is not an argument against vibe coding. It is an argument against pretending vibe coding is engineering.
Vibe coding is excellent for:
Prototyping
Validate an idea before investing engineering effort. Ship a prototype in hours instead of weeks. If the idea has legs, rebuild it with engineering practices.
Personal Tools
A script that renames your files. A dashboard only you use. A tool with no users to protect and no data to secure. Vibes are fine when the stakes are low.
Learning
Exploring how something works by asking AI to generate examples. Understanding a concept through generated code you can experiment with. Great for learning, dangerous for production.
Vibe coding does not belong in production systems that handle user data, process payments, manage authentication, or run business-critical workflows. Not because AI isn't capable—but because those systems require engineering practices that vibe coding explicitly skips.
The Culture Question
The deeper concern with vibe coding is what it does to engineering culture. When "it runs" becomes the quality bar, several things degrade simultaneously:
Debugging skills atrophy
When builders cannot read their own code, they cannot debug it. They throw errors back at the AI and hope for a fix. This works for simple bugs and fails for complex interactions between systems.
Architectural understanding disappears
If you never read how your data flows through the system, you cannot reason about security boundaries, performance bottlenecks, or failure modes. The code is a black box—and production systems cannot be black boxes.
Knowledge transfer breaks down
When someone leaves a vibe-coded project, the remaining team inherits code that nobody—including the person who prompted it—understands. There are no specs, no architectural decisions, no documented trade-offs. Just prompts and generated output.
Quality expectations lower
Teams that accept "it runs" as "it's done" gradually lose the reflex to ask "is it right?" and "will it last?"—questions that separate engineering from assembly.
Engineering culture is a set of shared beliefs about what good looks like. When vibe coding is treated as engineering, it redefines "good" to mean "it compiled"—and that redefinition is contagious.
AI is the most powerful tool for software development that has ever existed. It makes good engineers faster, it makes non-engineers capable contributors, and it makes bad practices more dangerous than ever. The answer is not to reject AI or to gatekeep who gets to use it. The answer is to build governance that makes everyone's contributions safe—specs, standards, review, verification.
Vibe coding is a valid prototype strategy. It is not a valid engineering methodology. The difference is not who writes the code—it's whether the system verifies it. Build the system. Then let everyone contribute.
Build governance that empowers your whole team
Our team—engineers, product, and beyond—uses AI to contribute to the system at scale. Specs, Cursor rules, compliance reviews, and automated verification make every contribution safe. If you're building an AI-augmented team where everyone contributes, I'm happy to share what we've learned.