And why the people who understand problems might be the best builders of all
I Was only a Marketer, a Consumer, and Not a Builder
If you started your career in sales or marketing over the last decade, you know the pain. You buy a tool, try to bend the data to fit your specific situation, and quickly realize that doing the manual work yourself would have been faster. The tools are built for someone else’s problems.
For most of my career, there was a very clear line: marketers think, and developers build. I stayed on my side of it. I wrote briefs, sat in developer queues, followed up, compromised, and eventually got something close to what I had originally imagined.
Three years ago, I got so frustrated that I decided to learn Python, then JavaScript, then HTML. I quickly got lost in a sea of libraries and jargon. I basically just gave up (true story 😊).
Then 2025 happened.
The Moment the Rules Changed
Being chronically online, I started noticing something on Twitter (yes twitter not X). People were building apps. Fast. Not just developers but founders, writers, marketers, people who had no business shipping software were shipping software.
So I went to ChatGPT with an idea I’d been sitting on for a while: a custom marketing experiments tracking tool. I was tired of squeezing my workflow into generic solutions. I explained the idea. I also mentioned, almost apologetically, that I couldn’t code.
It didn’t care. It laid out a complete, code-free plan and started building with me.
Watching an idea move from my head to a working thing on screen felt a little like cheating. Like the rules had quietly changed and nobody had sent the announcement.
To be more specific: I was dizzy and overwhelmed. A few hours later, I was just getting the code and adding it to VS code and one click on “Go Live” text in the footer I could actually see things in action. One of the top-top feelings!
So What Actually Is Vibe Coding?
The term was popularized by Andrej Karpathy, an AI researcher. But the definition that makes most sense to me is simple.
Vibe coding is building software by describing what you want in plain language and letting AI do the technical translation. You are not writing syntax. You are communicating intent.
But it’s worth being precise about where it sits, because “using AI” means a lot of different things right now. There’s a version most people are already doing, generating text, drafting emails, summarizing documents. That’s useful. But it’s operating inside existing tools, inside someone else’s system. Call it Level 1.
Vibe coding is Level 3. You’re using AI assistants like Cursor or Claude to build your own software, custom tools, interactive prototypes, applications that didn’t exist before you described them. It’s not prompting inside a product. It’s using AI to create the product itself.
That distinction matters more than it might seem.
What I Actually Built
My first project was that marketing experiments tracking tool, the one that started everything. I’d been frustrated for a long time with generic solutions that required tedious manual filtering and were clearly designed for someone else’s workflow. So I described exactly what I needed and built it myself.
The second project came shortly after: a Reddit brand analysis tool to help surface new marketing ideas from real conversations happening in my niche.
Neither of these were technically complex in the grand scheme of software. But they were mine, built around my exact problems, my exact workflow. That specificity is something you almost never get from off-the-shelf tools.
What the Process Actually Feels Like
I want to be honest here because most writing about AI leans too hard into the magic.
The good part genuinely feels like thinking out loud. You describe an idea, the AI builds something, and your thinking gets pressure-tested in real time. Sometimes it builds something slightly different from what you imagined and you realize, actually, that’s better. The conversation sharpens your own thinking.
The frustrating part is real too. There were stretches where I was going in circles, describing the same problem four different ways, wondering whether I was being unclear or whether the AI just couldn’t figure it out. Sometimes both.
My biggest early mistake was a painful one. I gave the AI a small, casual prompt to fix an input error. One prompt. It proceeded to break the entire system and the background along with it.
That taught me something important fast. You can’t throw generic prompts at it and expect surgical results. You have to break problems down step by step, like explaining to someone smart but completely new to the context how to build a glass of water. Small increments. Clear descriptions. Constant evaluation.
Where It Hits Its Limits
Vibe coding is real. It is also not magic.
It hits walls with complex backend integrations, database connections, and anything that needs serious infrastructure. The AI has limited memory across sessions, it forgets context, occasionally hallucinates fixes that don’t actually work, and can produce bloated code that becomes unmanageable as a project scales.
And here’s the honest core of it: you still need to know what you’re building. You need to define the problem clearly, write structured specifications, give the AI rich context, and evaluate the output for edge cases. The AI handles the technical translation. The thinking still has to come from you.
Which brings me to the part I find most interesting.
Why Marketers Are Surprisingly Good at This
Here’s a realization I didn’t expect going in.
The skills that make someone a decent marketer, understanding problems deeply, defining audiences, thinking in outcomes, communicating clearly, are almost exactly what vibe coding demands.
You’re not learning syntax. You’re writing briefs. Precise, structured, outcome-oriented briefs. You’re describing behavior, edge cases, what the user should experience. Vibe coding is essentially just writing a really good creative brief, and then watching it come to life.
Marketers spend years developing a feel for what people actually need versus what they say they need. That instinct, that ability to peek into real problems and translate them into something buildable, turns out to be genuinely valuable here.
The paradigm has shifted. The value in software is no longer in knowing how to build a system. It’s in knowing what to build. And that’s a question marketers have been answering their whole careers.
The Bigger Thing Underneath All of This
There’s a question I keep coming back to when I think about vibe coding: who gets to build things now?
For most of software’s history, the gate was simple. You either knew how to code or you depended on someone who did. I spent years on the wrong side of that gate, writing briefs, waiting in queues, compromising on my original vision.
That gate is not gone. But it’s more open than it has ever been.
And I don’t think the people walking through it first are going to be developers looking for shortcuts. They’re going to be domain experts, people who understand a specific problem deeply, who’ve been sitting on ideas for years with no way to build them. Marketers. Founders. Analysts. People who always had the brief but never had the means.
The shift I’m experiencing isn’t just about tools. It’s about identity. Moving from someone who executes tasks inside other people’s systems to someone who builds their own. From task executor to system orchestrator.
What Comes Next
This blog is going to be my building experiment journal. I’m going to document what works, what doesn’t, and what surprises me. The wins, the broken systems, the unexpected moments, and the questions I can’t stop thinking about.
I’m not a developer. I won’t become one. But I’m building things now, and that feels like enough of a reason to keep going.
Here’s the one question I’ll leave you with: What was the first time you heard of Vibe Coding and what was your first impression?
Top comments (0)