News

Built for Productivity: What the Data Finally Shows About Kotlin

Years of productivity-focused design are now visible in the data.

Pragmatism has been central to Kotlin’s design from day one. The language prioritizes the developer’s convenience and productivity over academic purity or feature ambition.

Developers describe working in Kotlin in a fairly consistent way: more time spent on what you’re trying to build, less time on ceremony. There are fewer rituals to satisfy the compiler, and less boilerplate to write before getting to the part that matters. For years, the interesting question was whether that effect would also be visible at scale.

Now there is data. A recent JetBrains Research study measured the wall-clock cycle from first edit to push across roughly 28 million examples. On comparable work, Kotlin developers spent about 15%–20% less time than developers working in Java.

That gap matters even more right now, as more code is written by AI agents and developers spend more of their time reading, reviewing, and verifying code. We’ll come back to this at the end.

Productivity by design: A short history

Pragmatism becomes concrete when you look at the features it produces. Here are five examples from more than a decade of language and ecosystem design decisions.

Data classes

Some patterns repeat in every codebase. Value objects, DTOs, message envelopes, and configuration records – Kotlin captures these shapes in a single declaration.

data class User(val id: Long, val name: String, val email: String)

There’s one line, value-like behavior, and minimal boilerplate. You get equality, hashing, structural destructuring, toString(), and a copy() constructor automatically. Adding a field doesn’t mean rewriting six methods by hand.

Null safety

Kotlin’s type system tracks whether a value can be absent, and the compiler refuses to let you ignore the question. A whole category of runtime failures becomes compile-time feedback.

val length: Int = user?.profile?.email?.length ?: 0

A nullable chain is expressed in one line, and the compiler verifies every step. Missing values surface at compile time, not later in production.

The small wins

A handful of features quietly remove friction at every call site. Smart casts eliminate redundant typing once a type check has already happened. Named arguments with defaults make configuration readable without builder ceremony. Trailing lambdas turn block-based APIs into something that reads like ordinary control flow.

Each one is small. Together, they shape what a typical function looks like:

fun createUser(
    name: String,
    role: Role = Role.MEMBER,
    email: String? = null,
) = transaction {                       // trailing lambda
    val user = Users.insert(name, role, email)
    if (email != null) {                // smart cast: email is now String
        sendWelcome(email.lowercase())
    }
    user
}

createUser(name = "Anton", role = Role.ADMIN)   // named args + default

Three features compound into one short, readable function.

Coroutines and structured concurrency

Async work in Kotlin reads like ordinary code. suspend functions look sequential but execute concurrently, and structured concurrency ties every async operation to the scope that started it – so nothing escapes and runs in the background unnoticed.

DSLs as a first-class idiom

Productivity didn’t stop at the language. The same syntactic decisions – trailing lambdas, extension functions, type-safe builders – also enable a culture of IDE-aware DSLs across the ecosystem: Gradle build scripts, Compose UI, Ktor routing, Exposed SQL, and HTML and JSON builders. Each is a configuration surface the compiler understands as native code, not a separate format to memorize. 

None of these is an isolated win. Each is the product of the same commitment to pragmatism. The rest of this post examines what that commitment looks like in aggregate.

The question stories couldn’t answer

Developers have described Kotlin this way for years: less ceremony and more time on the actual work. But description is not measurement. Whether the same effect would also show up in numbers, at a scale where one team’s opinion doesn’t dominate, is a different question.

Stories don’t scale, and self-reporting has known biases, including the obvious one: People who choose Kotlin want that choice to be justified. A quieter bias is that developers who tried Kotlin briefly and then went back may never be sampled. That’s the gap a study can close.

What the study found

In a recent study, the JetBrains Research team analyzed telemetry from IntelliJ IDEA Ultimate over a 20-month window, from November 2023 to June 2025, covering roughly 320,000 developers and 28 million development cycles. A cycle in this study is the wall-clock time from the first edit of a source file after a push to the next push on that file.

For small tasks (about ten minutes of editing), Kotlin cycles were on average about 15.7% shorter than Java cycles. For medium tasks (around half an hour), they were about 20.3% shorter. For large tasks (one and a half to two hours), they were about 15.1% shorter. In absolute terms, that’s a minute or two off a short fix, five to seven minutes off a medium one, and 15–20 minutes off a long one – repeated many times across a workday and a quarter. The same pattern held across task sizes and throughout the 20-month window.

The obvious questions are fair. Aren’t Kotlin and Java projects different sizes? Aren’t the developers at different experience levels? Aren’t some Kotlin teams just newer or better resourced than the Java ones they’re being compared to?

Significant effort went into ruling these factors out. The study compared the same developers before and after their migration from Java to Kotlin, against developers who stayed on Java over the same period – a longitudinal design that isolates the language change from team or project differences. Work was bucketed by task size, so the comparison did not pit a one-line tweak against a feature build. JDK version was used as a proxy for engineering culture, with the comparison run both with and without that control. The pattern held.

The full methodology – the longitudinal design, the controls, the validity checks, and the boundaries of what the study can and can’t claim – is in the JetBrains Research post. Everything from here on is how we, on the Kotlin side, read those results.

The bigger finding: Kotlin projects don’t slow down

A 15%–20% gap on individual tasks is real, but it isn’t the headline. The larger finding is in the trajectory. Looking at how the same kind of work changes shape over the lifetime of a project, the data tells a different story than the point-in-time numbers do.

In the study sample, Java projects slowed down over the 20-month window. Cycles became 9%–17% longer as codebases grew – across small, medium, and large tasks. The same pattern shows up in independent slices of the data: The longer a Java project ages, the more time the same kind of work takes. Kotlin projects barely showed that slowdown. Some Kotlin migrants even improved over the same period, working faster on comparable tasks at the end of the window than at the start.

This lines up with what we have heard for years from the maintainability side of the conversation:
Kotlin code is easier to maintain. You can come back six months later and still understand what you wrote. 

Until now, those reports lived alongside the productivity reports as separate observations. They increasingly look like the same finding from two angles.

Here is our reading of why this happens – explicitly ours, not a conclusion the study set out to prove. Kotlin code expresses intent more clearly than the equivalent Java code does. Types carry more information. Idioms are more uniform across teams and over time. Less of the work is encoded in patterns that the next reader has to reconstruct. 

If that’s the right interpretation, the trajectory result makes sense. A codebase that stays readable doesn’t accumulate the kind of friction that slowly turns a 10-minute change into a 15-minute one. The difference may not be noticeable on day one. But at scale, the compounding effect is undeniable!

What this means in the age of AI

As AI-assisted authoring and agentic workflows become more common, developers are spending more time reviewing, integrating, rejecting, and adjusting code than writing it themselves. Even on teams that haven’t adopted agents wholesale, this shift is changing the distribution of daily activities. More of the developer’s job is deciding whether that code belongs.

Two well-established facts sit side by side. First, developers spend most of their time reading code rather than writing it. The 80/20 estimate is industry folklore for a reason – it shows up in studies, in retrospectives, in any honest accounting of how a workday is spent. Second, on comparable work, Kotlin developers move through their cycles meaningfully faster than Java developers do.

The reasonable interpretation is that the time saved is reading time. Reading is where most of the time goes, and Kotlin appears to make that faster.

In agentic workflows, this is more important. Code review of an AI-generated change is reading. Verifying that a proposed implementation does what it claims is reading. Integrating it into an existing system is reading. Rejecting a bad suggestion starts with reading. The proportion of a developer’s week spent typing has been falling for two decades, and it’s plummeting now. Time spent reading and understanding is doing the opposite.

Languages that let you read faster – and trust what you read – are far more compelling for modern software development.

Kotlin also carries more static guarantees out of the box. Non-nullability is enforced at the type level. Type narrowing happens automatically once you’ve checked a type. Sealed hierarchies plus exhaustive when expressions can answer “Did the agent miss a case?” questions at compile time. The same features that make Kotlin code faster to read also make it faster to verify mechanically, by the compiler before review, and by the human reviewer thereafter.

That kind of safety really pays off when you didn’t write the code yourself.

The productivity edge in the data was real before AI, and how software development is changing could make that edge more important than ever. The day-one gap, the trajectory advantage, and the agentic workflow case all point in the same direction.

Takeaway

For developers: The team conversation that’s been running on intuition for years now has numbers behind it. The next time the question comes up about whether Kotlin actually pays off for a Java team, you can ground your answer in concrete data.

For technical leaders: The quantitative case for a new JVM service is now visible. The smaller day-one effect and the larger trajectory effect both work in your favor. The second matters most for anything you expect to maintain beyond a year.

Pragmatism produced a language whose payoff compounds with time – and matters more, not less, as the developer’s role evolves.

Links:

• JetBrains Research post – full methodology and caveats
• Kotlin for backend – frameworks, deployment, and migration paths
• Try Kotlin online – Kotlin Playground