JetBrains Open-Sources KotlinLLM Runtime Code Generator
JetBrains opened KotlinLLM to the public on July 28 as an IntelliJ IDEA research plugin for Kotlin/JVM projects. According to JetBrains Research, its Smart macros generate Kotlin source code for runtime scenarios that existing generated code cannot handle, then persist and hot-reload the update. The prototype exposes typed data conversion and stateful interface-mocking APIs.
JetBrains opened KotlinLLM to the public on July 28, releasing a research prototype that enables Kotlin/JVM applications to generate, persist, compile, and hot-reload Kotlin code in response to new runtime scenarios. The project is delivered as an IntelliJ IDEA plugin and introduces what JetBrains Research calls Smart macros: explicit Kotlin calls backed by generated Kotlin source code.
According to the JetBrains Research announcement, KotlinLLM is intended to delegate selected runtime logic to an LLM without making a model invocation part of every request path. When generated code does not cover a runtime case, the plugin can capture runtime values, invoke an LLM agent to create a narrow source update, compile that update, and hot-reload the affected class through the Java Debug Interface (JDI). The GitHub repository describes the generated behavior as ordinary Kotlin source that can be retained after generation.
Two public Smart macros
The current public API includes:
- •`asLlm<F, T>(from, hint)`, which converts an input of type F into a typed Kotlin value T, including data classes, enums, lists, and primitives.
- •`mockLlm<T>()`, which generates a stateful implementation of an interface T; its behavior can change based on the methods invoked during runtime interactions.
JetBrains' example uses asLlm to derive a GitHub API URL from repository input and to turn a response into a typed list of issues. The interface-oriented mockLlm API targets test-double-like behavior, according to the JetBrains post.
Generated source rather than repeated inference
The project's central design distinction is persistence. The repository states that KotlinLLM does not call a model on every Smart macro invocation. Instead, the LLM is used when the existing generated code cannot handle a scenario; successful behavior is subsequently stored in generated Kotlin files and later executions run that code directly.
InfoWorld, summarizing JetBrains' description, reports that the project addresses tradeoffs associated with direct runtime delegation, external agent workflows, and prior runtime-code-generation work focused on interpreted languages. JetBrains argues that direct calls can introduce latency, non-determinism, cost, and runtime dependence on an LLM service, while externally managed agent outputs can be harder to review, test, and ship with the application.
That architecture places generated logic inside standard software-engineering controls rather than retaining it solely in a model interaction or runtime session. According to JetBrains, generated source can be committed, reviewed, tested, distributed, and later reused as Kotlin code.
Prototype status and engineering questions
JetBrains labels KotlinLLM a research prototype, not a general-purpose production runtime. Its current scope is Kotlin/JVM and IntelliJ IDEA, and the public API is limited to the two Smart macros described in the project materials.
For teams evaluating comparable systems, persisting generated code changes the operational question from repeated inference quality to code provenance, review, test coverage, and rollback discipline. It can also reduce repeated model calls for cases already learned by the generated implementation. At the same time, runtime code generation and class hot-reloading introduce deployment and governance questions that differ from conventional build-time code generation, particularly around which runtime inputs trigger updates and how generated patches are validated before broader release.
KotlinLLM makes those generated artifacts inspectable Kotlin rather than opaque application state. Whether that approach is useful beyond research settings will depend on the reliability of scenario detection, the quality of generated narrow implementations, and integration with existing CI, code-review, and release controls.
Key Points
- 1JetBrains released a Kotlin/JVM prototype that generates Kotlin implementations for unsupported runtime scenarios, then persists and hot-reloads the resulting source.
- 2The public API combines typed conversion and stateful interface generation, making LLM-backed behavior explicit at Kotlin call sites.
- 3Comparable persistent-generation systems shift engineering emphasis toward source review, validation, provenance, and rollback rather than repeated inference alone.
Scoring Rationale
KotlinLLM offers an unusual runtime-generation architecture for Kotlin/JVM developers: LLM-produced code is retained as source rather than invoked repeatedly. Its research-prototype status and Kotlin-specific scope limit near-term broad adoption, but its approach is relevant to teams exploring governed agentic code generation.
Sources
Primary source and supporting public references used for this report.
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.
Try 250 free problems
