Vibe coding vs vibe engineering: where the line is

Short answer: vibe coding is prompting an AI, running the result, and accepting it if it appears to work, without reading the code. Using AI as an engineer means you still decide the design, read the diff, write or review the tests, and can explain every line you ship. Same tool, different responsibility.

Where did the term come from?

Andrej Karpathy used "vibe coding" in early 2025 for a way of working where you "fully give in to the vibes" and forget that the code exists. He described it as fine for throwaway weekend projects. The term then spread to cover almost any AI-assisted programming, which blurred it.

What is vibe coding good for?

• Prototypes you will throw away.
• Personal scripts and one-off data cleanups.
• Learning what is possible before you design properly.
• Landing pages and internal tools with no sensitive data and a handful of users.

In these cases speed matters and the cost of failure is low. Nobody should be ashamed of it.

When does it stop being fine?

When someone else depends on the result. Payments, authentication, personal data, anything that runs unattended, anything you will maintain for a year. The problem is not that the code is always bad. It is that you cannot tell which parts are bad, because you did not read them.

What does engineering with AI look like?

• You write the spec. Even a half-page of intent, constraints and non-goals.
• You ask for small steps. One function or one endpoint at a time, so a diff is readable.
• You read the diff before you accept it.
• Tests come first or alongside. And you check they fail when the code is wrong.
• You run linters, type checks and a security scan in CI regardless of who wrote the code.
• You keep the architecture in your head or in a short document, and correct the tool when it drifts.

How do you tell which one you are doing?

Ask yourself these.

• If this broke at 2 a.m., could I find the cause without asking the AI?
• Do I know which libraries it added and why?
• Can I explain how a request moves through the system?
• Would I be comfortable with a stranger auditing this?

If most answers are no, you are vibe coding. That is allowed. Just do not call it production.

What are the common failure patterns?

• Duplicated logic across files because each prompt started fresh.
• Authorisation checks that exist on the page but not on the API route.
• Secrets pasted into client-side code.
• Packages that do not exist, or exist under a similar name run by someone else.
• Tests that assert the current behaviour, including the bugs.
• Silent changes to unrelated files.

Is it a good way for beginners to learn?

It teaches you what you can build quickly, and it hides how things work. A useful compromise is to ask the tool to explain each piece, then type small parts yourself. You learn debugging by debugging. If every error goes straight back to the model, the skill never forms.

For a longer look at the safety side, see is vibe coding safe.