I hate the phrase ‘vibe coding’.
I hate the phrase ‘vibe coding’. It makes it sound as though you are doing something you probably should not be doing: typing a vague request, accepting whatever appears and quietly pushing it into production. That is not how I use AI to build products.
01
The label makes the work sound careless.
There is a version of this where someone with no product or technical judgement asks an AI tool to make an app, clicks through a few screens and assumes the job is done. That can produce something impressive in an afternoon. It can also produce poor UX, exposed data, brittle logic and a product nobody actually needs.
But the same tool in different hands produces a very different result. A chef and I can use the same kitchen. Nobody expects the same meal. The capability matters, but so does the judgement directing it.
02
Product people have been preparing for this for years.
Good product people spend their careers turning ambiguity into instructions. We used to call them PRDs, user stories, acceptance criteria and Jira tickets. We describe the problem, the user, the journey, the edge cases, the rules and what success looks like. Then we work with design and engineering to remove everything open to interpretation.
That discipline maps remarkably well to AI-assisted development. The prompt is not the product thinking. It is the final expression of it. If you understand how a service should behave—and can explain it precisely—you can direct these tools with far more intent than the phrase ‘vibe coding’ suggests.
- Start with the customer problem, not the feature you want to generate.
- Define the flows, rules, states and edge cases before polishing the interface.
- Treat every output as something to inspect, test and improve.
- Know where specialist engineering or security review is still required.
03
I have used it to build real products.
I used this approach to build SolarTyle’s quoting, catalogue, pipeline and customer design tools in weeks. I built PikClub as a functioning multi-sport prediction platform with groups and automated scoring. With Foremates, I turned an all-in-one golf proposition into a coherent mobile product rather than leaving it as a deck and a backlog.
Those products did not appear because I asked AI to surprise me. They came from years spent making product decisions: deciding what the customer needs, how the journey should work, which rules matter, what can wait and how the business operates behind the screen. AI shortened the route from those decisions to working software.
04
Speed does not cancel responsibility.
UX is not forgotten because a designer did not place every component by hand. Security is not optional because code was generated more quickly. Data handling, authentication, permissions, accessibility, error states, performance and maintainability still have to be designed, tested and challenged.
The sensible approach is not to pretend the risks have disappeared. It is to know where they are, build the right checks into the process and bring in deeper expertise when the product demands it. Senior judgement includes knowing what you do not know.
So yes, I use AI to build software. I use it a lot. I just do not think ‘vibe coding’ describes the work. For me, it is product-led development with a much shorter distance between a decision and something real.