Demo Night: Why Showing Unfinished Work Beats Another AI Panel

The least interesting sentence at an AI event is usually: “Imagine what will be possible.”

We do not need much more imagination. We need to see the workflow, watch it hesitate, and ask whether it is useful when the demo leaves the stage.

That was the operating idea behind our Vibe Coding Demo Night in Amsterdam.

The format was the argument

On 10 February, we ran an EU-INC edition with live demonstrations across Lovable, n8n and Mistral. The programme moved from new building features to automation, sales operations, an in-person networking product and a full path from research to prototype to coding agent.

No keynote. No panel predicting the future of work. Each speaker had to show a system and explain how it behaved.

That requirement changed the quality of the conversation. A product on screen creates questions a polished opinion can avoid:

• Where does the data enter?

• What still needs a person?

• What happens when one service fails?

• How long did the apparently simple step really take?

• Would the workflow survive a second user?

The room could see the joins.

Unfinished work has more information

A perfect demo is reassuring and often useless. It hides the recovery steps—the part people actually need when they try the workflow themselves.

Unfinished work shows the decision boundary. You can see which pieces the builder trusted, which parts were still manual and where the idea had outgrown the first architecture.

This is not an argument for arriving unprepared. It is an argument for showing enough reality that the audience can distinguish a product from a performance.

When something takes longer than expected, the pause belongs in the story. When a prompt needs to be rewritten, show the rewrite. When an automation needs a human approval, name it.

The awkward part is the transferable part.

Five demonstrations, five kinds of leverage

The evening deliberately put different workflows beside one another.

Lovable changed the distance to a first product

I opened with recent changes in Lovable and what they meant for a builder’s day-to-day workflow. The useful point was not a feature list. It was how quickly a person could move from an intention to something another person could test.

n8n made the application touch the rest of the business

Marrallisa Kreijkes showed how a Lovable product could connect to automated workflows. A front end becomes more consequential when it can create a record, trigger a process and return a result.

Natural language moved into workflow creation

Gonçalo Soares demonstrated using Mistral Vibe CLI with n8n, describing a problem and turning it into an automation. That exposed a useful question: when creating the workflow becomes easier, who owns checking its side effects?

A small automation removed ordinary friction

Maarten van Gennip shared a sales-pipeline hack designed to reduce manual administration. It was less cinematic than an agent demo and more immediately recognisable. That contrast mattered.

A real product carried real lessons

Malvina Puzenat showed an in-person networking platform built with Lovable. A shipped product brings constraints that a tutorial does not: users, venue behaviour, incomplete information and the need to make the interaction understandable quickly.

The final demonstration connected research in Mistral Le Chat, prototyping in Lovable and refinement with Mistral Vibe CLI. It made the stack visible as a sequence of jobs rather than a collection of logos.

The audience should be able to steal the method

A good demo night does not ask the audience to admire the builder. It gives them a method they can reuse.

For every presentation, I want the room to leave with four things:

• The problem that triggered the build.

• The smallest architecture that made it work.

• The failure or compromise that changed the approach.

• The next decision the builder has not resolved.

That last item keeps the conversation honest. Products are never as finished as a launch post suggests.

Why this is better for AI adoption

AI adoption is often presented through capability: the model can research, generate, classify, automate and code.

People adopt a new way of working when they can see themselves inside it. A product manager recognises the brief. An operations lead recognises the handoff. A founder recognises the admin that consumes Friday afternoon.

Live, specific work turns an abstract capability into a possible Tuesday.

It also reveals the cost. The audience sees setup, permissions, data quality, security and maintenance. Those are not objections to hide. They are the conditions of responsible use.

What I would keep—and what I would change

I would keep the range of demonstrations and the short slots. The pace prevented anyone from turning a workflow into a sales presentation.

I would make the brief for speakers even stricter next time:

• Begin with the old way of doing the work.

• Show the live path, not only screenshots.

• Name one thing that broke or remained manual.

• End with the decision you want help making.

I would also leave more time between demos for the room to compare patterns. Five tools may look different while repeating the same design mistake.

Show the work

The most valuable AI events I have attended or run do not make the technology look inevitable. They make the work inspectable.

That is a higher standard. It asks speakers to trade some polish for truth. It asks the audience to move from applause to questions. And it gives everyone permission to show a product before the story around it is perfect.

The Amsterdam Vibe-Coding Meetup record carries the community history and future events.

If your team has workflows worth making visible, talk to us about a workshop, buildathon or custom project. Bring the version that still has rough edges. That is where useful work begins.