Building AI workflows: from local experiments to serving users

Everyone can throw together an LLM, some MCP tools, and a chat interface, and get an AI assistant we could only dream of a few years back. Add some “business logic” prompts, and you get an AI workflow; hopefully a helpful one.
But how do you take it from a local hack to a production application? Typically, you drown in privacy questions, juggle npx commands for MCPs, and end up debugging OAuth flows before it hopefully starts to make sense.

In this session, we show a repeatable process for turning your local AI workflow experiments into a production-ready deployment using containerized, static configurations.

Whether you prefer chat interfaces or replace them with application UIs, you’ll leave with solid ideas for going from a cool demo to real applications without the existential dread of DevOps.

Your MCP client is not great. Here’s how to fix it

MCP servers are all the rage right now, but half the experience lives on the client side - and most MCP clients still leave a lot on the table.

In this session, we’ll break down what makes a great MCP client:
What responsibilities does it own?
Where should common concerns like: discovery, auth, and session handling actually live?

When is it better to delegate to other tools in the ecosystem?
We’ll also take a hard look at the lesser-used parts of the MCP spec like roots, or, for example, dynamic tool config reloading, and show how small features like these can dramatically improve the use experience.

Non-deterministic? No problem! You can test it!

Testing is hard, which is why developers tend to avoid it. Testing non-deterministic things is even harder, which is unfortunate, since we're all writing AI-infused applications, and AI models are notoriously non-deterministic. What happens when the applications start using advanced features, such as RAG, tools, and agents? How do you test these applications? There must be some tools, technologies, and practices out there that can help, while not costing your organization lots of money!

Join Java Champions Oleg & Eric in this session as they explore some of these tools & technologies, such as Testcontainers, LangChain4j, Quarkus, and Ollama. They’ll bring together Oleg’s Testcontainers knowledge and Eric’s testing obsessions, getting hands-on and show how you can incorporate these tools and technologies into your inner and outer loop processes.

You’ll see how effortlessly Quarkus integrates with Testcontainers, and how Testcontainers can be used in conjunction with popular LLMs when writing tests. You’ll also learn about how to use containers to extend your testing into your CI environments, so you can always be sure that if your tests are green you’re good to go!

Developer productivity for apps with AI

The AI landscape has grown a ton in the last year with many technologies and approaches that application developers must master to include AI in their end-user and enterprise apps. However, more focus must be put into enabling standard software development workflows: testing, ensuring RAG correctness and efficiency, local development environment and CI setups, and security of AI artifacts, monitoring of the quality and so on.

In this session, we look at how application developers can integration test their GenAI apps with local models, augmented with RAG both locally and in CI. You'll learn how the setups for GenAI apps in the inner development loop can be programmatically managed and how these new tools can get into typical software development workflows without impairing developer productivity.

Whether you're an enthusiast yourself, or your boss tells you to "add AI" to the software you're working on, this session will give you understanding of the scale of the problem of building with AI and suggestions how to do so without going crazy.

Simplified Inner and Outer cloud native developer loops

Despite the quality of modern cloud-native tools, the user experience for inner and outer developer loops are still radically different, which introduces friction and hampers developer productivity.

Development setups are app-centric, while production environments deal with deployments and tools required for operations teams to keep applications running. This session explores tools to simplify both side and improve developer productivity through a platform engineering and polyglot approach using a toolchain that:
Gives developers a standard set of app-level APIs to solve common distributed app challenges, using Dapr.
Equips developers and product teams with consistent, polyglot feature flags through OpenFeature.
Facilitates easy local development, outside of a Kubernetes cluster, with Testcontainers.

Attendees will walk away with a working demo showcasing a straightforward, lightweight and effective inner and outer dev loop, ensuring the seamless promotion of apps from dev to prod.

Making your own Testcontainers module for fun and profit!

Testcontainers libraries are a de-facto standard for integration testing in the Java community. One of the reasons for its popularity is the ecosystem of the modules -- pre-defined abstractions for creating containerized services for your tests in a single line of code.

Testcontainers modules help to integrate with new technologies, hide setup complexity behind a neat abstraction, or use in-house Docker images without using lower-level API all the time.

In this lab, we'll go over the architecture of a module, see how one can implement it, and make a small but helpful module ourselves.

Whether you're working on a database technology, want to implement chaos engineering practices, or improve your team's productivity, creating a Testcontainers module is an excellent way to abstract away some of the complexity of your integration tests and contribute to the Java ecosystem.

Making a Testcontainers module can be a great exercise -- either adding a more complex topology (adding a chaos engineering proxy and hiding it behind an abstraction, supporting your in-house docker images, or a new technology -- all these are great use cases and you can contribute to the Java ecosystem in a nice standalone way (without taking on yourself a ton of responsibility for maintaining the project forever).