Kotlin Research

TL;DR

KotlinLLM is now public. It’s a research prototype for delegating runtime logic to an LLM from Kotlin code. Instead of calling an LLM on every request or running a separate agent, you can write an explicit Kotlin call. Its body is generated Kotlin source code, and that code is updated as your application hits new runtime scenarios.

👉 Check it out 

👉 KotlinConf 2026 talk

What is KotlinLLM?

KotlinLLM is an IntelliJ IDEA plugin for Kotlin/JVM projects. It adds a language feature we call Smart macros. A Smart macro is a regular Kotlin function call whose body is generated Kotlin code. The public API has the following two Smart macros:

• asLlm<F, T>(from, hint) converts an input of type F into a typed value T (data class, enum, list, or primitive). Use it to parse unstructured or semi-structured data into typed Kotlin values at runtime.
• mockLlm<T>() generates a stateful implementation of an interface T. Its behavior depends on which methods are called on it, so it works as a test double that you don’t have to write by hand.

// One level of abstraction higher: describe intent, let KotlinLLM fill in the logic.
val issuesApiUrl: String = asLlm(repoInput, hint = "GitHub API URL: get all issues, including closed")
val issues: List<Issue> = asLlm(response, hint = "Return all beginner-friendly issues for this repository")

The behavior comes from actual runtime usage rather than being fully specified before the program runs. The call site stays compact and explicit: a clear, keyword-like API over generated code.

The problem it solves

In software engineering, LLMs are during development, i.e. code completion, code generation, and program comprehension. Using an LLM at the runtime of a compiled application is less common, and the existing options have clear trade-offs:

• Direct runtime delegation (calling the model on every invocation) is slow, non-deterministic, and costly. It also makes the application depend on an LLM service at runtime.
• External agent workflows keep the generated logic outside the codebase, where it’s harder to review, test, and ship.
• Most prior work (e.g. byLLM, nightjar, Healer) targets interpreted languages like Python, not a compiled, statically typed language like Kotlin.

KotlinLLM is built around three properties:

• Explicit – the call site shows that a feature is LLM-backed, so it’s visible in code review.
• Persistent – generated behavior is saved as an ordinary Kotlin source, not kept only in the runtime session. It can be committed, reviewed, tested, and distributed like any other code.
• Portable – once generated, the code runs as plain Kotlin without the plugin. For scenarios that are already covered, there’s no further LLM call, so no added latency or cost, and the result is reproducible.

Does it actually work?

We tested the approach on two Kotlin/JVM projects:

• An adapted Spring Petclinic Kotlin – 18 asLlm call sites, 24/24 application scenarios completed after Smart macro evolution, with a 100% hot-reload success rate and compilation/redefinition adding ~1% of total runtime overhead.
• A synthetic “GitHub Beginner Issue Radar” – parsing real GitHub issue data across 20 repositories (30k+ issues), reaching ~0.89 recall on ground-truth beginner labels.

These results show that persistent runtime evolution for compiled Kotlin is feasible. The evaluation also documents the current limits.

We’re making it public 

KotlinLLM is open source under the Apache License 2.0. The repository contains:

• The IntelliJ plugin prototype and the stable Smart macro API.
• Runnable example projects (GitHub Issue Radar, an adapted Petclinic), including committed generated sources, so you can inspect what the LLM produced and run it as ordinary Kotlin.
• The KotlinConf2026 talk recording and the theoretical write-up with the full design rationale and evaluation.

Try it and tell us what you think 

KotlinLLM is a research prototype, so feedback is useful at this stage. A few ways to help:

• Start and explore the repo
• Try it on your own Kotlin/JVM project. Add the KotlinLLM.kt API file, launch with the Run with KotlinLLM executor, and let the Smart macros evolve. Setup steps are in the README. 
• Open issues for anything you run into: rough edges, unexpected LLM behavior, missing cases, or behavior you’d expect to be different.
• Send PRs with use cases. Real scenarios where asLlm/mockLlm work well – or break – are the most useful. New examples, target types, and agent tools are all welcome.

If you find a place where runtime logic delegation fits your code, open an issue. If you build something with it, send a PR.