What Will Be the First Agent-Native Programming Language?

Human-readable code is becoming an intermediate format

For most of computing history, source code had two audiences.

The first was the computer that would compile or interpret it. The second was every human who might need to understand, debug, maintain, or extend it later.

That second audience shaped nearly every major language-design decision.

Python emphasizes readability. Ruby attempts to feel natural and expressive. TypeScript adds structure that helps large groups of people reason about JavaScript. Rust makes ownership and memory safety explicit so developers can understand and control behavior that other languages might hide.

These are valuable features because human attention has traditionally been the scarce resource.

Agentic coding changes the economics.

An agent does not need syntax that is easy to type. It does not need keywords that are easy to remember. It does not need a language that can be taught in a semester or explained in a shelf of books. It does not become fatigued while navigating a large repository. It can process representations that would be tedious, verbose, or incomprehensible to a person.

It may benefit from very different properties:

• unambiguous semantics
• compact token representation
• explicit dependencies and side effects
• deterministic transformations
• formal verification
• automatic parallelization
• machine-readable diagnostics
• built-in provenance
• incremental compilation
• hardware-specific optimization
• direct expression of constraints and tests

Once agents become the primary authors of software, human readability stops being the central design constraint.

It does not become worthless. It becomes a generated interface.

The machine-native representation could become the source of truth while humans receive whatever view is most useful at the moment: an explanation, a diagram, a behavioral specification, a security report, a test plan, or even generated TypeScript.

Human-readable code may eventually be no more fundamental than a graphical view of a database schema.

Why agents still write Python and TypeScript

The largest obstacle to any new programming language is not its syntax.

It is the ecosystem.

A new language needs compilers, debuggers, libraries, documentation, package management, editor support, deployment tooling, security analysis, and access to existing platforms. Developers are reluctant to adopt a language that makes them rebuild everything they already have.

Agents do not eliminate this problem, but they may dramatically reduce it.

Historically, a new language also had to convince millions of people to learn it. Developers needed training, examples, books, community support, and enough confidence to risk their careers and companies on unfamiliar technology.

An agent does not need months of training. Once a model or coding system can reliably produce a language, every user of that system gains access to it immediately.

That removes one of the largest historical barriers to language adoption.

The ecosystem problem remains, which means the first successful agent-native language will probably not replace Python, JavaScript, Rust, and C++ all at once. It will absorb them.

It may compile through LLVM, target WebAssembly, call existing C interfaces, import current packages, and communicate with established APIs. It may begin as an intermediate representation hidden beneath a coding agent rather than a language developers knowingly select.

The transition could happen without most people noticing.

Parts of this are already happening

There is not yet a widely adopted, general-purpose programming language written and consumed primarily by agents. There are, however, several early projects moving in that direction.

Researchers introduced Quasar in 2025 as a language for code actions performed by large language model agents. Agents commonly generate Python when they need to call tools or construct control flow, but the researchers argued that Python lacks the performance, security, and reliability features needed for this work.

Quasar adds automated parallelization, uncertainty tracking, and mechanisms for validating potentially unsafe actions. In the current implementation, the model writes a restricted subset of Python that is transpiled into Quasar. The researchers reported a 42 percent reduction in execution time when parallelization was possible and a 52 percent reduction in required approval interactions when its security mechanisms applied.

Quasar is not the final form of an agent-native language. The agent still emits Python-like code. But it demonstrates the pressure clearly: a language designed for people may not be the best execution model for agents.

Pel is another experimental language created specifically for orchestrating AI agents. It uses a minimal grammar and emphasizes constrained generation, capability control, inter-agent communication, safe execution, and automatic parallelization.

Pel is influenced by languages such as Lisp, Elixir, Gleam, and Haskell, but its design assumes that ease of reliable generation by a model is itself a language feature.

That is a meaningful change in priorities. Traditional language designers ask whether syntax is understandable to a person. Agent-native language designers may instead ask whether a model can generate it consistently, validate it mechanically, and recover from errors without human intervention.

Coding agents are also beginning to demonstrate that they do not need to learn unfamiliar languages the way humans do.

In a 2026 study of coding agents working with esoteric programming languages, leading agents frequently wrote Python programs that generated and debugged the unfamiliar target code. When researchers prohibited this metaprogramming strategy, performance declined substantially.

That is a primitive but important form of the future I am describing.

An agent can infer a target representation, build a generator for it, test the result, and revise the generator. It does not need to understand or maintain the target code in the human sense. The target language is simply another machine representation it can manipulate.

The first agent-native language may not look like a language

When people imagine a new programming language, they usually imagine new syntax.

That may be the least important part.

An agent-native language could be a structured representation of:

• desired behavior
• interfaces
• constraints
• permissions
• invariants
• tests
• resource limits
• performance goals
• security policies
• acceptable failure modes

The coding agent and compiler could jointly decide how those requirements should be implemented.

For one workload, the result might be native machine code. For another, it might be WebAssembly. For another, it might be a database query plan, a GPU kernel, a serverless function, or a composition of existing services.

There may be no permanent source file corresponding to the implementation.

The durable artifact would be the intent and the evidence that the implementation satisfies it.

This suggests a progression in three stages.

Stage one: Agents write human programming languages

This is where we are now. Agents produce code that looks like something a human developer could have written.

Stage two: Agents write machine-oriented intermediate representations

Humans primarily review behavior, tests, specifications, generated explanations, and changes in capabilities. The underlying implementation becomes less important to routine review.

Stage three: Agents generate executable systems directly

The source of truth becomes a collection of intent, policies, interfaces, constraints, and verification evidence. The agent generates and regenerates executable implementations as needed.

At that point, asking which programming language an application is “written in” may stop making much sense.

Human-readable does not mean human-auditable

The strongest argument against this future is that source code is not only used for writing software.

It is also used for debugging, auditing, governance, security review, maintenance, and accountability.

We cannot safely operate important systems whose behavior nobody can inspect.

But readable source code is already a weak substitute for actual understanding. A large modern application may contain millions of lines of first-party code and depend on millions more through packages, generated files, cloud services, operating systems, and firmware. Almost nobody understands the entire system.

Code can be readable without the system being comprehensible.

An agent-native system would need to provide stronger forms of inspection than a pile of source files. It could generate:

• explanations of specific behaviors
• maps of data movement
• proofs of important properties
• permission and capability reports
• dependency histories
• simulations of proposed changes
• executable tests
• records of why each decision was made
• human-readable implementations when necessary

The goal should not be to preserve readable code at all costs.

The goal should be to preserve human control.

Those are not the same thing.

The environmental cost of human-friendly code

There is another reason agents may eventually move beyond today’s programming languages: energy.

A widely cited 2017 study of energy efficiency across 27 programming languages compared runtime, memory use, and energy consumption across ten benchmark problems.

In its normalized results, Python consumed roughly 76 times as much energy as C and required roughly 72 times as much execution time. Python ranked near the bottom of the tested languages for energy efficiency.

This result has often been simplified into the claim that Python is one of the worst programming languages for the environment.

The reality is more complicated.

A 2024 reanalysis of programming-language energy efficiency found that these comparisons can conflate the language with its implementation, the quality of the benchmark program, the number of active processor cores, library behavior, memory activity, and other execution details.

After controlling for those factors, the researchers concluded that the programming-language implementation did not have a significant effect on energy consumption beyond execution time.

The central issue was not that the syntax of one language somehow consumed more electricity. Slower programs generally used more total energy because the hardware remained active longer.

That distinction does not make the problem disappear.

Standard Python is often much slower than optimized compiled code for computationally intensive work. A program that takes dramatically longer to perform the same job may consume dramatically more energy, even if the underlying processor draws power at a similar rate while executing it.

The good news is that the inefficiency is not unavoidable.

A 2025 study of compiled Python implementations compared CPython with several compilation and optimization systems, including PyPy, Numba, Codon, Cython, Nuitka, Mypyc, and Pyston-lite.

The researchers found that compilation could significantly improve execution time, memory use, and energy consumption. Codon, PyPy, and Numba produced speed and energy improvements of more than 90 percent on some of the tested workloads.

The more accurate conclusion is not that Python is inherently environmentally destructive.

It is that humans have often chosen programming languages based on human productivity while treating execution efficiency as a secondary concern.

Python is successful because it is readable, expressive, forgiving, and supported by an enormous ecosystem. In many organizations, saving developer time is worth spending additional computing time.

Agents do not face the same tradeoff.

A coding agent does not need friendly syntax to remain productive. It does not need a language that is easy to teach, type, or remember. It could generate a representation selected for the specific workload, compile it for the available hardware, measure the result, and replace it when a more efficient implementation becomes available.

Energy consumption could become a first-class property of programming rather than an optimization attempted after the software has already been written.

That matters because agents are not simply going to replace human-written code one line at a time. They are likely to increase the total volume of software produced and executed.

Agents can generate dozens of implementations, run thousands of tests, create disposable programs for individual tasks, and continuously regenerate working systems. Inefficiency that was tolerable when software was produced slowly by humans becomes more consequential when machines can generate nearly unlimited code.

The first agent-native language may therefore optimize for more than correctness and speed. It could consider:

• total energy consumption
• expected execution frequency
• available processors and accelerators
• memory movement
• compilation cost
• the carbon intensity of the available electricity
• whether a workload can be delayed or relocated
• whether an implementation will run once or billions of times

There may not be one universally optimal representation.

A one-time data conversion may favor minimal compilation overhead. A service expected to handle billions of requests may justify aggressive native optimization. A workload running on a battery-powered device may prioritize energy use over latency. A job operating in a data center could be scheduled around the availability of lower-carbon power.

An agent could make these decisions automatically.

Perhaps the environmental mistake would not be letting agents write unreadable code. It would be forcing them to keep writing Python simply because humans like reading it.

What becomes of the programmer?

None of this means humans stop building software.

It means our work moves upward.

Instead of spending most of our time describing implementation steps in a syntax designed for compilers, we will spend more time defining:

• what the system should accomplish
• what it must never do
• which tradeoffs are acceptable
• who can access what
• how success is measured
• how failures should be handled
• what evidence is required before deployment

That is still programming.

In many ways, it is more directly programming than manually translating those decisions into loops, classes, functions, and configuration files.

The role of the programmer becomes less about producing source code and more about establishing intent, constraints, architecture, and judgment. It is another reason I keep coming back to the idea that taste is the bottleneck once the building itself gets cheap.

The difficult part of software development was never typing the syntax. The difficult part was deciding what should happen.

Agents are removing the translation layer.

Who will create it?

The first true agent-native language may not be introduced at a developer conference.

It may not have a clever name, a public specification, or a community debating its syntax.

It may emerge quietly inside an agent platform as a private intermediate representation used for planning, generating, verifying, optimizing, and compiling software. It may initially target conventional languages and existing toolchains, then gradually bypass more of them.

By the time humans recognize it as a programming language, agents may already be using it to write a meaningful portion of the world’s software.

The winner will not necessarily be the language humans enjoy reading most.

It will be the representation agents can use to produce the most reliable, secure, efficient, and verifiable systems while still giving humans meaningful control over the result.

Programming languages were invented so humans could tell computers what to do.

The next one may be invented so computers can tell themselves.

← All postsNext: Scope Creep in the Age of AI →