Vibe coding or agentic engineering: what is the difference?

What is vibe coding?

Vibe coding is letting AI write software from a description, without reading or testing the code yourself. You say what you want, accept what comes back and only check whether the result seems to work. For the alternative, read what agentic engineering is.

The term comes from Andrej Karpathy, who introduced it on X on 2 February 2025⁠↗:

In the same post he describes what that looked like for him. He always hits “Accept All”, no longer reads the diffs and pastes error messages back in without comment. When the model cannot fix a bug, he works around it or asks for random changes until it goes away. His own verdict: “It's not too bad for throwaway weekend projects”.

You will sometimes see 6 February given as the date, including by Simon Willison, but the post itself is from 2 February 2025. Dutch Wikipedia calls it vibecoden⁠↗. In November 2025 Collins Dictionary named vibe coding its Word of the Year⁠↗.

How does it differ from agentic engineering?

The difference is control. In vibe coding nobody reads or tests the code; in agentic engineering, or agentic coding, somebody does, through bounded tasks, tests and a review before anything goes live. The AI tools can be exactly the same.

Simon Willison draws the line in the same place. In March 2025⁠↗ he wrote: “When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes.” If you do review, test and understand the code an LLM wrote, he argues, you are simply doing software development.

Karpathy saw the difference too. A year later⁠↗ he wrote that back then you would mostly use vibe coding for “fun throwaway projects, demos and explorations”, and that professionals now work with agents, “except with more oversight and scrutiny”. For that second way of working he proposed the name agentic engineering.

Same tools, different way of working

You can vibe code with Claude Code, Codex or Cursor, and you can do agentic engineering with them. The difference is what you set up around them. Coding agents can write and execute code. In agentic engineering you use that to have them test their own work, and then have someone else review the result. In vibe coding you skip those steps and accept whatever comes back.

When is vibe coding fine?

Vibe coding is fine when a mistake costs little: a prototype, a demo, an internal experiment or a project you throw away after a weekend. You want to see quickly whether an idea works, and whether the code will last does not matter yet.

• A clickable prototype to put an idea in front of users.
• A one-off script for yourself, with no sensitive data.
• A demo to show what is possible, for people who know it is a demo.
• Learning how a framework or API works by playing with it.

Be honest with yourself about what you built. A prototype that lands well turns into a product surprisingly fast, and then different requirements apply.

Karpathy looked back on it soberly a year later: “It was good fun and it almost worked.” Almost working is enough for a demo, but not for an app people rely on every day.

When does it get risky?

Vibe coding gets risky as soon as the software touches real users, personal data, payments or connections to other systems. A mistake nobody saw then costs money, trust or data. So is vibe coding bad? Not in itself, but it is the wrong tool for this kind of software.

• Security. Code nobody read can ship an API key inside the app, or an endpoint that returns more data than it should.
• Maintenance. If nobody knows how it is put together, every change becomes guesswork. Karpathy noticed it himself: “The code grows beyond my usual comprehension”.
• Silent failures. Something works in the demo and fails on edge cases: no internet, empty input, a user in another country.
• Claims without proof. “It works on iOS” because the build passed, while nobody has seen it on a device.

For Plens, our app that tells cyclists when to leave to stay driest, these risks are written into the architecture decision as hard rules. One of them, translated from Dutch: no mobile secret, service role or provider key in the app bundle. And when we put the native app through an independent review on 24 September, the first blocking finding was that the whole app lived in a single file of 317 lines, without deep links. It was quick to build, but you could not keep building on it.

How do you get from a vibe-coded prototype to production?

Treat the prototype as a specification: write down what it should do, have the code reviewed, add tests and rebuild where the structure does not hold. Sometimes rebuilding is faster than repairing.

1. Write down what it should do. Capture the behaviour the prototype showed: what the user sees, what happens on an error, what must never happen.
2. Have the existing code reviewed. An independent review shows what is usable and what is not: structure, security, dependencies. How we do that is in AI code review by a council.
3. Add tests for the behaviour that matters. The core first, then the edge cases.
4. Split the remaining work into small tasks. Give each task a clear check, so an agent can carry it out and you can see when it is done.
5. Agree who decides. Who approves a release, and what may an agent never do on its own, such as deploying to production?

Repair or rebuild?

Whether you repair the prototype or rebuild it depends on what the review finds.

• Rebuild if there are no tests and the structure is hard to follow, if everything sits in a few large files, or if keys and passwords are in the code.
• Repair if the structure is easy to follow and mostly pieces are missing, such as error handling, tests or access control.

Rebuilding feels like waste, but by then the prototype has already done its job: it showed what the software needs to do.

The native Plens app started this way. The opening brief for Claude Code told it to use Opus 5 first as a critical reviewer of what Codex had already built, and then to continue in small, demonstrable vertical build loops. The app's first commit was on 16 September 2026; by 27 September it was in a closed test on Google Play.

Do you have an idea, a plan or existing code and want to know what it takes to build it properly? Forenta turns it into a development plan and checks the assumptions. How we build ourselves is on our Build page.

Checklist: which approach fits your project?

If you answer yes to any of the questions below, choose agentic engineering. If every answer is no, vibe coding is fine.

• Will anyone other than you use the software?
• Does it handle personal data, payments or commercially sensitive information?
• Does it connect to other systems, such as a database, a payment provider or an API with your key?
• Does it need to work in three months, and does someone else need to be able to change it?
• Would a mistake cost more than an afternoon of fixing?
• Do you want to grow it into a product later?

Not sure where your project stands? Get in touch and we will take a look with you.