JetBrains Research
Research is crucial for progress and innovation, which is why at JetBrains we are passionate about both scientific and market research
KotlinLLM is Going Open Source
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.
👉 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(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()
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 = 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.
Facts Only
JetBrains Research released KotlinLLM as an open-source project.
KotlinLLM is an IntelliJ IDEA plugin for Kotlin/JVM projects.
The software implements "Smart macros" that generate Kotlin source code.
The API includes two functions: asLlm(from, hint) and mockLlm().
The project is licensed under the Apache License 2.0.
Tests were conducted on an adapted Spring Petclinic Kotlin project and a "GitHub Beginner Issue Radar" project.
The GitHub project parsed data from 20 repositories containing over 30,000 issues.
Performance results for Petclinic showed a compilation/redefinition overhead of approximately 1% of total runtime.
The GitHub project achieved 0.89 recall on ground-truth beginner labels.
Repository contents include the plugin prototype, example projects, a KotlinConf 2026 talk recording, and a theoretical write-up.
Executive Summary
KotlinLLM is a research prototype designed to bridge the gap between static compiled languages and the flexibility of Large Language Models (LLMs). While LLMs are typically used during development for code generation or via slow, costly runtime API calls, this tool introduces "Smart macros" that delegate runtime logic to an LLM to generate actual Kotlin source code. This generated code is persistent, meaning it can be committed to version control and executed as plain Kotlin without further LLM intervention, reducing latency and increasing reproducibility.
The system was validated through two use cases: a Petclinic adaptation and a GitHub issue parser. Results indicate that persistent runtime evolution is feasible for Kotlin/JVM, though the authors acknowledge existing limitations. By transforming unstructured data into typed values or creating stateful test doubles automatically, the tool aims to provide an explicit, reviewable way to incorporate AI-driven logic into a statically typed codebase.
Full Take
This project represents a shift from "AI as a copilot" to "AI as a runtime compiler." By persisting LLM-generated logic as source code, it attempts to solve the non-determinism and latency inherent in real-time AI delegation.
The methodology relies on a small set of synthetic and adapted projects. A peer reviewer would likely flag the limited sample size and the lack of a diverse set of complex, production-grade edge cases. While 0.89 recall and 1% overhead are promising, the "current limits" mentioned suggest that the stability of this evolution process may vary significantly depending on the complexity of the input data and the reliability of the underlying model. The core claim—that runtime evolution is feasible—is supported by these specific instances, but scaling this to massive, multi-contributor codebases remains an open question.
If these findings hold, the primary implication is a reduction in "boilerplate" logic for data parsing and mocking, effectively treating the LLM as a sophisticated macro processor. However, this introduces a new risk: "ghost code" that is technically valid and reviewed, but whose original intent was synthesized by a model, potentially masking subtle logical hallucinations that a human developer would have caught if writing from scratch.
1. How does the system handle "regressions" where a newly generated Smart macro evolves into a state that breaks previously passing tests?
2. What is the minimum threshold of "ground truth" data required before a Smart macro becomes stable enough to be committed as permanent source?
3. Would this approach be more viable in a language with a more flexible runtime than the JVM?
The hypothetical attack pattern for such a narrative would be "The Innovation Halo," using a high-profile research brand and a "prototype" label to bypass rigorous skepticism about the reliability of AI-generated code. This content does not match that pattern; it is a transparent research disclosure providing the source code for independent verification.
Sentinel — Human
This text reads like a direct announcement or research summary from a technical development team, balancing conceptual vision with empirical results.