My recap of WeAreDevelopers 2026

Berlin in July is developer season, and this year the WeAreDevelopers World Congress handed me two very different seats at the same table. On Thursday I was up on Stage 3 with a microphone, hosting other people's talks. On Friday morning I was the one being introduced, running my own workshop. Two roles, one badge, and a lot of coffee.

Here is my honest recap: what it is like to host a stage, what I actually taught in my workshop, and the people who made the trip worth it.

Thursday: moderating Stage 3

Moderating is one of those jobs that is invisible when it goes well, and that is exactly the point. You are not the star. Your job is to make each speaker feel comfortable in the ninety seconds before they walk on, keep the room running precisely on time, read the audience's energy, and ask the one question at the end that turns a good talk into a conversation.

I hosted Stage 3, powered by AWS, through the whole Thursday afternoon. It was a genuinely strong run of talks, and if there was a thread tying them together it was this: AI agents are moving out of the demo phase and into production, and the hard parts now are architecture, verification, and plain old craft.

Here is the full lineup I had the pleasure of introducing that afternoon:

• Programming with Contracts in C++26 by Peter Bindels (Staff Software Engineer)
• Swift, Server-side, Serverless by Sebastien Stormacq (Developer Experience Engineer)
• When Should You Use an Agent? Architectural Trade-offs in Agentic Systems by Matheus Guimaraes (Developer Advocate)
• Designing high quality software with AI by Brian Lovin (Product Designer)
• 5 things I wish I hadn't done building my AI agent by Shachar Azriel (VP Product at Baz)
• Event-Driven AI Agents: Orchestrating Long-Context Legal Processing at Scale by Luca Bianchi (CTIO)
• How to read code (properly) by Anja Kunkel (Principal Software Engineer)

From secure C++ contracts and serverless Swift, through the architecture of agentic systems, to the very human question of how we actually read each other's code, it was a wonderfully varied afternoon. By the end of it my voice was a little worn and my notebook was full. Sitting at the side of a stage, watching one speaker after another pour months of work into a tight thirty minutes, is a genuinely energizing way to spend a day.

Friday: my workshop

Friday morning it was my turn on the other side of the microphone.

The title was a mouthful, Bridging LLMs and Systems: Practical Automation with MCP Tools and Function Calls, but the idea behind it is simple. The demo I built for the session is called SpatialAI. You type something in plain English, like "create a 12 by 10 yard and put a fence around it," and it appears as a live 3D scene in the browser. Ask it to "make me a chair" and it will invent a reasonable chair on the spot.

The fun part is what happens underneath, because the model never draws anything itself. It reads your sentence, picks from a set of typed tools that I defined, and my application decides exactly what those tools do. That gap is the whole point of the workshop. There is a lot of excitement right now about letting AI models "do things." The interesting engineering question is not whether they can, it is how you stay in control when they do.

So we spent the morning on two ways to give a model tools, and when to reach for each:

• Function calling is in-process. Your application defines the tools and runs the model's tool-use loop itself. Reach for it when your app owns the interaction and wants the tools built in.
• MCP, the Model Context Protocol, is a transport. Your server exposes the same tools over a standard protocol, so any MCP-capable client (a desktop assistant, an inspector, someone else's app) can discover and call them. Reach for it when the tools should be reusable beyond the app you control.

Then the part I enjoy most: one implementation, three surfaces. Every action in SpatialAI lives in exactly one place, and it is driven three different ways, the in-app chat, an MCP server, and a small "bridge" that turns MCP tools back into function calls. All three edit the same live scene. To prove it, we did it live: I added one brand new tool during the session and watched it light up across all three surfaces, with the last one needing no extra code at all.

If you take one line away from the talk, take this one: the model proposes, the application disposes. Typed tool calls, deterministic server-side logic, and a live, reversible view are what make it safe to hand a model the keys to a real system. And although the demo happens to be a 3D scene, the pattern is general. Swap the scene for your own API and the same architecture holds.

A huge thank you to everyone who showed up at 09:45 on the last morning of a long conference. Turning up for a two-hour hands-on workshop at that point takes real commitment, and the room was brilliant.

The people

If I am honest, the talks are only half of why I go. The other half is the people, and this year did not disappoint.

• A really nice conversation with Camilla Moraes.
• I finally got a clear picture of what the team at Chainguard is building after a great chat with Kalle Westerling.
• The pleasure of introducing Shachar Azriel on my Stage 3 afternoon.
• A good talk with Daniel Tim Fetzer about his work, and I got to walk him through Halocline at the speaker event.
• Always a joy to catch up with an old friend, Ali Yazdani. We spent some proper time together, one of the highlights of the trip.
• A short but genuinely nice chat with Yasmine Kordjazy.
• And I was glad to get the chance to talk with Fernando Schneider.

If we spoke and you are somehow not on this list, blame my end-of-conference brain, not you. Send me a message and let us keep the conversation going.

Until next time

Two days, one stage hosted, one workshop delivered, a stack of new ideas, and a few friendships strengthened. That is a good conference by any measure.

If bridging AI models and real systems is your kind of problem, or you just want the short version of the workshop, here it is: let the model propose, but keep your application firmly in charge of what actually happens.

See you at the next one.