Vibe coding is building software by describing what you want in plain language. You say it, the AI writes it, you run it and change your mind.
Something clicks when people stop using AI and start building with it. It usually happens the moment a rough idea is running on screen the same afternoon.
The other half of the session is less fun and more useful. There is a lot of nonsense out there about what these tools can do, so we show you where the line actually falls: what works off the shelf today, what still needs an engineer, and what that means for how your team builds.
Step 1
Scope
A planning session before the day itself. We pick the format together: online or in person, one team or a mixed group, work projects or personal ones. Every combination has tradeoffs, and mixing usually works best.
Step 2
Prepare
We adapt our Coding for Non-Coders guide to the level of the group. You arrange paid AI tool access for everyone taking part, whether that is Claude, OpenAI, Mistral or something else. This matters more than people expect, because the tools set the ceiling on what anyone can build in an afternoon. We will tell you which ones suit your group.
Step 3
Build
Everyone picks a real problem of their own, describes it to the AI, and keeps refining until it runs. Most people have a working prototype within a few hours.
Step 4
Show
Every session ends with a show and tell. Watching what the person next to you built in the same afternoon does more for expectations than anything we could say.
Step 5
Keep
Your version of the guide page stays with the team for good. People use it to prepare, follow along during the day, and run the same exercise again later without us.
Step 6
Coach
A follow-up session afterwards is included. Anyone who wants to push a project further can book additional 1:1 time on top, focused on their own build.
Online or in person?
In person is better if you can manage it. The room has an energy to it, we can look over shoulders when someone gets stuck, and the show and tell at the end lands harder. Online is cheaper, easier to organize, and works fine for smaller or distributed groups.
One organization or a mixed group?
One team already shares context and can go after the same problems together. A mixed group brings stranger ideas and people learn from each other's fields, but you spend more time explaining yourselves.
Work projects or personal ones?
Work projects are easier to justify. Personal ones often go further, because nobody has to ship them and that freedom is where the confidence comes from. Most groups end up doing some of both.
Solo or in pairs?
Both work. Pairs help beginners find their footing, and the more technical people in the room tend to start helping everyone else without being asked.
How large a group?
One facilitator can look after about 15 people. Two of us can handle 25 or 30. Beyond that, nobody gets enough attention when they get stuck.
Follow-up coaching?
A follow-up session is included. Some people leave with a project they want to keep pushing, and additional 1:1 time afterwards is the fastest way to get them unstuck.




Getting from an idea to a working thing in a few hours is a habit, not a trick. It works on the next idea too, and since today is the worst AI will ever be, the habit gets more useful over time rather than going stale.
Nobody gets stuck on syntax any more. People get stuck saying clearly what they want. Learning to write a sharp brief pays off well beyond code.
You see for yourself what these tools do well, where they fall over, and which parts still need an engineer. Much better than taking anyone's word for it, including ours.
You leave with something you can show people, poke at, and keep building on, made from a problem you actually have. It is a starting point, not a finished product. Plenty of what gets built on the day is throwaway, and that is fine. The point is that you built it.
Every session is built around a version of our public Coding for Non-Coders guide, adapted to your group and yours to keep.
The format is simple enough that your own people can run it again for colleagues who missed it. We would rather leave you with a practice than a one-off event.
We are not going to promise you a finished product or a 10x team. What you get is an afternoon of first-hand evidence, which turns out to be a much better basis for planning than a vendor deck.
Tracking what is coming is only half of our work. The other half is people getting their hands on it. Build Sessions are where our research stops being something you only read about.
Since 2025 we have run these for hundreds of people, from complete beginners to advanced makers. Public-sector teams including the City of Amsterdam, executive groups, and open ticketed sessions.
Envisioning runs on software we built this way, from our Signals research platform to the agents doing our internal work. What we teach comes out of shipping and maintaining it, which is a different thing from having read about it.
Every dot is somebody’s idea. Bottom left they are small and cheap and there are lots of them. Top right there is one, and it costs real money. Click any stage for detail.
Left of the line
Fifteen people, fifteen ideas, and by the end of the afternoon most of them are running. Building got cheap enough that you can find out which idea is worth anything by building it, rather than arguing about it in a meeting.
Right of the line
Pilots and products mean real users, real data, and someone on call at 3am. Different budget, different timeline, different team. A session is how you work out which handful of ideas deserve that, and we will tell you honestly where yours sits.
Tell us about your group and we'll suggest a format that fits.