Agentic Engineering
vs. Vibe Coding
Both use AI to write code. One produces a demo that looks great and breaks the moment a live user touches it. The other produces production software that still runs in month seven. The difference is not the tool — it is who is accountable at the decision point.
Andrej Karpathy coined the term "vibe coding" in early 2025 to describe a mode of AI-assisted development where the programmer prompts the AI, accepts the output, and never fully understands the code that was generated. His framing was honest: the vibe is to just build something fast, not to build something right.
The term spread because it named something that existed. A huge portion of AI-assisted development happening right now is vibe coding — founders using Cursor, v0, Lovable, and Bolt to generate applications they plan to ship to production without any architect reviewing the output. Some of those applications work great in demos. Almost none of them hold under production conditions.
The Definition That Matters
The difference between agentic engineering and vibe coding is not about which AI tool is used, how fast the code is generated, or whether the developer runs the output through a linter. It is about one thing: accountability at the decision point.
Vibe Coding
Agentic Engineering
In vibe coding, the AI is the architect. In agentic engineering, the AI is the contractor — executing against decisions made by a human who understands what the output is supposed to do in production, what happens when it fails, and how it will need to change in six months.
Why Vibe Coding Breaks in Production
The failure mode is almost always the same. A vibe-coded application works perfectly for the person who built it, in the environment where they tested it, with the data they used to demo it. Then it hits production. Live users do things the AI did not anticipate. Production data has edge cases the prompt did not describe. Production load exposes race conditions the AI never had reason to prevent.
The data model breaks at volume
AI tools generate data models that work for the demo data. They do not generate indexes, they do not plan for N+1 queries, and they do not account for concurrent writes. At ten users, it is fine. At one thousand, it locks.
Error handling is optimistic
AI-generated code handles the happy path. Network failures, malformed inputs, expired tokens, and third-party API rate limits are treated as edge cases to handle later. Production is made entirely of edge cases.
Security is assumed
Vibe-coded authentication often works — until it does not. Missing row-level security, exposed API routes, hardcoded credentials in environment variable names, and CORS configurations that accept anything are all patterns AI tools reproduce by default.
Nobody knows how to maintain it
The person who vibe-coded the application cannot explain how it works because they never understood it. When something breaks six months later, there is no architect to call — only a prompt history and a codebase nobody owns.
What Agentic Engineering Looks Like in Practice
The process does not look dramatically different from the outside. Code still gets generated with AI. The velocity is still high. The difference is everything that happens before the first prompt is written and between every significant output the AI produces.
Before a line of code exists: the data model is sketched on paper. The integration points are mapped. The failure modes are listed. The definition of production-ready is written down. The AI does not decide any of those things — the architect does, drawing on experience with production systems, documented failure scenarios, and live operations.
During development: every significant AI output is reviewed against those decisions. Not line by line — at the decision level. Does this data model hold under the load we expect? Does this auth pattern match our threat model? Does this error handler handle the errors that will happen, not the errors the AI guessed might happen?
After launch: the architect owns the code. Not the AI tool. Not a prompt history. A human who can explain every significant decision, change any part of the system, and respond when something goes wrong.
The Question to Ask Before You Build
Before you start any AI-assisted build, one question separates a production outcome from a demo:
“When this breaks in production at 2am, who understands it well enough to fix it?”
If the answer is "whoever wrote the prompts," you are vibe coding. If the answer is a named architect who can read the code, explain the decisions, and fix the failure — that is agentic engineering.
The AI does not care about the answer. It will write the code either way. The question is for you — and for whoever is relying on the software to run their business.
Build It to Production Standard
Every build at Paddock20 starts with a structured scoping session — a documented scope, a data model, and a production-readiness definition before any code is written. It opens with a free 15-minute Fit Call. That work is what separates the 31% that ship from the 69% that stall.
Build With RAIL: Free
90 Seconds to
Build Your App
With RAIL.
Answer three questions—type them or say them out loud—and watch RAIL scope your app in real time. Named app, working interface, and a build blueprint you keep. Before you ever talk to anyone.
A named app. A working interface. A blueprint PDF you keep. Whether we ever talk or not.