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.

Why participate?

GSoC is one of the best-known programs for introducing new contributors to open-source development. By joining, you’ll work on a real project, get hands-on guidance from a dedicated mentor, earn a stipend, and come away with production experience. Last year’s contributors shipped work that is already being used by other developers, from a compiler-integrated Kotlin LSP to KMP support for Firebase AI. They wrote about how the program changed their perspective on open-source development – you can read their stories here.

This year’s projects:

• Kotlin Compiler Fuzzer (Kai) – Build a new, modular fuzzer for the Kotlin compiler from scratch. [Hard, 350 hrs]
• Swift-to-Kotlin interop (PoC) – Create a proof of concept for importing Swift APIs into Kotlin/Native. [Hard, 350 hrs]
• Tail call support in Kotlin/Wasm – Design and implement tail call support in the Kotlin/Wasm backend. [Medium, 90 hrs]
• Kotlin Education landscape report – Research and document how Kotlin is taught worldwide, creating reusable datasets and strategic input. [Medium, 175 hrs]

Browse all project details and contributor guidelines here.

Important dates:

• March 16 – Contributor application period opens
• March 31 – Application deadline
• April 30 – Accepted projects announced
• May 25 – Coding begins!

How to apply:

1. Explore the project ideas and pick one that interests you.
2. Join the #gsoc channel on Kotlin Slack to connect with mentors and ask questions.
3. Review the contributor guidelines and prepare a code sample.
4. Submit your application on the GSoC website by March 31.

Questions? You can reach us on Slack or gsoc@kotlinfoundation.org.

Not a student?

If you are an open-source maintainer or contributor but not eligible for GSoC, the Kotlin Ecosystem Mentorship Program may be for you. The current round is already underway, but we are likely to run another one – follow our announcements so you don’t miss it.

Join us this summer, we look forward to your proposals!

• Gradle: Compatibility with Gradle 9.3.0 and Kotlin/JVM compilation uses the Build tools API by default.
• Maven: Simplified setup for Kotlin projects.
• Kotlin compiler plugins: Lombok is Alpha and improved JPA support in the kotlin.plugin.jpa plugin.
• Language: Support for name-based destructuring declarations.
• Standard library: New API for creating immutable copies of Map.Entry.
• Kotlin/Native: New interoperability mode for C and Objective-C libraries.

For the complete list of changes, refer to What’s new in Kotlin 2.3.20 or the release notes on GitHub.

How to install Kotlin 2.3.20

The latest version of Kotlin is included in the latest versions of IntelliJ IDEA and Android Studio.

To update to the new Kotlin version, make sure your IDE is updated to the latest version and change the Kotlin version to 2.3.20 in your build scripts.

If you need the command-line compiler, download it from the GitHub release page.

If you run into any problems:

• Find help on Slack (get an invite).
• Report issues to our issue tracker, YouTrack.

Special thanks to our EAP Champions

• Alexander Nozik
• Benoit Lubek
• Bernd Prünster
• David Lopez
• Dayan Ruben
• Florian Schreiber
• Johannes Svensson
• Josh Stagg
• Łukasz Wasylkowski
• Rick Clephas
• Sechaba Mofokeng
• Yang
• Yuri Geronimus
• Zac Sweers

Further reading

• What’s new in Kotlin 2.3.20 documentation
• Kotlin 2.3 compatibility guide
• Kotlin EAP Champions
• What’s new in IntelliJ IDEA 2026.1

It works seamlessly with common Kotlin/LLM stacks (including OkHttp and Ktor clients, as well as OpenAI, Anthropic, and Gemini ones) while relying on OpenTelemetry under the hood. This architecture guarantees complete flexibility over your trace data, enabling both standard exporting to any compatible backend (like Jaeger, Zipkin, or Grafana) and direct integration with dedicated LLM engineering platforms like Langfuse and W&B Weave.

While full-fledged AI frameworks like Spring AI or Koog provide built-in observability, LLM calls must be made exclusively through their framework APIs to be traced, and they do not provide an easy way to trace the internal application flow. In contrast, Tracy helps you monitor LLM usage through API or HTTP client instrumentation. It also helps you unwind the timing of and causal relationships between AI components or internal AI-agent states by annotating Kotlin functions or blocks of code.

By making Tracy open-source, we invite you to help extend its functionality – whether by requesting new integrations for AI backends and API clients, or by submitting pull requests to implement them.

Components of AI observability and how Tracy helps

As engineers, whether we’re adding observability to an existing application or building a new one from scratch, we want to trace, store, and analyze the following:

1. LLM call metadata, including the API being called, the model, and its parameters. Optionally, we may want to track LLM inputs and outputs during development for debugging, while ensuring they are not traced in production.
2. Application logic flow that leads to and from LLM calls – where a certain call originates and which tools are involved.

Imagine a very simple LLM chat application that greets the user, employing tools to make the greeting more personal. Using the OpenAI client, the application code might look like this:

/** Interface for LLM tool */
interface Tool<T> {
   /** Tool call */
   fun execute(): T
}

/** Gets the current user's name from the system */
class GetUserName() : Tool<GetUserName.UserNameResult> { ... }

/** Gets the current date and time */
class GetCurrentDateTime() : Tool<GetCurrentDateTime.DateTimeResult> { ... }

fun main() {
   // Create OpenAI-client using environment variables
   val client: OpenAIClient = OpenAIOkHttpClient.fromEnv()
   ...
   val params = ResponseCreateParams.builder()
       .model(ChatModel.GPT_4O_MINI)
       .maxOutputTokens(2048)
       .addTool(GetUserName::class.java)
       .addTool(GetCurrentDateTime::class.java)
       .input(ResponseCreateParams.Input.ofResponse(inputs))
       .build()

   // Get the response. 
   // In a real application, it would use a loop to process tool calls.
   val response: Response = client.responses().create(params)
   ...
   println(finalGreeting)
}

The important things to trace here are:

1. The fact that the greeting agent was called.
2. The LLM calls.
3. The tool executions.

We could use the basic OpenTelemetry SDK, but that would require us to add instrumentation code manually, and it would lead to code repetition for tool call traces. 

In an ideal scenario, we would be able to configure tool tracing once and have all implementations traced automatically, ensuring we never end up in a situation where newly added tools go untraced. Tracy makes this scenario a reality.

Adding observability with Tracy

Tracy provides three high-level APIs that help us fully cover our chat application with tracing.

Scoped spans

The withSpan API allows you to create scoped spans. These spans automatically activate when a block starts and end when the block finishes, ensuring correct nesting and timing. 

fun main() {
   // Encapsulation into withSpan ensures that all nested events will be
   // traced as part of the greeting agent’s work.  
   withSpan("Greeting agent") {
       ...
   }  
}

LLM client instrumentation 

LLM calls are a crucial part of any AI agent. They define the cost, latency, and efficiency of the application, and they are the first things to be investigated if something goes wrong. That’s why adding observability to an LLM client should be straightforward and require minimal changes to the codebase. For example, adding instrumentation to your OpenAI client is as easy as:

val client = OpenAIOkHttpClient.fromEnv()
// All calls made with the instrumented client are traced.
instrument(client)

By default, client instrumentation traces metadata only. To trace LLM inputs and outputs, which may contain sensitive data, you must explicitly enable this programmatically with:

TracingManager.traceSensitiveContent()

Alternatively, you can enable it at runtime by setting the TRACY_CAPTURE_INPUT and TRACY_CAPTURE_OUTPUT environment variables to true.

Tool calls and function tracing

LLMs love tools: They help the LLMs effectively complete deterministic tasks, save tokens, and interact with the environment they operate in. As developers, we love tools as well, but adding observability for each and every LLM tool in the codebase is a mundane task that is easy to forget.

While decorators shine for such scenarios in Python frameworks, Kotlin developers previously could only look on with envy. Tracy changes things for the better. With annotation-based tracing, you simply have to add the @Trace annotation to an interface method to enable tracing in all implementing classes. If you have an isolated method you want to trace, it’s just as easy. The @Trace annotation works on individual methods or functions as well.

/** Interface for LLM tool */
interface Tool<T> {
   // All tool calls are now traced
   @Trace(name = "Tool Call")
   fun execute(): T
}

Bringing it all together

Capturing telemetry from the application is only half the battle. The other half is routing it to a proper backend where it can be stored and analyzed. While we definitely recommend using observability solutions that target LLM tracing specifically, and provide support for Langfuse and W&B Weave out of the box, Tracy also offers effortless ways to send traces to any OpenTelemetry-compatible backend, file, or console. The repository contains a number of examples, and the complete code for the example from this article is available here.

Configuring telemetry export to Langfuse takes seconds with Tracy. As a result, you get a hierarchical application trace with both LLM and tool calls captured.

What’s next

We truly believe that regardless of the pace of LLM progress in the coming years, observability will remain a cornerstone of effective and reliable AI engineering. No matter how good the underlying LLMs become, the applications using them must still be debugged and evaluated – both during development and in the field. We created Tracy in response to this demand, aiming to bring production-grade AI observability to the Kotlin ecosystem.

And we are just getting started! You can contribute to the growth of the Kotlin AI ecosystem by filing issues, submitting pull requests, or simply by trying Tracy in your projects and sharing your feedback. Let’s trace together!  

1. Explore Munich (before things get busy)

If you’re arriving before the conference, try to set aside some time to explore the city. Munich has great food, interesting neighborhoods, and plenty of places to slow down before the schedule gets busy.

Not sure what to see? Keep an eye out for my social media posts, I’ll definitely have some tips for you! ;-)

2. Skip the line. Register early

Standing in line on the first morning, half-awake and carrying a backpack, is not how you want to start KotlinConf.

Come to the venue the day before the conference kicks off on May 20 between 2:00 and 5:00 pm. You’ll avoid large queues, save time, and keep your energy for what really matters. And believe me, you’ll need it.

When you’re already checked in, you can walk in on Day 1, grab a coffee, find your seat, and focus on the talks instead of logistics. It’s a much better way to begin.

3. Start with a workshop

If you want to get even more out of KotlinConf, start with a full day of hands-on workshops on May 20.

• Build Shared UI With Compose Multiplatform.
• Go Deeper Into Kotlin Multiplatform Architecture.
• Master Coroutines and Asynchronous Programming.
• Build High-Performance Backends With Spring Boot.
• Create AI Agents in Kotlin.
• Refactor Toward Functional Kotlin.
  

Workshops are practical, focused, and led by Kotlin experts. You’ll leave with skills you can apply right away.

Seats are limited, so make sure to save yours before they’re gone!

4. Don’t miss the Keynote!

Join us for the opening Keynote to see the big picture. This is where we set the stage, introduce the year’s most ambitious ideas, and bring the entire community together. There is a specific energy to experiencing these reveals live – don’t settle for the recap.

5. Take a selfie with me

If you spot me somewhere around the venue, don’t hesitate, come over and say “hello”. 
A quick selfie, a short chat, a shared laugh in between sessions, whatever, I’m down!
I’m always happy to meet you, hear where you’re from, what you’re working on, and how KotlinConf is going for you. And who knows, you might even end up in one of my posts. Let’s create some memories!

6. Join the Coding Challenge

Engage in our Coding Challenge. It’s a good way to test yourself, learn something new, and see how you approach problems under a bit of pressure. It gets even more interesting when you are watching others code! And if you win? Well then, you’ve earned the right to brag a little.

7. Wander around the expo 

Don’t be shy, after you’ve met everything Kotlin, go out and meet some of our partners!
This is where companies, communities, and partners set up booths to connect with all of you!

See how Kotlin is used in practice, and talk directly with engineers. Ask some questions and discover new tools, libraries, and platforms. Of course, do some networking and meet other developers. And also, get some swag for yourself and colleagues back home, it’s always nice to have some souvenirs!

8. Go to the party

On the evening of May 21, put on your fancy clothes (maybe even your dancing shoes) and come to the party.

This is where you can reconnect with friends you haven’t seen in a while, continue conversations that started earlier on in the day, and meet new people along the way. Come for the music, stay for the conversations, and leave with a few more names in your contacts list!

9. Wake up early for Day 2

After a night of partying, I know waking up isn’t always the easiest. But you have another full day of learning ahead, starting from the Day 2 Keynote at 9:00 am, where Lena Reinhard will take the stage to set the tone for the day. Set your alarm, grab a coffee (no worries if you don’t have time for one: The team and plenty of coffee will be waiting for you at the venue), and head down to the conference. You’ll be glad you did. 

10. Learn something new (and eat well)

The main reason you’re here is to learn – new tools, ideas, or ways of thinking.
Take notes, ask questions, and give yourself time to reflect. And don’t forget to eat. Good food keeps you focused and energized, and don’t worry, KotlinConf has plenty of delicious eats on offer!

11. See the future! 

Make a wish, write a prediction, and place it in a time capsule. We’re going to open it and reveal what’s inside in 2031, so you’ll have to be patient and wait a bit to see if you were right! 

12. Take part in the games

After all the learning and networking, it’s always good to relax. Use what you’ve just learned and play a game built with Compose Multiplatform for web, with a chance to win a prize. If I were you, I wouldn’t miss this! 

13. Attend the Golden Kodee Awards

The Golden Kodee Awards celebrate individuals and communities who make a real impact by sharing knowledge, organizing events, and inspiring others. This year is special, because 2026 marks the very first time these awards are being presented.
 It’s a chance to recognize outstanding contributors and thank them for everything they do. And let’s be honest, gold looks great on me, don’t you agree?

14. Don’t forget to take a photo with me!

Did I already mention that?

15. Leave feedback and vote

Vote for all the sessions you attended. Leave your comments in the app about the talks. Reach out to us – don’t be shy, your feedback means a lot. We want to provide the best possible experience. The next KotlinConf might be even better than this one!

+ 16. Mark your calendars

Before you head home and dive back into your inbox, take a moment to mark the dates for next year’s KotlinConf. It’s a small step, but it makes sure you won’t miss it once work gets busy.

I already miss you all, so let’s make sure we meet again next year.