5 Takeaways from WeAreDevelopers 2025 That Stuck With Me

This year was my very first time at the WeAreDevelopers World Congress 2025 in Berlin. When my colleague Mišo and I bought the tickets, we expected a big conference. But over 15,000 people, hundreds of talks, and 17 stages with parallel sessions running from morning to evening – that’s a whole new dimension. On top of that, this edition was special: the conference celebrated its 10th anniversary and once again proved why it’s called the largest developer event in Europe. 

Already on day one it became clear that we couldn’t possibly attend everything, so we split the schedule and agreed to share the best highlights afterwards. With so many talks, some content inevitably blended together, some topics repeated, and not everything left the same impression. But a few ideas really stuck with me. Here they are:

1. Large applications get simpler when you break them down (microfrontends at ZEISS)

I’ve been following the topic of microfrontends for years, even though I haven’t had the chance to use them in production yet. I’ve always believed that smaller means simpler, and simpler means easier to maintain. This belief was confirmed by Stefan Bley and Lucas Braeschke from ZEISS Digital Innovation, who illustrated the concept on a real-world challenge.

Their Health Data Platform (HDP) was a monolithic frontend where each release triggered time-consuming testing across the entire app. The solution? Splitting the app into micro parts that can be developed, tested, and deployed independently. In practice, a main shell wrapped around individual components, which could share dependencies and even run on different frameworks (in their case Angular and React side by side).

Each micro-part was owned by its own team responsible for both development and release planning. The result: more independence, faster iterations, and less waiting on others. The key, however, lies in defining the right boundaries so teams don’t step on each other’s toes while still keeping the system maintainable.

This isn’t just a neat architectural idea – it’s a practical way to simplify development in large teams and reduce deployment risks. Since that talk, I’ve kept a mental list of projects where this approach might fit.

My view of the packed hall and the welcome sign “Karibuni” – Swahili for “welcome”.

2. The biggest security risk isn’t always in the code – it’s in user behavior (inspired by John Romero on cheating and AI)

John Romero, creator of Doom and Quake, talked about security in a way I didn’t expect.
He explained how cheating in games has evolved. It used to mean hacking memory or modifying code. Today, cheaters don’t need to touch the system at all – they simply train an AI to watch the screen until it learns how to play the game by itself. No code changes, no hacking.

For developers, the lesson is clear: cheating is a business. Because there’s real money in e-sports, people invest in increasingly sophisticated tools. AI can now act as an autonomous player, learning from observation and reacting faster than humans. And interestingly, the same principles that let AI cheat also power tools like GitHub Copilot – except here they accelerate work and support developers instead of exploiting the system.

For me, this was a strong reminder that security isn’t just about encryption and access tokens – it’s also about how users interact with the system. The same thinking applies to web and business apps: risks often come not from the code itself, but from user behavior.

3. Node is no longer an excuse – true parallelism is here without changing your stack (on worker_threads and Piscina in Node.js)

Mišo attended Matteo Collina’s talk Node.js: More Threads Than You Think. If you still think of Node as a single-threaded runtime, it’s time to update your perspective.

Thanks to the built-in worker_threads API and tools like Piscina, we can now introduce true parallelism in Node.js apps – without changing technologies or architecture.

The benefits are obvious for CPU-heavy tasks like report generation, data processing, or statistics that would otherwise slow down the main event loop. Offload them to worker threads, and they run in parallel without blocking requests.

Selfie in front of the hall with the iconic duck – the conference mascot referencing “rubber duck debugging”.

4. When dev and production environments behave the same, development speeds up (on docker-compose in Google Cloud)

From the Google Cloud sessions, the most exciting update was the ability to deploy apps directly using docker-compose.yml. Not through a traditional Dockerfile or Kubernetes manifests – but exactly the same way we do locally.

Until now, moving to production meant rewriting configs into K8s YAML or Terraform, which was slow and error-prone. This new approach could cut down that overhead significantly.

If it works in practice like it did in the demo, developers will be able to test complex changes without waiting for DevOps. For smaller services or internal tools, there might not even be a need for a “production-only” deployment anymore – just run docker compose up… directly in the cloud.

The result could be:
– faster testing of architectures,
– fewer errors caused by mismatched environments,
– easier staging deployments,
– lower infrastructure knowledge requirements during development.

It may not be a revolution yet, but if it stabilizes and gains adoption, it could change how teams handle smaller apps.

#WeAreDevs – a reminder that even if we all write different code, we’re still part of one developer community.

5. AI is no longer just autocomplete – it’s becoming a colleague (on GitHub Copilot as an independent agent)

Copilot was one of the hottest topics – sometimes technical, sometimes more philosophical.

What stood out most was how it’s becoming more autonomous. Not just a plugin guessing the next line of code, but an agent you assign an issue to – and it works on it by itself. It can open a pull request, take feedback, and push an updated solution.

The live demo didn’t work at all, which was a funny moment. But that doesn’t change the fact: Copilot already saves time. With the right prompts and review, it works like a smart junior developer who never forgets, never delays, and is always online.

Bonus: JavaScript’s skeletons in the closet aren’t going anywhere (on backward compatibility and syntax oddities)

Peter Kroner delivered a funny but accurate roundup of JavaScript’s strangest syntax quirks – like why [] + [] isn’t the same as [] + {}. The takeaway? It all stays because of 100% backward compatibility.

A good reminder that tech debt doesn’t only apply to projects, but also to languages themselves. Sometimes we code despite the language, not thanks to it.

Not something I’d deploy Monday morning – but as a reality check that even languages carry their past baggage, it was spot on.

Conclusion

What impressed me most was the organization. With so many people, everything ran smoothly. Networking was interesting too – QR-code cards linked to app profiles replaced business cards, which felt natural and practical. Still, it was mostly companies using it; let’s be honest, developers tend to be introverts.

In short – the conference was excellent. A well-curated expo, loads of inspiring talks, and often the hardest decision was simply choosing where to go. And that, I think, is the best problem a developer can have at an event like this.

At the end of the day, we agreed on one thing: AI is reshaping how we build software. Programming today looks nothing like it did just a few years ago, and a year from now it will look different again. Still, we need to stay cautious about what we adopt – sometimes new tools bring more chaos than clarity. Some things aren’t ready for production just yet, while others we started trying out on the way home. And that’s exactly what conferences like this are for.

Taking a moment to pause. A good event isn’t just about content – it’s also about letting your brain reset and process the ideas.

FAQ: Frequently Asked Questions about WeAreDevelopers 2025 and Conference Topics

What are the benefits of microfrontends and when are they worth using?

Microfrontend architecture splits a large application into smaller, independently deployed parts. This simplifies development, testing, and deployment while reducing release risks. It’s especially useful for larger teams and complex products.

How can Node.js achieve parallelism without rewriting the application?

With the built-in worker_threads API and the Piscina library, Node.js can handle CPU-intensive tasks in parallel without blocking the main event loop – and without changing the entire stack.

Can you deploy applications to Google Cloud directly with docker-compose.yml?

Yes. Google Cloud now supports docker-compose configurations for straightforward deployments. It’s a fast, practical option for staging environments and smaller apps, without needing to manage complex Kubernetes YAML files.

How can AI tools like GitHub Copilot handle tasks independently?

Copilot has evolved beyond autocomplete. It can open pull requests, respond to feedback, and iterate solutions on its own. Think of it as a digital junior developer who remembers context and makes autonomous decisions.

What does cheating in games have to do with application security?

Game hackers show that exploiting behavior doesn’t require touching the code – just the UI and logic. The same principle applies to business applications. That’s why security should consider user behavior, not only developer safeguards.

Is programming in 2025 different from just a few years ago?

Absolutely. AI tools, new deployment workflows, and architectural shifts are transforming how developers work. What was considered futuristic last year is quickly becoming the new normal.

What was networking like at WeAreDevelopers 2025?

Digital, efficient, and surprisingly natural. QR codes, open booths, and a strong community vibe made connecting easier – even for developers who aren’t the most outgoing.