Vibe coding vs agentic coding: what's the real difference

A few days ago a past client reached out to me and asked to quote a Webflow build for their new website. I told him that I don’t work with Webflow anymore, but I can offer you something much better - a fully coded website that you can integrate in your business processes run by an AI agent - Claude. I wrote about making that switch in detail. To me it’s a no-brainer. Since I made a switch, my productivity increased and I don’t waste time on manual stuff. Instead, I can lead several projects and build things.

To my surprise, the client responded with “Unfortunately we’re happy to stick to Webflow, and try to avoid LLM tools where possible.” It was disappointing but I get it.

LLMs, or rather their output, have a bad reputation - the AI slop. Since the technology democratizes writing code anyone can prompt a model to create something and in virtually all cases the result is slop. Garbage in, garbage out. Just faster. The term ‘vibe coding’ illustrates this very well. When you vibe code, you are not very serious about it, you just checking out things or maybe you test the model’s capabilities, or maybe you use it as a hobby with a tool like v0 or Loveable.

Even if you are serious about the product you are creating with an LLM, it’s most likely you are vibe coding it too. You care about the outcome but your workflow is a series of prompts and a bloated CLAUDE.md. There’s no spec, no plan. You open a new session, paste some context in, and hope the model picks up where you left off.

The difference between vibe coding and agentic coding is taking a fundamentally different approach. It’s not a series of prompts anymore. Instead, you create a certain structure in which you define requirements, goals, workflows, planning, context management, execution. This increases the output quality of the code that an LLM generates.

I’ve been using a spec driven approach and so far it proved really well. Every project I work on has a /project folder where we create a spec, architecture, state and roadmap files with the project requirements and documentation. Each phase of the project is properly planned and executed. At each phase end, project files are updated and changes documented.

This works because your project has a single source of truth (spec.md), a reference for architecture (no waste of tokens on repository discovery each new session), a state of the project to know where we are and a roadmap to know where we go next.

Planning and execution works too because it improves context management. Planning tokens are used for research, discovery, planning. Once it’s done, you start a new session with fresh context and execute the detailed plan. The context window is not polluted and you avoid context rot and degraded performance that starts after 50-60% of filled up context window.

Besides the workflows and structure, another important factor that increases the quality is you - your ability to understand, to some extent, what’s going in the project. You may not be an engineer, but as the owner of the project it’s better you have a sense of what’s going on. The better you understand the better your project becomes.

Here’s an example. I know pretty well how marketing websites work. I can use Claude to build me one and I can easily see what it lacks, what’s wrong and what to improve. A website I built with Claude would be on another level with a website built by a person who hasn’t built websites before.

That said, it’s not only about the technical part of the project. Building and producing code becomes increasingly cheap and simple. The harder parts are UX and marketing. If you are building an app, solo, then you better be a generalist who understands most parts of the project: design, product, marketing, and code. The better generalist you are the better your product will be.

Since producing code becomes cheap and available, the market is going to be flooded with ‘vibe coded’ apps. Therefore, while you focus on clean and production grade agentic coding, you can, or rather should, invest in UX and marketing if you want your product to win.

I like to think about current AI models as your own team. They can execute but you are the leader of the company and you have to lead the team. If your understanding in, let’s say, marketing is poor then your instructions to AI will be too. And that will lead to average results. However, if you know that every marketing strategy starts with proper user research, problem and avatar definition, offer creation, and then distribution - then the outcome of your marketing AI team will be on a different level from the competition.

To sum up, there are 2 factors that differentiate vibe coding from agentic: structure and system, and personal skills. Both are challenging areas where you can learn and master.

For structure, look into spec driven approach. My exploration in this area started with GSD framework and led to my own implementation that I’ll share soon. There are multiple implementations of this approach, including a version from Github. Start from somewhere and adapt it to your own needs. The best thing about agentic coding is that it’s so flexible that you can build your own systems and processes. The more important part is your own understanding and knowing what you want to achieve. The execution is the simplest part.

For personal growth and becoming a generalist, drive your curiosity in areas where you feel the weakest. Learn and understand what AI is doing. Ask questions. Close the gaps. A true leader may not be an expert in every domain, but he has to have a good understanding in each.

The client wasn’t wrong to avoid vibe coding work. It will take some time for the market to shift. When it does, vibe coding will be associated with weekend projects and agentic coding with professional work. That line is already being drawn.

This site is my contribution to drawing it clearly.