The phrase “vibe coding” has bothered me for some time.
It’s usually said with a smirk. Usually by experienced engineers.
And that was appropriate for a while. 2024-25 were full of crypto-bro levels of fanfare fuelled by big egos building small apps in days.
Most of that was hype was unwarranted.
But we're in 2026 now. The slow boil has reached us.
What is now possible with AI has evolved unimaginably.
We've moved past "vibes", yet the term “vibe coding” has stuck.
Empowerment isn't a "vibe"
To many, the term implies that what’s happening is casual. Loose. A founder waving at an LLM and hoping something compiles.
But “vibe” massively undersells what’s really going on.
For someone like me — not an engineer by training — being able to build working software isn’t about vibes. It’s about empowerment, velocity, momentum. It’s about user experience. It’s about customers and satisfaction.
Your product is a conversation with the market.
I first heard this quote from Des Traynor on the Cheeky Pint podcast with John Collison and it’s really stuck with me.
For years, the path from idea to implementation looked something like this:
Have an idea → explain it → write a spec → justify it → debate it → prioritise it → design it → refine it → debate it more → build it → test it → ship it → get feedback → repeat back to step 1.
Every step added latency. Not just time — cognitive drag. Social drag. Justification drag.
Not to mention, the very number of steps, the time consumed by passing through all these steps, and the very thought of even going through these steps, meant many ideas were never even attempted.
It may sound harsh, but I've seen it in so many teams: engineering is where good ideas go to die.
Now? If you're set up to embrace the world we're in, the journey is radically transformed:
Idea → build → test → refine → ship → improve.
And that is not a cycle that happens in months, weeks, or even days. It's a cycle that can happen in hours, if not minutes.
Speed of iteration isn’t a "vibe"
Forgive me for linking to another Stripe founder, but I have long found Patrick Collison's "Fast" page immensely inspiring: examples of people quickly accomplishing ambitious things together.
Iteration speed is leverage.
When building something new, the most valuable thing is rarely elegant code, a beautiful user interface, or following a set process or doing things in a certain way.
It’s really simple: all you really care about, to begin with, is whether the thing you are building is actually valuable.
Does this flow make sense?
Is this interaction clear?
Does this feature solve the actual problem the user has?
Before, for any product manager or designer or non-technical founder, exploring those questions meant being away from the product.
Drawing, writing, designing. You would do a lot of work in places that were not the actual product. You would work in the abstract.
Then, after that work was complete, another round of work would begin: you would need to persuade someone else to explore the proposal with you. It would require tightly aligned schedules, a shared set of values, shared appreciation of the customer, shared priorities, compromises. You'd need to align on whether your proposal even could be built. And that answer could often be at the whim of any engineer. And in many organisations, that answer is not always completely objective based on the pure difficult of the engineering effort involved.
This whole process has now changed. The questions above can be answered directly.
I don't say this to be disrespectful to great, professional engineers. Quite the opposite. But so few founders or PMs ever get to work with truly great engineers. Often they are held back by outsourced teams, or engineers over-worked and unable to spend the time required, or simply by those who are inexperienced or insufficiently passionate and motivated.
Truly great engineers are needed more than ever, but the roles and responsibilities have changed. I don't see a split between product management, design, or front-end development any more.
I don't need help validating small UI tweaks. Heck, I don't need help building the 1.0 of a piece of software.
But that doesn't mean I don't need engineers. People like me desperately need help with the stuff that still sucks — forward-thinking architecture decisions, industry-leading performance, robust security, pristine data migrations, and true scalability.
The faster I can explore, the better the eventual product. And the best products are still a team effort.
Empowered exploration: not a "vibe"
For most of my career, if you weren’t an engineer, your leverage was persuasion.
You wrote PRDs.
You created Figma files.
You tried to be precise enough that someone else could execute your thinking.
Something always got lost in translation.
When I build something myself — even imperfectly — I’m exploring with the product, not describing it.
If your strength is empathy — if you spend your life talking to customers, using your own product, feeling friction, obsessing over tiny moments of confusion — the ability to implement directly isn’t a "vibe". It’s empowering, and it leads to fidelity.
You reduce the distance between user pain and product change.
Cutting out process theatre: not a vibe
In any team I have ever come across, there's some amount of theatre in software process.
Tickets. Sprints. Point estimates. Triage. Backlogs. Retros. Standups. Agile. Jira. Velocity.
These can all have their place. But so often, they are leant on as a sort of crutch of proof that "we're functioning as well as we possibly can".
Sometimes that’s rigour. Often it’s friction disguised as rigour.
The cost of trying something is dropping close to zero.
You can assign actual work to robots in the sky.
And you can try ten feature ideas in a single morning.
I'm not saying you should have no process.
I just think it might be worth rethinking some processes that were defined a decade ago.
It’s not anti-engineer. It’s anti-latency.
Great engineers are still invaluable. Possibly more than ever.
But what’s changed is who gets to initiate motion in the product itself.
If you deeply understand the customer…
If you care about craft…
If you think structurally…
You can now build.
Not perfectly. Not always beautifully. But meaningfully.
With a wonderful team, I’ve been building software for ~20 years now. For most of that time, my job was translating ideas into designs and persuading others to execute on them. That translation layer was necessary — and sometimes frustrating.
What’s changed isn’t that I’ve become an engineer.
It’s that the gap between empathy and execution has collapsed.
Call it whatever you like.
But it's so much more than a vibe.