Schedule

We'll take a look at where the FFM API (Project Panama) stands in 2026, drawing on our experience with both using large native libraries like Catboost and more granular — but no less practical — examples, such as our own bindings to libc.

We will tell and show how the hybrid JIT + AOT code compilation model works under the hood in the Android Runtime and what benefits it brings to real applications. We will compare the Google solution with the Leyden project in the big Java.

I will tell you what we had to modify to run our service locally on Valhalla Early-Access Build, what changes we saw in the metrics, and what conclusions we can draw from this experiment.

How Java 25 with FFM API learned to manage hardware without a single line of C: we analyze the evolution of the architecture of the open-source Pi4J project: from JNI/JNA to pure Java, the boundaries of applicability, timings and memory — with benchmarks and demos on real sensors.

We will look into different models of concurrent programming.

Let's look at the evolution of the JVM through the lens of closing architectural holes. Using the one-nio serialization framework as an example, we will conduct an archaeological dig from Unsafe, MagicAccessorImpl, and synthetic accessors to modern mechanisms such as VarHandles, Nestmates, and Hidden Classes.

Vector API doesn’t speed up code on its own: the result is determined by the dependencies between operations, the capabilities of the JIT, and the processor architecture. Using JMH benchmarks, we’ll examine when auto‑vectorization is sufficient and when explicit SIMD actually changes the algorithm and provides a benefit.

At the JVM Language Summit 2025, Brian Goetz talked about plans to add type classes to the Java language. The talk is based on Brian's story, as there is very little other information on this topic, but it is not just a retelling.

We'll take a look at where the FFM API (Project Panama) stands in 2026, drawing on our experience with both using large native libraries like Catboost and more granular — but no less practical — examples, such as our own bindings to libc.

In this talk, we will analyze Java virtual streams not as a feature, but as an engineering solution.

Elasticsearch as a search engine can be debated for a long time. But it turned out to be unexpectedly good for storing metrics: I'll tell you how we launched TSDS under a load of more than a million metrics per second, what problems we encountered and why we eventually had to go inside Elasticsearch and Lucene.

Vector API doesn’t speed up code on its own: the result is determined by the dependencies between operations, the capabilities of the JIT, and the processor architecture. Using JMH benchmarks, we’ll examine when auto‑vectorization is sufficient and when explicit SIMD actually changes the algorithm and provides a benefit.

The E2E benchmark, beautiful graphics, impressive RPS and the first place in the table easily create the feeling that the technology is objectively faster than competitors. But what exactly does the E2E benchmark show: the actual stack performance, the quality of the selected scenario, or the ability to prepare the test correctly?

If you want to understand what lies behind the beautiful hitmaps, or if you want to build profiles in your production environment, then this talk is definitely for you.

The talk focuses on the transition from static agents to self-evolving systems that can adapt to the developer's preferences.

I decided to check: what would change in my work if I gave the AI agent the same tools that the developer himself uses: an IDE, LSP, and the project’s knowledge base?

I'll tell you how to make agents create UI based on guides.

What part of the work does management take on and how can the delivery process really be accelerated?

We will perform the Sharikov Blues (perhaps literally!) to reveal the complex aspects of the modern understanding of how technological systems are shaped by social, economic, and cultural factors.

The dominant paradigm of LLM development assumes that the growth of solution quality is linearly related to the growth of the power (and cost) of the underlying model.

The talk challenges this assumption by showing that with a well-thought-out engineering architecture — the distribution of tasks among short-lived agents, the accumulation of structured state, and strict symbolic control — comparable-quality results can be achieved at a fraction of the cost of models.

The talk is intended for developers and tech leads who use agents to work with code and are responsible for release decisions.

Why Context Engineering is becoming a new engineering discipline, how AI is changing the entire development lifecycle (AI PDLC), and what expertise will define a strong engineer in the coming years.

We’ll look a few years ahead: how AI agents will change the developer profession, why DDD and modeling will become more important, how the roles of product and platform developers will be divided, and what will remain within a person’s responsibility when writing code yourself will no longer be necessary.

The talk will provide an overview of the theory and apply it to specific cases that I have heard in dozens of presentations on the topic, highlighting the common elements. Come to get a ready-made theoretical foundation and a set of practical templates!

In reality, only engineers will survive with AI: those who do not fully surrender their thinking to machines and remain decision-makers rather than interface operators.

Let's figure out what really separates us from general-purpose robots. Let's disassemble a robot and see where each part is reaching its limits, and where progress is happening faster than we think.

We will analyze several typical cases in which our agent and platform use LLM to solve "fuzzy" tasks, and after the talk, the audience will grasp specific approaches based on our production cases.

How I sketched out a Kotlin Script with a simple agent on Koog. It's not particularly smart, but it's simple and manageable: sometimes it's easier to explain a task with code than with words.

Let’s talk about what vibe coding is and why this term causes so much resistance among experienced programmers.

In Russian classics, there’s a character known as the “little man.” A large system is moving forward, great decisions are being made, and somewhere down below, there’s a person who just wants to do their job properly. With AI, we’re now in roughly the same situation: there’s a big race going on around us, and we, the little people, need to somehow adapt to a world where AI has already become part of development — and still manage not to end up in a psych ward.

Using the composite case, we will analyze a situation in which an LLM agent dramatically accelerated the preparation of specifications, but almost did not shorten the total product release period.

In an hour, the agent does the work that I used to do in a week. And for the first time in my career, I caught myself asking a question that’s silly to say out loud: am I an engineer?

...but so that nobody notices it.

We'll talk about the schedule, sessions and share information. 

During the conference, we explore new technologies, and at the after‑party, we discover new ways to open drinks when the usual tool is not at hand.

10‑minute presentations on professional or semi‑professional topics and lively discussions.

Coming soon.

Let’s recall what engineers and educators feared, how work and education changed, and what these stories help us understand about today’s changes.

I am going to talk about the controversial but possible impact of modern AI variants on human memory and thinking, as well as about reasonable strategies for developing one’s own thinking (including critical thinking) under these conditions.

Summing up the results of the conference, remembering the highlights and talking about plans.