The concept of Code Sommelier compared to Vibe Coding

In one of my recent projects, I found myself questioning the entire software planning routine. Even though I already use AI to generate specs and user stories, it still took substantial effort to prepare them for sprints: organizing them into tickets, assigning priorities, and scheduling meetings. Meanwhile, code generation from AI feels like almost instantaneous by comparison.

But it doesn’t stop there. The quickstart you’re hoping for? Not gonna happen. How many times I’ve heard, "I’m still reading through the specs and docs." And that’s fair. I’ve been on both sides. Sometimes it takes days to get into a codebase, and other times you never fully do because everything changes so fast or the architecture is just too big to grasp entirely.

No one’s happy.

Devs have to dig through a pile of diagrams and documents before they can even start coding. Meanwhile, the Product Manager is already waiting for the first prototype.

And then we have this situation where the PM is generating the specs and user stories with AI. And the devs are generate a summary of the Stories and generating the Code with AI.

I stopped midway and thought, "By the time I explain, describe, and categorize everything, I could have done a part already myself with AI."

But that’s not true. Delegation is crucial to avoid getting lost in the work. Even with AI, there are limits. You realize them quickly when you hit an error you can’t fix for hours. So I discarded this idea.

Why Multitasking Doesn’t Solve It

One might think: "If AI can write code so fast, I can multitask while it does the job." But that approach has a hidden cost. There’s a quote from Dr. David Meyer about how switching between tasks can add 25% to 100% more time to complete them, depending on their complexity. So every time you jump from one project to another, you lose focus and need time to ramp back up. This interrupts the flow and can leave you drained by the end of the day... definitely not the efficiency boost you’d hoped for.

So even with AI, working on multiple things at once can reduce clarity and lead to exhaustion. If we want to scale or collaborate effectively as a team. But still ensure speed, quality and alignment with the original vision - we need a different strategy. That's where Sommelier Coding comes in.

Getting from Idea to Implementation Fast

Sommelier Coding is designed to transform a concept into a working product quickly, without sacrificing planning or coordination. It’s about reducing all the unnecessary steps in our workflow -like writing dozens of user stories that nobody truly reads - yet keeping just enough structure to align everyone on the team. The aim is to ensure that speed and quality can coexist, and that the vision for the application is passed on to developers in the fastest way possible.

When you work alone, you can "vibe" through the process. But in a team, you can't expect that everyone follows your vision and long-term goals.

Traditional Development

This is the classic route of detailed specs, comprehensive user stories, sprint planning, and lots of checkpoints. It excels at clarity and thoroughness - everyone knows what they’re supposed to do, and there are fewer surprises. However, it’s slow. A lot of time is spent on documentation, meetings, and waiting. By the time code is written, the market or requirements may have shifted. The overhead of managing a backlog, coordinating across teams, and lengthy QA cycles can become a bottleneck. In short, traditional methods provide structure, but at the cost of speed and agility.

Vibe Coding vs. Sommelier Coding

This is the extreme opposite. You dive in with AI and start building with minimal planning - essentially letting the AI code whatever feels right in the moment. It’s fast and freeform. Developers using this approach might say they’re “just following the vibes” of the AI. It can be incredibly quick to get something running because you’re not stopping to write anything down or hold meetings. The downside is chaos and lack of long-term structure. You might end up with a codebase that works in the immediate term but is a nightmare to maintain or scale. There’s a real risk of deviating from the core vision or having to refactor heavily later because no upfront thought went into architecture. It’s like jazz improvisation - fun and creative, but if multiple people are involved, you might not be playing in the same key.

If "vibe coding" is like jamming on a guitar, Sommelier Coding is like conducting an orchestra.

Code Sommelier vs. Developer Roles

Code Sommelier:

Acts as Product Manager + Software Architect + "Foreman" Dev
Mainly uses Deep Research + Pro Models to generate "Codestories"
Leads the team and gives direction

Dev:

Picks a CodeStory from the Roadmap
Puts the building blocks together with AI
Does Quality Checks and Tests

The Concept

The main idea is to generate code snippets that fit seamlessly into the overall architecture since the LLM has a full understanding of it.

Additionally, through the research process, you’ve already identified and preselected a suitable tech stack.

Just like a sommelier selecting the perfect wine for each course.

For example, defining an ERD Diagram is unnecessary when devs can get the full Drizzle schema in one run. If someone needs an explanation, then reverse it to a diagram.

Final Comparison

Traditional Development: Thorough and methodical, but can drown you in specs, user stories, and sprint rituals. Good for clarity, slower to deliver.
Vibe Coding: Fast and freeform. Let the AI build everything on the fly, but structure and consistency often suffer. Fine for tiny side projects, risky for bigger team efforts.

Sommelier Coding: Balances speed and oversight. Think of it like a sommelier selecting the perfect wine for each course curating the best fit while giving everyone a taste of the outcome. You’re still making careful choices, but without forcing everyone to read an encyclopedia of wines beforehand.

Sommelier Coding vs. Vibe Coding