José Valim: Rethinking Programming Languages and Tools for the AI Agent Era

Introduction: A Viral Post

On September 24, Elixir creator José Valim published a long post on X titled "Evolving programming languages in the AI era." Within a day it garnered hundreds of likes and tens of thousands of views, splitting the comment section into two camps. Valim structures his thinking in two parts: a reflection on what happens when humans no longer write most code, and a practical tooling discussion on how developer tools should change now that coding agents are becoming a new class of language users.

Reflection: When Humans Stop Writing Most Code

What Holds Communities Together?

Valim observes that every mainstream language community coheres around shared values: Python's "one obvious way," Ruby's "programmer happiness," Lisp's pride in reshaping the language itself. If humans no longer write the bulk of code, what remains of that belonging? Is it worth preserving, or will communities find new glue?

He extends this to language ecosystems (web frameworks, tensor libraries, data pipelines, GUI toolkits). Agents affect ecosystems in two opposing directions:

On one hand, building these frameworks is extremely labor‑intensive — much of it is "translating existing implementations" or "reproducing algorithms from papers," tasks at which agents excel. Small ecosystems may therefore catch up to large ones quickly.

On the other hand, if the cost of implementing something drops low enough, do people still have an incentive to collaborate on a shared solution? If I need a library for problem X, I might just ask an agent to custom‑build one for my exact needs.

Valim calls this a tension : agents drastically lower the cost of building ecosystems while simultaneously weakening the original motivation for ecosystems to form.

Does Ergonomics Matter to Agents?

This is one of the post's most pointed sections. Over the past decade many languages have evolved toward ergonomics — adding optional chaining, for example, to spare humans from writing long null‑check chains. Valim asks: if humans are no longer the primary code writers, how much do these improvements matter?

Agents do not get bored writing boilerplate; syntactic beauty differences are likely negligible to the model. One might argue such optimizations improve token efficiency, but Valim does not consider that a top priority — especially as models become cheaper and context windows grow, token efficiency should be the last metric to optimize.

He goes further: any new language that claims to be "built for coding agents" yet focuses on syntax is essentially optimizing around today's limitations. Having used agents to write HTML, CSS, JavaScript, Elixir, Rust, and Lean, he finds that syntax styles that look wildly different to humans are all just "tokens in, tokens out" to the model.

Will Compilers Disappear?

Following the "syntax doesn't matter" thread, a more radical question arises: do we need programming languages at all? Could agents bypass languages and write assembly directly?

Valim answers no, for two reasons:

If you are building a desktop application, you probably do not want to maintain separate assembly implementations for every architecture. You still need an architecture‑independent intermediate representation and the ability to lower it to target machines — in other words, you have reinvented a compiler and part of a high‑level language, even if that language was never designed for human writing.

Humanity has never found a single "universal" language or computational model. Systems languages, theorem provers, concurrency‑oriented languages (Erlang/Elixir), query languages, hardware description languages — each encodes different semantics, different abstraction levels, different guarantees. Expecting one low‑level language to unify all these scenarios is unrealistic.

So the question becomes: if programming languages persist but are no longer optimized for "humans who write them," who do we optimize for? The answer is the subject of part two: the agents themselves.

Tooling: Redesigning Developer Tools for Agents

Valim emphasizes that these tooling ideas do not require agents to write 100% of the code; even at 20% adoption they are worth investing in. He also states a principle he has long believed: building great tools for humans ultimately yields great tools for agents. We have already been moving in that direction — having agents write the same tests, consume the same program metadata, read the same logs.

But what about tasks humans dislike — tedious work, steep learning curves, or information volumes beyond human capacity? The next three directions address that.

Loosening Constraints: Who Are Type Systems For?

Language design balances expressiveness, guarantees, and ergonomics . If agents write most code, these trade‑offs deserve re‑examination.

A typical example is function signature inference . For humans, writing out types the compiler could infer is a burden; agents do not care about verbosity. Explicitly writing types and intent instead gives the compiler, other agents, and ourselves more information.

More importantly, the set of types a type system can fully infer is usually a subset of the types it can check — optimizing purely for inferrability caps expressiveness and the upper bound of guarantees. Since we have already seen agents write formal proofs in far more complex systems, why impose that limit?

Guarantees need not be purely static. Memory safety can be enforced statically or via runtime (garbage collection); model checking can verify real systems against execution traces generated from models. A classic case is Erlang/Elixir using isolated processes and message passing to constrain concurrent program structure — sacrificing some expressiveness for stronger isolation and fault‑tolerance guarantees. Not every concurrent algorithm maps efficiently to this model, but those that do inherit concrete benefits.

Valim summarizes four guarantee mechanisms that can be combined today:

Static typing

Runtime enforcement (e.g., GC, bounds checking)

Model checking / formal verification

Architectural constraints (e.g., actor model isolation)

He argues that future language differentiation and adoption will increasingly depend on how these mechanisms are combined and where each language draws its expressiveness‑vs‑guarantees boundary — especially if agents make it easier for ecosystems to catch up with each other (echoing the community section).

Program Database Replaces LSP

This is the post's most concrete prediction: the Language Server Protocol (LSP) will likely not outlive the debugger.

As the "death of the IDE" has been repeatedly proclaimed, LSP — designed around file/line/column locations for human interaction — will struggle because agents are not good at tracking precise coordinates. While building Tidewave (a CLI/tool that lets agents ask questions like "where is foo_bar documented?" or "where is BarBaz defined?"), Valim's team found that this Q&A‑style interaction works far better than demanding exact source‑location references from agents .

More fundamentally, LSP presents information for human consumption — one small piece at a time, requiring the developer to jump between files and mentally assemble the whole picture. The good news: many language servers already possess or can access what agents actually need — symbols, references, call graphs, type information, sometimes data‑flow information. Valim's proposal: expose this as a queryable "program database" — whether via a Datalog‑like query language or another interface.

Requiring most human developers to write a query just to find all references to a function is unrealistic; for an agent, writing a programmatic query costs about the same as calling a CLI or LSP tool. Crucially, agents can compose queries that would never make sense as single IDE features — e.g., "find all public functions that eventually call this function" or "find all value paths in the program that could become nil." Such databases could even serve as linters to constrain agents from making non‑idiomatic changes.

Valim adds a caveat: locality remains critically important , especially in large codebases. Monkey‑patching, implicit hooks, dynamic binding — "action at a distance" patterns — make it hard to fully trace system‑wide effects even with a program database.

Runtime Observability Replaces the Debugger

Another classic human‑centric interface is the debugger: breakpoints, single‑stepping, inspecting variables. Valim argues agents can do more — they can instrument code, collect execution traces, and correlate information at speeds far beyond humans, so we should give them interfaces that match that capability .

Moreover, if we assume agents will eventually write most code, a logical corollary is that they will also take on more responsibilities across the entire software lifecycle, including monitoring and diagnosing production systems , not just relying on logs and dashboards.

Valim's recommendation: expose the system's runtime and state in a programmatically queryable, explorable way . Runtime observability can provide agents with a unified interface to diagnose failures, locate reliability issues, and discover performance bottlenecks in real time across all environments.

Interestingly, he notes this is exactly where Erlang/Elixir have always been strong — thanks to the BEAM VM, inspecting processes, sockets, applications, supervision trees, ETS tables, message queues, etc., is built into the runtime. The remaining gap is simply how to safely expose these capabilities to agents — whether through a toolset, a query language, or a sandboxed environment.

Comment Section Debates

The post sparked vigorous discussion. Key threads:

"Debuggers Won't Die" Camp

Some developers disagreed, arguing that letting agents single‑step and replay program state like humans could provide faster feedback and might not be replaced. Valim responded that the two views aren't contradictory — the goal is always to give agents better interfaces to reach state and trace execution paths, without forcing them to step through one instruction at a time. The information is the same; the interface differs.

Concerns for Newcomers

One commenter worried that if agents silently fix errors, beginners might never realize where they got stuck, and fundamental questions could disappear before the community sees them — a hidden risk for knowledge transfer. Valim admitted he currently has no answer .

Will Humans Lose a Say in Language Design?

A follow‑up asked: if we stop reading code and debating designs, how will we know what the next "Elixir" should look like? Valim's guess: languages will keep evolving, but the driving force will shift toward the vision of core teams rather than community demands and requests — he stressed this is pure speculation.

The "Lisp Curse" at Scale

Others invoked the "Lisp curse" — because Lisp is so malleable, everyone tends to reinvent their own solutions, hindering community cohesion. With agents drastically lowering the cost of "doing it yourself," could this curse become the new normal for everyone?

Chinese Developers' Perspective

Chinese commenters focused on tooling feedback loops: after agents write most code, the real bottlenecks become compiler errors, linters, CI — the "human‑designed" feedback stages. The structure and recoverability of error messages may matter far more than syntax itself. One noted that structuring minimal reproducible cases and one‑fix diffs would completely change agents' rework paths.

Overall, no consensus emerged, but one comment captured the essence well:

Whether language ergonomics matters may no longer depend on "who is typing," but on what the surviving communities end up teaching agents — human syntactic taste, or something else entirely.

Conclusion: Open Questions, Not Final Answers

Valim ends with a disclaimer: the post received AI assistance for wording and grammar — a fitting footnote, since while we debate how AI will change code writing, AI is already participating in the debate itself .

His conclusions are not radical: programming languages will not vanish, compilers will not be bypassed, but the entire toolchain designed around human interaction — IDEs, LSP, debuggers — will likely need to be reimagined . Program databases and runtime observability are just two concrete landing points in that direction, not the final destination.

As for what will re‑bind communities, who will drive the next "Elixir"‑level language, how to preserve newcomers' growth paths — Valim offers no answers. Perhaps that honesty is the article's greatest value: it raises more questions than it answers.