Agentic Engineer vs Vibe Coder: What's the Difference?
How much do we use AI coding tools, and which is the favorite?
For the last 3–4 years, AI has inevitably become a part of everyone's coding sessions. According to research conducted by IdeaPlan on April 29th, 85% of developers use AI coding tools and 73% use them regularly [1]. It would not be wrong to say that this figure is much higher for the younger generation.
After all, as GenZ, we were born into the world of AI and are raising ourselves as early adopters by default. Let's keep this in mind and now look at which AI coding tools are being used.
According to research by The Pragmatic Engineer in March 2026, Claude Code leads as the most loved coding tool with 46%, having risen from zero to this point within 8 months. Second in this ranking is Cursor with 19%, while GitHub Copilot is in third place with 9% [2].
When you become a passenger in your own codebase
Coding tools are improving every single day. I don't want to bore you by going too far back, but a short while ago, Gemini 3 Pro and Opus 4.5 entered our lives at almost the same time and left everyone in shock.
Following that, 3.1 Pro and 4.6 took things a step further, and people began talking about Opus 4.6 being something akin to AGI.
The problem here is this: as models improve and people see that the outputs are correct, they have stopped questioning the changes made or what is happening within the system architecture.
Even though the code written by these tools is fully transparent and we can see what has changed, people have reduced their review of the code so much that these tools have effectively turned into a black box. Feed the input, look at the output, and if it's wrong, iterate until it becomes correct.
People coding with this methodology (I do it too sometimes when I need to ship fast, I won't lie) lose track of the architecture at some point: maybe you understood what was going on while writing code on day 1, day 2, and day 3…
But on day x+3, when you needed to get work done quickly, you stopped questioning… and suddenly, you lost your power and knowledge over the architecture. Now you are only there symbolically as a human-in-the-loop.
TL;DR: In a world that evolves rapidly and requires us to ship fast, we aren't conscious of the code we write. This problem leads to technical debt and bad coding practices; the pain might not surface in a week, but by the first month it becomes MASSIVE.
Why can't coding tools always apply best practices?
Even with a tool as powerful as Claude Code, we see that it sometimes fails to apply coding best practices.
Sometimes it doesn't reuse a shared function in the codebase, sometimes it introduces unnecessary complexity, fails to use an existing software design pattern, forgets necessary exception handling, stays weak on modularity, or doesn't fully implement scalability best practices with the future of the code in mind…
Of course, it is incredibly powerful and Claude Code feels like magic. However, technical debt and system architecture should never be underestimated.
You MUST NOT forget that once you introduce a bad practice, you will fill the context of these coding tools with those very same bad practices.
We know that agentic tools like Claude Code perform context research before doing any task: What is the interface of the code to be changed? Which parts of the code are related, and where should changes be made? How is the code written? Is a specific design pattern used?
Consequently, if best practices are not applied in your codebase, the code Claude writes will also be written according to those bad practices, that is what will inspire it.
This is exactly what separates "Vibe Coding" from "Agentic Engineering." The difference is about being aware of these, taking deliberate actions, and bringing the human-in-the-loop from a symbolic dimension back to a functional one.
It requires a human to truly understand the architectural decisions made, check for modularity, verify best coding practices, perform scalability analysis, look at exception handling, know design patterns, ensure existing functions are reused (avoiding redundancy), apply atomic-concern principles, and make sure file line counts don't exceed 400–500…
There will be those who say: "Can't I just put these as principles into a CLAUDE.md file? If I provide them there, won't it keep them in mind and act accordingly?"
It's certainly a good argument and it might work to a certain extent, but is it enough? I don't think so. Will it ever be enough? As long as tokens burn a lot of money, still no…
Only if the price per token decreases can these best practices be abstracted away on the developer side. Only then can a Vibe Coder produce outputs of nearly the same quality as Agentic Engineering.
Why writing to CLAUDE.md isn't enough
CLAUDE.md is a configuration file that Claude Code reads automatically at the beginning of every session, which can be defined per-project or globally. Here, you write how Claude should behave, which rules it should follow, and what it needs to know about the project.
However, you have no guarantee that Claude will keep what you've written in mind. You're certainly further ahead when you write it than when you don't, but you still cannot be sure.
This is because with every prompt you submit, whether for a new feature or a bug fix, you begin to fill Claude's context. And the likelihood of the information within CLAUDE.md being taken into account gradually decreases.
At some point, when you don't see best practices being applied while the code is being written, you'll find yourself saying, "But I told you this, Claude, it was in your markdown file!"
We see this especially with long-form skills, such as Superpowers' brainstorming skill or Matt Pocock's "grill-me" skill. Both require extensive prompting to achieve a shared contract between the human-in-the-loop and Claude Code. In these skills, you sometimes need to answer 10 or 20 questions.
After answering those questions to agree on a shared understanding, a design.md file is created, followed by an implementation plan, and then you start coding.
Throughout this process, the things you wanted Claude to remember from your CLAUDE.md file have likely already been forgotten because of context decay.
Is there a solution? Yes, but first you must acknowledge the problem and remind yourself of it during every single session.
How to actually solve this issue
First of all, there's no doubt that the brainstorming and grill-me skills are incredibly useful and will make your coding sessions 10x more productive. As someone who has used Claude Code continuously for more than 4 months, I personally use those skills every time I implement a new feature.
And when I say continuously, I'm serious. My daily average commit count for the last 2 months is over 60; I walk around with my computer in my hand, and I even code from my phone, so I had to establish my own workflows.
To solve the problem here, you need to understand that LLMs are stateless and would be "practically useless" if the concept of context didn't exist. As I mentioned, because of these skills you might be asked 20 questions, and you'll provide 20 answers. Afterward, an implementation plan is written as a "spec" in some folder, and Claude asks whether it should proceed.
It is at this point that you can achieve relatively better best practices if you prompt the following instead of jumping straight to "proceed":
"In this session I've answered nearly 20 questions because we had to design the implementation plan around a shared understanding. Now my context window is nearly full, so I need you to create a self-sufficient session-onboarding prompt so another Claude session can continue seamlessly. Mention the implementation .md file you just wrote, and explicitly state that this .md file may not be designed according to the best practices in CLAUDE.md. Also explicitly state that, in that first prompt, Claude must audit the implementation plan and adjust it to the best practices in CLAUDE.md. Finally, have it ask me whether to go subagent-driven or inline-driven."
What do you gain? First, a spec has been written for you, there's an implementation plan and we'll need it. But because that plan was written over 20–30 prompts, it's very likely it wasn't written according to best practices.
So we start the new session with a clean context window while stating that the plan needs to be adjusted with best practices in mind. This way, you won't have to constantly keep coding practices in your head throughout the session.
Note: As an extra step, add a check to the prompt above for any incompatibility between the existing spec and the current codebase. That way, if there's a gap in the plan, it performs a self-audit.
Bonus: Claude Code + Playwright MCP = automated E2E testing (for web apps)
After your code is written, your feature likely won't be done in a "one-shot" manner. The subject I'm about to mention is testing, in corporate structures, others might handle it, but I'll explain from a startup perspective, where the assumption is that you do the testing yourself.
The first thing to do after the code is written is unit testing; for this, I strongly recommend either preparing a skill for yourself or using an existing one. Afterward, perform your integration tests. Finally, my favorite part, E2E testing. Here, live containers are used, you test in a real development environment, and you use the Playwright MCP.
Playwright MCP enables Claude Code to use a browser. It mimics real user behavior to surface bugs at the user level, feeds the errors back to itself, fixes them, and iterates. But you need to state this explicitly each time:
"Use the Playwright MCP, generate a list of the journeys affected by the feature we just implemented, test these user journeys, stop when you find an issue, feed the problem back to yourself, verify you've solved it by repeating the journey, and do this until you've checked all journeys one by one…"
The act of constantly giving this as a prompt will probably remind you of something. Yes, skills! So I recommend writing a skill for this; its content should include the methodology above, and you can even tell it to follow a methodology like DFS.
What I mean is: you can instruct the Playwright MCP to treat every possible action at any given point as a branch, and then tell it not to stop until all branches are explored (all possible user journeys tested). You speak in an algorithmic language Claude understands (DFS) and bring every potential journey to the surface:
"While identifying affected user journeys, think of every state where a user can take an action as a node, consider every action they can take at that point, and keep it in mind as a branch; create an affected-journey tree this way and use DFS while doing so. Proceed automatically until the affected-journey tree is fully explored and all bugs are fixed. Whenever you find an error in a path, feed it back to yourself, repeat the journey that path represents, and ensure it's fixed. Continue until all branches are explored and functioning as intended…"
This prompt can certainly be improved further; I'm giving you the baseline, and you're free to develop it.
Conclusion
- Using AI coding tools does not mean being a vibe coder. If they're used consciously, the codebase stays clean, and in that way, your teammates and even your teammates' agents will function properly.
- If there are multiple people coding on a team, an internal agreement must be reached on how to keep the codebase clean; everyone must do their best to maintain it in every session.
- Agentic Engineering is the transition of the human-in-the-loop from a symbolic point back to a functional one. It's about making deliberate decisions on system architecture, managing context effectively, and creating efficient AI coding workflows.
- Yes, there's a massive level of abstraction in coding today, and these tools are now very intelligent. But you can be sure that if we code blindly due to the context-window problem, best practices will eventually cease to be implemented (tried and tested).
Thanks a lot for reading, I hope it was, or will be, helpful.
One last suggestion
This piece holds special significance for teams shipping at high velocity; in fact, it was written specifically for them. I recommend applying these best practices even if you aren't in a rush to ship, but this article specifically explores how to keep a codebase clean while minimizing the human-in-the-loop.
In a scenario where you have the time, meaning you aren't in a hurry, my recommendation is always to understand exactly what Claude is writing and changing, at least at a module level. You don't need to know what every single line does in exhaustive detail, but maintaining a grasp of your codebase at a module or function level remains critical.
References
- IdeaPlan, AI coding assistant market share, 2026
- The Pragmatic Engineer, AI tooling, 2026