What an AI Open Mic Revealed About Amsterdam’s Builders

A curated speaker programme tells you what an organiser thinks matters. An open mic tells you what the community cannot stop working on.

On 2 June, we handed the stage to builders in Amsterdam and asked them to share their setups, products, mistakes and lessons.

The result was less tidy than a conference agenda and much more useful as a signal.

The format removed the expert costume

The Vibe Coding Open Mic was hosted with support from ASAL Startup Studio. Product people, designers, founders and community builders came with different levels of confidence and very different definitions of what counted as a finished product.

That difference was the point.

A normal technology event tends to separate the room into speakers and listeners. The open mic made the boundary temporary. Anyone could show what they had tried and let the room examine it.

You did not need a grand theory of AI. You needed a piece of work and enough honesty to explain where it was still strange.

People were building sideways across roles

The most persistent pattern in this community is not that everyone wants to become a developer.

It is that people no longer accept their job description as the boundary of what they can make.

A product manager builds the internal tool instead of adding it to a backlog. A designer makes the interaction work rather than stopping at a prototype. A founder connects the form, the payment and the follow-up without assembling a small agency.

AI building does not erase those disciplines. It lets people travel further before the next handoff.

The open mic made that movement visible.

The smallest projects often carried the clearest lessons

Large product claims can hide weak thinking. A small workflow has nowhere to hide.

When somebody shows one repetitive task they removed, one awkward customer moment they redesigned or one idea they finally made clickable, the room can understand the before and after.

The useful questions become concrete:

• What did you do before this existed?

• Which part did the AI handle well?

• Where did you have to intervene?

• What information does the product need?

• What would make you trust it with a real user?

• What will you change tomorrow?

These questions turn a show-and-tell into peer review.

Mistakes became community infrastructure

Most builder content removes the dead ends. The final screenshot appears beside a clean list of lessons, as if the project moved in a straight line.

In the room, someone can say the prompt that worked yesterday failed today. They can show the integration that took three attempts or the feature they deleted after testing.

That knowledge is valuable because it is situated. It includes the tool version, the confidence level, the compromise and the recovery.

A community does not become useful by collecting only success. It becomes useful when one person’s failure shortens another person’s afternoon.

AI adoption is partly a confidence problem

Access to tools is not the same as permission to use them.

Inside companies, people often wait for an official programme, a safe use case or a colleague who appears more technical. They may be curious and still assume building belongs to somebody else.

Watching a peer show an imperfect product changes that assumption. The distance feels smaller because the person on stage is not performing mastery. They are showing a method.

That is why community events can produce a different kind of adoption from formal training. Training transfers a planned body of knowledge. Peer demonstration transfers belief that participation is possible.

The room was a better map than a trend report

Technology trend reports organise change into categories: agents, copilots, automation, AI-native interfaces.

Builders organise it around annoyances, ambitions and moments when the old way stops making sense.

The open mic showed the latter. People were not beginning with “I need an agent.” They were beginning with a workflow they hated, a customer they wanted to help or an idea they were tired of explaining.

The tool arrived after the tension.

That order matters. It keeps the product from becoming a demonstration in search of a problem.

What I would keep

I would keep the low barrier to speaking, the short demos and the expectation that unfinished work is welcome.

I would also keep the mix of disciplines. A room composed only of experts in one tool quickly develops a shared blind spot.

What I would add

The next version should make continuation more visible:

• A simple public gallery for the products and experiments shown.

• A place for builders to state the help or collaborator they need.

• A follow-up note one month later: what changed, stopped or found a user.

• Small critique circles after the main stage for people who want deeper feedback.

• A recurring slot for a failed build and the recovery.

The stage creates a moment. The archive and follow-up turn the moment into community memory.

More agency, less isolation

I started the Amsterdam community because AI gave me more agency and, at the same time, made the work feel strangely solitary.

When you are constantly doing something for the first time, it is difficult to know whether the uncertainty means you are behind or simply building at the edge of your role.

An open mic answers that question without pretending the work is easy. You see that everyone gets stuck. You also see the different ways people move again.

The point is not to make every builder agree. It is to make the work less lonely and the learning easier to share.

You can explore the wider community record on VibeConf and find upcoming sessions on the CraftingProduct Luma calendar.

If you want to create the same kind of builder movement inside your organisation, see our team workshops and buildathons. If you have a product or platform to make, talk to the studio.