Rust is the language of the AGI

If an AI writes the code and a human assists it, what should a programming language optimize for? Ease of writing is no longer the only consideration. Michael Yuan opens with that reversal: Rust tools for AI coders first, their human assistants second.

His project, RustCoder, starts from a tension in Rust’s reputation. Around its tenth anniversary, Yuan describes Rust as having topped Stack Overflow’s most-loved-language results throughout its history. Yet admiration does not translate directly into wanting to use it. On the displayed 2024 Stack Overflow survey chart, Rust’s red admired marker is about 82%, while its blue desired marker sits below Python’s, though above Go’s. These measure different things: continued interest among existing users versus interest in using a language.

The obstacle is the learning curve. Rust’s type system and compiler reject classes of mistakes that a developer might otherwise discover later. That is useful, but it also means a beginner must understand more before getting a program through compilation. Yuan recalls encountering the same difficulty himself, followed by a point at which Rust made writing correct code feel easier. The initial cost and the eventual benefit come from the same enforcement.

For a human trying to get something working quickly, Python or JavaScript can offer an attractive tradeoff: less friction now, with some debugging or maintenance deferred. Yuan connects this to Bret Taylor’s conversation on Latent Space, which contrasts human-oriented language ergonomics with the needs of machine-generated software. Rust offers execution efficiency, structural rigor, and strong compiler checks even when those properties make it harder to write initially.

The compiler gives a code generator a concrete signal about what to change next. Yuan describes the familiar Rust experience of spending substantial effort reaching a successful build, then finding fewer problems afterward. The important boundary is that compilation checks language constraints, not whether the application does what its user intended. A program can compile and still calculate the wrong answer. Within that boundary, compiler diagnostics provide a much tighter repair loop than asking a model whether its own answer looks plausible.

Yuan extends that feedback argument to reinforcement learning, invoking DeepSeek, AlphaGo, and AlphaZero as reference points. Compiler acceptance can serve as a reward signal: generate a candidate, evaluate it with an external checker, and use the result to improve the next candidate. This is his proposed advantage for Rust code generators, rather than a description of a RustCoder training run.

The language choice changes further if generated code becomes difficult for humans to read. Human readability is a major reason to choose Python or JavaScript; producing incomprehensible code in those languages gives up that advantage. Yuan’s alternative is to favor a language whose generated output is amenable to mechanical checking while remaining reasonably accessible to human maintainers.

RustCoder’s immediate goal is to teach AI systems to generate better Rust. Yuan describes support from two Linux Foundation internship grants, comparable in structure to Google Summer of Code, and the use of educational materials he attributes to the Rust Foundation. The intended users split into two groups: humans learning Rust or working in an IDE, and machines generating code on demand. For the latter, a model could execute a plan by producing a program rather than relying exclusively on existing API calls.

The initial retrieval pipeline begins with educational material. Interns derive several hundred tasks that Rust developers commonly encounter, create embeddings, and place them in a vector database. A programming question can then retrieve relevant material to support a Rust answer. The knowledge base supplies examples and context; the model still has to adapt them to the requested task.

The first demonstration asks Qwen Coder, running on a Gaia network node, to solve a number-base conversion problem from Cursor. The interaction proceeds in a deliberate order:

1. Supply the programming question.
2. Add examples pairing inputs with expected outputs.
3. Explicitly request a Rust implementation.
4. Send the prompt to the Gaia node.

The explicit language instruction prevents the assistant from defaulting to Python or JavaScript.

The response includes both code and an explanation of its data structures and functions. Yuan copies the generated program into the editor and runs cargo run, which compiles and executes it; the demonstration produces the expected result.

For a compact base-conversion example, consider converting decimal 42 into binary and hexadecimal. Repeated division produces digits from least significant to most significant, so the implementation reverses them before returning the result:

fn to_base(mut value: u64, base: u32) -> Option<String> {
    if !(2..=36).contains(&base) {
        return None;
    }
    if value == 0 {
        return Some(String::from("0"));
    }

    let alphabet = b"0123456789abcdefghijklmnopqrstuvwxyz";
    let mut digits = Vec::new();
    while value > 0 {
        let remainder = (value % u64::from(base)) as usize;
        digits.push(char::from(alphabet[remainder]));
        value /= u64::from(base);
    }
    Some(digits.into_iter().rev().collect())
}

fn main() {
    assert_eq!(to_base(42, 2).as_deref(), Some("101010"));
    assert_eq!(to_base(42, 16).as_deref(), Some("2a"));
    assert_eq!(to_base(0, 10).as_deref(), Some("0"));
    assert_eq!(to_base(42, 1), None);
}

The assertions make the input/output contract concrete, just as the demonstration’s examples constrain the requested answer.

Yuan reports that over 1,000 developers used the project in a university-based Rust camp. He describes essentially all comparable exam questions as answerable in one shot, with explanations that help learners explore further. That broad statement should be read alongside the project team’s published case study: it documents selected first-attempt successes, including base conversion, but also reports difficulty with harder semifinal problems. The demonstration establishes a successful learning interaction, not an aggregate exam pass rate.

The next step moves beyond answering a prompt with a retrieved example. RustCoder exposes an MCP server that Cursor can use to generate projects and repair existing ones. In the demonstration, the server runs locally on port 3000 and exposes two tools.

Generate draws on stored algorithms and use cases. Compile and Fix instead receives the project in the IDE’s context and delegates compilation to the server’s own Rust compiler. Its coding model then uses the resulting errors to attempt a repair.

The repair loop is straightforward:

1. Compile the received project.
2. If compilation fails, give the diagnostics and source to the coding model.
3. Apply a candidate repair and compile again.
4. Return the resulting project when compilation succeeds, or stop when the configured attempt budget is exhausted.

Yuan explains the loop as repeating until it works. The current repository documents bounded attempts through max_attempts; its documented payload examples below describe the current interface, rather than a pinned version of the recording. Iteration provides opportunities to recover, not a promise of eventual success.

The repair demonstration uses a deliberately small project: a program intended to print Hello, world!, with missing closing syntax. Yuan places Cargo.toml and src/main.rs in Cursor’s context and asks it to compile the project and fix the compiler errors. Cursor selects Compile and Fix; Yuan authorizes the tool call, receives the syntax repair, and accepts the change. The program can then compile.

Inspecting the tool exchange reveals the important contract. The request contains filename-delimited sections: first Cargo.toml and its contents, then src/main.rs and its broken source. The response returns the entire corrected package, not merely an explanation or a patch. Cursor’s own model compares that returned source with the editor’s files and turns the difference into a proposed edit. The repair service returns a project; the IDE manages applying it.

A missing delimiter is not a persuasive test of specialized Rust expertise. Yuan acknowledges that Cursor’s existing compiler integration and a model such as Claude could likely solve this example. His proposed advantage lies in packaging the compiler with a Rust-specific knowledge base, prompts, and a coding model. Error examples associate a diagnostic with code that triggers it and a corresponding repair. When the service cannot fix a problem, a successful alternative from Cursor or a human can supply another useful example.

In this setup, Gaia and LlamaEdge run Qwen Coder. Yuan expects this integrated specialization to outperform generic coding assistants on more complex Rust work, but the small syntax demonstration does not measure that comparison. The proposed improvement comes from making the components work together and expanding what the system can retrieve.

The model is configurable: a deployment can use a commercial or open-source coding model. Prompts must match the selected model’s format. Yuan uses Gemma 3 as an example: its native instruction-tuned conversation format places system-level instructions in the initial user message. Other models can accept instructions and code context through a system message. This is a formatting distinction, not an inability to follow system-level instructions.

The compiler-error knowledge base remains incomplete. Its useful unit is a concrete relationship—this source pattern produces this diagnostic, and this edit repairs it. Community contributions can extend those relationships so retrieval supplies relevant examples for increasingly complex errors. Yuan presents that growing coverage as a long-term goal, rather than demonstrating an automatic learning mechanism in the IDE session.

Underneath the repair service, Yuan describes LlamaEdge as a runtime based on a Linux Foundation project. He positions it as broader than an LLM-only runner: alongside language models, the examples include YOLO, Whisper, text-to-speech models, and Stable Diffusion, across GPUs and NPUs. His analogy is to a general model-execution environment such as Python, rather than only to llama.cpp or Ollama.

Yuan describes the LlamaEdge runtime as tens of megabytes, compared with gigabytes for a PyTorch environment. The comparison concerns runtime footprint, not model weights, and does not specify matched versions or dependency boundaries.

The remaining layers divide responsibility:

• Full-text retrieval: Elasticsearch and TiDB are named as search options.
• Vector retrieval: Qdrant stores searchable embeddings, with a choice of embedding models.
• Packaging: Gaia Network combines the inference and knowledge-base capabilities on LlamaEdge.
• Tool exposure: An open MCP proxy presents the resulting service to MCP clients.

This separates model execution from retrieving Rust knowledge and from the interface through which an IDE or agent invokes the service.

So far, the visible beneficiary is a human: a learner receives an explanation, or a developer accepts a repair in Cursor. Yuan’s larger interest is the consumer on the other side of the tool interface. Web, desktop, and mobile interfaces are designed for human eyes and fingers; multitouch makes that physical assumption especially clear.

API-first software shifted the immediate consumer to another program or workflow engine. Stripe’s payment APIs and Twilio’s telecom services illustrate how a capability can be delivered without owning the application’s primary user interface. LLM tool use introduces another consumer: a model that can interpret a task and choose a service, rather than following only a predetermined workflow. RustCoder exposes compilation and model-assisted repair for that consumer.

Yuan’s proposed drone application makes the distinction concrete. An MCP server’s knowledge base would include the drone SDK’s Rust crate. A model would generate code describing where to fly and how to respond under specified conditions, send it through compilation and repair, and upload the resulting program to the drone. This is a long-term autonomous execution vision, not a demonstrated deployment. Compiler checks would constrain the generated program, but safe flight and correct mission behavior would still require validation beyond compilation.

RustCoder belongs to LowCodeRust, a collection of Rust tools for computers. Its two interfaces serve different callers: APIs fit deterministic programs and workflow engines, while MCP lets language models discover and invoke tools. Both can participate in an autonomous-agent system.

The deployment path Yuan describes is to clone the repository, configure the coding model, and start the supplied Docker Compose stack on a machine with Docker Desktop:

docker compose up

Compose starts the containers, connects to the specified model, and brings up the included vector database and service APIs.

Generation accepts a JSON object with description and requirements. For the Hello World project used earlier, a request body can be as small as:

{
  "description": "Create a Rust command-line application",
  "requirements": "Print Hello, world! and exit successfully"
}

The result contains the project files. A downstream caller must separate and save them; Cursor already performs that role when it recognizes filenames in the returned text. A workflow engine needs equivalent file-handling logic.

Repair takes the reverse path: combine the existing files into one text payload, send it for compilation and repair, and receive the whole project in the same format. Current documentation uses markers such as [filename: Cargo.toml] and [filename: src/main.rs]; the repair request carries the project in code, and the response provides it in combined_text.

For example, a complete corrected Hello World package can be represented as:

[filename: Cargo.toml]
[package]
name = "hello"
version = "0.1.0"
edition = "2021"

[filename: src/main.rs]
fn main() {
    println!("Hello, world!");
}

Preserving filenames lets the next component reconstruct the package after the compiler-and-model loop finishes.

The same capabilities are available through MCP without Cursor. Yuan points to a command-line MCP client in the documentation and then to integration with agent frameworks. Once the server is connected to a framework, generation and repair become ordinary tool choices: the model decides when it needs new Rust code and when it should send an existing project for compilation and fixes.

At the time of the talk, RustCoder is a work in progress, with its second Linux Foundation internship still underway and progress tracked on GitHub. Yuan’s contribution priorities follow directly from the architecture: enlarge the knowledge base, improve the system’s ability to repair Rust, and expose more functionality for other agents to use. His thesis that AI coders offer a path toward AGI ends with that practical task—make generation and compiler feedback useful enough that another machine can reliably build on them.