This is our first WeAreDevelopers World Congress. We have done the conference circuit before, most recently KubeCon, so we walked into CityCube Berlin with a rough idea of what a big developer event feels like. This one feels different, and I want to write down why while it is still fresh, before the main stages open and the noise starts.
A quick, honest note up front: it is Day 0. July 8. The badges are getting picked up, the warm-up program is running, and the workshops and masterclasses are in full swing, but the real thing, the keynotes and the 20-plus parallel tracks, doesn’t start until tomorrow.
So treat this as a first impression. The judgment comes later. Today is about the place's texture and the conversations in the hallways.
Key Takeaways
- Day 0 is the warm-up. July 8 is for workshops and masterclasses; the keynotes and over 20 tracks start July 9. Too early to judge, but the character is already clear.
- Younger and wider than KubeCon. KubeCon offers deep, single-topic expertise; WeAreDevelopers is a broad, workshop-heavy crowd that comes to build, not to defend positions.
- Every AI conversation turned into cutting token consumption: trim DTOs, load MCP tools on demand, write better tool descriptions.
First Impression: This Is a Builder's Warm-Up Day
WeAreDevelopers runs its Day 0 as a genuine pre-event. You pick up your badge, and then you can drop into a full-day masterclass, a hands-on workshop, or one of the satellite sessions.
That is a deliberate choice, and it sets the tone.
The whole congress is built around one question this year: AI is already inside the development workflow, so what do you actually build with it, what do you automate, what do you trust, and how do you run it in production?
That framing is on their own site, and you feel it in the room. Nobody is here for a keynote about the future. They are here to try things and break them.
The scale helps. The event pulls 15,000-plus attendees from more than 100 countries across three days, with a Tech Expo that runs 40,000 square meters. It is big. But big in a different way than KubeCon, and that difference is the thing I keep coming back to.
How Does It Compare To KubeCon?
KubeCon is huge, and it feels mature. There is a deep, settled community around a single problem space, cloud native and Kubernetes, and everyone in the room already shares a vocabulary.
When we attended KubeCon India, the density of expertise on one topic was the whole point. You could go three layers deep on etcd or GPU scheduling with a stranger at the coffee bar. That is what a focused, older community gives you.
WeAreDevelopers is younger and more general. The crowd is not organized around one problem.
It is developers of every kind: web, AI, cloud, security, startup founders, platform engineers. One of our team members put it well while we were standing in the atrium: this is a small community because it is young, and it leans workshop-heavy on purpose. They bring developers in and make them do things.
That is the trade. You lose the single-topic depth that KubeCon has, and you gain a room full of people who are here to learn hands-on rather than to defend a position they already hold.
Neither is better. They are built for different jobs.
If you want to go deep on one ecosystem, KubeCon wins. If you want a wide read on what developers across the whole stack are actually worried about right now, this is the best window.
For anyone weighing an event like this, that distinction matters more than the headcount, and it is the same lens we used in our KubeCon attendee guide: pick the event that matches the depth you need.
One small human observation, and I mean this neutrally: A lot of the local conversation happens in German, and a couple of times, an English-only exchange stalled as a result. It is not rudeness. It is just Berlin, a German event, with a strong local base. Worth knowing if you are flying in and expecting everything in English by default.
The One Conversation Everyone Was Having: The Token Economy
If Day 0 had a theme in the hallways, it was cost. Specifically, token consumption. Almost every AI conversation eventually turned into the same practical question: how do you get an AI application to do the same work for fewer tokens?
People are past the demo stage. They are running agents in production, and the bill is real.
The answers people kept circling were not exotic. They were architectural, and they were consistent:
Cut the integration code and the DTOs: A lot of token waste is just shape. Standard JSON responses are verbose, and every extra field you hand a model is tokens it has to read.
The fix people described is to filter at the source and return only the fields the agent actually needs, rather than passing whole data-transfer objects through the context window.
That single change is described as the highest-leverage optimization for MCP-based agents, and it is the same instinct as trimming a bloated API response before it ever reaches the model.
Stop loading every tool up front: This was the sharpest thread. Before an agent does any real work, it can spend an enormous amount of time just describing the tools it might use.
Anthropic's own measurements put tool-definition overhead at 55,000 to 134,000 tokens in some production setups before a single task begins.
The move that fixes it is code execution with MCP: let the agent load tools on demand and process data outside the context.
Anthropic reported that one workflow dropped from 150,000 tokens to 2,000, a 98.7% reduction. That number came up more than once today, and for good reason.
This connected directly to the workshop we sat in, which is where the day got genuinely useful.
The Workshop: LLM Fundamentals, From Tokens To Tool Calling
Day 0 ran a whole parallel track of masterclasses, and we only caught a slice of it. The one we picked was a hands-on session on how LLMs actually work under the hood.
Tokenization explains more than you would think.
The same text can be 64 tokens on one tokenizer and 53 on another. Numbers fragment into multiple tokens, which is exactly why models are unreliable at arithmetic. The speaker's rule makes a lot of sense: never prompt a model to do math. Route the calculation to a tool.
Also, some of the suggestions were like: use the better model to plan things and let the weaker model execute them.
Context windows are a security surface
One of the more common attacks on LLM applications is prompt overflow: flooding the context with enough input that the system prompt gets pushed entirely out of the window, and the model forgets its own rules. If you are building anything user-facing on an LLM, that is table stakes now, not an edge case.
MCP server design has real constraints
The guidance was specific. Keep tool counts around 20 to 25. Avoid similar-looking functions because models confuse them. And don’t mirror your REST API. Expose capabilities the way you would design a UI, not the way your backend happens to be structured.
The line that stayed with me: description quality determines whether the model picks the right tool. That is not a coding problem. That is a writing problem.
Evals are the boring part that eats all the time
LLM-as-judge pipelines score answers 1 to 100 against expected outputs, watching for regressions when a model or parameter changes. Unglamorous. Non-negotiable. It is the same discipline we use when we benchmark LLM citation share for clients, and the parallel was not lost on us.
We Ran Into a Client Here: Graftcode
One of the better moments of the day was not on any agenda. We met the team from Graftcode in the hallway and ended up in a long, good conversation about open source and GitHub. They are thinking hard about how to get their open-source work seen, and they were asking about our help with GitHub marketing, which is work we already do for them on the developer marketing side.
That conversation is timely because it is exactly the problem we just documented.
We are about to publish a case study on how a distribution system took an open-source repo from a near-standstill to a compounding growth curve.
The short version of what we told the Graftcode team is the same thing that the case study shows: strong code doesn’t get discovered on its own. It gets discovered when it shows up in the threads developers read, the lists they browse, and the AI answers they now trust.
If you run an open-source project, that is the whole game, and it is what our GitHub Marketing service is built around.
What Day 0 Leaves Me Thinking?
Final summary: it is too early to call. The main event hasn’t started, so anyone writing a grand verdict today is absurd.
What I can say is that the character of this place is clear already. It is younger than KubeCon, wider than KubeCon, and it earns its keep through hands-on workshops rather than a settled shared expertise. That is a real strength for a certain kind of attendee and a real gap for another.
The through-line of the day was cost discipline in AI. Fewer tokens, leaner tool design, better descriptions, real evals.
It is the same shift we see from the marketing side: the teams that win are the ones treating how they describe their product to a machine as seriously as how they build it. Tomorrow, the keynotes open, and the real signal arrives. We will be back with what actually holds up.
If you are here in Berlin and you build developer tools, come find us. And if you’re wrestling with the same open-source visibility problem Graftcode is, book a free consultation, and we will walk you through exactly how we approach it.
Frequently asked questions
When and where is WeAreDevelopers World Congress 2026?
July 8 to 10, 2026, at CityCube Berlin (Messe Berlin, South Entrance). Day 0 (July 8) is the warm-up: badge pickup, workshops, and masterclasses. The main stages open on July 9.
How is it different from KubeCon?
KubeCon is older, huge, and built around one topic (cloud native), so it goes very deep. WeAreDevelopers is younger, broader, and workshop-heavy, covering the whole stack. Pick KubeCon for single-topic depth; this is for a wide read across developer tooling.
How big is the event?
Around 15,000 attendees from more than 100 countries, 500-plus speakers, 20-plus parallel tracks, and a 40,000-square-meter Tech Expo across three days.
What was the main theme in the hallways?
Cost. Specifically, reducing token consumption in AI apps: leaner data (fewer DTOs), loading MCP tools on demand rather than all at once, and better tool descriptions. Teams have passed demos and are now watching the bill.