More than six months ago, in issue 6, I mentioned the term vibe coding. Back then I was mostly teaching it to product teams and the functional experts who wanted to tinker without waiting on engineering. In the past few weeks the sessions have changed. Increasingly they are with executives, on what vibe coding is, what it means for their organisation, and hands-on tips for the leaders themselves to try it out. As one CEO told me while we were planning a session for his leadership team, "building is believing".
That phrase captures the shift. For a couple of years executives have been briefed on AI in slide decks and signed off on budgets for it. Far fewer have built anything themselves. The moment a leader describes what they want to a tool and watches a functioning app appear, the mood in the room changes. A sceptical executive who has felt that firsthand drops the usual abstractions, and the discussion turns concrete: where the appetite sits, which guardrails are sensible, how quickly real momentum is possible. They stop asking whether this is genuine and start asking what their teams could pull off. That is why I now run these sessions with the leaders' hands on the keyboard, not on the strategy slide.
I have already vibe-coded a few live production apps, such as Castifai and Jazz in Stockholm, but I will leave those aside here. What I want to highlight is the set of things you and your team can grab quickly, the lower-hanging fruit, without a heavyweight project around it.
Three ways to create value with vibe coding
The first is prototyping. You no longer have to make hard bets about which idea deserves development resources before you can put something in front of users. Tools such as Base44 and Lovable let a product manager or even a CISO spin up a working mock-up in an afternoon. You gather early reactions from real users before sinking scarce engineering hours into the polished thing. And if the scrappy version flops, you have lost an afternoon rather than a funded project. I dig into the discipline behind this in the piece on working backwards to a prototype in a week.
The second is internal workflows. If you have followed this newsletter for a while, you will recall that one of the three buckets of AI business value is boosting productivity. It lets you assemble AI-powered apps that plug into your existing systems, match how your team actually works, and spare IT yet another support burden. It drops the threshold for solving a business problem from "open a ticket and wait a quarter" to "rig up a rough version this week". This is the productivity bucket made concrete.
A common one I see is a team building a small tool that pulls numbers from two systems that never talked to each other, so nobody has to copy figures between spreadsheets by hand every Monday. An afternoon's work rather than a quarter, no ticket filed with IT, and a problem that had quietly cost the team hours a week simply goes away. None of these tools is the kind of thing a roadmap would ever prioritise, which is exactly why they sat unbuilt for years.
The third is customer-facing applications. Sometimes there is a real business need that never made it onto a backlog because there was no time or budget, like a landing page for a short-lived campaign or a small site for an event. Now the functional team and the subject matter expert can produce these themselves, simply by asking the tool for what they need. There are security and privacy considerations to handle here. Whoever builds these should learn a few essential principles first. That caveat is itself an opportunity to enable more people and spread value creation more widely across the company.
Maor Shlomo, the founder of Base44, recently described how his own company leans on this internally:
We keep allocating more and more talent to a role we call "internal builders" - people whose entire job is building internal tools for the team. This makes the gap between "we should pay for this" and "just build it" shrink.
So what is the role of our software engineers?
Andrej Karpathy, who coined the term vibe coding, has been clear about what happens to experienced engineers as this becomes an everyday habit. Their job, in his words, is "preserving the quality bar in terms of what existed before in professional software. How do we go faster, properly." That is the same move I described in this issue's leadership piece on security as an innovation enabler: a senior function holds the standard while clearing the way for many more people to build at speed.
There is a neat example from Twitch, an Amazon subsidiary. Lauren Kearney, a Director of Product there, has talked about using vibe coding for prototyping. That one caught my attention, because I led the innovation programme at Amazon Web Services, where writing a PRFAQ document was a hard requirement before anyone wrote a line of code. Now an Amazon product director is describing the sequence flipping, where you build the prototype first and write the document after. The other lesson she shares is one I repeat in my own sessions: the tool matters less than the loop. Tools keep changing, so the lasting investment is a way of working that survives whichever vibe-coding tool you happen to have access to this quarter.
I am not saying the document stops mattering. The thinking that goes into a PRFAQ, getting clear on the customer and the problem before you build, is still the hard part of the job. What changes is the order. A rough prototype can now do some of the work the document used to do on its own, showing people what you mean instead of describing it on a page, and the writing tends to get sharper once you have already seen the thing run.
Your action step
If you have not shipped anything with a vibe-coding tool in the past three months, fix that this week. Pick a subject you really care about. If company data is off-limits for now, choose a personal project, maybe planning a home renovation or wrangling your training log. You will feel the speed and the rough edges directly, and you will understand why this deserves to become a widespread skill rather than a curiosity.
The second part of the exercise is to notice how the experience changes your view of what software is worth. Can you treat a build as a highly personal application with an audience of one? Is it acceptable to ship something built to survive a week and then be discarded? What would you learn if you spun up five rival versions of the same solution in parallel and let real feedback pick the winner?
If you want your leadership team to build with these platforms rather than just hear about them, that hands-on session is one of the things I run as an AI keynote speaker and workshop facilitator, and it sits at the centre of AI strategy advisory work with executive teams across Europe.