For the last 50 years, programming language evolution has had one single north star: Human Ergonomics. We design syntax sugar, optional typing, and complex implicit behaviors to make code faster to write and easier for human brains to read.
But we are ignoring the elephant in the repository.
With autonomous platforms like OpenHands, GitHub Copilot workspace, and custom multi-agent reasoning loops writing, refactoring, and deploying code, the primary consumer of source code is radically changing. We aren’t just writing code for our peers anymore; we are writing code that AI agents must ingest, parse, and modify.
It’s time to face a contrarian truth: New language features must be optimized for AI processing, not human typing convenience.
1. Syntax Sugar is Token Poison
Humans love concise, clever shortcuts. We love implicit returns, ternary operators, and magical macros that turn 10 lines of code into 1.
For an AI, however, syntax sugar often adds unnecessary ambiguity. When an LLM generates or parses code, it breaks it down into tokens. Highly implicit, dense syntax requires more reasoning steps and token overhead for the model to successfully predict structural intent.
Instead of adding more magical, compressed syntax features, modern language updates should focus on explicitness. Explicit type declarations, mandatory block boundaries, and structured configurations make it vastly easier for an AI agent to read an abstract syntax tree (AST) and execute a flawless refactor without hallucinating edge cases.
2. The Nightmare of Code Sprawl and Context Windows
AI agents can write code faster than any human engineering team in history. But that speed introduces a terrifying side effect: Accelerated Code Sprawl. When bots generate thousands of lines of code across massive dependency structures, they easily shoot past their own context window limitations. If a language allows tightly coupled architectures, messy implicit imports, or sprawling global states, the AI will quickly lose track of the codebase logic, resulting in catastrophic dependency loops and structural decay.
Languages need built-in architectural guardrails. We don't need features that let us write code faster; we need language features that enforce strict boundaries, isolate modules natively, and flag structural corruption right at the compiler level.
3. Designing for Compiler-Driven AI Feedback
The most effective way an AI agent improves its code is through a tight feedback loop with the compiler or a static analyzer.
If an LLM writes bad code, a cryptic compiler error message helps no one. Language features should evolve to provide semantic, structured error payloads (like JSON-formatted diagnostics) rather than raw text outputs. Imagine a compiler or static analysis engine that doesn't just say Error: NullPointerException, but explicitly outputs a deterministic matrix map of the structural loop causing the failure.
When the language infrastructure speaks the same structured data language as the AI, agentic self-healing code transitions from a sci-fi concept into standard CI/CD reality.
Conclusion: The New Dev/AI Symbiosis
This doesn't mean human developers are obsolete. It means our roles are shifting from "code typists" to software architects and system reviewers.
If we continue to update languages like C++, Java, or Rust based purely on how many keystrokes it saves a human finger, we are optimizing for the past. The languages that dominate the next decade will be the ones that turn code into a clear, predictable, and highly structured data asset that AI agents can refactor with 100% mathematical precision.
What do you think? Should language designers start prioritizing LLM readability over human convenience, or are we risking making code completely unreadable for the humans left in the loop? Let’s discuss in the comments below.
Top comments (1)
As a language designer myself, I've given this matter a lot of thought. I think you points are really strong. I'd add a couple things:
1) Locality matters. You should we able to read one block of code and understand it without looking elsewhere. Here I think strong type signatures are really valuable.
2) Compile time matters. In the past, coding was so slow that a few minutes waiting for the compiler to process the code was never really a bottleneck. Now it kind of is. My test suite has thousands of golden tests that require compiling small programs and running them end-to-end. The compile and test part of the loop can completely dominate dev time. I've considered switching from Rust/Cpp to Zig/VLang for this reason alone.
3) As you say, human egonomics doesn't matter anymore. I suspect that languages like Ruby and Python, where the sole selling point is smooth onboarding, are doomed.
4) Abstraction still matters. Being able to safely compose two things and then treat them as one thing with confidence has always been to key to building complexity. I believe this is a general principle that will carry on long after our programming age ends.
5) Strong types are good. I don't want to be a Haskell fanboy, and I think Haskell itself compromises too much on performance and compile-time to have a longterm future, but the types are a massive boon to LLMs. They provide machine checked documentation and guarantees about behavior.
So I'd say the dimensions on the Pareto plane that matter are performance (speed, memory), compile time, ease of LLM reasoning, and verifiability.
I think Zig and Lean have a future, but Python and Rust will die. Or more likely, no member of the final family has yet been written. There will probably be a series of massive phase shifts as languages settle, with billions of lines of code being translated automatically to lower energy states.
This brings up another MASSIVE change that LLM's bring. The greatest challenge to any new language in the past was adoption. But LLM's can adopt new languages and write in them perfectly almost immediately. They just need a few pages of examples. So I predict a future of hundreds of specialized languages that are optimimal for some sub-problem and compile to a common binary (e.g., something like WASM).
I could talk forever about this, but I risk writing a comment that is longer than the post, so I'll stop.