Kotlin 2026: Layoffs, AI, Google — Is the Golden Age Over? Jake Wharton Explains

Jake Wharton discusses Kotlin's evolution, his employer-selection values, AI adoption, and the responsibilities that come with building on open source. His recurring engineering concern is what happens after code is written: maintaining it, adapting it to changing requirements, and keeping control of the tools and dependencies it relies on. 53:30–56:42(opens in a new tab), 1:53:51–1:58:11(opens in a new tab)

This summary uses the video's English auto-generated captions, which contain name and technical-term transcription errors; it is not an original-audio verification. Wharton explicitly says he has never written code with AI agents. His AI arguments are a values-based critique and forecasts, not a hands-on tool evaluation or productivity study. 47:17–50:32(opens in a new tab)

AI adoption, autonomy, and maintenance

• Tool choice should follow engineering requirements. Wharton contrasts bottom-up enthusiasm for Kotlin and IDEs with executives mandating LLM usage. His objections combine autonomy, training-data ethics, and layoffs; he also acknowledges that his financial position lets him reject employers in ways others cannot. His ethical and legal characterizations are his position, not independently established findings here. 16:06–22:23(opens in a new tab)
• He distinguishes augmentation from dependence. Even while refusing agents himself, he describes responsible use as accelerating work within an engineer's existing capabilities. He considers generating systems the engineer could not otherwise build risky because a loss of affordable access could leave them unable to continue the work. He predicts rising prices and declining software quality after AI-driven staffing cuts; the interview does not establish those outcomes. 42:58–50:32(opens in a new tab)
• His employer choice is more nuanced than “no AI anywhere.” He says Skylight met his priorities despite having LLM features: he describes them as optional and limited, rather than a pivot of the whole product around AI. This qualifies the earlier shorthand list of employer requirements. 37:41–41:55(opens in a new tab)
• Generating boilerplate does not replace language design. For Wharton, the expensive work is deciding boundaries and data models, then changing the system as requirements evolve. Kotlin's lasting value lies in its type system, refactoring tools, and ecosystem—not merely fewer keystrokes. He allows that automating repetitive call-site updates can be useful without treating that as the whole maintenance problem. 53:30–56:42(opens in a new tab)

Kotlin and architecture that can change

• Incremental adoption helped Kotlin succeed. Existing Java code and libraries could remain in place while teams introduced Kotlin gradually. Wharton describes Google initially adding Kotlin companion libraries rather than immediately rewriting Java libraries. That compatibility reduced the scope of the transition. 01:00–05:52(opens in a new tab)
• Make failure visible at the call site. He praises Kotlin's explicit nullability but criticizes unchecked exceptions because callers may not know an operation can fail. His example is parsing a string into a number: a language should require the caller to handle or propagate failure, rather than leave an unexpected runtime exception. He points to Swift and Rust as useful comparisons, not as evidence that Kotlin already has their error models. 58:43–1:06:24(opens in a new tab)
• Share business logic without requiring identical interfaces. At Cash App, he describes Kotlin compiled to JavaScript running inside Android and iOS apps, using Compose—not Compose UI—to drive native views. Downloadable logic updates addressed changes faster than their normal app-store release cadence. Redwood exposed design-system concepts such as a primary button; each platform retained control of its appearance and behavior. He says the system shipped on important screens before the project was wound down. 1:11:29–1:15:44(opens in a new tab), 1:21:50–1:27:05(opens in a new tab)
• Prefer replaceable libraries to deep framework coupling. This requires consumers to write integration code, but can make later migrations more localized. He gives Redwood and Zipline as separate pieces: Redwood could provide the native design-system abstraction without dynamic updating, while Zipline supplied the separately integrated update mechanism. The trade-off is substantial upfront design-system work, not a turnkey starting point for every app. 1:26:03–1:30:07(opens in a new tab)

Open source is more than code you do not have to write

• Treat dependencies as part of the product you own. Users experience the bundled application, not the boundary between your code and someone else's library. Wharton argues for following dependency changes and contributing fixes as normal engineering work, so a maintainer's change of direction is something you can anticipate and participate in. 1:53:51–1:57:04(opens in a new tab)
• Shared maintenance still matters if an LLM can generate an implementation. A common library distributes bug fixes and performance improvements to many consumers. Generating a private replacement does not automatically reproduce that continuing benefit; his example is inheriting a fix for a bug your code would only encounter after a future refactor. 1:57:04–1:58:11(opens in a new tab)
• Do not mistake a public repository for a support contract. He distinguishes employer-funded library work from personal projects that become critical dependencies elsewhere. Consumers can reduce maintainer load by implementing features, fixing bugs, or triaging issues, rather than only filing requests. He wants sustainable payment models but does not claim to have solved them. 2:03:21–2:07:42(opens in a new tab)

Full interview: JetBrains — Kotlin 2026 with Jake Wharton(opens in a new tab).