AI-Favored Programming Languages
AI-favored programming languages is the idea that AI as the primary code producer shifts programming language selection criteria from human ergonomics toward formal properties - strong type systems, verifiability, and performance - and may ultimately favor languages that look nothing like what humans converged on.
Details
Programming language adoption has historically been driven by human psychology and social dynamics: ease of learning, simplicity of writing correct code, community size, ecosystem breadth, and how welcoming a community is to newcomers. These factors shaped which languages grew fastest and which ecosystems became dominant. Fundamental properties like provable correctness, formal verification, and the balance between dynamic and static checking mattered, but were secondary to human adoption dynamics.
As coding agents write an increasing share of production code, this balance shifts. Languages with strong type systems and formal verifiability become more attractive because they suit LLMs' strengths: type checkers and compilers provide immediate, structured feedback that functions as a reinforcement learning signal, and formal properties constrain the output space in ways that reduce hallucination risk. However, model familiarity bias currently works against this - LLMs perform best on languages with the most training data, not the strongest type systems. Agent legibility takes the familiarity side of this tension as a current design principle, favoring "boring" well-represented technologies over formally superior but less familiar alternatives. Languages that are harder for humans to learn but offer stronger correctness guarantees - Rust, Haskell, dependently typed languages - face fewer adoption barriers when the primary author is a machine.
A separate axis favors languages based on runtime concurrency properties rather than type system strength. When the primary challenge is running thousands of concurrent, long-lived, failure-prone agent sessions, process isolation, supervision trees, preemptive scheduling, and fault tolerance become the dominant selection criteria. Erlang/Elixir (BEAM VM) is the canonical example - designed for telecom workloads with requirements nearly identical to multi-agent systems.
Novel AI-optimized languages
In the longer term, AI may not share the tradeoffs that shaped human language design: expressiveness vs. simplicity, safety vs. control, performance vs. abstraction, compile time vs. runtime, explicitness vs. conciseness. An optimal LLM programming language could diverge significantly from human-designed languages, potentially optimizing for machine verifiability, token efficiency, or properties humans never prioritized. The reasons to create new programming languages would shift from human productivity to machine productivity.
Counterarguments
- Current evidence (2026) shows LLMs performing best on languages with the most training data (Python, TypeScript) rather than the most formally verifiable (Rust, Haskell, Idris). Training data volume may matter more than formal properties for LLM code generation quality, and this advantage compounds: more usage generates more training data.
- AI-generated code still needs human review, debugging, and maintenance in most workflows. Human readability remains a hard constraint as long as humans are in the loop, limiting how far language design can diverge from human ergonomics.
- New languages face a bootstrapping problem: LLMs need training data in the language to generate it well, but training data requires an existing ecosystem of code written in that language. A language designed purely for LLMs would lack this ecosystem initially.
- Ecosystem network effects - tooling, libraries, CI/CD integrations, and hiring pipelines - create switching costs that dominate language choice even when the primary author is a machine. An agent writing Rust still needs the Rust ecosystem (crates, build tooling, deployment infrastructure) to be healthy.
- Most codebases are polyglot, and language choice is dictated by existing systems, platform constraints, and team expertise rather than greenfield decisions. Even if agents favor Rust, a team maintaining a Python monolith faces migration costs that dwarf any language-level advantage - the Lindy effect of existing codebases limits how quickly language preferences can shift in practice.
- The concurrency argument (Erlang/BEAM for agent orchestration) is a separate claim from the type system argument, and alternatives exist across the language spectrum. Go, Rust async runtimes, JVM virtual threads, and cloud orchestration platforms all address concurrency at scale without requiring a language switch. The BEAM VM's advantages are real but narrow to the agent runtime layer, and most agent sessions are I/O-bound on inference API calls rather than CPU-bound, reducing the practical impact of runtime concurrency properties on language selection.
Confidence
Low. The near-term claim about strongly typed languages contradicts current evidence of LLM performance correlating with training data volume rather than type system strength. The long-term claim about novel LLM-optimized languages is highly speculative and faces the bootstrapping problem. The underlying logic - that removing human factors from adoption changes which properties dominate - is sound, but the specific predictions are unsubstantiated.