The post-hype reality for developers

Devoxx Poland 2025 felt different. Not because of revolutionary new frameworks or another "this changes everything" moment, but because of what didn't happen. The conference had an unusual dose of pragmatism. Maybe it's because developers are asking the right questions: "Does this solve a problem?" and "What happens when this inevitably breaks?"

Here's what emerged from the sessions we watched, and the people we spoke to. 

The AI recalibration

The most illuminating conversations happened around AI tooling, and they weren't what you'd expect from a 2025 tech conference. Instead of breathless promises about autonomous coding agents, we got measured analysis of what's working and what's just theater.

RAG got contextualized. Piotr Przybył's "To RAG or not to RAG" session was full of energy. His core insight? You can build effective RAG systems with bash scripts. No need for expensive AI frameworks that promise everything. The real question isn't "how do we add AI to everything?" but "do we need the generation part, or is search sufficient?"

The keynote delivered an even sharper perspective. Venkat Subramaniam – who had the entire auditorium stand up and sing "Happy Birthday" in Polish – posed a question that should make every AI-first startup uncomfortable: "If chatbots come with disclaimers that information might be incorrect, is that like releasing software that might or might not work?" AI should generate ideas, not solutions. Solutions require accountability, reliability, and correctness – current AI tools haven't mastered the quality yet.

This evolution from "AI will replace developers" to "AI might help with ideation" represents the industry maturation we've been waiting for.

GitOps: The unglamorous revolution

While everyone chased shiny new deployment tools, Tomasz Cholewa presented something that sounds mundane but fundamentally matters: splitting CI and CD into separate, declarative processes.

His model is elegantly straightforward: CI builds artifacts, GitOps deploys them. Three repositories handle everything; CI templates, deployment manifests, and platform configuration. The result is that deployments become predictable, auditable, and – most importantly – rollback-friendly.

Why does this matter for streaming architectures? Because when you're managing Kafka schemas, Kafka Connect configurations, and stream processors, having everything versioned and declaratively deployed isn't just convenient; it's essential for operational sanity. The GitOps approach makes evolving streaming topologies manageable by humans who don't need distributed systems doctorates.

Here is Drew multi-tasking across separate processes at Devoxx Poland by juggling Lenses demos, and keeping track of high scores in the hammer game.

Stream Processing: Strategic tool selection

The Kafka Streams vs. Flink comparison revealed something important: these tools serve different purposes. Viktor Gamov clarified the landscape, accompanied by a delightful parade of AI-generated space otters and squirrels. If you're building event-driven microservices with Kafka-to-Kafka processing, Kafka Streams is the natural choice. If you need complex analytics across multiple data sources, Flink becomes relevant.

The pattern emerging across streaming sessions was deliberate tool selection. XM.com's architectural journey demonstrated the value of managed services ("Don't run Kafka yourself"), and his advice was simple: Don’t even start thinking about Kafka without developer tooling. The Spring Kafka with Kotlin session showed how mainstream frameworks are making streaming accessible to typical Java developers. No need to become a distributed systems specialist just to process events.

The principle: use Kafka for event-driven microservices, consider Flink when you genuinely need its complexity. Revolutionary? No. Sustainable? Absolutely.

The microservices maturation

Wei Hu's session on AI-driven microservices brought welcome realism to the discussion. His guidance? Design for "mini services" (5-9 services) rather than dozens of microservices. The complexity overhead isn't justified for most teams.

More significantly, he emphasized designing systems that both AI and humans can comprehend. Simpler architectures benefit everyone, including your future self. The focus on "AI-sandboxing" (designing for rapid AI component substitution) demonstrated practical thinking about AI integration rather than wholesale AI replacement.

Frontend architecture gets strategic

Tomasz Ducin's bounded contexts session brought domain-driven design principles to frontend architecture; a topic often relegated to afterthought status. His key insight was that different parts of your application assign different semantic meanings to the same data. A product in your catalog differs from a product in an order, which differs from a product on an invoice.

The practical recommendations: 

• Use separate data models for different bounded contexts

• Communicate through events rather than centralized stores, and

• Structure teams around business outcomes rather than technical boundaries. 

It's foundational DDD applied to frontend challenges most teams encounter.

The productivity paradox

Perhaps the most honest session addressed developer productivity measurement. The "Developer Rhapsody" talk made a crucial point: productivity can't be measured through lines of code, pull requests, or tickets. The real drivers are collaboration, continuous learning, stable output (not firefighting), and sustainable pace.

JetBrains' cross-organizational productivity session reinforced this. Their journey from internal dogfooding to understanding genuine customer problems illustrated how even well-intentioned internal tools can miss the mark. Operational blindness; seeing only how you use your product, not how customers use it – affects both product development and internal tooling decisions.

Our Lenses.io hammer game winner certainly didn't miss the mark.

Looking beyond the sessions

The conversations that resonated with us extended far beyond individual talks. This conference reinforced the shift toward building systems humans can understand and maintain, choosing tools based on particular problems rather than general popularity, and making incremental improvements rather than wholesale rewrites.

Reflections from our Polish adventure

What struck us most about Devoxx Poland compared to Devoxx UK was the sheer volume of Kafka-focused content. Every other session seemed to touch on streaming, event-driven architectures, or data processing – a testament to how central these patterns have become in modern development.

This was our first time at Devoxx Poland, but it won't be our last. We'll be back next year. We have to apologize to our booth neighbors though – we were definitely the noisiest booth with our hammer game (yes, that was us, sorry!). Next time we're thinking of going for a "silent disco" approach instead.

The organizers delivered exceptional quality throughout, and Krakow provided the perfect backdrop for meaningful technical discussions. The city's beautiful architecture seemed to inspire equally thoughtful software architecture conversations.

The level of interest in our free Kafka tooling was remarkable. For those who missed us at the booth, you can still download our tools and join the community exploring better ways to work with streaming data.