Martin Odersky – Keynote: The End of Programming? #ScalaDays

Summary

Martin Odersky argues that AI agents may automate much of software development, including code review. But if programs become opaque “black boxes,” people risk losing meaningful control over them. He questions whether programming languages would still matter in such a workflow and warns that agents’ speed and access to private data, external communication, and untrusted content can create serious security risks.

Securing agents with types and capabilities

Odersky’s central proposal is to make the execution environment safe, rather than relying on models to behave reliably. Agents would generate code in a restricted language, and a compiler would check that code before it can run.

The approach tracks capabilities—permissions such as file access, network communication, or input/output—in types. Sensitive data can be wrapped in a classified type: agents may transform or combine it using pure functions, but cannot reveal it or perform side effects with it unless they have the required capability. Timing-based side channels remain a limitation.

The prototype, Tacit (“Traceable Agent Capabilities in Types”), uses Scala 3 capture checking and a safe mode that disables unsafe features in agent-generated code. Odersky says experiments using Agent Dojo, Software Engineering Bench, and Tau² found the approach effective against tested dangerous behaviors without being overly restrictive. He does not provide detailed performance figures in the talk. The project and an associated research paper are described as publicly available.

Odersky also discusses combining type-checked interfaces with sandboxing: types describe permitted behavior, while a sandbox could enforce capability rules at runtime, including for code written in other languages.

Ideas for programming languages in an agent-heavy workflow

Odersky presents three preliminary ideas intended to help people retain oversight without reviewing every line:

1. Specification lines: Keep human-written prompts or specifications in the program alongside the implementation. An agent updates the code to match changes to those specifications, making the program’s intent easier to inspect.
2. Required interfaces: Let a program declare what it requires from external libraries, including their permitted capabilities. This could expose a dependency’s security footprint and help detect supply-chain changes that expand permissions.
3. Refinement types and proofs: Enrich types with predicates—for example, specifying that a number is non-negative or a vector is sorted. Automated checks, SMT solvers, or model-generated proofs could verify some of these properties. Odersky notes that full specifications are difficult to write, so formal verification is most practical for properties that can be stated clearly.

Overall takeaway

Odersky sees strong types, capabilities, modules, specifications, and formal verification as tools for keeping software understandable and constrained as agents write more of it. His goal is not necessarily to inspect every generated line, but to preserve people’s ability to shape systems and check key properties. He presents the language ideas as exploratory and expects programming workflows and languages to evolve.

Content type

This is a technical keynote, not a product review or step-by-step tutorial. It presents a security approach, a prototype, and proposed directions for language design.

Speaker and sources

Martin Odersky is the speaker. He cites claims attributed to Anthropic, Google CEO Sundar Pichai, and the creator of Ruby on Rails; a comment by Kent Beck; and the Tacit research paper’s coauthors and evaluation benchmarks.