Vibe Coding vs Agentic Engineering: Where the Line Is

I use coding agents daily on client work, and they type a lot of the code. That is not the same as vibe coding, and the difference matters most to the people paying for the software. This post defines both, shows where each fits, and gives the checklist I use when a client arrives with a vibe-coded prototype that now has real users.

What is vibe coding?

Vibe coding is writing software through prompts while ignoring the code itself. Andrej Karpathy coined the term in February 2025, describing a style "where you fully give in to the vibes, embrace exponentials, and forget that the code even exists", as quoted by Simon Willison in Not all AI-assisted programming is vibe coding.

Willison's point in that post is the one I find most useful: the term gets stretched to cover all AI-assisted coding, and it should not. In his words, if an LLM wrote the code and you "reviewed it, tested it thoroughly" and made sure you could explain how it works to someone else, "that's not vibe coding, it's software development." His own rule is that he won't commit code he "couldn't explain exactly what it does to somebody else."

What is agentic engineering?

Agentic engineering is professional software development where coding agents do much of the typing and the engineer stays responsible for the result. Willison's Agentic Engineering Patterns guide defines it as "the practice of developing software with the assistance of coding agents", and describes what the human still does: decide what code to write and weigh the trade-offs, give agents the tools and a detailed enough problem, verify the results, and update instructions as the agents' mistakes reveal gaps.

When is vibe coding the right choice?

Vibe coding is the right choice when the code is disposable and the stakes are low. I use it, deliberately, for:

• Throwaway prototypes to test whether an idea is worth building properly.
• Personal tools that only I run, on data I can afford to lose.
• UI exploration, generating three layouts to react to before designing one.
• Learning what a library or API can do before reading its docs closely.

The common thread is that nothing depends on the code continuing to work, and nobody else's data passes through it. The trouble starts when a prototype quietly becomes the product.

Even when vibe coding, a few habits keep the downside small. Work in a fresh repository or a throwaway branch. Use fake or sample data, never an export of real customer records. Give the agent no production credentials and no access to shared accounts. Commit often, so you can roll back a bad turn instead of arguing with the agent about it. And label the result honestly: a README line that says "prototype, not reviewed" stops a colleague from deploying it next month because it looked finished.

What goes wrong when vibe-coded software reaches production?

Three things go wrong: security holes nobody looked for, agents taking destructive actions nobody constrained, and subtle bugs nobody can diagnose because nobody understands the code.

Security. Veracode's GenAI code security report, testing over 100 models across Java, Python, C# and JavaScript, found that "45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities". Java had "a 72% security failure rate", and the models failed to defend against cross-site scripting in 86% of relevant samples. If nobody reviews the code, nobody catches those.

Destructive actions. In July 2025, The Register reported that SaaStr founder Jason Lemkin's production database was deleted while he built an app on Replit, with the tool's own message calling it "a catastrophic error of judgement". Lemkin also wrote that "there is no way to enforce a code freeze in vibe coding apps like Replit." The lesson is not about one vendor: an agent with production access and no guardrails can do anything that access allows.

Almost-right code. In the 2025 Stack Overflow Developer Survey, 66% of developers named "AI solutions that are almost right, but not quite" as their top frustration, and more developers distrusted AI output (46%) than trusted it (33%). Almost-right code that nobody reads is how a bug reaches users. I wrote about that failure mode in almost-right AI code.

What does agentic engineering look like in practice?

It looks like normal engineering discipline, applied to a faster typist. The habits I rely on:

• Spec first. A short written plan of what to build and how to verify it, before the agent writes anything. See spec-driven development with AI.
• Project instructions. A CLAUDE.md or equivalent with the commands, conventions and things the agent must never do, updated whenever it makes the same mistake twice. My guide to writing a CLAUDE.md covers it.
• Tests as the definition of done. The agent runs the tests and must make them pass; I check that the tests themselves test the right thing.
• Small diffs, reviewed. One change at a time, read before it merges.
• No production credentials. Agents work in a sandbox or a branch with preview deployments, never against live data.
• CI as a backstop. Type checks, linting, tests and a dependency audit on every pull request.

None of this makes the agent slower in a way that matters. It makes the output something you can put your name to.

How do you take a vibe-coded prototype to production?

Treat the prototype as a detailed spec, not as the foundation, until you have proved otherwise. This is the checklist I work through:

• Read the code. All of it, or have someone who can. Note what nobody can explain.
• Find the secrets. API keys in the client bundle, in the repository history, in environment files committed by accident. Rotate anything exposed; protecting API keys in AI web apps covers the fixes.
• Check authentication and data access. Can one user read another's data by changing an ID? This is the most common serious hole I find.
• Write tests for what it already does, so you can change it without breaking it.
• Remove the agent's production access. Separate environments, least-privilege database users, backups you have restored at least once.
• Add the production basics: error handling, logging, rate limits and monitoring. My checklist for hardening an AI feature for production covers the AI-specific parts.
• Decide: keep or rebuild. If most of the code cannot be explained or tested, rebuilding the core with agentic engineering is often faster than repairing it.

Work with me

I take vibe-coded prototypes to production and build new products with agentic engineering: specs, tests, review and least-privilege access from the first commit. See full-stack development and SaaS MVP development, or browse my work and book a call.