I believe vibe coding could change product delivery by giving developers clearer direction before they start building.

Currently, an idea comes in and is evaluated against things like the number of users impacted, severity of the problem, cost to implement, time to implement, expected ROI, technical complexity and strategic alignment. This helps teams decide what should be prioritised, but it still relies on a big assumption: that the solution being built will solve the problem in the way users expect.

By introducing an additional layer, idea → vibe-coded prototype → internal/customer feedback → validated MVP brief → developer build, teams may increase the time it takes to get to final delivery, but they also gain valuable information about how users expect to use the solution and whether it is likely to be used as much as first proposed.

This means you often do not see the real results of new features until after the MVP has already been produced and product feature testing begins. This can lead to multiple failed product features. A solution might be created, only for teams to realise that it does not properly solve the customer need. It can then take multiple adjustments to get to a working product, taking up valuable developer time in the process.

While a lot of features can now be turned around much faster than before, there are still big risks that come with adding new features to live systems. This is where I think vibe coding could be part of the solution.

By having a dedicated group of people in the team developing MVPs that are not connected to the main system, you can create valuable evidence before committing full development resource. These MVPs could be tested by teams or selected users, with feedback gathered around things like usability, workflows, feature value and whether the solution actually solves the problem.

Successful product features can then be presented to developers with clearer success factors based on user feedback. While this still carries risk amongst a larger user base, it should lead to a higher success rate for new features that are implemented. It should also allow developers to spend more time adding value where they are best placed, such as making the feature scalable, secure, maintainable and properly connected to the live system.

It should also lead to faster onboarding. Training guides, sessions and documents can be produced alongside MVP development, rather than needing to be created afterwards. A product manager is then able to guide the backlog more effectively with more knowledge, leading to better prioritisation over time.

During my research, I found an example of GitHub already using a similar version of this method, using GitHub Copilot. A prototype was built first, before engineering resource was brought in to move it towards production. This shows how vibe coding can support the early validation stage without replacing the need for proper engineering.

This will create additional work, as teams will need to manage more moving pieces at one time. There will still need to be decisions around which MVPs should be mocked up, which should be tested further and which should then be taken on by a developer. However, this trade-off should lower the risk of larger changes and allow more successful product features to be developed.

This should also allow developers to produce more with fewer iterations and check-ins needed, giving them more time to work with greater clarity.

It should also give teams more time for optimisation. If an MVP has been successful but received feedback, it becomes easier to test different suggestions during MVP development. This could include different layouts, workflows or features, which previously may have been too expensive or time-consuming to explore once development was already underway.

While vibe coding can technically be done by anyone, junior developers could bring real value to this role. Their expertise would allow them to create MVPs at a much faster pace than someone with no coding experience, while also giving them a pathway to develop into more senior developers. This pathway appears to be becoming harder as tools like Claude and ChatGPT have changed how entry-level coding work is done.

Vibe coding is currently seen as quite gimmicky by a lot of people on LinkedIn, but I believe there is a lot of untapped potential in the product space. The real value may not just be building things faster, but helping teams test ideas earlier, reduce wasted development time and give developers better-quality problems to solve.