José Valim outlines how AI coding agents could reshape programming languages

José Valim published a blog post on Dashbit's site on September 24th, 2026, titled "Evolving programming languages in the AI era," laying out a set of reflections on how programming languages, their communities, and their tooling might change as AI coding agents take on more of the work of writing code. The post is split into two parts, Reflections and Agentic tooling, and Valim frames it as a snapshot of thinking he expects to keep evolving.

In the Reflections section, Valim asks what happens to language communities once humans stop writing most of the code themselves, since communities like Python's or Ruby's have historically rallied around shared sensibilities about how code should be written. He argues coding agents could pull ecosystems in two opposite directions at once: agents can cheaply port algorithms and implementations between languages, letting smaller ecosystems catch up with larger ones, but if building a library becomes cheap enough, developers may simply ask an agent to build exactly what they need instead of joining a shared effort, weakening the very forces that cause ecosystems to form. He also questions whether syntactic ergonomics, such as optional chaining over explicit null checks, still matter as much once code is mostly agent-written, and argues that any language marketed as being "for coding agents" that focuses on syntax is really just building around today's model limitations, since token efficiency should not be a top priority as models get cheaper and context windows grow. On the question of whether agents will eventually bypass compilers and write assembly directly, Valim says he does not buy that scenario: developers would still need an architecture-independent representation to target multiple platforms, effectively reinventing a compiler, and no single low-level language or model has proven capable of unifying the very different demands of systems programming, theorem proving, concurrent/distributed software, or hardware description.

The Agentic tooling section is more concrete. Valim's central point is that even developers using agents for as little as 20% of their code could benefit from tools designed for agents rather than humans. He argues that because coding agents do not find explicit type annotations tedious the way humans do, languages can push toward stronger guarantees rather than optimizing for type inference; he notes that the languages whose types can be fully inferred are generally a subset of those whose types can be checked, so favoring inference can limit both expressiveness and the strength of guarantees a type system provides. He lists four ways software guarantees can be established: correct by construction (invalid states are hard to express), statically established (types, proofs, static analysis), runtime-enforced (memory management, isolation, capability boundaries), and empirically validated (tests, property-based testing, fuzzing), and predicts languages will increasingly differentiate themselves by how they combine these. He also argues the Language Server Protocol, built around file/line/column positions for IDEs, is poorly suited to agents, and that once IDEs fade, LSPs will not survive either; drawing on his team's experience building the tool Tidewave, he proposes exposing the same symbol, reference, call-graph, and type information LSPs already gather as a queryable program database instead, since agents can happily write a query to find every reference to a function or every call path where a value could become nil, tasks that would be unreasonable to ask of most human developers. Finally, in a section on runtime observability, Valim argues debuggers are another human-first interface that agents do not need, since agents can instrument code and correlate traces far faster than people can, and that Elixir has always excelled in this area; the excerpt of the post ends mid-sentence in this section before explaining why.

Key facts

  • José Valim published the essay 'Evolving programming languages in the AI era' on Dashbit's blog on September 24th, 2026, split into a Reflections section and an Agentic tooling section
  • He argues coding agents could both help smaller language ecosystems catch up with larger ones and simultaneously weaken the incentive for developers to collaborate on shared libraries
  • He rejects the idea that agents will bypass compilers and write assembly directly, since architecture-independent representations and specialized languages (systems, concurrent/distributed, query, hardware-description) would still be needed
  • He proposes replacing type inference optimization with stronger guarantees, since fully-inferable type systems are generally a subset of fully-checkable ones, and lists four ways to establish guarantees: correct by construction, statically established, runtime-enforced, and empirically validated
  • He predicts Language Server Protocols and debuggers, both designed for human IDE workflows, will be replaced by queryable program databases and agent-facing runtime observability, an area he says Elixir has always excelled in

Why it matters

Valim writes about a question many toolmakers are grappling with quietly: if AI agents end up writing most code, should languages and developer tools keep optimizing for human ergonomics at all, or pivot toward what makes agents more effective and code more verifiably correct. His argument that inference-friendly type systems trade away guarantees, and that LSPs and debuggers were built for a human, file-and-line-oriented workflow that agents don't share, is a concrete reframe of tooling priorities rather than generic AI commentary.

Who it affects

Programming language designers and maintainers of developer tooling (type checkers, LSP implementations, debuggers), teams building AI coding agents and their surrounding infrastructure, and the Elixir/Erlang community specifically, since Valim draws on his own experience building the agent-facing tool Tidewave and points to Elixir's process isolation and runtime observability as examples worth building on.

How to use it

The essay is a free blog post, not a product; its practical suggestions are architectural ones for tool builders: expose the symbol, reference, call-graph and type information language servers already collect as a queryable program database (SQLite, Datalog, or a custom DSL) instead of, or alongside, an LSP, and build runtime observability interfaces that let agents query and instrument running systems programmatically instead of relying on logs, dashboards, or step-through debuggers.

How solid is it

This is a first-person opinion essay from the author reflecting on his own experience, not a study or an announcement with independent verification; Valim explicitly frames it as a set of ramblings he expects his views on to change. The excerpt used here is truncated mid-sentence in the runtime observability section, so the piece's remaining examples and conclusion are not covered.

Risks and caveats

The essay is speculative and does not cite specific AI models, coding agent products, or adoption data to back its predictions; its claims about LSPs and debuggers not surviving, and about ecosystems weakening, are the author's own forecasts rather than established outcomes. No companies or agent products besides the author's own Tidewave and the Elixir/Erlang ecosystem are named as examples.

“Overall, there has never been a better time to provide stronger guarantees about our software.”

— José Valim