The Code Sommelier

Intro

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.

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.