Vibe coding vs agentic engineering: what changes

Vibe coding vs agentic engineering comes down to one question, which is who checks the work. In vibe coding, you prompt an AI for code and accept the result largely on feel. In agentic engineering, an agent still writes the code, but the repository checks it, and a change is done only when the agent has run the real thing and shown the output.

Both can use the same model and the same tools. The difference is what happens after the code appears. Use vibe coding when the code is disposable. Use agentic engineering when someone will depend on it.

The two side by side

Where vibe coding is the right choice

Vibe coding is the right choice when the point of the code is to answer a question. Will this layout feel right? Does this interaction feel right? Does this idea make sense once you can click on it? A sketch you can look at settles those faster than a discussion does.

Our own agent rules include a prototype playbook for throwaway work. Even there, the agent records what it observed, such as a screenshot or a logged timing. It is the one place where speed beats polish and code quality does not matter. It has two conditions. The prototype exists to make a named decision, and it lives in a scratch directory separate from production source. Once it has answered the question, it is thrown away and the chosen direction is built properly.

Setting up checks for code you plan to delete is wasted work. If nobody will depend on the result, feel is a good enough test.

Where vibe coding breaks down

It breaks down when the sketch becomes the product. The check that was good enough for a demo is now the only check on code that people rely on.

• +Unexercised fixes. An agent will confidently report a fix that it never ran. Code that compiles is not evidence that it works.
• +Rules that do not hold. An instruction in a prompt is a suggestion. Nothing stops the next change from ignoring it.
• +Paths you did not try. Judging by feel covers the path you clicked through. It says nothing about the others.
• +No trail. The reasoning lives in a chat transcript. The next person cannot audit the work without it.

A better model does not fix these. They are what happens when a person is the only check. They are what happens when a person is the only check. What is agentic engineering covers the alternative in full.

A checklist for moving from one to the other

You do not need a new stack. You need the repository to be able to say no. Work through these in order.

1. 01Write one verify command. It runs everything CI runs, which means typecheck, lint, format check, tests and build.
2. 02Put it where it cannot be skipped. If you work alone, that is the git hooks, with the bypass flag ruled out. If anyone else can push, it is a required check on a hosted runner. Pre-commit hooks vs CI explains which fits.
3. 03Change what done means. The agent runs the command and pastes the real output. It says which step could not run instead of skipping it quietly. See how to verify AI generated code.
4. 04Turn repeated corrections into checks. A review comment you give twice becomes a lint rule or a CI check. Guardrails for AI coding agents shows how.
5. 05Keep sketches out of production source. Prototype in a scratch directory, then rebuild the chosen direction inside the checks.
6. 06Give the agent written working rules. We publish ours as the agentic engineering manual, one file you can save into any repository.

Which one to use

Ask what happens to the code afterwards. If you will delete it once it has answered your question, vibe code it. If it will merge into a branch that deploys, or another person will build on it, it needs proof.

The two also work well together. Explore by feel, pick a direction, then build that direction where the repository can check it. The mistake is skipping the second step.

• agentic engineering
• comparison