I don't know if a term has ever been so ubiquitous, so quickly as "vibe coding". Five months in and it's still all my LinkedIn feed is talking about. It's stuck, most likely, because it's describing a thing we all already knew was happening, we were all already doing it, but it put a name to it.
(All Fours got massive for arguably similar reasons. From The Guardian: "There’s a funny bit in All Fours when she talks about the female artist’s lifecycle: first “hot young thing”, then wilderness years, and a final spurt of attention before you die". Miranda July says: “I wrote it as if it was OK – as if everyone knew what I was talking about...as if you could make a joke about something shameful, as if we had all already talked about that thing. Even though we hadn’t. So it was skipping a few steps, even to have humour about it. I was building on an internal world that I believed existed, not just in me.”)
The other week Ben Welby wrote a blog post about how after a few days of vibe-coding, he finally had a prototype that built confidence in the team and their vision. "One person can now create the fast, dazzling demos that make people believe again in what digital can do."
I'd been spending some time defining FF Studio's proposition around how we use pilots and prototypes as input into strategies and business cases that outline clear, actionable paths to success. And reading Ben's post, I panicked a bit. Oh crap, the bottom's fallen out of the market. Everyone can prototype now. No one needs to pay external people to make things real, they can just get Claude Code running in the terminal and bash out a prototype in a day or two.
But I was forgetting something, or at least, only doing a very selective read of what Ben was writing about. It's true that the prototyping cost of entry has dropped hugely - but it's only true for the pixels.
It isn't true for the rest of the stack - Sarah Drummond's model of full stack service design calls out services being underpinned by infrastructure, organisation, intent, and culture.
The vibe-coded prototype output is the start of the conversation. And the output can only be converted into value - something actually shipped - if there's clarity over the product or service vision. If the trade-offs of each decision that we're about to encode into software are well understood. If the team or teams involved understand the rationale and the user need. If the infrastructure is there to deploy. If stakeholders are aligned and the benefits are worth the investment and the business case stacks up. If the culture supports delivery. Ben talks about how you can "have the instinct, the skills, and the tools, and still hit a wall", because building the thing is not and has never been what gets in the way of idea to reality or theory into practice.
It’s great that prototypes are easier to build, because prototypes provoke questions and force us to answer them. Some of those questions are about the service itself and how it works. But there is no value in answering those questions unless the people involved know how to prod at the answers the rest of the stack requires. In any kind of complex environment (let’s be realistic, basically anywhere), every vibe-coded prototype that warrants delivering real value to an end user needs help from multiple angles before it can make it into production and into being useful.
There seems to be another market emerging from the emergence of vibe coding, outside of the realm of the public sector. Allow me to introduce it via metaphor. Building a digital product has become more like something like writing a novel - "anyone can do it" - rather than previously where it was more like hiring a team of builders ("I have a vision but I can't make it happen, over to the experts"). There remains a large industry for those novel writers of editorial consultants, agents, coaches, retreats, training courses. Hire someone who knows what great looks like and can help you to get there or pay someone to teach you (sell shovels in a gold rush). Designers asked to QA vibe-coded apps, developers asked to debug them.
So: I no longer think the bottom has fallen out of the market. It's ok if one thing becomes more commodified. Expertise remains valid, even if we might find ourselves needing to reposition how to describe it. The skill remains in not only knowing what we're doing, but also in asking better questions - and the ability to run up and down the stack asking them, in service of getting something that works out of the door.