Scala Summit 2026 2026

The AI revolution raises questions about the utility of various technologies, especially programming languages. And when it comes to developer experience, Scala might have just the right answers.

We’ll take a tour of how to use Scala efficiently for and with AI. We’ll start by augmenting existing Scala development workflows with AI, leveraging Metals MCP and Cellar.

Next, we’ll teach AIs to write better Scala and more functional code. A short Scala skill makes a whole lot of difference in the quality of the generated code. Here we’ll focus on the direct-style-Scala skill we’ve been developing, highlighting the main challenges that AI faced in our experiments.

We’ll finish by looking at applications: using Scala to orchestrate coding agents and to orchestrate arbitrary business workflows. These are two broad categories. First, we’ll take a hands-on look at Orca, which offers an API for setting up deterministic, AI-driven development flows.

For the second, we’ll see how sttp-ai and chimp work together to provide the necessary Scala tooling to use AI models in your applications: talking to OpenAI/Claude APIs, running an agentic loop, using structured inputs & outputs. One theme will be constant: leaning on type safety and Scala’s toolchain to deliver business value not only faster, but also with more reliability.

In each case, we’ll show where Scala is better suited than alternatives for the problem at hand — and where it loses to the competition. Our goal will be to answer the question: in the age of AI, where does Scala have the upper hand?

I am the co-founder of SoftwareMill, head of R&D at VirtusLab, where I primarily generate code using Java, Scala, Rust and other interesting technologies. I am actively involved in open-source projects, such as Ox, Jox, Tapir, sttp, and others. I have also been a speaker at major conferences, including JavaOne, Devoxx, GeeCON and ScalaDays.

In addition to writing closed- and open-source software, I spend my free time exploring various programming-related subjects. Any ideas or insights I gain usually end up with a blog.

ScalaTest 3.3 is the biggest release since 3.0, and it completes a plan that started in 3.1, when FunSuite, FlatSpec and their siblings were deprecated and renamed AnyFunSuite, AnyFlatSpec. The Any prefix indicates that test bodies have type Any. One consequence is a test that forgets to assert still compiles, runs, and passes. In 3.3 the original names come back, with a test body type of Assertion. A test that ends in a Boolean expression in a FunSuite, for example, will not compile. The Any* styles stay — they are still useful in many ways — but now there’s a more typesafe alternative.

We paired the safer style traits add a new kind of assertion, an Expectation, which always returns a value rather than sometimes throwing an exception. Fact is that value, and it composes using the logical operators — such as &&, ||, or implies — so a sequence of statements whose results get discarded becomes one expression.

In addition, we’ve been developing a property-based testing framework for several years, and it will be released as part of 3.3. Shrinking is integrated rather than bolted on. A generator produces a lazy tree of progressively simpler candidates instead of a bare value, and every candidate is filtered through the generator’s own validity check, so a shrunken counterexample is always a value that generator could have produced in the first place. Edge cases are first-class as well: each generator carries a list of boundary values, and a property run works through those as well as generating random values, so the cases most likely to break your code are tried regularly rather than left to chance. Because Randomizer is immutable and seed-based, any failing run can be replayed exactly.

As a provider of personal lines insurance, Annex Risk is responsible for maintaining a large set of underwriting rules across multiple product lines. Underwriting rules can be arbitrarily complex and often evolve over time. Many teams handle this with a rules engine or a DSL stored in a database. We went the other way: our rules are plain Scala.

This talk explores how we model underwriting rules as an interval map, where each range holds a function object implementing the rule in effect for a particular time window. Thin Scala-friendly constructors and builders reduce a new rule version to a few lines of code. Because it’s just Scala, we get type safety, the compiler, IDE support, and all our existing tooling for free, and source control gives us a complete audit history.

Everyone knows about LLM inference on GPUs, but what about type inference on GPUs? After all, we love strong types, but hate compile times. Unfortunately, the more we try to prove about our programs, the more time we spend waiting for our builds.

Can we throw a GPU at it? Is type inference even that parallelizable? What about for type systems of real languages like Scala, or Rust, etc.?

One commonality of these languages is typeclass resolution. Whether it’s called implicit resolution or trait resolution, it’s a powerful pattern, but can induce particularly long compile times.

We’ve convinced ourselves that type inference is highly serial, but it doesn’t have to be. We’ll explore how we might scale such type systems to many cores, unlock data-parallelism, and accelerate type inference and resolution on GPUs.

Working with AI can sometimes feel like a psychedelic time sink, but it doesn’t have to be that way. Scala is a great language to code with an agent if you can get it to talk to the compiler.

We’ll start by looking at the fundamentals: using the agent to minimize context switching, tooling, how to stay safe, and how to help it write in plain English.

Next, we’ll look at tooling to let agents run wild with Scala, with dangerous permission levels but in locked down containers so that you can go off and do other things while your agents are working away.

Finally, we’ll zoom out and consider strategies to help you stay productive and happy, working along side agents and product on mature production code.

Chisel is a Scala-embedded DSL for describing hardware. Created by UC Berkeley researchers in the early 2010s, Chisel has undergone numerous iterations and is now used heavily by many modern hardware companies, including SiFive, where it forms the backbone of highly parameterized RISC-V CPU generators.

We have been undertaking a multiyear effort of migrating Chisel and our internal SiFive codebases to Scala 3. This talk will highlight the techniques, pitfalls and takeaways from our large migration from Scala 2 to 3. I’ll also touch upon the new features we’re excited about in Scala 3 and how we’re planning on incorporating them in Chisel.

Everyone and their dog are building permanent AI agents, but nobody is solving the real problem — how to prevent the agent from doing something it should never, ever do while preserving its general problem-solving capability. In this talk, we will introduce the CapybaraClaw — the agent built with safety in mind that gives you the peace of mind.

We keep writing the same application three times: types for the database, types for the wire, types for the UI — in three languages, kept in sync by hope and integration tests. This talk presents a complete, opinionated Scala 3 stack where the model is defined exactly once and shared, compiled, from the database to the browser.

Vivek is going to talk about Scala 3’s experimental feature: capture checking. He’ll show how resource leaks are flagged as compile-time errors, which the compiler identifies by tracking which capabilities each value retains. He’ll also cover the type system updates related to capture checking.

Having recently started working in Scala after years of being a Rust developer, Gus noticed many similarities in the 2 languages. This made onboarding to the language easy, and made each design difference a curiosity worth exploring! This quick talk will talk about some of the overlap, and differences, between the two languages, and how that affects the experience working in them day to day.

AI is a multiplier, not a fixer — point it at a mess, and it scales the mess up: defects climb, reviews balloon, tests become a farce. Scala’s honest compiler and typed libraries are a base that holds as you push harder. We’ll assemble the workflow around them with agents, context, deterministic refactors, hermetic builds and more.

A year ago, my argument was that productivity lives in the whole development lifecycle, not in how fast anyone types. AI hasn’t changed that — it made it unforgiving. The instinct is to treat an agent as a fixer, something you point at a problem to make it go away. It isn’t. It’s a multiplier, and a multiplier obeys whatever it’s standing on. Direct it at a shaky team process, and nothing gets repaired; the shakiness simply scales. More defects, longer review queues, green test suites that are quietly wrong — and reworks that grow faster than anyone wants to admit.

Which reframes the whole question. It’s not “how do we add AI?”, it’s “what is it multiplying?” For Scala teams, the honest answer is the language itself. Strongly typed libraries and a compiler that refuses to lie give you a foundation that gets firmer under pressure. This allows to discover failures at runtime — the kind of failures that only surface at runtime on production with other stacks. The types you already have are complex enough. What’s usually missing is a process built to lean on them.

So that’s what we’ll assemble, one component at a time, like building together a kit. Context Fabric, CI build for Machine Speeds, Tiered Review and testing strategies for the AI era. We will apply the same discipline we’ve been using in large monorepo teams — the Airbnb and Databricks tier — where we’re seeing output climb by roughly half in a matter of months, but in a way that can be split and rearranged to match your context. You won’t leave with a mandate to adopt all of it. You’ll leave with the kit, the cost of each piece, and a clear sense of what to reach for next on your own Scala projects — a way to raise productivity and quality at the same time, instead of trading one for the other.