KotlinConf 2026 — Day 2 Impressions

KotlinConf 2026 continued today at the ICM, Internationales Congress Center Messe München. Day two went deeper into language-level topics, covering experimental features coming in future Kotlin releases, idiomatic server-side patterns with Spring Boot 4, and the accelerating conversation around AI and agents in the Kotlin ecosystem.

Day two was more outward-facing, a look at what the community is building and where JetBrains is taking the language.

Idiomatic Kotlin Applications With Spring Boot 4

Sébastien Deleuze, Spring Framework core committer

A practical tour of idiomatic Kotlin with Spring Boot 4, covering a wide surface area from null-safe APIs to observability and persistence. Dense with short examples and actionable recipes.

Full disclosure, I'm not as well versed in Spring as other JVM based frameworks, so some specifics did not find their soft landing as well as other topics, which is a "me" problem more than a talk problem. Worth watching the recording if Spring is something in your tool belt.

Eval-Driven Development

Urs Peter, Senior Software Engineer & JetBrains certified Kotlin trainer

Urs gives talks with real commitment, and it's been engaging content across both KotlinConf visits for me. This one was about bringing reliability to agentic systems, and the central argument was straightforward: probabilistic systems need their own version of test-driven development.

The talk introduced Eval-Driven Development as a systematic approach to testing AI agents at multiple layers. Schema validation, tool correctness, decision flows, and end-to-end goal completion, each treated as a first-class concern rather than an afterthought bolted on post-hoc.

The hook for me was the concept of using LLMs as "judges" within the evaluation pipeline itself. Generating test cases, writing assertions, and acting as evaluators of synthetic agent traces.

It is a self-referential approach that raises obvious questions about trust, but Urs addressed these. The demos were built on Koog, which gave the abstractions genuine purchase.

The broader point is one that the industry is still working through. Agentic systems that impress in a demo and fall apart in production are not a model capability problem but rather an engineering discipline problem. Urs made a credible case that the discipline exists and is learnable, which is more than most talks in this space manage.

Context Parameters & API Design

Alejandro Serrano Mena, Researcher, Kotlin Language Evolution Team, JetBrains

Context parameters are an experimental Kotlin feature that arrived with some fanfare. A context declaration on a function signature names a type that must be present in the calling scope. The compiler resolves and threads it through automatically, no manual passing, no ceremony at the call site.

context(users: UserService)
fun getFriends(user: User) {
  val friendIds = users.findFriendsById(user.id)
}

context(userService: UserService)
fun summarize(user: User): String {
  val friends = getFriends(user)
  // ...
}

The UserService flows from summarize into getFriends without appearing in either function's explicit parameter list. Context parameters are parameters, just ones the compiler handles for you.

The more interesting part of the talk was the design guidance built around a concept Alejandro called the spotlight principle. The framing is that reading code is like watching a film. Each function is a scene, and within any scene there are primary and secondary characters. Primary characters are front and centre, named in the explicit signature, doing the visible work of the scene. Secondary characters move between scenes largely unnoticed, present when needed but never demanding attention.

The spotlight principle gives you a concrete way to decide between a context parameter and a receiver. If a value is the subject of the function, the thing the function is fundamentally about, it belongs in the explicit signature or as a receiver. If it is supporting infrastructure that needs to be present but is not what the function is about, a context parameter is the right fit. Dependencies, loggers, and service locators are naturally secondary in nature. The domain object you are operating on is almost always a primary.

The talk also addressed the question of multiple context parameters, which came with an honest trade-off summary. You get explicit, surgical dependencies and the ability to refine any one context independently. The cost is that introducing a new context means touching a lot of function signatures. The recommended pattern for managing this at scale is the holder approach, composing contexts into a delegation tree rather than threading individual services everywhere.

class DbDependencies(...) : UserServiceHolder, GroupServiceHolder

class Dependencies(val db: DbDependencies, ...) :
  UserServiceHolder by db, GroupServiceHolder by db

Context parameters are still experimental, but the guidance here felt appropriately calibrated to that. The spotlight principle is a useful heuristic now regardless of whether you adopt the feature today, because the underlying question of what belongs in a signature versus what belongs in the ambient environment is one you face with receivers, dependency injection, and thread-locals already.

Kotlin Context Parameters