why the next programming language will be designed for AI agents, not developers
Table of content
by Ray Svitla
armin ronacher — the person who created Flask, Click, and a dozen other tools you’ve probably used without knowing his name — published something this week that’s going to age like fine wine.
his argument: we need new programming languages. not because the old ones are bad. because the audience changed.
the audience problem
every programming language ever designed optimized for one scenario: a human sitting at a keyboard, typing code.
we built languages around writing efficiency. type inference saves keystrokes. syntactic sugar reduces boilerplate. implicit behavior keeps code short. DRY principles eliminate repetition.
these choices made sense. writing code was the bottleneck.
but in 2026, agents write most of the code. humans review it.
the bottleneck moved. and the language priorities should move with it.
what agents don’t care about
agents don’t care about keystrokes. they can type 10,000 characters per second. verbosity is free.
agents don’t care about DRY. repeating yourself costs nothing when you’re an LLM.
agents don’t care about syntactic sugar. they’ll happily write the long-form version every time.
what agents do care about: explicitness. tooling quality. low churn. clear semantics. statically analyzable code.
and here’s the uncomfortable part: humans reviewing agent-generated code care about the same things.
the type inference problem
ronacher uses type inference as his main example. and it’s a good one.
type inference is amazing for writing code. you type less. the compiler figures it out. everyone’s happy.
but type inference is terrible for reading code. especially when you’re reviewing a 500-line PR from an agent.
# with type inference
result = process(data)
what’s the type of result? you don’t know. you have to trace through process(). maybe jump to its definition. maybe run a type checker. maybe guess.
# without type inference
result: ProcessedData = process(data)
now you know. immediately. no context switching. no guessing.
when you’re writing code, the first version is better. when you’re reviewing code — especially hundreds of lines of agent-generated code — the second version is better.
the optimization target flipped.
the implicit behavior problem
modern languages love implicit behavior. it makes code concise. elegant. clever.
python’s __init__.py turns directories into packages. JavaScript’s this binding changes based on call context. Ruby’s method_missing lets objects respond to undefined methods.
beautiful when you’re writing it. exhausting when you’re reviewing it.
agents will happily use every implicit feature available. because they don’t experience cognitive load. and humans reviewing that code will burn out trying to hold all the implicit rules in their head.
explicit is verbose. but explicit is verifiable.
what an agent-first language looks like
ronacher doesn’t propose a specific language. but the constraints are clear:
1. explicit over implicit
every behavior should be visible in the code. no magic. no “you just have to know the framework.”
2. strong static analysis
tooling should catch mistakes without running the code. agents make weird mistakes. static analysis catches them early.
3. low syntactic churn
language features should stabilize. agents trained on old code should still work with new code. breaking changes are expensive when your primary user is an LLM.
4. optimized for review, not writing
verbosity is fine. repetition is fine. clarity is mandatory.
5. minimal abstraction layers
every abstraction is a place agents can make subtle mistakes. keep the layers shallow.
does this sound boring? yeah. boring is the point.
the Go parallel
this entire argument feels like the Go language design philosophy, but taken further.
Go was controversial when it launched. no generics (at first). no clever type inference. no inheritance. minimal abstractions. verbose error handling.
the Go team’s argument: we’re optimizing for code that 10 engineers read over 10 years, not code that one engineer writes in 10 minutes.
they were right. Go became the language for infrastructure, SRE tooling, and backend services. places where clarity beats cleverness.
the agent-first language is the same bet, pushed further. optimize for 1000 engineers reviewing agent-generated PRs, not one engineer typing at a keyboard.
the transition problem
here’s the uncomfortable part: we can’t just switch languages.
billions of lines of code exist. entire ecosystems are built on Python, JavaScript, Java, C++. you can’t rewrite the world.
but you can start designing the next generation with agents as the primary user.
the language that wins the next decade won’t be the one developers love writing. it’ll be the one humans can review at scale without burning out.
why this matters now
stripe ships 1000+ agent-written PRs per week. that’s one company. imagine when it’s every company.
the bottleneck isn’t agents writing code anymore. it’s humans reviewing it.
and current languages weren’t designed for review-at-scale. they were designed for write-at-keyboard.
the gap is becoming a crisis. quietly. because nobody wants to admit that their favorite language is optimized for the wrong thing.
the real question
ronacher’s piece isn’t really about language design. it’s about acknowledging that the job changed.
software engineering used to be: write code → test code → ship code.
now it’s: describe problem → review agent’s solution → iterate until correct.
the skills that matter shifted. the languages should shift too.
nobody’s built the agent-first language yet. but someone will.
and when they do, it’s going to feel boring, verbose, and obvious. and it’s going to win.
because the audience isn’t developers typing anymore. it’s developers reviewing. and clarity beats cleverness when you’re reviewing 500 lines of agent-generated code at 4pm on a friday.
what you can steal
→ if you’re building tools for agents: optimize for review, not writing. verbose output is fine. explicit is better than clever.
→ if you’re reviewing agent-generated code: demand explicitness. if the types aren’t clear, send it back. if the behavior is implicit, send it back. train the agent to write code you can verify.
→ if you’re designing a new language: ask “would I want to review 10,000 lines of this per week?” if the answer is no, rethink the abstractions.
the next programming language won’t be designed by asking “what do developers love writing?”
it’ll be designed by asking “what can humans review without burning out?”
that’s the shift.
Ray Svitla
stay evolving