Recently, I attended the London AI Hackathon, organised by Mind the Product and Pendo. I hadn’t been to a hackathon for a while, and I’m still relatively new to the latest wave of AI “vibe coding” tools, so I wasn’t entirely sure what to expect — somewhere between productive chaos and a mild ego bruising, probably.
It was, in fact, neither.
Setting the scene
The central London venue had the right energy for this kind of thing: half conference, half playground. The Pendo and Mind the Product teams welcomed us in and gave the room some time to network before we kicked off. (Worth flagging here: Pendo acquired Mind the Product, which is partly why this event existed at all and why the tooling on show came from inside that combined orbit.)
A few short presentations set the context — how AI is reshaping product development this year, and an introduction to Bolt’s AI-powered product management tooling. Then we got the problem statement:
Build an app to help avoid unnecessary meetings.
It’s the kind of brief that lands well in a room of product people. We’ve all sat through the meeting that should have been an email, the email that should have been a Slack message, and the Slack message that should never have been sent at all.
The two tools we were introduced to
Bolt is a vibe coding tool — a visual front-end on top of AI coding agents that pushes generated code into a connected GitHub repo. You describe what you want in natural language, and Bolt scaffolds working code, screens, components, and back-end glue. Roughly 60–70% of Bolt’s users are non-technical: product managers, designers, founders. That ratio matters; it’s not just developers using AI assistants, it’s the people who’ve historically briefed developers now building the first version themselves.
Novus is Pendo’s new product agent. Where Bolt helps you build, Novus is what watches what happens once people use the thing. It connects directly to your codebase, automatically instruments the product, analyses how users actually behave, and surfaces what matters straight into Slack or Teams. Think of it as the post-launch counterpart to Bolt’s pre-launch role — together they sketch out a new kind of product loop where building, instrumenting, and learning all happen with the AI doing the heavy lifting.
How our team approached it
Once everyone had access to Bolt’s team plan, we got organised quickly:
- Brainstormed onto a Miro board. Every idea, no filtering, no debating. The usual divergent first pass.
- Filtered down to an MVP. We took the long list and cut to the features that would actually fit a two-hour build: a form to create a meeting, validation, a simple confirmation flow. The kind of scope that, on a normal day, would still be sitting in a backlog ticket somewhere.
- Wrote the prompt. Our team admin drafted the instruction for Bolt, describing what we wanted built and how it should behave.
- Ran it. The agent connected to GitHub, scaffolded the boilerplate back-end, generated the screen for creating a meeting, added form validation, and stitched it together.
- Reviewed and tested. We poked at it, broke a few things, fixed them with follow-up prompts, and ended up with something that worked.
Total time, from blank Miro board to working prototype: a couple of hours.
The finished thing is here: https://calendar-meeting-tem-60es.bolt.host/
It’s not going to win any design awards, and you’d want to throw the code away before any of it touched production — but as proof of concept, it’s a long way from where this kind of timeline used to sit.
Initial thoughts
Three things stood out to me on the day, before I’d had time to properly process any of it.
It’s genuinely accessible to non-coders. I came in with a developer background myself, so I wasn’t worried about being lost in the syntax — but the more interesting observation was watching how easily the non-coders on the team got hands-on. They weren’t reduced to fetching coffees while the more technical members ran the keyboard; they were prompting, reviewing, and steering the build alongside everyone else. The bottleneck was clarity of thought, not knowledge of syntax — and that’s a domain product managers already live in, regardless of whether they can read a stack trace.
The Miro-to-prompt step is the new design step. A messy Miro board is a poor input. A tightly framed prompt is a great one. The discipline shifted from “what does this need to do” to “how do I describe what this needs to do clearly enough that an agent doesn’t hallucinate around the edges.”
Some teams sidestepped Bolt entirely. A few opted to plug existing tools together rather than build from scratch. A useful reminder that just because you can generate something in two hours doesn’t mean you should — sometimes the right answer is still the one already on the shelf.
Takeaways
There are the obvious headlines (it’s fast, it’s accessible, the demo worked), and then there’s the more interesting layer underneath — the implications for how product teams actually work. I want to spend most of this section there.
The prototyping bar has moved, and so has what “validation” means
Two hours from idea to clickable prototype is a category change, not an incremental improvement. Historically, the cost of building anything was high enough that we had to choose carefully what we tested. Now the cost is approaching zero, which means the constraint becomes something else entirely: judgement about what’s worth testing. If you can build five prototypes in a day, the question isn’t “can we build it?” but “do we know what we’re learning from this one?” Product managers will need to get sharper at framing hypotheses, not just shipping faster.
PMs are now potential builders — but the role hasn’t actually changed
There’s a temptation to read vibe coding as “PMs become engineers.” I don’t think that’s right. What’s changed is that PMs can now produce a tangible artefact — a working prototype — at the discovery stage, before any engineer is involved. That’s a powerful new tool in the kit, but it’s still in service of the same job: understanding the problem, deciding what to build, getting to evidence as quickly as possible. The risk is treating the prototype itself as the goal. It isn’t. It’s a sketch with a working demo button.
Throwaway code is fine — until it isn’t
We left the hackathon with a working prototype that we all agreed should be thrown away. That’s the right answer for a two-hour build. But it raises an awkward question for teams adopting these tools at scale: what happens when the prototype works too well? When stakeholders see a slick demo and start asking when it’ll be in production? The skill teams will need to develop is the discipline to throw work away even when it’s tempting to keep it. That cultural muscle is harder to build than the technical one.
Engineering’s job changes, but doesn’t shrink
If PMs are doing the prototype scaffolding, where does that leave engineers? Probably in a better place than the doom-takes suggest. Boilerplate isn’t where engineers add their highest-leverage value; the interesting work — system design, performance, security, the production-grade rewrite of whatever the prototype proved out — is still very much theirs. The handover model needs rethinking, though. “Here’s a Figma” is being replaced by “Here’s a working Bolt project, please take it from here,” and that’s a different conversation.
Build + instrument + learn is becoming one loop
The Bolt + Novus pairing hints at where this is going. You build a prototype with one agent, instrument it with another, get behavioural data back inside hours rather than weeks, and feed that into the next prompt. The traditional gaps between build, ship, learn, and iterate compress dramatically. Whether your team is set up to act on insights at that pace is a separate, harder question.
IP, ownership, and the boring questions that aren’t actually boring
Bolt writes code into a GitHub repo. Whose repo? Under what licence? Who owns the output, and what’s been used to train the model that produced it? At a hackathon you can hand-wave these away. In a regulated business, your legal team will not. Any team thinking about adopting these tools in earnest needs an answer ready before the first prompt gets typed.
Questions I’m still chewing on
- Agent set-up. What does it take to turn a one-off Bolt experiment into a repeatable workflow that the whole team can use?
- Skill atrophy. If PMs lean on AI for everything from synthesis to prototyping, what muscles stop being exercised — and does that matter?
- Where prototypes live. A throwaway prototype is one thing; a throwaway prototype on a public URL that someone in another department starts circulating is another.
- When not to vibe code. The teams that ignored Bolt and used existing tools weren’t wrong. Working out the heuristic for when to build versus when to assemble is its own problem.
Closing thought
I went in unsure of what to expect and came out with a working app, a sketchy one, and a long list of questions that feel more interesting than the prototype itself. That’s probably the right ratio. The tools have moved fast enough that “what can they do” is largely a settled question. “What should we do with them” is where product managers — and product teams — are going to earn their keep over the next year.
You can poke at the demo here: https://calendar-meeting-tem-60es.bolt.host/. Don’t book any actual meetings with it.
Chandran Honour's Blog 
Leave a comment