TL;DR

• New “val inside parentheses” syntax is being introduced to allow for name-based destructuring. Additionally, new syntax with square brackets is being introduced for positional destructuring.
  • Both are currently Experimental (enabled using the -Xname-based-destructuring=only-syntax compiler argument) and will become Stable in a future release.
• In the distant future, the behavior of the “val outside parentheses” syntax for destructuring will change from being position-based to name-based.
  • There will be a long migration period before the default changes, and tooling is already in place to help with migration.
  • You can already make the switch to the new behavior (-Xname-based-destructuring=complete), but note its Experimental status.
• The compiler ships with migration helpers that will be enabled by default for a few versions, and it will be some time before the new behavior becomes the default.
  • You can enable these helpers now by using -Xname-based-destructuring=name-mismatch.

Kotlin is changing, with names set to become central in destructuring. In the future, val (name, age) = person will extract the name and age properties from the person value, regardless of the way and order in which they were defined. This marks a change from the current approach to destructuring, in which the position is the key element. This blog post explains the reasoning behind this change, the migration strategy, and how Kotlin’s tooling supports it.

Why destructure by name instead of position?

Destructuring is most commonly used to access properties from data classes. For example, we can define a Person class as follows:

data class Person(val name: String, val age: Int)

Then we can extract several of the primary properties in a single go. This is what we call destructuring the value into its components.

fun isValidPerson(p: Person) {
  val (name, age) = p
  return name.isNotEmpty() && age >= 0
}

Currently, destructuring is done by position. The variables we introduce in a destructuring declaration often follow the names of the properties in the data class, but there’s no such requirement in the language.

// this is exactly the same function as above
fun isValidPerson(p: Person) {
  val (foo, bar) = p
  return foo.isNotEmpty() && bar >= 0
}

This lack of connection can cause problems, as it is very easy to inadvertently swap the order of two properties. This mistake may be caught later because of non-matching types, but it appears far from the actual origin.

The way in which components relate to primary properties also hinders refactoring. For example, we cannot move the age property to be computed and still retain the nice data class syntax. Imagine we make the following change:

data class Person(val name: String, val birthdate: Date) {
  val age = (Date.now() - birthdate).years
}

Now every destructuring declaration suddenly changes from age to birthdate! To be clear, source compatibility is still possible, but you need to do a lot more work.

The current approach to destructuring is also at odds with abstraction. If we turned Person into an interface, previous instances of destructuring would no longer be valid. We could work around this by introducing our own component functions, but this is usually seen as advanced. As a result, most interfaces do not provide such facilities.

interface Person {
  val name: String
  val age: Int

  operator fun component1(): String = name
  operator fun component2(): Int    = age
}

These problems go away if destructuring depends on names instead of positions. It doesn’t matter if you rearrange the order, change a computed property into a primary one or vice versa, or define a property in a class, interface, or object. The property’s name is a stable characteristic, which means that the source does not require any changes.

The new syntax

You can enable the new syntax by passing -Xname-based-destructuring=only-syntax as a compiler argument.

Without further ado, let’s look at the new syntax, which uses names for destructuring. Instead of a single val outside of the parentheses, you use val for each property inside the parentheses.

fun isValidPerson(p: Person): Boolean {
  (val name, val age) = p
  return name.isNotEmpty() && age >= 0
}

As expected, the order in which we write val name and val age in the example above doesn’t matter. This new syntax also supports renaming for cases in which the new variable you want to define is not the same as the property you want to access.

fun isValidPerson(p: Person): Boolean {
  (val age, val theName = name) = p
  return theName.isNotEmpty() && age >= 0
}

Destructuring based on position is still important for a few use cases. Pairs and triples, for example, don’t have names for their components at a conceptual level, and there’s no intention to require littering code that uses them with first and second. Position-based destructuring can also be used for collections, and in that case, there are no available properties. The new syntax for position-based destructuring uses square brackets – mirroring the syntax of upcoming collection literals. You can choose whether to put val inside or outside the brackets.

fun isZero(point: Pair<Int, Int>): Boolean {
  val [x, y] = point      // one way
  [val x, val y] = point  // or another
  return x == 0 && y == 0
}

All of this new syntax is available anywhere you can destructure, including lambda expressions and loops.

// suggested new syntax for iterating through a map
for ([key, value] in map) {
  // work with each entry
}

person?.let { (val name, val years = age) -> "$name is $years years old" }

To reiterate: This is all new syntax. As of version 2.3.20, the compiler knows what it means, and we intend to keep this syntax once the feature reaches Stable status.

Repurposing parentheses

At some point in the future, we intend for all destructuring using parentheses to be name-based. You can actually experience this future now by using the -Xname-based-destructuring=complete compiler argument.

If you already have a project, though, making the switch could have a major impact. The most visible issue would be if destructuring stops working, and the code needs to be updated. A more dangerous one would be destructuring declarations that remain valid but change the meaning.

For that reason, the compiler ships a migration helper under the -Xname-based-destructuring=name-mismatch compiler argument. When enabled, the compiler gives a warning in cases where the behavior is inconsistent between position-based and name-based destructuring or where the code won’t be accepted once destructuring with parentheses is no longer positional.

// accepted by both with the same behavior 
val (name, age) = person

// warning: accepted by both, but the behavior changes
val (age, name) = person

// warning: accepted only by position-based destructuring
val (personName, personAge) = person
// the IDE suggests potential fixes
// - renaming: (val personName = name, val personAge = age) = person
// - square brackets: val [personName, personAge] = person

The future

As hinted in this post, there will be ample time to migrate to the new name-based destructuring. Our current timeline looks as follows:

• As of version 2.3.20, name-based destructuring is Experimental, meaning that you need a special compiler argument to use it.
  • Support in IntelliJ IDEA may be lacking, especially for migration.
    
• With version 2.5.0 (at the end of 2026), the feature will become Stable.
  • The new syntax will be available without additional configuration.
  • The compiler will start reporting migration hints, and IntelliJ IDEA will include inspections and quick-fixes to help with the process.
  • This stage roughly corresponds to name-mismatch in compiler arguments, although we may make some adjustments to reporting depending on user feedback.
    
• By version 2.7.0 (at the end of 2027), destructuring with parentheses will be name-based.
  • You can migrate to this stage earlier by using complete in compiler arguments.
    

This is a big change, and we don’t want to rush it. If at any point during 2027 it becomes clear that the ecosystem is not ready, we may postpone the change until another major version.

At no point are we deprecating the generation of component functions for data classes. Data classes will still generate the same bytecode – name-based destructuring is a feature for use sites. However, we plan to introduce multi-field value classes without component functions. That means that destructuring for value classes will only be name-based.

References

• Release notes for Kotlin 2.3.20, the first version to offer name-based destructuring.
• Design document (KEEP) for the feature and corresponding public discussion.

Congratulations to the winners:

• Mentor: Ruslan (yet300)
• Mentee: Clare Kinery (kinerycl)
• Project: bitchat-android

Ruslan’s and Clare’s collaboration focused on the Android client of BitChat, where Clare contributed UI and UX improvements that brought the Android experience closer to platform conventions and enhanced overall polish and accessibility.

Clare submitted and merged two pull requests: PR #680 and PR #682. Her work improved BitChat’s voice note styling, camera and audio controls, dark/light theme support, visual hierarchy, and press interaction feedback.

Ruslan shared that Clare adapted quickly to the codebase and was able to work independently after the initial alignment. Their collaboration started with a kickoff call and continued asynchronously through chat and GitHub.

“Clare demonstrated strong problem-solving skills, attention to detail, and a solid understanding of UI/UX principles”, said Ruslan.

For Clare, the biggest takeaway was not just the code itself, but understanding the realities of open-source collaboration.

“As a developer who had never contributed to open source before, the biggest thing I learned was how open-source collaboration actually works. This program made it feel approachable and far less intimidating than I ever expected. I genuinely don’t think I would have taken that leap without it”, she commented.

Other participants

We received 80 mentee applications and 29 mentor applications – a clear sign of strong community interest in this kind of initiative, so we plan to continue the program.

For this pilot, we selected ten pairs. Eight remained active through the middle of the program, and four completed it successfully. These successful pairs contributed across different parts of the Kotlin ecosystem and Kotlin-related projects, including the Android UI, developer tooling, documentation, CI/CD, and multiplatform libraries.

We also want to recognize the other pairs who successfully completed the program:

Mentor: Mohamed Rejeb

Mentee: Kaustubh Deshpande

Project: Calf

Kaustubh contributed across several areas of the project, including dependency updates and CI/CD automation.

Mentor: Nikita Vaizin

Mentee: Anshul Vyas

Project: FlowMVI

Anshul fixed a bug in the metrics module and contributed to the migration guide that helps developers move from MVVM to FlowMVI.

Mentor: Adetunji Dahunsi

Mentee: Yu Jin

Project: heron

Yu Jin worked on improvements related to input handling and developer-facing issues, with a focus on making the project easier to use and maintain.

What we learned

Here are a few valuable takeaways from the participants’ feedback:

• Clear task scoping matters. Start with work that is concrete, manageable, and reviewable within the program timeline.
• Asynchronous mentorship can work well, but only when expectations are explicit, and collaborators align early on communication style, task size, and review cycles.
• The program creates value on both sides. Mentees gain confidence, workflow knowledge, and real experience. Mentors get fresh contributions, a chance to improve onboarding in their own projects, and a reminder that open source becomes healthier when maintainers make room for new contributors.

Thank you to all mentors and mentees who joined the first Kotlin Ecosystem Mentorship cohort! We’re especially grateful to the maintainers who opened their projects to newcomers and invested time in guidance, reviews, and support.

Congratulations again to Ruslan and Clare, who were selected in the KotlinConf trip prize drawing, and to all four pairs who successfully completed the program.

To stay updated on future programs, join the KEMP Slack channel. See you there!

Kodee-Approved Spotlight

KotlinConf 2026 is almost here

KotlinConf 2026 is just around the corner, and the excitement is definitely building. On May 20–22, more than 2,000 Kotlin developers from around the world will gather in Munich to share ideas, learn from each other, and connect. If you cannot make it in person, you can still join online – the conference will be livestreamed on the Kotlin YouTube channel. I’ll be there in Munich, but I definitely recommend tuning in to catch the key announcements and talks as they happen.

Join KotlinConf

Golden Kodee finalists

The Golden Kodee finalists have been announced! The top three nominees in each category will be invited to KotlinConf in Munich, where one winner in each category will receive a Golden Kodee award. It is a great way to celebrate people who share knowledge, organize events, inspire others, and help grow the Kotlin community.

Meet the finalists

Kotlin release updates

April brought two Kotlin release updates. Kotlin 2.4.0-Beta2 offers an early look at what’s coming next across the language, the standard library, the JVM, Kotlin/Native, and the compiler. Kotlin 2.3.21 focuses on performance improvements and bug fixes for the 2.3 release.

See what’s new in Kotlin 2.4.0-Beta2

IntelliJ IDEA 2026.1

IntelliJ IDEA 2026.1 brings improvements that many Kotlin developers will notice in their daily work. From general performance enhancements to better language and framework support, this release is a strong ecosystem update and an important part of the Kotlin developer experience.

Explore the release

Helping Decision-Makers Say Yes to Kotlin Multiplatform (KMP)

Adopting Kotlin Multiplatform is easier when the business value is clear. I found this guest post from Touchlab useful because it explains how KMP can improve delivery speed, reduce risk, and support long-term product strategy.

Read the post

KotlinConf’26 Speakers: In Conversation With Lena Reinhard

Ahead of KotlinConf’26, I found this interview with Lena Reinhard interesting because it explores what it means to build a career in tech today, especially when old promises no longer feel certain. It covers leadership, uncertainty, the productivity debate in the age of AI, and the human side of our industry.

Read the interview

Kotlin Professional Certificate by JetBrains on LinkedIn Learning

Looking to build your Kotlin skills? The Kotlin Professional Certificate by JetBrains is now available on LinkedIn Learning. In less than 12 hours, you can go through four courses, pass the final exam, and earn a certificate you can share on your LinkedIn profile.

Start learning

Koog updates for the JVM ecosystem

Koog had a busy month, and I found these two updates useful for JVM developers. First, Koog now offers an idiomatic Java API, making it easier for Java teams to build agent workflows. Second, Koog integrates with Spring AI, helping Kotlin and Spring-based projects use Koog in a familiar setup.

Explore Koog’s Java API

Kotlin + WebAssembly: `wasi:http` sample

I like this sample because it shows how to run a minimal HTTP server with Kotlin and WebAssembly using `wasi:http`. It highlights practical progress in Kotlin’s WebAssembly story and future backend possibilities.

See the sample

Amper 0.10.0

Amper keeps evolving quickly, and this update brings several useful improvements. Version 0.10.0 introduces automatic JDK provisioning, a Maven-to-Amper converter, support for custom Kotlin compiler plugins, and an improved IDE experience.

See what’s new in Amper 0.10.0

Spring Data JPA with Kotlin

I found this practical post worthwhile because it shows how Spring Data JPA works with Kotlin across entities, repositories, custom queries, and DTOs. It is useful for teams already using Spring.

Read the post

Spring guide: Uploading Files

This guide is helpful if you want to compare Kotlin and Java side by side. It makes it easier to see how Kotlin fits into existing backend workflows.

View the guide

Coroutines Guesser Game

Created by kt.academy, Coroutines Races Guesser Game offers an interactive approach to learning coroutine behavior by predicting what happens and when. It is a fun way to test your intuition.

Play the game

Where you can learn more

• Workshops – KotlinConf 2026, May 20–22, Munich
• Introducing the Skill Manager and Skill Repository
• Give AI Something Worth Amplifying: Three Priorities for Technical Leaders
• Using ACP + Deep Agents to Demystify Modern Software Engineering
• Prototype LLM calls on the JVM using Kotlin Notebook and LangChain4j in IntelliJ IDEA
• Next-Level Observability with OpenTelemetry
• Exposed now supports array types out of the box for PostgreSQL
• Using Spring Data JDBC With Kotlin
• Ktor 3.4.3 has been released
• Dokka 2.2.0 is out

YouTube highlights

• How KMP Helped a 378-Year-Old Company
• How Uber Uses AI to Move from Java to Kotlin
• Exposed 1.0 and Beyond | Talking Kotlin
• Best KMP libraries with Klibs.io

Kevin Kimani

Kevin Kimani is a software engineer and technical writer with over three years of experience in software development and documentation. He works across full-stack web development, database design, RESTful API development, and technical writing for engineer audiences. His writing focuses on clear API documentation, tutorials, and how-to guides that help developers understand and use products more easily.

GitHub | X.com

Repository with the companion code for the tutorial

Go to GitHub

As a developer, logging is usually the first technique that you reach for when something goes wrong in your application. You add a few log statements at the start and end of a function and in the exception handlers, and then you get a basic picture of what your application is doing. For simple services that run on a single instance, this approach is usually enough. You can just go through the log file, spot the error, and trace it back to its cause in just a few minutes.

But as your systems grow, that same approach doesn’t work. Logs start to pile up from multiple sources, executions interleave, and the error you’re looking at in the logs doesn’t provide enough information. You can clearly see the error, but you can’t trace it back to what caused it.

In this tutorial, you’ll learn how to move beyond basic logging by instrumenting a Kotlin and Spring Boot backend service with OpenTelemetry. You’ll learn how OpenTelemetry’s tracing model gives you the execution context that logs alone can’t provide. By the end of this guide, you’ll have a working instrumented service and a clear mental model for building more observable backend systems.

Why You Need Next-Level Observability

Modern backend systems are rarely linear. One operation might fan out to several downstream services, retry on failure, or execute concurrently across multiple instances and threads. All these patterns create opportunities for failure that might be hard to explain after the fact. When a background job that processes hundreds of records across overlapping executions errors out, your logs won’t tell you much. You won’t be able to explain which execution the error belonged to or whether the other executions succeeded or failed in the same way.

The lack of execution context creates a gap between seeing the error in your logs and actually understanding what happened leading to it. You just have the error message and a timestamp, but no way to connect it to the broader execution that it belongs to. In a system that runs multiple concurrent job executions, logs from different runs always interleave freely, and thread names get reused by the thread pool. Without a way to uniquely identify each execution, each line of text in your log file is an isolated fact without any reliable way to group it with others that belong to the same run.

Observability gives you a structured view of what your system did and in what order. It does this through traces, which are records of complete operations that contain unique identifiers. You can easily filter your logs by these trace identifiers, and you’ll be able to see the entire history of a specific execution clearly. Metrics add another dimension by revealing patterns over time that no single log entry can show. Together, they help to transform debugging from guesswork into a structured investigation.

What OpenTelemetry Provides

OpenTelemetry is an open-source observability framework that defines a unified model for collecting three types of signals from your applications:

• Traces: represent the full lifecycle of a request or an operation as it moves through your system. A trace is made up of spans, where each span represents a unit of work within the operation, such as an HTTP call or a background task. Each span contains a trace ID and a span ID as part of its context, where the trace ID ties back the span to its parent operation (trace) and the span ID uniquely identifies the single specific step within the operation.
• Metrics: capture aggregated measurements over time, such as how long an operation takes and the error rates. This helps to give you a statistical view of the overall system health.  
• Logs: represent discrete events that happened at a specific point in time. When correlated with trace context, logs stop being isolated entries in a file and become anchored events within a specific execution, which makes it easy to understand exactly what happened and why.
  

The OpenTelemetry ecosystem consists of three main components:

• Instrumentation
• The Collector
• Exporters
  

Instrumentation is how you integrate OpenTelemetry into your application. It uses language-specific SDKs that implement the OpenTelemetry API for creating spans, recording metrics, and propagating the context.

The Collector is an optional but powerful middleware component that defines the logic for receiving, processing, and exporting telemetry data to one or more supported backends.

The exporters are plugins that send your application’s telemetry data to a specific destination, such as Prometheus, Jaeger, or any other compatible backend.

What makes OpenTelemetry a valuable long-term observability strategy is its vendor neutrality. Before OpenTelemetry, instrumentation was tightly coupled to specific vendors, and switching always meant that you needed to rewrite your instrumentation code throughout the entire codebase. OpenTelemetry fixed this by separating the instrumentation from the destination. This means that you can now instrument your service once using the standard API and then change the exporters as your infrastructure and specific requirements evolve.

Repository with the companion code for the tutorial

Go to GitHub

Setting Up Next-Level Observability with OpenTelemetry

If you want to follow along with this tutorial, you’ll need the following:

• An IDE, such as IntelliJ IDEA.
• JDK 17 or later and Git CLI installed on your local machine.
  

Here is a rough architecture diagram of what you’ll build in this guide:

The application consists of a Spring Boot Service running in a single Java Virtual Machine (JVM). The Task Scheduler triggers the OrderSummaryJob at regular intervals. The job reads orders from an embedded H2 database via Spring Data JPA, processes them, and writes summaries back to the database. The OpenTelemetry Java Agent sits within the JVM, automatically instrumenting the job and injecting trace context into the Mapped Diagnostic Context (MDC). This context flows through the log output, allowing you to correlate all logs from a single execution when multiple executions run concurrently.

Now that you have the prerequisites and understand the system you will build, it’s time to get started.

Setting Up the Starter Template

To keep this tutorial focused on adding observability, we’ve prepared a Kotlin and Spring Boot application that runs a scheduled job every few minutes. Clone the application to your local machine by executing the following command:

git clone --single-branch -b starter-template https://github.com/kimanikevin254/jetbrains-otel-order-summary.git

Then, open the project in your code editor.

The most important file in this project is the src/main/kotlin/com/example/order_summary/service/OrderSummaryJob.kt, which defines the scheduled job. The job reads orders created in the last 24 hours from an H2 database via Spring Data repositories, processes them one by one, and writes summaries back to the DB. The job runs every five minutes using Spring’s @Scheduled annotation. The summaries generated by this job can later be consumed by other parts of a larger system, such as dashboards, analytic pipelines, or downstream services that need a periodic snapshot of order volume and revenue.

Since this tutorial’s main focus is on observability, let’s review the logging approach used in this job:

@Service
class OrderSummaryJob(
   private val orderRepository: OrderRepository,
   private val orderSummaryRepository: OrderSummaryRepository
) {
   private val logger = LoggerFactory.getLogger(OrderSummaryJob::class.java)

   @Scheduled(fixedDelay = 300000) // 5mins in ms
   fun generateSummary() {
       logger.info("Starting order summary job...")

       val periodEnd = LocalDateTime.now()
       val periodStart = periodEnd.minusHours(24)

       val orders = orderRepository.findByCreatedAtAfter(periodStart)
       if (orders.isEmpty()) {
           logger.info("No orders found in the last 24 hours. Skipping summary generation.")
           return
       }
       logger.info("Found ${orders.size} orders to process")

       var processedCount = 0
       var totalAmount = BigDecimal.ZERO

       for (order in orders) {
           try {
               logger.info("Processing order ${order.id} for customer ${order.customerId}...")

               // Simulate processing work
               Thread.sleep(2000)

               // Simulate occasional failures
               if (order.amount > BigDecimal("400")) {
                   throw RuntimeException("Order amount exceeds threshold: ${order.amount}")
               }

               totalAmount = totalAmount.add(order.amount)
               processedCount++
           } catch (e: Exception) {
               logger.error("Failed to process order ${order.id}: ${e.message}")
               // Continue processing other orders
           }
       }

       val summary = OrderSummary(
           totalOrders = orders.size,
           totalAmount = totalAmount,
           periodStart = periodStart,
           periodEnd = periodEnd
       )

       orderSummaryRepository.save(summary)
       logger.info("Order summary job completed. Total: ${orders.size} orders, Amount $totalAmount")
   }
}

As you can see, the logging approach is straightforward and very common. You log when the job starts, log each order being processed, log if an exception occurs, and log when the job finishes.

To see it in action, run the following command in your terminal:

./gradlew bootRun

Once the application starts, you can see the logs. Execute the command tail -f logs/order-summary.log in a separate terminal to stream the logs from the configured log file:

2026-02-24T15:49:47.304+03:00  INFO 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Found 12 orders to process
2026-02-24T15:49:47.305+03:00  INFO 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Processing order 1 for customer CUST-10001...
2026-02-24T15:49:49.306+03:00  INFO 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Processing order 3 for customer CUST-10003...
2026-02-24T15:49:51.307+03:00  INFO 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Processing order 7 for customer CUST-10007...
2026-02-24T15:49:53.308+03:00  INFO 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Processing order 8 for customer CUST-10008...
2026-02-24T15:49:55.308+03:00  INFO 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Processing order 9 for customer CUST-10009...
2026-02-24T15:49:57.310+03:00 ERROR 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Failed to process order 9: Order amount exceeds threshold: 458.23
...

2026-02-24T15:50:11.322+03:00 ERROR 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Failed to process order 19: Order amount exceeds threshold: 427.98
2026-02-24T15:50:11.340+03:00  INFO 605417 --- [order-summary] [scheduling-1] c.e.o.service.OrderSummaryJob            : Order summary job completed. Total: 12 orders, Amount 1680.31

The logs show clean, linear execution. Each step follows the previous one, and errors are easy to associate with the work being performed. This works well when the job runs infrequently, and only a single instance of the application is deployed. One execution completes before the next begins, so tracing failures back to their source is straightforward. For early-stage systems, this level of logging is sufficient.

Introducing Complexity

As a project evolves, two changes might occur:

• The business might demand near real-time visibility into the order metrics, which means that the job needs to run more frequently. Say, every five seconds instead of every five minutes.
• The application may be deployed across multiple instances for high availability.
  

Let’s start by running the job more frequently to see how this affects our current logging approach. To do this, open the src/main/kotlin/com/example/order_summary/OrderSummaryApplication.kt file and add the following line of code to the main application class:

@EnableAsync

This enables async execution. Remember to add the following import statement to the same file:

import org.springframework.scheduling.annotation.EnableAsync

Next, open the src/main/kotlin/com/example/order_summary/service/OrderSummaryJob.kt file and replace @Scheduled(fixedDelay = 300000) // 5mins with the following:

@Async
@Scheduled(fixedRate = 5000) // 5secs in ms

Changing from fixedDelay to fixedRate means the job starts every five seconds regardless of whether the previous execution has finished. Adding @Async ensures that each execution runs on its own thread from Spring’s task executor pool, preventing slow jobs from blocking the scheduler. This is a common pattern when scaling background jobs to handle higher throughput.

Remember to add the following import statement to the same file:

@import org.springframework.scheduling.annotation.Async

Restart the application and observe the logs. You should see something like this:

2026-02-24T16:17:40.469+03:00  INFO 610799 --- [order-summary] [task-1] c.e.o.service.OrderSummaryJob            : Starting order summary job...
2026-02-24T16:17:40.596+03:00  INFO 610799 --- [order-summary] [task-1] c.e.o.service.OrderSummaryJob            : Found 12 orders to process
2026-02-24T16:17:40.597+03:00  INFO 610799 --- [order-summary] [task-1] c.e.o.service.OrderSummaryJob            : Processing order 1 for customer CUST-10001...
...
2026-02-24T16:17:47.468+03:00  INFO 610799 --- [order-summary] [task-2] c.e.o.service.OrderSummaryJob            : Processing order 3 for customer CUST-10003...
2026-02-24T16:17:48.602+03:00  INFO 610799 --- [order-summary] [task-1] c.e.o.service.OrderSummaryJob            : Processing order 9 for customer CUST-10009...
2026-02-24T16:17:49.469+03:00  INFO 610799 --- [order-summary] [task-2] c.e.o.service.OrderSummaryJob            : Processing order 7 for customer CUST-10007...
2026-02-24T16:17:50.460+03:00  INFO 610799 --- [order-summary] [task-3] c.e.o.service.OrderSummaryJob            : Starting order summary job...
2026-02-24T16:17:50.472+03:00  INFO 610799 --- [order-summary] [task-3] c.e.o.service.OrderSummaryJob            : Found 12 orders to process
2026-02-24T16:17:50.473+03:00  INFO 610799 --- [order-summary] [task-3] c.e.o.service.OrderSummaryJob            : Processing order 1 for customer CUST-10001...
...
2026-02-24T16:17:54.476+03:00  INFO 610799 --- [order-summary] [task-3] c.e.o.service.OrderSummaryJob            : Processing order 7 for customer CUST-10007...
2026-02-24T16:17:54.608+03:00  INFO 610799 --- [order-summary] [task-1] c.e.o.service.OrderSummaryJob            : Processing order 14 for customer CUST-10014...
2026-02-24T16:17:55.460+03:00  INFO 610799 --- [order-summary] [task-4] c.e.o.service.OrderSummaryJob            : Starting order summary job...
2026-02-24T16:17:55.473+03:00  INFO 610799 --- [order-summary] [task-4] c.e.o.service.OrderSummaryJob            : Found 12 orders to process
2026-02-24T16:17:55.474+03:00  INFO 610799 --- [order-summary] [task-4] c.e.o.service.OrderSummaryJob            : Processing order 1 for customer CUST-10001...
2026-02-24T16:17:55.475+03:00 ERROR 610799 --- [order-summary] [task-2] c.e.o.service.OrderSummaryJob            : Failed to process order 9: Order amount exceeds threshold: 458.23

The logs are now completely interleaved. Executions from task-1, task-2, and task-3 are all running simultaneously, processing the orders, and logging to the same output. When an error occurs, like the failure on order 9 at 16:17:55, it’s not easy to figure out which job execution the log belongs to and which orders were successfully processed before the error occurred in that specific execution.

You might think searching by thread name, such as task-1, would solve this, but Spring’s thread pool reuses threads. After task-1 finishes its first execution, it picks up execution 9, then execution 17, and so on. Searching by thread name now gives you mixed logs from multiple unrelated executions. In production, where multiple application instances run behind a load balancer, thread names are no longer unique across your system.

This is where plain logging breaks down. You know and see that something failed, but you can’t explain what happened leading up to it.

A Better Solution: Adding OpenTelemetry

To address the missing execution context, let’s adapt the application to use OpenTelemetry for log correlation. The goal is not to analyze the performance or optimize the job, but to fix the issue of associating logs with their execution context. Each job execution will be treated as a logical unit of work. A unique trace ID will be attached to that execution, and all logs emitted during the job will include that ID. This way, even when multiple executions run concurrently, and your logs get interleaved, you can filter them by trace ID and see exactly what happened in a single run from the start to the end.

OpenTelemetry provides several ways to instrument applications. In this guide, we’ll use the Java Agent, which automatically instruments your application without requiring any changes to the source code.

Let’s start by downloading the agent JAR file. Execute the following commands in the project root folder to create a directory for the agent and download it:

mkdir -p agents
curl -L https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar \
-o agents/opentelemetry-javaagent.jar

Verify the download using the following command:

ls -lh agents/opentelemetry-javaagent.jar

You should see a file around 24MB in size.

Add the agents/ directory to your .gitignore file so that the JAR file is not committed to version control. You can use the command echo "agents/" >> .gitignore or add it manually.

Once you’ve confirmed that the agent was downloaded successfully, it’s time to configure it. You need to attach it to the JVM when running the application by passing it as an argument. Open the build.gradle.kts file and add the following configuration:

tasks.bootRun {
   jvmArgs = listOf(
       "-javaagent:${projectDir}/agents/opentelemetry-javaagent.jar",
       "-Dotel.service.name=order-summary-service",
       "-Dotel.traces.exporter=logging",
       "-Dotel.metrics.exporter=none",
       "-Dotel.logs.exporter=none"
   )
}

Here is what each argument does:

• -javaagent tells the JVM to load the OpenTelemetry agent before your application starts
• -Dotel.service.name sets the name of your service in the telemetry data
• -Dotel.traces.exporter=logging prints trace data to the console. No external backend is needed for this guide
• -Dotel.metrics.exporter=none and -Dotel.logs.exporter=none disable metrics and log exporting since that is outside the scope of this guide
  

Lastly, you need to update the log patterns to include trace context. The OpenTelemetry agent automatically injects trace_id and span_id into the logging context (Mapped Diagnostic Context). To display these values in your application logs, open the src/main/resources/application.properties file and add the following:

logging.pattern.console=%d{HH:mm:ss.SSS} [%thread] [trace_id=%mdc{trace_id} span_id=%mdc{span_id}] %-5level %logger{36} - %msg%n
logging.pattern.file=%d{HH:mm:ss.SSS} [%thread] [trace_id=%mdc{trace_id} span_id=%mdc{span_id}] %-5level %logger{36} - %msg%n

The %mdc{trace_id} and %mdc{span_id} directives extract values from the MDC that the agent populates automatically.

Now, let’s restart the application and observe the logs:

17:19:43.715 [task-1] [trace_id=da673f1ec49eba77264c5912584e7183 span_id=74c708e335a974e3] INFO  c.e.o.service.OrderSummaryJob - Starting order summary job...
17:19:43.856 [task-1] [trace_id=da673f1ec49eba77264c5912584e7183 span_id=74c708e335a974e3] INFO  c.e.o.service.OrderSummaryJob - Found 12 orders to process
17:19:43.857 [task-1] [trace_id=da673f1ec49eba77264c5912584e7183 span_id=74c708e335a974e3] INFO  c.e.o.service.OrderSummaryJob - Processing order 1 for customer CUST-10001...
17:19:45.860 [task-1] [trace_id=da673f1ec49eba77264c5912584e7183 span_id=74c708e335a974e3] INFO  c.e.o.service.OrderSummaryJob - Processing order 3 for customer CUST-10003...

...

17:19:53.704 [task-3] [trace_id=4a969bbb00634e0ee36b2fbda1399d8a span_id=0a602f1a58df2f71] INFO  c.e.o.service.OrderSummaryJob - Starting order summary job...
17:19:53.715 [task-3] [trace_id=4a969bbb00634e0ee36b2fbda1399d8a span_id=0a602f1a58df2f71] INFO  c.e.o.service.OrderSummaryJob - Found 12 orders to process
17:19:53.715 [task-3] [trace_id=4a969bbb00634e0ee36b2fbda1399d8a span_id=0a602f1a58df2f71] INFO  c.e.o.service.OrderSummaryJob - Processing order 1 for customer CUST-10001...
17:19:53.868 [task-1] [trace_id=da673f1ec49eba77264c5912584e7183 span_id=74c708e335a974e3] ERROR c.e.o.service.OrderSummaryJob - Failed to process order 9: Order amount exceeds threshold: 458.23

All logs from the first execution share the same trace_id (da673f1ec49eba77264c5912584e7183), while logs from the third execution have a different trace_id (4a969bbb00634e0ee36b2fbda1399d8a). Even though both executions are running concurrently and their logs are interleaved, you can now filter by trace ID to isolate a single execution.

For example, to see logs only from the first execution, you could search for trace_id=da673f1ec49eba77264c5912584e7183 in a log aggregation tool such as Amazon CloudWatch.

All the code used in this tutorial is available on GitHub.

Future Considerations

To make filtering even more powerful, you can update this logging strategy further by adding structured fields to logs for record IDs or job phases. For example, you could log order_id as a dedicated field alongside the trace ID, allowing you to query all executions that touched a specific order.

You can also export logs alongside traces to an observability backend like Jaeger or Grafana. This allows you to visualize the full trace as a timeline, showing how long each step took and where errors occurred. The OpenTelemetry agent supports exporting to multiple backends by changing the exporter configuration, so you can start with logging and migrate to a full observability platform later without making any changes to your instrumentation code.

You can also apply this same pattern to other background jobs, API handlers, or any asynchronous work in your system. Once OpenTelemetry is in place, every part of your application automatically benefits from trace context propagation, making it easier to debug complex workflows that span multiple services or components.

Conclusion

In this guide, you built a Kotlin and Spring Boot application with a scheduled background job, observed how plain logging breaks down under concurrency, and solved the problem by instrumenting the application with OpenTelemetry. You learned how the OpenTelemetry Java Agent automatically injects trace context into logs without requiring code changes, and how trace IDs enable you to correlate logs from a single execution even when multiple executions run concurrently.

Observability isn’t just about adding more logs; it’s about adding structure and context to the signals your system already emits. With OpenTelemetry, you can turn interleaved, confusing logs into isolated, queryable execution traces.

But the benefits go beyond debugging. Building systems with observability in mind changes how you design them. Traces reveal where boundaries should exist and help you set realistic timeouts based on actual production data. Metrics show trends over time, which make it easier to plan capacity, define SLOs, and alert on deviations before your users are affected. Additionally, well-instrumented code is more readable. When every operation is traced, you think more carefully about what constitutes a meaningful unit of work, which makes the system clearer for both observability tools and other developers.

Who it’s for

This certification is designed for developers with basic programming knowledge who want to pick up Kotlin and explore multiplatform development. Whether you’re coming from Java, Python, C, or another language, this program will give you insight into what Kotlin can do across the full development landscape. If you are a mobile developer who wants to stop writing things twice, a backend developer curious about Kotlin’s server-side capabilities, or a generalist who wants to ship on multiple platforms without fracturing your codebase, this is for you.

What the learning path covers

The certification includes four courses structured to guide you along an intuitive path:

Kotlin Essential Training: Functions, Collections, and I/O starts with the fundamentals – how Kotlin handles functions, how its collection APIs work, and how to interact with files and I/O, as well as core Kotlin syntax. If you are coming from Java, a lot of this will feel familiar but cleaner. If you are coming from elsewhere, this is where Kotlin’s expressiveness starts to click.

Kotlin Essential Training: Object-Oriented and Async Code goes deeper into OOP principles and asynchronous programming in Kotlin. The course introduces distinctive Kotlin features such as sealed classes, data classes, and extension functions, while showing how coroutines make async programming more readable. This course builds the foundation you need before getting started with multiplatform.

Kotlin Multiplatform Development teaches you how to write shared business logic once and deploy it across multiple platforms – mobile (Android and iOS), web, desktop, and backend. You’ll learn about the architecture that makes this possible, as well as how to structure a KMP project, what can and can’t be shared, and how to make the boundaries between platforms work for you rather than against you.

Exploring Ktor With Kotlin and Compose Multiplatform brings it all together. Ktor is JetBrains’ own framework for building asynchronous servers and clients in Kotlin; Compose Multiplatform extends Jetpack Compose to desktop and web. Together, they let you build full-stack applications with a genuinely unified approach. This course is the practical capstone – you leave with experience actually building something, not just learning concepts.

Access

The Kotlin Professional Certificate is available on LinkedIn Learning through a LinkedIn Premium subscription, which includes a one-month free trial for eligible users. Many organizations and universities also provide LinkedIn Learning access to their employees and students, and some public libraries offer free access with a library card as well, so it’s worth checking with your employer or institution.

The certificate

In total, the certification takes about 11 hours spread across the four courses. You’ll work in IntelliJ IDEA, the industry’s leading IDE, gaining practical knowledge that’s essential for your career. By the end, you’ll be able to build complete multiplatform applications from a shared codebase. 

Complete all four courses and pass the final exam to earn your Kotlin Professional Certificate by JetBrains. You’ll be able to download it, share it, and add it directly to your LinkedIn profile to showcase your Kotlin and multiplatform development skills to recruiters and hiring managers.

Let us know how you like the courses, and be sure to share your certificate and tag us on LinkedIn.

We’re excited to see what you build with Kotlin!

Justin Mancinelli

Justin Mancinelli is VP of Client Services at Touchlab, where he leads client services strategy and complex technical delivery. He partners with engineering leaders on mobile apps, SDKs, developer tooling, Kotlin Multiplatform, and Compose Multiplatform. With more than 13 years of experience helping software businesses succeed, he focuses on turning product and engineering goals into delivery.

LinkedIn

Samuel Hill

As VP of Engineering at Touchlab, Samuel Hill leads engineering strategy and supports teams building mobile products across Android and iOS. He works with engineering leaders on Kotlin Multiplatform, architecture, development standards, and team growth. With more than 13 years of experience in mobile engineering, he focuses on strong technical delivery and cross-functional collaboration.

LinkedIn

KMP is a strategic platform

In the current competitive landscape, the traditional mobile development model characterized by maintaining independent, duplicated codebases for iOS and Android is no longer a sustainable use of capital. This approach systematically introduces feature lag, technical debt, and a fragmented engineering culture that hinders organizational agility. For leadership, adopting Kotlin Multiplatform (KMP) must be viewed as a fundamental shift in capital allocation for mobile engineering.

KMP is not merely an incremental technical upgrade – it is a strategic platform that enables a unified engineering organization. By sharing high-value business logic while preserving native performance and UI integrity, KMP enables organizations to drastically reduce the total cost of ownership (TCO) of their mobile ecosystem. This transition transforms mobile development from platform-specific silos into a high-velocity engine that accelerates roadmaps, mitigates delivery risks, and secures a competitive advantage. As organizations increasingly integrate AI into their products, Kotlin Multiplatform provides a reliable, JVM-native foundation for building and deploying AI-powered mobile and backend services without introducing additional language or runtime complexity.

Quantifiable metrics for KMP adoption

Understanding the strategic impact of Kotlin Multiplatform for your organization starts with modeling potential cost savings, development velocity improvements, and risk mitigations. The following data, synthesized from enterprise-scale implementations and market leaders, provides an empirical foundation for proposing, budgeting, and planning your KMP adoption initiative.

Velocity and feature parity

KMP eliminates the feature lag that historically forces businesses to delay launching on the second platform and marketing departments to delay new feature announcements. In traditional siloed development, discrepancies in business logic and implementation speed between iOS and Android teams are inevitable. KMP solves this by enabling a single, verified implementation of business rules that serves both platforms simultaneously.

An engineer can build and test a new feature on one platform. Subsequent platforms then simply hook up the existing data models and logic from the shared KMP code to their native UI. This groundwork reuse ensures consistency from day one. 

Beyond immediate speed, this unified architecture promotes maintainability and de-risks incremental development across platforms. Future requirements, such as top-down enforced migration from one data, analytics, or streaming platform to another, are accelerated by building upon a stable, shared foundation that supports synchronized launches across the entire user ecosystem.

Organizational risk reduction

Adopting KMP is a primary driver for organizational risk reduction, enforcing a new foundation that prioritizes architectural discipline over the spaghetti often found in legacy mobile apps. By centralizing core business logic, organizations gain strategic agility that de-risks the technical roadmap. This architectural flexibility allows leadership to pivot across web and mobile ecosystems at a speed impossible when logic is trapped in platform-specific silos, enabling the engineering department to meet sudden market demands.

Consolidating complex calculations and business rules into a single source of truth fundamentally lowers the probability of systemic error. When logic is duplicated across disparate codebases, an organization implicitly accepts a doubled risk of regression and a fractured quality assurance cycle. KMP mitigates this operational hazard by ensuring that a single, verified enhancement or fix propagates across the entire product line, effectively slashing the technical debt and remediation costs that typically compound in traditional multi-platform environments.

Shared logic with KMP naturally mandates a clean separation of concerns, moving the organization away from fragile, UI-entangled code. The clear architecture empowers teams to achieve significantly higher automated test coverage, which removes the fear of the unknown that often plagues legacy systems. As the codebase becomes more predictable and less reliant on manual intervention, the organization achieves a level of stability where innovation can occur without the constant threat of destabilizing critical business functions.

Engineering culture and talent

The shift to KMP directly affects talent retention and internal mobility within the engineering organization. By moving away from platform-specific constraints, KMP allows teams to transition from isolated silos to a unified model where developers function as mobile engineers. This shift creates a more flexible and responsive technical workforce where engineering resources are allocated based on business priorities rather than purely on platform and language expertise.

Architectural alignment simplifies the codebase and clarifies the path to productivity for new hires. By maintaining a single logic layer instead of two separate implementations, organizations typically see a 30–50% reduction in onboarding time. Engineers can focus on mastering a well-structured system that minimizes technical debt and cognitive overhead often found in siloed environments.

Proven market validation

KMP has proven its benefit at world-class organizations that require stability and scale. The following companies have been Touchlab clients, or discussed their data publicly with Touchlab and JetBrains:

• Bitkey shares 95% of its mobile codebase with KMP and was able to tear down silos so that Android and iOS engineers became mobile engineers, picking up tickets no matter the platform
• Blackstone achieved a 50% increase in implementation speed within six months of code consolidation, sharing ~90% of business logic with KMP.
• Duolingo saved 6–12 engineer-months leveraging KMP to deliver iOS and Web implementations after the initial Android implementation. They spent five engineer-months to adopt KMP and deliver the iOS version of Adventures, then only one and a half engineer-months to deliver it to web, leveraging the same KMP codebase compared to 9 months for the initial Android implementation. 
• Forbes achieved significant savings in engineering time and effort by consolidating over 80% of logic across platforms, sharing ~90% of business logic in total.
• Google has been investing in and transitioning to KMP for several years, stating that KMP allows for “flexibility and speed in delivering valuable cross-platform experiences”. The Google Workspace team found that iOS runtime performance and app size with KMP were on par with those of the existing code.
• Philips effectively halved the time to develop features on both Android and iOS.
• An information security company re-targeted their mobile app to the web in three weeks for a press conference after a third-party vendor blocked the release of their mobile apps. Thanks to KMP, it was very easy to call the already implemented and tested code from JavaScript.
• A national media company built its KMP Identity SDK for use across brand apps on Android, iOS, and web, with a team half the size of that typically allocated for platform-specific projects.
• A world leader in tabletop gaming accelerated a multi-year mobile roadmap into a single quarter with KMP to meet the needs of explosive growth and demographic shift towards mobile users.
  

For more stories discussing real-world strategies, integration approaches, and gains from KMP, check out the Kotlin Multiplatform case studies collected by JetBrains.

Strategic recommendation

Kotlin Multiplatform is a future-proof architectural standard developed by JetBrains and supported by Google. It offers a low-risk, high-reward path for organizations looking to modernize their mobile strategy. Most organizations that adopt KMP for shared logic see a measurable ROI within three to six months.

The strategic recommendation is to initiate a pilot project focusing on pure business logic areas, such as calculations, data models, and business rules. With a conservative sharing potential of 75% in these areas, scaling KMP will allow your organization to eliminate redundant effort and transition toward a high-velocity, unified engineering future.

The Touchlab acceleration factor: While the long-term gains of KMP are inherent to the technology, expert guidance from experienced Kotlin Multiplatform practitioners, such as Touchlab, can help minimize the initial learning curve and accelerate adoption. Specialized assistance early in the adoption process prevents the trial-and-error phase that can stall pilot projects, ensuring the first success occurs quickly and the architectural benefits begin compounding immediately. When scaling challenges arise, Touchlab’s tools and experience take your KMP teams to the next level. Find out what Touchlab can do for you at https://touchlab.co.

• Multi-step strategies and workflows for more precise control.
• Persistence and checkpoints for fault-tolerant execution.
• Sophisticated history management for cost-optimization.
• Automated deterministic planning.

You can now get the best of both worlds. Koog offers seamless Spring AI integration and can be easily layered on top as a higher-level agentic runtime.

Spring AI

If you already use Spring AI, you’re familiar with its broad integration landscape: 13+ LLM providers, 18+ vector databases, and 10+ chat memory backends, all built seamlessly into the Spring ecosystem.

Your application likely already relies on some of these integrations and wasn’t built in isolation. But as your agent’s complexity increases and business requirements demand more reliability, you start needing things that sit above the integration layer, for example, controlled execution logic, guardrails, fault tolerance, and cost optimization. These are the problems Koog was built to solve.

The good news is you don’t have to choose one or the other, or dramatically change your existing setup to get there. Koog’s new Spring AI integration lets you keep your current LLM providers and databases exactly as they are, while writing your agents in Koog with minimal configuration changes. Your integration layer stays intact. Koog simply adds a powerful orchestration runtime on top of it.

Let’s take a look at how it works. This post uses a Kotlin and Gradle setup for simplicity, but you can also use the recently released native Java Koog API (and, of course, Maven).

Koog’s Spring AI integration

Let’s say your Spring project already uses three common Spring AI interfaces: ChatModel, ChatMemoryRepository, and VectorStore. Adding Koog on top is just a three-step process.

Step 1: Keep your existing Spring AI dependencies.

// LLM
implementation("org.springframework.ai:spring-ai-starter-model-openai")

// Chat memory
implementation("org.springframework.ai:spring-ai-starter-model-chat-memory-repository-jdbc")

// Vector store
implementation("org.springframework.ai:spring-ai-starter-vector-store-pgvector")

Step 2: Add the Koog integration dependencies.

// Koog
implementation("ai.koog:koog-agents-jvm:0.8.0")

// Bridges ChatModel to Koog's LLMClient / PromptExecutor
implementation("ai.koog:koog-spring-ai-starter-model-chat:0.8.0")

// Bridges ChatMemoryRepository to Koog's ChatHistoryProvider
implementation("ai.koog:koog-spring-ai-starter-chat-memory:0.8.0")

// Bridges VectorStore to Koog's KoogVectorStore
implementation("ai.koog:koog-spring-ai-starter-vector-store:0.8.0")

Step 3: Use the auto-configured Koog beans. Each Koog starter automatically exposes a Spring bean that wraps your existing Spring AI bean:

The beans are auto-configured by default when there is a single matching Spring AI candidate, so your existing Spring AI application config stays untouched.

That’s it for setup. Now let’s walk through what you can build. To make things concrete, we’ll use a customer support agent as our running example and progressively add capabilities.

When a pure Spring AI agent reaches its limit

One version of an agent that you could build in pure Spring AI would look like this:

@Service
class CustomerSupportService(
    chatClientBuilder: ChatClient.Builder,
    vectorStore: VectorStore,
    chatMemory: ChatMemory,
) {
    
    // Build a fully configured ChatClient once at construction time
    private val chatClient: ChatClient = chatClientBuilder
        .defaultSystem("""
            You are an e-commerce support assistant.
            Be concise and policy-aware.
            Never invent order data.
            If order context is missing for an order-specific request, ask for it.
        """.trimIndent())
        .defaultAdvisors(
            // Vector store RAG advisor – enriches every prompt with relevant docs
            QuestionAnswerAdvisor(
                vectorStore,
                SearchRequest.builder()
                    .topK(4)
                    .similarityThreshold(0.7)
                    .build()
            ),
            // Sliding-window chat memory advisor – keeps last N turns per session
            MessageChatMemoryAdvisor(chatMemory)
        )
        .build()
    
    suspend fun createAndRunAgent(userPrompt: String, sessionId: String): String? =
        chatClient.prompt()
            .user(userPrompt)
            // Scope memory to session
            .advisorParam(ChatMemory.CONVERSATION_ID, sessionId)
            .call()
            .tools()
            .content()
}

This agent implements a simple tool-calling loop that runs on top of the LLM defined in the config and inserted as a ChatClient. Besides this, the agent has two features. The first is QuestionAnswerAdvisor, which is built on top of VectorStore and behaves like RAG, enriching the conversation with relevant information from external docs. The second is ChatMemory, which keeps only a specified number of messages, helping you control the number of messages in a conversation and save tokens.

But what if we don’t want a window of messages but a message history summary instead? Or, increasing complexity, what if, instead of a primitive tool-calling agentic loop, we wanted a more controllable and tailored strategy with different e-commerce support scenarios, or persistence and durable execution to make our agent fault-tolerant? This is where we reach the limits of Spring AI. But these, and many other agentic features, already exist in Koog and, thanks to the integration, they can easily be built on top of what you’ve already set up for Spring AI in your project. 

What does Koog’s Spring AI integration enable?

First of all, this is what our e-commerce agent would look like in Koog.

@Service
class CustomerSupportService(
    private val promptExecutor: PromptExecutor,
    private val chatStorage: ChatHistoryProvider,
    private val knowledgeBase: SearchStorage<TextDocument, SimilaritySearchRequest>
) {

    suspend fun createAndRunAgent(userPrompt: String): String {
        val agentConfig = AIAgentConfig(
            prompt = prompt("ecommerce-support") {
                system(
                    """
                        You are an e-commerce support assistant.
                        Be concise and policy-aware.
                        Never invent order data.
                        If order context is missing for an order-specific request, ask for it.
                    """.trimIndent()
                )
            },
            model = OpenAIModels.Chat.GPT5Nano,
            maxAgentIterations = 100
        )

        val toolRegistry = ToolRegistry {
            tools(EcommerceSupportTools())
        }

        val agent = AIAgent(
            promptExecutor = promptExecutor,
            agentConfig = agentConfig,
            toolRegistry = toolRegistry,
	    // Simple tool-calling loop strategy
	    strategy = singeRunStrategy()
        ) {

            // Vector store RAG advisor – enriches every prompt with relevant docs
            install(LongTermMemory) {
                retrieval {
                    storage = knowledgeBase
                    searchStrategy = SimilaritySearchStrategy(
                        topK = 4,
                        similarityThreshold = 0.70
                    )
                    promptAugmenter = UserPromptAugmenter()
                }
            }

            // Sliding-window chat memory advisor – keeps last N turns per session
            install(ChatMemory) {
                chatHistoryProvider = chatStorage
                windowSize(20)
            }
        }

        return agent.run(userPrompt)
    }
}

With Koog’s Spring AI integration, the PromptExecutor bean is auto-configured from your existing Spring AI ChatModel. You inject it directly into your service – no boilerplate configuration class needed.

The same is true for the doc database and chat memory storage features. You don’t need to make any changes to the application config. With Koog beans, they are seamlessly injected into Koog’s LongTermMemory and ChatMemory and used under the hood.

What can you add on top?

Controllable type-safe workflows

Simple LLM loops lack predictability and control for enterprise scenarios. Each iteration is opaque. You can’t branch based on tool results, retry failed steps, or enforce specific conversation flows. For production support agents handling refunds, escalations, or multi-step verifications, you need explicit control over the execution path.

With Koog, in addition to using predefined strategies (such as default loop or ReAct), you can customize a strategy using graphs:

val agent = AIAgent(
    promptExecutor = promptExecutor,
    agentConfig = agentConfig,
    toolRegistry = toolRegistry,
    // Graph strategy, can accept and return anything!
    strategy = strategy<String, String>("ecommerce_support") {
        // Define graph here
    }
)

Instead of putting all of the instructions in a single naive text prompt, the best way to do this is to use structured output and then append an intent-specific prompt to it. This approach reduces the amount of context and gives you more control. 

@SerialName("SupportIntent")
@Serializable
enum class SupportIntent {
    ORDER_STATUS,
    CHANGE_ADDRESS,
    REFUND,
    OTHER
}

@Serializable
@LLMDescription("Normalized support request extracted from a user message.")
data class SupportRequest(
    @property:LLMDescription("Detected support intent")
    val intent: SupportIntent,

    @property:LLMDescription("Order ID if present, otherwise null")
    val orderId: String? = null,
)

val graphStrategy = strategy<String, String>("ecommerce_support") {
    // 1) Detect the intent of the request from user message
    val classifyRequest by nodeLLMRequestStructured<SupportRequest>(
        examples = listOf(
            SupportRequest(
                intent = SupportIntent.ORDER_STATUS,
                orderId = "84721",
                userRequest = "Check the status of order 84721"
            )
        )
    )
}

Once you know the intent, you can append intent-specific instructions or narrow down the required tools and delegate the task to a subgraph with a tool-calling loop:

val graphStrategy = strategy<String, String>("ecommerce_support") {
    ...
    // 2) Check that all request information is provided
    val checkRequest by node<SupportRequest, CheckRequestResult> { request ->
        when {
            request.intent == SupportIntent.OTHER ->
                CheckRequestResult(
                    request = request,
                    needsMoreInfo = true,
                    clarificationQuestion = "Specify the intent: order status, refund, change address?"
                ) 
            ...
            else ->
                CheckRequestResult(
                    request = request,
                    needsMoreInfo = false
                )
        }
    }

    // 3a) Process order status request in separate subgraph with additional prompt (or tools subset)
    val orderStatusFlow by subgraphWithTask<SupportRequest, String>(
        tools = EcommerceSupportTools().asTools()
    ) { req ->
        """
            Handle this request as an ORDER STATUS case.
            Use the order status tool and then answer the user clearly.
            Request: ${req.userRequest}
            Order ID: ${req.orderId}
        """.trimIndent()
    }

    // 3b) Process other intents
    ...
}

Finally, you can organize each step of your workflow into a graph using type-safe edges and conditions that control your agent’s behavior:

val graphStrategy = strategy<String, String>("ecommerce_support") {
    ...
    // Chain all nodes by edges
    edge(nodeStart forwardTo classifyRequest)
    edge(classifyRequest forwardTo checkContext 
        onCondition { it.isSuccess } 
        transformed { it.getOrThrow().data }
    )
    edge(classifyRequest forwardTo nodeFinish 
        onCondition { it.isFailure }
        transformed { "Failed to classify request." }
    )
    // If more information is required
    edge(checkContext forwardTo nodeFinish
        onCondition { it.needsMoreInfo }
        transformed { it.clarificationQuestion }
    )
    // If we know the intent
    edge(checkContext forwardTo orderStatusFlow
        // Add intent == SupportIntent.ORDER_STATUS condition for the transition  
        onCondition { request.intent == SupportIntent.ORDER_STATUS }
        transformed { it.request }
    )
    ...
    edge(orderStatusFlow forwardTo nodeFinish)
}

You have complete freedom to experiment and make the agent as complex as you need it to be.

Persistence (durable execution)

There’s complex logic at play, so you need to be extremely careful not to lose the execution point and state. And thanks to graphs, that’s possible. Just install and configure the Persistence feature, which will also use the data source from Spring!

@Service
class CustomerSupportService(
    private val dataSource: DataSource,
    ...
) {
    ...
    val agent = AIAgent(
        ...
    ) {
        // Make agent fault-tolerant using Koog's persistence.
        // The agent will recover from the exact graph node where it crashed
        install(Persistence) {
            // Configure where to store the checkpoints:
            storage = PostgresJdbcPersistenceStorageProvider(dataSource)
        }
    }
}

The persistence feature allows the agent to recover from the exact graph node where it failed and continue execution, which is essential for building reliable services.

History compression

Once you start scaling your AI agents to millions of users and longer-running sessions, managing LLM costs becomes critical. Each step of the agent’s execution, typically a tool call or an LLM request, adds to the message history, and every token has a price. Beyond cost, every model has a context window limit that’s easy to hit when processing large documents, handling tool outputs, or running extended sessions.

You don’t want to silently drop earlier messages when the window fills up. But you also don’t want to pay for irrelevant tokens or risk the model losing important context. Instead of dropping the history, you can replace it with a summary:

private fun AIAgentGraphContextBase.tooManyTokensSpent(): Boolean = 
    llm.prompt.latestTokenUsage > 1000

val graphStrategy = strategy<String, String>("ecommerce_support") {
    ...
    // Compress history node with compression strategy
    val compressLLMHistory by nodeLLMCompressHistory<String>(
        // Substitute every 5 messages with TL;DRs
        strategy = HistoryCompressionStrategy.Chunked(5)
    )
    // Do nothing node for navigation only
    val maybeCompressHistory by nodeDoNothing<String>()

    edge (orderStatusFlow forwardTo maybeCompressHistory)
    edge (maybeCompressHistory forwardTo compressLLMHistory 
        onCondition { tooManyTokensSpent() }
    )
    edge (maybeCompressHistory forwardTo nodeFinish 
        onCondition { !tooManyTokensSpent() }
    )
    edge (compressLLMHistory forwardTo nodeFinish)
}

After adding history compression into the strategy, our updated graph workflow for the  e-commerce agent would look like this:

Check out the full example in Kotlin or Java.

The bottom line

In this article, we saw how you can use Koog and Spring AI together to benefit from Spring AI’s model connections and database integrations, as well as the advanced production-focused orchestration layer from the Koog framework.

If you want to learn more about Koog, its product page is a good place to start, and if you have any questions or feedback, be sure to join the discussion on GitHub.

Finally, don’t forget to join #koog-agentic-framework on the Kotlin Slack (get an invite here).

Lena Reinhard, VP Engineering, leadership coach & mentor, facilitator, artist

Lena Reinhard is a VP of Engineering, a leadership coach, facilitator, and artist. In her 20-year career, she’s served in tech leadership roles, such as VP of Engineering with CircleCI, Travis CI, and as a SaaS startup co-founder and CEO. Now, she helps leaders and teams succeed in co-located and remote teams in organizations ranging in size from startups and scale-ups to corporations.

The tech industry has long promised opportunity, growth, and the chance to build things that reach millions of people. Today, many of those assumptions are being questioned. At KotlinConf’26, Lena Reinhard, leadership coach, former VP of Engineering, and the Day 2 keynote speaker, will explore these shifts in her talk We Were Meant to Be.

Ahead of the conference, we spoke with Lena about the uncertainty many people in tech are feeling today, the realities behind the productivity debate in the age of AI, and what leaders can do to support their teams through change.

As she prepares for KotlinConf ’26, Lena is documenting the process of shaping this keynote in a public work log, sharing the ideas and resources influencing her thinking. You can follow her progress here: The Making of: A Keynote on Tech, Humanity, Crisis, and the Future.

Q: In your keynote We Were Meant to Be, you touch on uncertainty, job insecurity, and how the tech industry is changing. What questions or experiences led you to create this talk, and what do you hope the audience sits with after hearing it?

Lena Reinhard: This is probably the question where I have the longest answer, because there’s a lot of history to this. And that’s also why I’m so excited to talk about it at KotlinConf in May.

My career is over 20 years old now. I actually started in finance, and very early on, the industry went through the 2008 financial crisis. So that was a weird way to start a career.

I’ve now been in tech for 16 years, and during that time I’ve seen many shifts in how the industry works. In the early 2010s, I worked a lot in open source. That’s really how I started my tech career, working with communities like CouchDB and some in the JavaScript ecosystem. Later, I shifted more into working with companies in Silicon Valley while still staying close to open source.

Over the last few years, I’ve worked more with leaders across different companies, from startups to large corporations to NGOs all around the world. That means my lens on the industry has changed over time, depending on who I’m working with and which aspects of the ecosystem I’m seeing.So throughout my career, I’ve spent a lot of time thinking about how technology works and what responsibility we have as people building it. In 2015, I gave the keynote A Talk About Nothing that encapsulated a lot of my thoughts at that point in time, and the question of our role as people building software and the responsibilities that come with that.

“The work we do has a lot of leverage, and the question is how we use that in a way that benefits not only us but also the people who use technology.”

Over the last four or five years, especially since generative AI really took off around 2022, I’ve noticed a lot of uncertainty among industry professionals.

People entered tech for many reasons: building products that reach millions of users, the opportunity for upward mobility, or simply the ability to experiment and create.

“Over the last three to five years, many of those things have been called into question. Software engineers, but also managers, are asking themselves, each other, and sometimes me, how career growth will work, or whether those careers will even exist in the same way. And that uncertainty has only been increasing, and the way that the discourse about this is playing out across the media, from podcasts and social media, to newspapers and “thought leaders,” isn’t helping that.”

At this point, I think people who claim to have definitive answers about what AI will mean for the global economy or for the tech industry, let alone for individuals and our careers, simply don’t have them. Those answers don’t exist at this point.

There are many hypotheses, and it’s important to stay open to them. But it also means that many of the promises that originally motivated people to enter this field are no longer as stable as they once felt.

Even the way people tinker with technology has changed. I know many programmers who used to build countless side projects in their spare time, and even that culture has shifted.

All of those questions and that uncertainty from the past few years ultimately led to this talk.

Q: You’ve written a lot about how to understand and improve productivity in engineering teams. (For example, your article How to Understand, Measure, and Improve Productivity in Your Engineering Team.) With AI becoming more present in our daily work, how do you think our ideas of productivity are shifting, or need to shift, for individuals and teams?

Lena: It’s a great question. And I think the two are very intertwined.

“One thing I often think about is that engineering productivity, and the discourse around it, has been a hot mess for a very long time.”

It’s always been a mix of the work people are doing, how meaningful that work is, and how productive that work appears from the outside.

For example, does your executive team think that you’re actually getting stuff done? And those can be very different things that don’t necessarily overlap.

So productivity has always been difficult for teams. I also don’t know of a company that has really figured it out well. It’s always somewhat ambiguous.

Now, with generative AI and coding assistants entering the picture, the conversation has become even more complicated.

“One big issue is that a lot of the current AI discussion is surrounded by hype and marketing messages that aren’t really backed up by solid data or real-world experience.”

At the same time, executives and senior leaders are often driven by pressure from their boards and investors. At this point, many leaders feel they can’t say, “We’re not doing AI,” because their investors will worry the company is falling behind.

So there are a lot of really messy incentives around this that engineering teams get caught up in.

Navigating that debate is difficult right now. It requires open conversations internally – with managers and teammates.My approach right now is that it’s important to talk about what productivity actually means and how it relates to the company’s goals. I recently wrote more about this in my article What AI Can (and Can’t) Do for Your Engineering Team (Beyond the Hype), where I look at some of the current limitations of AI and where it can actually be useful for teams.

“The goal can’t simply be to get as much stuff done and move as fast as possible. If what you’re working on doesn’t actually help the company achieve its goals, then being fast doesn’t get you anywhere.”

So the conversation should start with: what are our goals, how do we measure progress toward them, and how can AI actually help us get there?

For some teams, AI can be useful for experimentation. For others, it can help with debugging or act as a coding assistant in everyday workflows.

But the key is cutting through the hype and figuring out what is actually useful for your team and for the problems you’re solving for your users.

One thing that concerns me is that AI is already increasing the pressure on teams to produce more output.

I’m seeing discussions again where people think lines of code generated by AI are a useful productivity metric, which they are not. That’s a debate I thought we had already moved past about ten years ago.

At the same time, what I’m hearing from many teams is that people are simply working much more. Instead of working less, they’re working more hours because now, in addition to their regular job, they’re also expected to figure out how to integrate AI into their work, and the scrutiny on “productivity”, most commonly meaning “output”, not outcomes, is intense.

So my advice right now is to cut through the noise as much as possible. Don’t fall for the hype around just running as fast as possible. Focus on the goals: what your team is responsible for, how that connects to the company’s goals, and what meaningful progress and impact actually look like.

I talk about goals until the cows come home, because that’s what teams should ultimately be measured against.

Moving fast only matters if you’re moving in the right direction.

“One way I often describe generative AI tools is that they’re like an overly eager junior engineer who’s extremely confident.”

That kind of person can be great to work with, but they also require constant monitoring and guidance. It’s going to tell you stuff that’s just not true, not out of malice, of course, it doesn’t have a world model, and it’s important that we don’t anthropomorphize these tools. And it’s going to say it in a way that makes you think, “Oh yeah, that sounds great,” but actually it’s just nonsense. And that creates a lot of overhead and context switching. The mental load for teams right now is just much higher than it used to be.

That doesn’t mean the tools are useless. But they require a lot of handholding to produce useful results. They’re currently most useful for people with significant experience as software engineers who know what good software engineering looks like, how it works, and who can then utilize these tools well and productively. Where it gets tricky is that both the process of generation as well as the output look very good and convincing to the untrained eye. That’s where unhelpful discussions come in, like CEOs saying, “I vibe-coded this in two hours, why does our engineering team need this many people, and why are they producing so little? Also, I put my thing live just now.” That’s a tough position to be in.

Q: In your talk description, you say that many of the promises of tech careers have crumbled. From what you’re seeing and hearing, what still draws people to tech today – and how do you think that motivation might evolve?

Lena: Honestly, right now I find that question difficult to answer.

When I look at the people I talk to, and also at discussions in online forums for people who are just entering the field or participating in different communities, my impression is that many people are still drawn by the promises the industry used to offer – things like career progression and stable jobs; the same for building things, being creative, and solving problems.

Those ideas haven’t completely disappeared.

But at the same time, people are much more uncertain about how true those promises still are and how much they can and want to bet their ability to make a decent living on them. There’s a lot more doubt about whether those careers will still exist in the same way, or whether people should pursue something else.

So that uncertainty that’s affecting the entire industry is visible there as well.

And the noise-to-signal ratio is incredibly high. Like we briefly touched on earlier, the debate on social media, industry newsletters, at conferences, etc., also exists about “whether software engineering jobs will still exist in the future.” Those debates don’t really help, and again, no one has the answers.

Q: You work closely with leaders and speak a lot about leadership. For example, you explored the topic in your LeadDev talk on what we really mean when we talk about leadership. In periods of change and instability like the ones many teams are facing now, what do you think leaders most often underestimate about how uncertainty affects their teams?

Lena: One big piece is that leaders often have an information advantage.

Managers – and often technical leads and very senior engineers – are often briefed about changes long before their teams are. They are involved in discussions about reorganizations before they happen, or in creating a new technical strategy.

So they’re often part of shaping those changes, or at least they know about them well in advance.

“When leaders announce a change to their team, they’ve often already processed it. Mentally, they’ve moved on. But for the team, it’s completely new information.”

People need time to process it. They need time to understand what it actually means for them – how it will affect their day-to-day work, their role, how they get things done, or even what success will look like going forward.

I’ve often worked with leaders who become impatient at that stage. They wonder why people can’t just get on board immediately, or why there are so many questions.

But it’s important to remember that you may be in a very different place simply because you’ve had that information for much longer.

Giving people time and actually sitting down with them, explaining things, and listening to their questions requires effort, but it’s really important. Esther Derby, who started as a programmer and has written great books about agile work and handling change, likes to describe what leaders then tend to call “resistance” to change rather than a “response.” I wrote about dealing with these kinds of responses here.

Another pattern I see is that some leaders feel they need to have everything completely figured out before they talk to their teams.

But especially right now, there’s so much uncertainty inside companies and across the entire industry that none of us can really control it.

Things are changing quickly: companies are redesigning career frameworks, rethinking productivity measures, and trying to figure out what the future of work even looks like.

As a leader, you don’t always need to have everything figured out.

Sometimes it’s more helpful to simply acknowledge the uncertainty to say openly that things are chaotic or unclear right now.

That helps address the elephant in the room. It prevents people from feeling like something strange is happening behind the scenes, and it makes it easier to have open conversations.

Because the reality is that no one really has all the answers.

“Leaders often assume that their teams expect certainty from them. But in many cases, what people actually need is openness.”

Being able to say, “I don’t have all the answers, but I’m working through this with you,” is often much more useful.

And empathy matters as well.

Instead of projecting what you think people need, it’s important to sit down with them and understand what they actually need.

Because those two things can be very different.

Lena will explore these ideas in more depth in her keynote at KotlinConf’26.

Don’t miss Lena’s Day 2 keynote.

Kodee-Approved Spotlight

Kotlin 2.3.20 is out

A fresh Kotlin release always catches my attention, especially when it focuses on improving everyday development. Kotlin 2.3.20 brings bug fixes, performance improvements, and small but meaningful enhancements across the ecosystem. It’s the kind of update that strengthens the foundation and makes your day-to-day work more stable.

See what’s new

Kotlin Foundation Grants Program winners announced

Out of 117 applications, only five could walk away with a grant – and what a five. Firebase Kotlin SDK, Shadow Gradle Plugin, Mokkery, Stack Trace Decoroutinator, and Kobweb were selected to receive a USD 6,000 grant and recognized for their impact, technical quality, and real value to developers. I love seeing this kind of direct investment going to the tools that keep the whole ecosystem growing.

Meet the winners

KotlinConf’26 speakers: In Conversation with Josh Long

I loved this interview with Josh Long, Spring’s first developer advocate. He shares why Kotlin feels like a natural fit for Spring and how the JVM continues to be a strong platform for modern applications, including AI. It’s a great read if you’re working on backend systems or using Spring.

Read the interview

KotlinConf’26: Talks to help you navigate the schedule

KotlinConf’26 is almost here, and the full schedule is already live. With so many sessions across multiplatform, backend, AI, and language design, choosing what to attend can be a challenge. Take a look and start planning your agenda. Whether you’re building Kotlin Multiplatform (KMP) apps, scaling backend systems, or exploring AI in Kotlin, these sessions highlight where the ecosystem is heading and what you can apply in your own projects.

Plan your schedule

Android Gradle Plugin 9.0: What Kotlin developers need to know

Big changes are coming with the latest version of the Android Gradle plugin. In this video, Zac walks through what’s changing, why it matters, and how to upgrade your Kotlin projects with confidence.

Watch the video

Experimental Swift Package Manager support for KMP

Here’s something I’m excited about this month – Swift Package Manager support has landed in Kotlin Multiplatform as an experimental feature. You can now import iOS dependencies directly from Swift packages or migrate existing CocoaPods integrations. There’s even an AI-assisted skill to help with the conversion!

Try it out

IntelliJ IDEA’s new Kotlin coroutine inspections, explained

If you’re working with coroutines, this is a must-read. IntelliJ IDEA now features new inspections designed to catch common pitfalls and guide you toward safer, more reliable coroutine usage. It’s a subtle enhancement that can make a significant impact on your daily development.

Explore the details

Introducing Tracy: The AI observability library for Kotlin

Kotlin keeps growing in the AI space, and it’s just the beginning. Tracy is a new open-source observability library that helps you understand what’s happening inside AI-powered applications by tracking model calls, tool usage, execution time, and overall flow. No more guessing what your AI is up to.

Explore Tracy

Java to Kotlin conversion comes to Visual Studio Code

Kotlin is becoming more accessible outside of IntelliJ IDEA, too. We’ve released the J2K Converter extension, bringing Java-to-Kotlin conversion directly to VS Code. Just right-click any Java file and convert it in seconds. It’s powered by the same proven engine as our IntelliJ-based IDEs. I’ve already tried it – have you?

Download the extension

Building modular monoliths with Kotlin and Spring

When thinking about architecture, I often like approaches that balance simplicity and scalability. Modular monolith architecture allows you to split the application into isolated modules with their own business logic, while still being deployed as a single artifact. It’s a read!

Read the article

Love using Junie and Kotlin in your workflow?

The camera’s on, and I’m ready! We’re recording short interviews with Kotlin developers who use Junie in their day-to-day workflows. Selected clips will be featured in a compilation video shown at KotlinConf. Want to share your experience and be part of it? Fill out the short form below.

Sign up here

Where you can learn more

• Workshops – KotlinConf 2026, May 20–22, Munich
• Spring AI Kotlin Tutorials – Build AI-Powered Applications
• Google Summer of Code 2026 Is Here: Contribute to Kotlin
• Elevating AI-Assisted Android Development and Improving LLMs With Android Bench

YouTube highlights

• Explicit Backing Fields are experimental in Kotlin 2.3
• Kotlin Devs Diversify: Android Is 25% Now
• How Major Metros Run on Kotlin Multiplatform | Talking Kotlin #145

To get support for Amper’s latest features, use IntelliJ IDEA 2025.3.4  or IntelliJ IDEA 2026.1 (or newer). Make sure the latest version of the Amper plugin is installed. 

JDK provisioning

Amper needs a JDK (Java Development Kit) in order to perform various tasks in the project: compile Kotlin and Java sources, run tests, run JVM apps, etc.

Our philosophy is that you should be able to run your project without manually installing anything on your machine or having to configure anything. This is why Amper is able to provision a JDK automatically for you – JDK 21 by default. 

However, some projects require specific JDK versions. You can now specify the criteria for the necessary JDK in module.yaml, and Amper will download and install the matching JDK.

settings:
  jvm:
    jdk:
      version: 21 # major version
      distributions: [ zulu, temurin ] # acceptable distributions

Amper also takes the JAVA_HOME environment variable into account, since it is a common way to set the JDK to be used on the machine. You can read more about Amper’s JDK provisioning behavior in the documentation.

Maven converter and Maven plugin compatibility

If you have an existing Maven project, you don’t have to rewrite your build configuration from scratch. This release introduces a semi-automated conversion tool that reads your pom.xml files, including those in multi-module reactor projects, and generates the corresponding project.yaml and module.yaml files for you. To use it, simply run:

./amper tool convert-project

The converter maps your dependencies, BOMs, repositories, publishing coordinates, compiler flags, and other settings to their Amper equivalents. To support using both build systems during the transition, it sets layout: maven-like in every module so that your source directory structure, including src/main/java and src/main/kotlin, stays the same and no files need to be moved.

Well-known Maven plugins such as maven-compiler-plugin and spring-boot-maven-plugin are translated into built-in Amper settings. Other Maven plugins are added to the new mavenPlugins configuration section in module.yaml, and Amper can execute them during the build process through our Maven plugin compatibility layer.

The conversion is best-effort, so some projects may require tweaks afterward. For a full walkthrough and a list of limitations, see the documentation.

Kotlin compiler plugins

This release brings support for third-party Kotlin compiler plugins. Enabling this support is as easy as adding the following to module.yaml:

settings:
  kotlin:
    compilerPlugins:
      - id: org.example.my.plugin
        dependency: org.example:my-plugin:1.0.0
        options:
          myKey1: myValue1
          myKey2: myValue2

See the documentation for examples and how to enable IDE support for custom plugins.

We also added built-in support for the kotlinx.rpc and JsPlainObjects compiler plugins. 

IDE improvements

Reworked UX for running Amper commands

We’ve revisited the UI for creating and editing run configurations in the IDE. New custom views allow you to configure the options for run and test commands in a more convenient way:

Additionally, you can now create a configuration for any Amper command by choosing Amper in the Add New Configuration menu:

If you want to run a command in an ad-hoc way, you can use Run Anything (Ctrl+Ctrl) and prepend your command with amper:

Run gutters for native applications in module.yaml

Native applications (linux/app, macos/app, windows/app) can now be run from the IDE via the gutter:

Better test names in the Test tool window

The @DisplayName and @ParameterizedTest.name JUnit 5 annotations are now respected in the Test tool window when showing the test execution tree.

@ParameterizedTest(name = "Test #{0}")
@DisplayName("My parameterized test")
@ValueSource(ints = [1, 2, 3])
fun parameterized(i: Int) {}

Ktor plugin assistance

If your module has the Ktor server dependency, the module.yaml file provides support for searching and adding plugins via the Add Plugins… inlay:

Alternatively, you can use completion in the Kotlin code, which will add all the necessary dependencies to the module without you even having to touch the module.yaml file:

Support for profiling JVM applications

Note: This feature requires IntelliJ IDEA Ultimate.

The configuration for the run command in jvm/app modules can now be run using IntelliJ IDEA’s support for profilers:

Amper plugin development

The previous release of Amper brought the preview of Amper’s extensibility system. We received a lot of feedback, and we are working on extending the capabilities of plugins. While the ability to publish and share plugins is still a work in progress, a valuable improvement is already available in this release: you can now reference the module settings from the plugin using ${module.settings} in plugin.yaml:

Other improvements

Starting with version 0.10, Amper supports Maven profiles declared in the POM files of transitive dependencies.

In this release, we’ve also introduced the ability to add module descriptions in module.yaml. The description is formatted in Markdown and can occupy multiple lines. This text is used by the ./amper show modules command in the CLI, as well as by the IDE to show information about the module. For libraries, it is also used as a description in published metadata by default.

Updated default versions

We updated some of our default versions for toolchains and frameworks:

• Kotlin: 2.3.20
• Android minimum SDK: 23
• Compose: 1.10.3
• KSP: 2.3.6
• Ktor: 3.4.1
• Spring Boot: 4.0.5

Try Amper 0.10.0

To update an existing project, use the ./amper update command.

To get started with Amper, check out our Getting started guide. Take a look at some examples, follow a tutorial, or read the comprehensive user guide depending on your learning style.

Share your feedback

Amper is still experimental and under active development. You can provide feedback about your experience by joining the discussion in the Kotlinlang Slack’s #amper channel or sharing your suggestions and ideas in a YouTrack issue. Your input and use cases help shape the future of Amper!

Josh Long, Spring Developer Advocate

Josh Long is the first Spring Developer Advocate, starting in 2010. Josh is a Java Champion, author of 7 books (including Reactive Spring) and numerous bestselling video trainings (including Building Microservices with Spring Boot Livelessons with Spring Boot co-founder Phil Webb), and an open-source contributor (Spring Boot, Spring Integration, Axon, Spring Cloud, Activiti, Vaadin, and others), a YouTuber (Coffee + Software with Josh Long and his Spring Tips series), and a podcaster (A Bootiful Podcast).

The Spring ecosystem has evolved dramatically over the past decade, from traditional enterprise applications to microservices, distributed systems, and now AI-powered services. Few people have witnessed that evolution as closely as Josh Long, who has served as Spring’s first Developer Advocate since 2010.

Ahead of KotlinConf’26, we spoke with Josh about how the Spring community has grown, why Kotlin has become such a natural fit for Spring developers, and why he believes there’s never been a better time to build on the JVM.

Q: You were the first Spring Developer Advocate, starting in 2010. How has the community around Spring changed during that time?

Josh Long: Back then, most of the things people built were basically web applications. Nowadays, there are web services and backend server-side applications, and those applications are expected to do many more things.

So, the use cases that people introduce into their applications have grown. Before, Spring was very narrowly focused on the enterprise server-side world. Today, we talk about microservices, distributed computing systems, batch processing, integration, and all kinds of security.

And now we talk about AI.

These used to be different jobs and different career paths, but today they can all be done with Spring very naturally – quite elegantly in a lot of cases, compared to some of the alternatives.

So, the community has changed accordingly. The kinds of things people are doing have expanded, and the community around that has grown as well.

Put another way, it’s not that the people who were doing things in 2010 stopped doing those things. It’s more that people who were doing other kinds of work joined the community.

You see this represented in open-source projects, in language choices, Kotlin, for example, and across the whole ecosystem. It’s this wonderful open-source diaspora.

“The galaxy of things people need to do has grown, and so has the community.”

Q: As you mentioned, the Spring and Kotlin teams have worked hard to make sure that Kotlin and Spring Boot are a first-class experience. From your perspective, what makes a language truly first-class within a framework ecosystem?

Josh: Spring is a framework built on top of the JVM. Most of Spring itself is written in Java, because Java was the only language people used when we created Spring back in 2001.

But we’ve always tried to excel at integration. We want Spring to be a well-behaved citizen on top of the JVM and the languages that run on it.

If you’re a Java developer, we want Spring to feel natural and idiomatic. Someone who understands Java should look at Spring code and immediately understand what’s going on.

The same is true for all integrations. Spring works with dozens of libraries and technologies, and we want those integrations to feel coherent and consistent.

The same principle applies to languages.

“If we support a language, we want Spring to feel natural for people who already use that language. That’s definitely true for Kotlin.”

For the longest time, our goal was simply to be a good citizen on top of these languages. We didn’t expect the languages to adapt to us.

When the relationship between the Spring and Kotlin teams began developing more than ten years ago, we discovered that they were incredibly pragmatic and collaborative. They genuinely wanted Kotlin to work well for Spring developers.

That partnership has been a real honor.

One of my favorite examples is the Kotlin all-open plugin.

In Kotlin, classes are final by default. But frameworks like Spring and Hibernate rely on subclassing.

So normally you’d have to declare everything as open. The Kotlin team solved this by creating a compiler plugin. When you use Spring annotations, the classes are implicitly open behind the scenes.

Developers don’t have to change anything – if you go to start.spring.io, it’s already configured.

“It’s a thousand small changes like this that make it clear the language wants to make Spring developers feel comfortable. I feel warm, grateful, and happy thinking about this wonderful teamwork.”

Q: When you’re actually building a Spring application in Kotlin, where does it feel noticeably different from building it in Java?

Josh: Spring has DSLs. These DSLs are about as elegant as they can be in Java, but Kotlin has a much more expressive language for designing DSLs. That’s not a controversial thing to suggest – it’s just empirically true.

The Spring team has embraced Kotlin. We actually have Kotlin code in Spring itself. We’ve written parts of Spring in Kotlin.

There are several DSLs that we provide in Java that also have sister DSLs written in Kotlin, and those Kotlin DSLs are much nicer.

For example, Spring Cloud Gateway, functional HTTP routes, and the new BeanRegistrar API in Spring Framework 7. There are lots of them. Spring Security has one as well. They’re everywhere.

It’s just a really nice, elegant little language.

And we’ve essentially done the work of building DSLs twice – once for Java and then again in Kotlin – because we wanted the Kotlin version to feel nice and idiomatic and natural. It feels really good.

Q: For Kotlin developers who are new to Spring, what’s one misconception they often have, and what’s one feature that usually wins them over? For those who haven’t tried Kotlin yet but are big fans of Spring, why should they give it a shot?

Josh: I imagine the misconceptions those developers might have are the same ones anyone might have.

If you’re using Spring, you certainly don’t have to use just Java. Spring has always tried to embrace different languages.

“Kotlin is by far the best story we’ve had there.”

People may not realize this, but we had a Spring for Scala project about fifteen years ago. We also tried Groovy. You can still use Groovy today, although I personally never do.

Kotlin is just a really natural fit.

The only language where Spring has actually added that language to the Spring Framework itself, as part of the codebase, is Kotlin.

So, I use Kotlin all the time.

Q: You’ve spent years helping developers navigate new technologies. What excites you most right now about building on the JVM?

Josh: First of all, the languages we have on the JVM today are very competitive.

If you’re building something today, languages like Kotlin are just as concise, small, and efficient as many other modern languages. They’re easy to reason about, but they also come with a lot of additional benefits because they run on the JVM.

The JVM itself is incredibly fast and very scalable. It’s one of the few places where you can have a program that is both very small and very fast.

There used to be a kind of trade-off. If you wanted to write something quickly, you used a scripting language like Python or Perl, at least when I first started working. If you wanted performance, you used something like C++.

But now, with languages like Kotlin running on the JVM, you can have both. You can write programs that are as concise as scripting languages while performing close to native languages.

We live in an amazing time.

There’s a second part to this. Because we have this amazing runtime infrastructure and language ecosystem, people are building incredible tools and frameworks on top of it to support new kinds of applications.

For example, I spend a lot of time talking to people about AI. Spring AI is a really nice way to build AI integrations, agentic systems, and integrations with AI models.

“If you had told me 10 or 15 years ago that we would be writing five-line Spring applications in Kotlin that talk to AI models and do interesting things, I would have laughed. That would have sounded impossible. The world is very different now. There has also never been a better time to be a JVM developer or a Spring developer.”

Q: With rapid growth in AI-driven applications, what does building AI-powered systems on the JVM look like today, and where do Kotlin and Spring play a role?

Josh: I think people are sometimes misguided about AI.

When people talk about AI, they often mix up two very different use cases. 

One involves building and training models. That kind of work often uses tools that don’t really exist on the JVM today.

“Building your own models, training them, and doing data science is a very rare and a small use case compared to what 99% of the ecosystem will be doing, which is integrating these models into their business applications. Most of these models are just REST APIs, which means that this is an integration problem.”

For most applications, leveraging AI is about integrating those models into existing systems, and the JVM has always been extremely good at that.

That’s why enterprises use it – it can talk to anything.

Today, we have Spring AI, which makes it easier to build these integrations. Of course, there are other ecosystems on the JVM that have their own approaches to building AI-based applications.

There are lots of good options.

But the important thing is that the JVM is not just as good as something like Python or TypeScript for building these systems. In many cases, it’s actually much better.

There was a benchmark that came out recently looking at the performance of Model Context Protocol implementations. The JVM came out on top. Spring Boot and Spring AI had the best performance.

They compared implementations in Go, Python, and TypeScript, and the JVM performed the best.

So it’s not just a question of whether you can do this work on the JVM. In many cases, it’s much more performant. We also have better security and stronger integration with existing systems.

It’s a really big opportunity for developers in this ecosystem.

Another thing people often miss is that many AI projects fail because they don’t integrate properly with existing systems.

There was an MIT study that suggested something like 90% of AI integrations fail.

That’s not surprising – many teams build AI workflows as completely separate systems, often in Python, that don’t integrate well with the rest of their infrastructure.

But if you extend the systems where the business logic already lives, which is often on the JVM, things tend to work much better.

If you extend those existing services with tools like Spring AI and Kotlin, you’ll usually have a much better experience.

So it’s not just about being as good as other ecosystems. In many cases, the JVM is simply better for this kind of work.

As Josh notes, many new technologies, including AI, ultimately come down to how well they integrate with the systems developers already use.

Josh will dive deeper into how Kotlin and Spring Boot work together to create a cleaner, more productive developer experience in his KotlinConf’26 talk “Bootiful Kotlin.”

Don’t miss Josh Long at KotlinConf’26!

With parallel tracks, deep-dive sessions, and back-to-back talks, planning your time can feel overwhelming. When almost every session looks interesting, deciding where to spend your time isn’t easy.

To help you navigate it all, the Kotlin team has selected a few talks worth adding to your list. Whether you’re an intermediate or advanced Kotlin developer looking to sharpen your expertise, part of a multiplatform team solving cross-platform challenges, building robust server-side systems, or exploring AI-powered applications in Kotlin, these are sessions you might want to check out.

Want more than talks? Start with hands-on practice

If you prefer learning by doing, consider starting KotlinConf with a full-day hands-on workshop on May 20. Workshops are small-group, code-focused sessions where you can go deeper into topics like Kotlin Multiplatform, coroutines, backend, AI, and more.

Some workshops are already sold out, and others are filling up fast.

Intermediate 

These talks are perfect if you want to build on your foundations, understand where Kotlin is heading, and sharpen practical skills you can apply in your day-to-day work.

Evolving Language Defaults

Michail Zarečenskij

Kotlin Lead Language Designer, JetBrains

Programming languages are shaped by their defaults – what’s safe, convenient, and practical. But defaults evolve, and yesterday’s good idea can become today’s source of friction. This session explores how languages rethink and change their defaults, including mutability, null-safety, and deeper object analysis. With examples from C#, Java, Swift, Dart, and Kotlin, you’ll gain insight into how Kotlin continues to evolve and what those changes mean for everyday development.

Real-World Data Science With Kotlin Notebook

Adele Carpenter

Software Engineer, Trifork Amsterdam

Data is messy, and drawing the right conclusions takes more than generating a pretty chart. In this practical session, Adele will walk you through analyzing a real-world powerlifting dataset using Kotlin tools. You’ll explore how to understand and validate data, work with Postgres and DataFrame, and visualize results with Kandy – all directly from your IDE. It’s a hands-on introduction to doing thoughtful, reliable data science in Kotlin.

Talking to Terminals (And How They Talk Back)

Jake Wharton

Android Developer, Skylight

Modern terminals can do far more than print text. In this deep dive, Jake explores how command-line apps communicate with terminals – from colors and sizing to advanced features like frame sync, images, and keyboard events. Using Kotlin, he covers OS-specific APIs, JVM vs. Kotlin/Native challenges, and reusable libraries that help you unlock the full power of the terminal.

Dissecting Kotlin: 2026

Huyen Tue Dao

Software Engineer, Netflix
Co-host, Android Faithful

Ten years after Kotlin 1.0, the language continues to evolve quickly. This talk examines recent stable and preview features, unpacking their design and implementation to reveal what they tell us about Kotlin’s direction. You’ll leave with a deeper understanding of how the language is shaped and how those insights can influence your own Kotlin code.

Full-Stack Kotlin AI: Powering Compose Multiplatform Apps With Koog and MCP

John O’Reilly

Software Engineer, Neat

This session explores how Koog can power the intelligent core of a Compose Multiplatform app. This session demonstrates building AI-driven applications using local tools across Android, iOS, and desktop, connecting to an MCP server with the Kotlin MCP SDK, and integrating both cloud and on-device LLMs. It’s a practical look at bringing full-stack AI into real Kotlin applications.

Advanced

Ready to go deeper? These sessions dive into compiler internals, language design, architecture, and performance, making them ideal for experienced developers who want to explore Kotlin beneath the surface.

Metro Under the Hood

Zac Sweers

Mobile Person, Kotlin

Metro is both a multiplatform DI framework and a sophisticated Kotlin compiler plugin. This advanced session breaks down how Metro works inside the compiler, what code it generates, and how its “magic” actually happens. If you’re comfortable with DI frameworks and curious about compiler-level mechanics, this is a rare behind-the-scenes look.

Local Lifetimes for Kotlin

Ross Tate

Programming-Languages Researcher and Consultant

What if Kotlin could enforce that certain objects never escape their intended scope? This talk introduces a proposed design for enforceable locality – lightweight, limited-lifetime objects that prevent leaks and enable safer APIs. Beyond bug prevention, locality opens the door to advanced control patterns, effect-like behavior, and strong backwards compatibility, all while integrating cleanly into today’s Kotlin ecosystem.

Advanced Kotlin Native Integration

Tadeas Kriz

Senior Kotlin Developer, Touchlab

Kotlin Multiplatform native builds come with a key constraint: one native binary per project. This session explores what happens when multiple binaries enter the picture, the architectural impact on large systems, and strategies for splitting compilation into manageable parts. It’s a practical look at scaling Kotlin/Native in complex, multi-repository environments.

Deconstructing OkHttp

Jesse Wilson

Programmer

Instead of showing how to use OkHttp, this talk opens it up. You’ll explore its interceptor-based architecture, connection lifecycle management, caching state machines, URL decoding, and performance optimizations. From generating HTTPS test certificates to extending the library in multiple ways, this session is a masterclass in reading and learning from high-quality Kotlin code.

Multiplatform

Kotlin Multiplatform continues to expand what’s possible across devices and platforms. These sessions showcase the latest advancements, real-world journeys, and forward-looking tooling shaping the cross-platform landscape.

What’s New in Compose Multiplatform: Better Shared UI for iOS and Beyond

Sebastian Aigner

Developer Advocate, JetBrains

Márton Braun

Developer Advocate, JetBrains

This session explores what’s new in Compose Multiplatform and how it continues to improve shared UI across iOS, web, desktop, and Android. You’ll get a hands-on look at recent platform advances, including faster rendering, improved input handling, richer iOS interop, web accessibility improvements, and a smoother developer experience with unified previews, mature Hot Reload, and a growing ecosystem. It’s a practical update on how Compose Multiplatform is becoming an even stronger choice for cross-platform UI.

If you’re interested in going deeper into Compose Multiplatform, there is also a hands-on workshop where you can build shared UI across platforms and work directly with architecture, state, and real-world app patterns.

Sony’s KMP Journey: Scaling BLE and Hardware With Kotlin Multiplatform

Sergio Carrilho

TechLead, Sony

Go behind the scenes of Sony’s six-year journey from an early, risky experiment with Kotlin Multiplatform to the global success of the Sony | Sound Connect app. From high-speed BLE and background execution to migrating from React Native to Compose Multiplatform, this talk explores technical trade-offs, stakeholder skepticism, and hard-earned architectural lessons. It’s a real-world story of betting on KMP early and scaling it globally.

Swift Export: Where We Stand

Pamela Hill

Developer Advocate, JetBrains

Swift Export aims to make calling shared Kotlin code from Swift more idiomatic and natural. This session looks at the current experimental state of Swift Export, demonstrates the transition from the old Objective-C bridge to the new approach, and highlights supported features, current limitations, and practical adoption guidance. By the end, you’ll be able to evaluate whether Swift Export is ready for your team.

Practical Filament – Reshape Your UI!

Nicole Terc

SWE, HubSpot

Discover how Filament, a real-time physically-based rendering engine, can bring dynamic visual effects into your Compose Multiplatform UI. Through practical examples, you’ll explore materials, shaders, lighting, and touch-reactive animations – all without diving too deep into low-level graphics code. It’s a hands-on introduction to building expressive, animated interfaces.

Kotlin/Wasm: Finally, the Missing Piece for a Full Stack Kotlin Webapp!

Dan Kim

Engineering Manager

With Kotlin/Wasm reaching Beta and supported in modern browsers, full-stack Kotlin is closer than ever. This talk walks through building a complete web app using Kotlin/Wasm, Compose Multiplatform, Coroutines, Exposed, and Ktor – unifying the frontend, backend, and database in one ecosystem. It’s a practical guide to building performant, fully Kotlin-powered web applications.

Server-side

Kotlin is increasingly used to power large-scale backend systems. These talks explore how Kotlin powers high-performance systems, large migrations, and mission-critical platforms in the real world. 

Prefer hands-on backend work? A KotlinConf workshop covers building high-performance APIs with coroutines and Spring Boot.

How Google.com/Search Builds on Kotlin Coroutines for Highly Scalable, Streaming, Concurrent Servers

Sam Berlin

Senior Staff Software Engineer, Search Infra, Google

Alessio Della Motta

Senior Staff Software Engineer, Search Infra, Google

Discover how Google Search uses server-side Kotlin and coroutines to enable low-latency, highly asynchronous streaming code paths at massive scale. This session explores Qflow, a data-graph interface language connecting asynchronous definitions with Kotlin business logic, along with coroutine instrumentation for latency tracking and critical path analysis. It’s a deep look at building “asynchronous by default” systems at massive scale.

Go Get It, With Kotlin: Evolving Uber’s Java Backend

Ryan Ulep

Tech Lead, Developer Platform, Uber

Uber introduced Kotlin into its massive Java monorepo to modernize backend development without disrupting scale. This talk shares how the JVM Platform team built the business case, addressed tooling and static analysis gaps, overcame skepticism, and enabled thousands of engineers to adopt Kotlin. It’s a practical story of large-scale language evolution inside a global engineering organization.

Kotlin Bet for Mission-Critical Fintech: Reliability, ROI, Risk, and Platform Architecture

Yuri Geronimus

Tech leader, Verifone

Adopting Kotlin in a payment platform is a strategic decision about risk, trust, and long-term ROI. This session examines how Kotlin was integrated into a global EMV/PCI ecosystem – from Android terminals to gateways – using null-safety, sealed hierarchies, and value classes to eliminate entire classes of production issues. You’ll see architectural outcomes, measurable compliance gains, and a practical framework for positioning Kotlin as a strategic bet in regulated industries.

AI

AI is rapidly becoming part of modern application development. If you’re exploring agents, LLM integrations, or AI-assisted coding, these sessions will give you both strategy and hands-on insight.

Eval-Driven Development: The Fine Line Between Agentic Success and Failure

Urs Peter

Senior Software Engineer, JetBrains certified Kotlin Trainer

Agentic systems introduce probabilistic behavior and real risk. This talk introduces Eval-Driven Development (EDD), an engineering-first approach to making AI agents reliable. Using Koog, you’ll see how to test agents at multiple layers, collect meaningful metrics, detect regressions, generate synthetic test cases with LLMs, and build continuous evaluation loops that prevent silent degradation in production.

Why Do Most AI Agents Never Scale? Building Enterprise-Ready AI With Koog

Vadim Briliantov

Technical Lead of Koog, JetBrains

Many AI agents fail when moving beyond demos. This session introduces Koog 1.0.0-RC and explains how its structured, type-safe architecture enables scalable, production-ready agents across JVM and KMP targets. You’ll explore cost control, strongly typed workflows, state persistence, observability with OpenTelemetry and Langfuse, and integrations across the Kotlin ecosystem – all focused on building agents that actually scale.

You can also explore these topics in a full-day workshop focused on building AI agents in Kotlin with Koog.

Increasing the Quality of AI-Generated Kotlin Code

Sergei Rybalkin

Kotlin, Meta

Improving AI-generated Kotlin code requires more than better prompts. This talk explores practical strategies, evaluation techniques, and lessons from advancing Kotlin code generation in real-world agents. You’ll learn how to measure quality, refine outputs, and apply tools and best practices that ensure reliability, readability, and maintainability, even as models continue to evolve.

Take it further with a workshop

If you want to go beyond talks and build things yourself, workshops take place on May 20, the day before the conference.

They’re hands-on, small-group sessions led by Kotlin experts — and seats are limited.

This is just a glimpse of the many great sessions waiting for you at KotlinConf’26. With dozens of talks across multiple tracks, the hardest part might simply be choosing which ones to attend. Don’t forget to dive into the full schedule, plan your agenda, and get ready for three days packed with ideas, insights, and conversations with the global Kotlin community.