Summary

Elon Musk recently said, “The next step is getting rid of “source code” entirely and just making an efficient binary directly with AI.” I largely experimented with this idea through my Athena project a few years ago, in which fine-tuned large language models directly generated optimized x86 assembly code. Although successful as an experiment, I found this to be, in the long-term, an infeasible approach to software engineering and, more directly, a bad idea. Assembly gives a model direct access to hardware and memory while removing many of the safety guardrails, abstractions, and validation opportunities provided by interpreters and compilers that make software understandable and dependable. A small hallucination can lead to memory corruption, a security vulnerability, or a program that appears correct while failing in ways that can be extraordinarily difficult to diagnose. Depending on what specific kind of assembly code is being generated, it can also very potentially lead to permanent hardware damage, and even literal physical destruction (unsafe voltages/power states, permanently degrading silicon). Although that last claim is a bit of a stretch, it's certainly in the realm of possibility for hallucinatory LLM outputs.

I now believe a better direction would be an agent-first compiled programming language. It would be a high-to-medium level language designed around the behavioral strengths, limitations, and fundamental architectures of LLMs and LLM-based programming agents while remaining readable, reviewable, and editable by humans.

For clarity and cognitive convenience, I will refer to the proposed agent-first programming language as tensorlang throughout this proposal.

LLMs/LLM-powered agents would write source code in tensorlang. The tensorlang frontend would parse and validate that source before lowering it into a tensorlang-specific typed intermediate representation. An early implementation could translate this IR into LLVM IR and use LLVM's existing processor-specific code generators to compile efficient native code for x86_64, AArch64, and other instruction sets. An additional or alternative early path could be transpiling tensorlang IR into C and then use an existing C compiler to produce native code. The long-term goal would be a compiler built from the ground up in which separate processor-specific code generators translate the shared tensorlang IR into native assembly. This would allow the tensorlang compiler to control code generation end-to-end while keeping parsing, type checking, semantic analysis, and processor-independent optimization shared across architectures. Compared with standardizing the direct generation of machine code by LLMs, I believe my proposal is a significantly superior approach (and this is an extreme understatement), for a myriad of reasons that I think should be obvious to most engineers.

Tensorlang should make it easier for agents to translate intended behavior into efficient logic with fewer unnecessary syntactic decisions and less opportunity for error in general, while keeping the resulting code readable and reviewable by humans. It should favor compact and maximally unambiguous syntax, explicit behavior, strong static guarantees, deterministic tooling, structured diagnostics, and a small number of canonical ways to represent common operations. The goal is to give agents, which are very obviously and undeniably taking over software engineering, a more natural way to write high-level logic, designs, and system behavior in a form that remains feasibly readable, debuggable, and auditable by people. Whether that level of simplicity and clarity is meaningfully achievable without significantly sacrificing human readability is perhaps an open question, though regardless, the design should optimize for directness, precision, and should be structured in a way most efficient for the nature of large language models.

Rationale and Motivation

Most established programming languages give an agent many ways to express the same operation. A collection might be traversed with a for loop, a while loop, an iterator, map, forEach, a comprehension, or a library-specific helper, each with different rules and failure modes. A function name may refer to several overloads, a value may be silently converted to another type, and an imported package may expose hundreds of similarly named methods. The model must spend tokens (especially in its reasoning process/thinking blocks) choosing among these possibilities and can produce code that looks reasonable while calling a nonexistent API, selecting the wrong overload, capturing a value incorrectly, or relying on behavior that is only implicit.

At a more fundamental level, tensorlang should be designed around how an autoregressive LLM actually produces code, one token at a time, with each new token predicted from the tokens currently in context. The objective should therefore not merely be to make programs shorter. It should be to reduce uncertainty at each step of generation. After an agent begins a function declaration, condition, loop, or operation, the syntax rules should sharply constrain what can validly follow and make the most likely continuation correspond to the correct structural continuation.

This should extend below the visible syntax to tokenization itself. Semantically meaningful units such as keywords, operators, delimiters, primitive types, and common control structures should have stable boundaries instead of being unpredictably divided into different subword fragments by spacing or context. If tensorlang is paired with a fine-tuned model, its tokenizer could be designed alongside the syntax. If tensorlang is intended for existing models, its lexical forms should be tested across their tokenizers and chosen to remain as stable and economical as possible. Research into code-tokenization drift has found that formatting and identifier changes which preserve a program's meaning can still substantially change model behavior because the resulting token boundaries differ.

The syntax should also be prefix-local. Earlier source should not acquire a different meaning because of syntax written much later, and an invalid continuation should become detectable as soon as it is emitted. Declarations, types, effects, invariants, and resource ownership should remain close to the code they govern so that generating or modifying a function does not require reconstructing important facts from distant files or hidden global state.

The compiler could participate while the agent is generating the program rather than only after generation ends. At any source position, it could expose the syntactic forms, symbols, types, fields, capabilities, and operations that are valid in the current environment. The agent's decoder could then exclude continuations that cannot possibly form a valid program. Grammar-constrained decoding research already demonstrates how token masks can prevent syntactically impossible output. A language designed for this process from the beginning could make those constraints simpler, faster, and more semantically useful.

Illustrative Syntax Experiment

Tensorlang's syntax has not been designed, but a small hypothetical comparison can demonstrate what should be investigated. Consider a function that reads and parses a configuration file. A conventional Python implementation might look like this.

def load_config(path: str) -> Config:
    with open(path, "r", encoding="utf-8") as file:
        text = file.read()
    return Config.parse(text)

Rust already expresses ownership and typed errors compactly.

enum ConfigError {
    Io(std::io::Error),
    Parse(ParseError),
}

fn load_config(path: &std::path::Path) -> Result<Config, ConfigError> {
    let text = std::fs::read_to_string(path).map_err(ConfigError::Io)?;
    Config::parse(&text).map_err(ConfigError::Parse)
}

An experimental tensorlang form could make the same operation and its external capability explicit in the function contract.

error ConfigError includes [IoError, ParseError]

function load_config(path borrowed Path) returns Result<Config, ConfigError>
requires [Filesystem.Read]
{
    text owned Text = try Filesystem.read_text(path)
    config owned Config = try Config.parse(text)
    return Ok(config)
}
end function

The tensorlang example merely illustrates a possible direction. Each try would unwrap a successful result or immediately propagate a compatible ConfigError, while Ok(config) would satisfy the declared return type. Prefix try commits to error propagation before the fallible expression is generated, unlike Rust's postfix ?, making the intended continuation visible earlier in left-to-right generation. The delimiters make parameter lists, type arguments, capabilities, calls, and block boundaries locally visible.

The effect declaration becomes more useful when another function calls load_config but fails to declare the required capability.

function start(path borrowed Path) returns Result<Config, ConfigError>
requires []
{
    return load_config(path)
}
end function

The compiler could reject that call and return a stable diagnostic that is readable by both the agent and a person.

error E_EFFECT_MISSING
location start line 4
call load_config(path)
missing [Filesystem.Read]
repair add Filesystem.Read to requires of start

This exposes transitive effects without requiring the agent to inspect every implementation in the call chain. Rust can encode comparable capabilities through handle types, sealed traits, module privacy, or explicit parameters. The distinction is that these patterns are manual and optional in Rust, while tensorlang would investigate making effects mandatory and automatically propagated. Whether that difference materially benefits agents is an open research question.

The tensorlang version is not shorter than the Rust version. Its proposed advantage is that more of its structure is available to the compiler, the agent, and grammar-constrained decoding as the function is generated. The English keywords may also align more reliably with existing model tokenizers than novel symbolic syntax, though this must be measured rather than assumed. The example deliberately uses both braces and end function so experiments can determine whether a redundant named closing marker improves structural synchronization and error recovery enough to justify its token cost. These choices should be evaluated under the comparative benchmarks described later.

The strongest alternative to a new language would be a restricted Rust profile with mandatory effect annotations, a deliberately reduced standard-library surface, deterministic tooling, and an agent-oriented diagnostic protocol. That alternative would retain Rust's ecosystem while addressing much of the ambiguity identified in this proposal. Tensorlang would likely only be justified if its tokenizer-aware syntax, mandatory semantics, and compiler-integrated generation constraints produce meaningful gains beyond what this restricted Rust profile can achieve. Restricted Rust should therefore be the primary baseline rather than a weaker comparison chosen to make tensorlang look favorable.

These lower-level properties should still produce recognizable source code rather than an opaque model protocol. A human would continue to see named functions, variables, types, conditions, loops, and ordinary block structure. The textual representation would also act as a predictable projection of the program's structure. It would remain easy for a person to read while being deliberately shaped around token boundaries, sequential generation, limited context, and incremental validation.

At the language-semantics level, common operations should have one clear, standard representation, and every function should state its input types, output type, possible errors, external effects, and ownership of memory or other resources. File access, network access, mutation, allocation, and concurrency would be visible directly in otherwise familiar high-level source code. If an agent passed text where a byte buffer was required, used a value after transferring its ownership, or called a function without declaring its filesystem capability, the compiler could return a stable error code with the exact source span, violated rule, expected form, and machine-readable repair options. Tensorlang would leave substantially less unstated for either the person or the model to infer.

The tensorlang compiler should then enforce strong rules around types, bounds, initialization, control flow, and memory safety before a generated program can run. When it rejects code, it should return both a clear human explanation and structured information that an agent can act on, including a stable error identifier, the exact source location, the rule that was violated, and valid ways to repair it. Preconditions, postconditions, invariants, tests, and performance requirements should also be written alongside the code they constrain instead of being left in external documentation or implied by convention.

It should go without saying that formatting, dependency resolution, and builds must be deterministic so that identical inputs always produce the same normalized source and output. The core language specification should remain small enough for a person or agent to inspect and reason about as a whole, without requiring either to navigate decades of exceptions, aliases, and legacy behavior.

Unlike Athena and Elon Musk's aforementioned suggestion, tensorlang would not make the LLM responsible for selecting or sequencing raw processor instructions. This should have been extremely obvious already, but it is important enough to state explicitly. The LLM would generate human-readable tensorlang source. The deterministic toolchain would validate that source, lower it into tensorlang IR, and then translate the IR through LLVM, C, or tensorlang's own processor-specific code generators. This preserves tensorlang's safety and semantic guarantees while keeping probabilistic generation away from direct control over machine instructions.

The first implementation, as implied, should use a deliberately small tensorlang core and target x86_64 and AArch64 by translating tensorlang IR into LLVM IR or C. Once the frontend semantics and tensorlang IR are validated, custom x86_64 and AArch64 code generators should progressively take over assembly generation from that same IR. Adding another instruction set would require a new processor-specific code generator rather than a rewrite of the frontend or processor-independent optimization pipeline. Research should compare agent performance in tensorlang against established systems languages across compilation success, correctness, security defects, token usage, repair iterations, execution speed, binary size, and human review time. It should also measure tokenizer fragmentation, uncertainty among valid next tokens, how quickly invalid prefixes are detected, and how much distant context an agent needs to generate or modify a function correctly. The research and engineering results should determine whether an agent-oriented language produces a meaningful improvement rather than assuming that syntactic novelty alone is valuable.

Limitations and Requirements

Designing a language for agents introduces the risk of optimizing for the behavior of current models, benchmarks, or prompting methods that may rapidly change in the near future. Tensorlang must therefore be based on concrete software-engineering properties such as clarity, determinism, verifiability, safety, and composability, as well as general/broad LLM architecture and behavior rather than quirks of one model family. This is especially important, otherwise you will end up with a language optimized and highly efficient for GPT 5.6 Sol, but considerably less efficient with Claude Opus 5. Human readability must remain a core requirement and priority, so that people can audit, debug, modify, and ultimately remain responsible for the software produced. It's also just important to be able to see code in general, and have confidence in it. This is especially true for systems in high stakes environments. You need to know what your LLM-generated code is actually doing if it's going to be controlling life support systems in a spacecraft, stabilizing an aircraft mid-flight, or guiding surgeons and/or measuring data during a heart transplant.

Tensorlang should make departures from its safety model structurally obvious. Foreign-function interfaces, inline assembly, filesystem access, network access, subprocess creation, and other external capabilities should be explicit and narrowly scoped in tensorlang source. The tensorlang IR should retain those restrictions so every code-generation path can enforce them consistently. Dependencies should be pinned and attestable so that an agent cannot quietly change the effective program by selecting a different package version or source.

Tensorlang IR should preserve ownership, aliasing, effects, overflow behavior, alignment, capability restrictions, and other semantics that would be expensive or impossible to reconstruct later. The LLVM and C paths must translate those concepts without weakening tensorlang's guarantees, while tensorlang's custom processor-specific code generators can consume the IR directly. Compatibility with existing libraries will also require restraint, since importing their overlapping APIs and implicit behavior could recreate the ambiguity tensorlang is intended to remove.

Tensorlang would begin with effectively no natural training corpus, while models have absorbed enormous amounts of Python, C, C++, and Rust. This disadvantage could overwhelm every theoretical benefit described in this proposal. A bootstrap corpus could combine mechanically translated programs, compiler-validated synthetic programs, equivalent implementations in established languages, generated diagnostics and repairs, and human-reviewed examples. Evaluation must give tensorlang and the restricted Rust baseline matched treatment, including comparable corpus quality, corpus size, fine-tuning compute, task exposure, and inference conditions. In essence, poor model familiarity could sink this proposal, but this is likely to be more of a short-term problem.

The project must define “optimized for agents” through measurable outcomes. Tensorlang should be evaluated according to invalid generations, repair cycles, defect rates, tokenizer fragmentation, next-token uncertainty, dependence on distant context, runtime performance, and human comprehensibility in comparison with restricted Rust and other suitable established languages. The purpose of this research would be to determine whether tensorlang provides meaningful benefits and which design choices, if any, are responsible for them.

Benefits for Humanity

If successful, tensorlang could let agents produce efficient native programs through a representation shaped around their actual generation process while preserving a source artifact that humans can inspect and modify. Its value would come from reducing the distance between an agent's intended behavior and a valid implementation without surrendering that implementation to raw machine-code generation.

More reliable agent-authored software could lower the cost of specialized tools for science, engineering, education, accessibility, and public infrastructure. Native compilation could also make those tools practical on constrained hardware and in environments where cloud-dependent runtimes are undesirable.

The broader benefit would be a purpose-built interface between probabilistic generation and deterministic execution. That interface is likely to be substantially more valuable than attempting to eliminate source code altogether, which, again, is a bad idea (at least given our current form of computing) for a variety of reasons that should be painfully obvious.

Additional Comments

This proposal treats AI agents as a distinct class of programmer whose needs can be studied and optimized for without making the code they produce opaque to humans.

The most important early work would be empirical. A minimal compiler, agent-facing diagnostic protocol, small standard library, and controlled benchmark suite should be enough to test the central hypothesis. Multiple model families should attempt identical implementation and repair tasks in tensorlang and comparable established languages. The evaluation should retain prompts, reasoning traces where available, generated source, compiler feedback, repair sequences, native output, execution metrics, and blinded human review results.

Athena demonstrated that an LLM's ability to produce correct assembly code does not make raw instruction generation a sound software-engineering model. Tensorlang keeps the useful ambition of efficient native programs authored by agents while retaining a representation that humans can understand, verify, and govern.