Vibe coding as a product manager: risks and opportunities

Vibe coding. Hard to believe this was first coined in February 2025, as it’s a phrase I have heard more than almost any other in recent times. The only thing surprising about it being the Collins Dictionary 2025 Word of the Year is that it is actually two words.

What is vibe coding? British royalty might say “One ‘vibe codes’ when one describes what one wants in natural language to an AI tool and it writes the code on one’s behalf.” This is a really exciting prospect to a novice coder like me. There are many vibe coding product managers out there working in more advanced ways than me, but I am already seeing these tools have a great impact on how I work.

This post covers my experience of vibe coding so far: the tools I have used, the opportunities and risks as I see them, and some of the things I have vibe coded along the way.

EDIT: 3 months is a long time in the World of AI! My recent post on prototyping with Claude design covers use of vibe coding for product discovery in more depth.

Vibe coding tools

Late last year I got a Lenny Product Pass. For £300, this has given me one year of free access to Lovable, Bolt and Replit (amongst others).

These are AI-powered platforms designed to turn natural language prompts into working web applications available on the internet, with minimum friction. Some powerful capabilities I have observed in these tools:

1. Instant visual feedback. Enter a prompt, and within minutes you can see something interactive on the screen.
2. Clarification questions. These AI tools are interactive, often stopping to ask me questions before burning through lots of credits.
3. Automatic handling of hosting, databases, authentication and deployment. I would struggle to build these things from scratch myself.
4. Agentic testing of web applications. After responding to a prompt, some of these tools will start testing the app against my new or previous requirements, checking to see the requirements have been met and that there are no regressions. If it spots regressions, it will try to fix them.

I also use IDEs like Cursor and VS Code for simpler tools and automations. But I would highly recommend giving these vibe coding tools a spin if you want a taste of where AI-assisted software development is heading.

Properly explaining what you want is a key skill for anyone managing humans or instructing AI tools. I have written a general post about this before in prompt engineering for product managers. For specific guidance on vibe coding I suggest checking out Vibe Coding Best Practices by Teresa Torres.

Opportunities

Communicating direction to the team.
Sometimes I have an idea in my head that I want to get across. A solution that I want the team to consider. I am no artist. People can barely even read my handwriting. So using AI tools to share my vision can be a great way for me to communicate.

Lightweight tooling.
This is the opportunity I have made the most use of. There are so many examples where vibe coded solutions have helped me do something 10x faster, or that I wouldn’t have been able to do without AI. For example, I had four 2,000 row JSON files I needed in a spreadsheet with duplicates merged. I also merged product analytics with document metadata to identify which types of documents get the most visits from users, validating assumptions around which datasets we should prioritise. Either of these jobs would have taken me hours of wrestling with Google Sheets or Python, or requesting help from a member of the team. Other examples include cleaning up messy datasets, analysing survey data, complex product analytics queries, sourcing new content, synthesising research and competitor analysis. Being able to do these little things myself makes me so much faster. Check out Using Cursor and MCP as a Product Manager for more on this.

Testing value hypothesis with users faster.
The democratisation of building makes it easy to build prototypes and deliver value to users faster. I built a simple ‘climate policy counter’ web app, an interactive data visualisation tool that stakeholders could use to quickly access key stats and growth trends. This was solving a known problem for users, but requests to update the dataset that powers it months after it was built still put a smile on my face. In another example, I used spreadsheets generated by deep research agents to test whether AI-assisted document sourcing could identify content missing from our database. It proved valuable to our content curators – saving them hours and helping them to find more relevant content. This is not a scalable solution, but it was enough to validate the concept before investing engineering time and thinking about less model-intensive ways of solving the problem at scale. It is also a good example to illustrate that even in the age of vibe coding, there are often good ways to validate hypothesis without AI needing to write any code at all. My recent post on prototyping with Claude design goes into more detail on some of these examples.

The thing that most excites me about AI tools for product development is seeing how the wider product team can build and prototype faster using AI, rather than trying to do it all myself. I have seen some amazing prototypes shared by all sorts of different people in our team – from product designers to policy analysts. And I hope to see more as people get more used to using these tools.

On a personal note, I have a lot more good stories to tell about vibe coding internal tools than I do for end user facing capabilities. This is an area where I would really like to learn and do more, and there are many examples out there of people vibe coding in more advanced ways that me. However, I question whether this is the right thing to do with my time. More on that in the risks section.

Building production apps.
More and more I am hearing about product people who are vibe coding real life production apps, or contributing to the codebase in production grade products. I am not there yet. But this feels like a direction of travel, especially if/when vibe coding tools become more trusted and reliable. One element of this that I am already looking at is having product documentation like PRDs closer to the code. If we have AI agents helping in the writing, reviewing and testing of code, requirements documents like these would serve as excellent context.

I have enjyed vibe coding some simple personal projects where the risk is low or I have the technical capability to maintain the end product myself without dependency on AI. But I am generally avoiding it otherwise for now. Two good examples are my girlfriend’s website – a single page app built in Lovable and converted to HTML/CSS – both of which I am comfortable with. And this blog, which I am exploring moving to a static file generator like Hugo, where risk can more easily be controlled because all the files are static.

Glimpse of the future.
Product managers operate at the intersection of the business, the user and technology. Understanding where technology is going helps us spot opportunities for improving our products. Vibe coding tools are operating at the edge of what is possible right now with AI powered tooling. Some of the capabilities I have seen give me good ideas for how I could improve my own products & processes. Agentic quality assurance testing is a great example of this. Integrating some of the automated testing capabilities I have seen in vibe coding tools with the products my team is building could help us spot bugs or usability issues before one of our team members or users do. That would be a real progress accelerator.

Risks

Dilution of focus.
As a product manager, I am responsible for helping the team understand our vision, strategy, users, problems to solve and desired outcomes. Vibe-coded products or prototypes from product managers are a poor substitute for an empowered cross functional product team who understand their users and mission. I understand why product managers in early stage startups or hybrid product/design roles are spending serious hours vibe coding. I enjoy being more involved in building, and I think I add value there. But as a time-poor product lead in an organisation of 35 people, I think there is a very good case to be made that I add the most value by using the time savings AI gives me to go from good to great at the things I am responsible for instead. The bottlenecks we have now as a product organisation are perhaps not best solved by me vibe coding.

Signal vs noise.
The power of sketches and wireframes is that they are ugly and minimal. They force us to focus on the concepts that are central to the idea. Sharing vibe coded prototypes or AI generated documents with the team makes people ask the question: which of these bits are your strongly held opinions vs which of it is AI fluff? I have seen AI generated content shared with the team cause confusion and misalignment because of this false precision.

Solutionising.
There is a fine line between articulating the vision that is in my head and prematurely solutionising with the team. If sharing prototypes with the team, it is important that there is enough psychological safety between the team and the product manager for the team to push back. I don’t feel like I have much of a problem here as my team seem to disagree with every other word that comes out of my mouth. Regardless, it is something anyone in a managerial or leadership role should be very aware of.

One of the things I have experienced often when working with designers is that when I think I have a good solution to a problem, they usually have a better one. So for me, the importance of the product manager/product designer relationship and the critical role good product designer play on a product team is still very much true in the vibe coding era.

Blurring of roles and responsibilities.
Product managers can now design and code. Product designers can now code and manage. Engineers can now manage and design. This is a risk and an opportunity. It is an opportunity, because it makes it easier for people to speak the same language, to not block each other from making progress, and for everyone to get to ‘good enough’ fast in more than one domain. It is a risk, because most people are not good at most of those things, and if you don’t know what good looks like, it is hard to critically evaluate an AI output in that thing. Now that it is easy for everyone to get to ‘good enough’ fast, being able to go from good to great becomes more of a differentiator than it was before.

There is also the human side. This is a big technological change that is enabling new and better ways of working. Teams are at the very early stages of figuring out what these are, and in the early stages, lots of mistakes will be made. People will also be fearful – worrying about what the future of their role looks like. And territorial – trying to ‘protect their turf’ from others. Navigating this is more of a leadership challenge than a technical one.

What I’m taking from this

There are huge opportunities to do more, better, faster with AI. Such a huge amount of technological change is happening in such a short space of time. Factors such as social/emotional intelligence, psychological safety and a culture of experimentation become more important than ever if trying to realise this value as part of a product team.

AI opportunities are particularly great for people who are expert in more than one domain. Improving my knowledge of software engineering and design is something I have enjoyed doing for years. Vibe coding makes me want to spend more time building a cross-functional skillset – not less.

These are such early days, and it is unclear whether AI will live up to the hype. But generative AI already feels like a bigger and more impactful thing than the blockchain or the metaverse – it has certainly had more of an impact on me and the way I work. My hunch is that if vibe coders can already achieve so much, when the term was only coined a year ago, imagine where we will be in five years. Or ten. Or twenty. I think it is important for people working in product roles to stay curious, experiment with new tools, and keep looking for ways to improve our products and processes. And that is what I am going to continue doing.