Blaze

A research compiler written by LLMs. Compiles from a frontend language (Python/TypeScript) to the IR (internal representation) to a backend (C/machine code/WebAssembly).

Comment

About

Inspiration

Now that AI has become capable of coding we should raise our ambitions. Blaze is an experiment in writing a compiler for languages like Python and TypeScript, that generates very fast machine code (and other backends).

My research found that this is possible with the right approach.

What it does

The compiler uses an internal representation (IR) language to support multiple frontends compiled to multiple backends.

Use of AI (e.g. Nemotron models via Nebius Token Factory):

  • Programs can be compiled with an AI model specified in blaze.toml to perform compile-time optimizations. This is useful for logs to boost agentic coding.
  • The blazeup utility uses AI with the Pi SDK to automate coding loops that improve the compiler.
  • Agentic coding to continue developing the compiler.

A frontend supports a language like TypeScript or Python, but only a subset due to time and resource constraints. Backends are the output, with C and machine code the current focus.

Initial support for Nim and WASM backends is available, but not yet on par with the others due to time constraints.

To achieve this functionality Blaze has an IR notation. Frontend languages are first compiled to the IR, before the IR is compiled to the backend. This helps to reduce duplicated effort in the compiler.

Blazeup is included, a utility to improve the compiler by taking inputs such as related research papers identified by Tavily, build artifacts and compiler code introspection. It uses the Pi SDK, leveraging models such as Nemotron 3.5 Super VL, to suggest changes, and implemented and test them.

Every backend includes its own runtime services, e.g. common standard library functions.

Major features:

  • Python and TypeScript/JavaScript frontends (subset)
  • C and machine code backends (with initial Nim and WASM backends)
  • Incremental compilation
  • Optimized arithmetic
  • Dynamic values (any type)
  • JSON parse/stringify
  • HTTP server (via facil.io C lib)
  • SQLite support (via linked lib)

How we built it

Blaze is written using LLMs, with technical direction from myself.

Some of today's LLMs are high capable when it comes to writing and debugging complex, highly technical code. A good example is Nemotron 3.5 Super VL. It was also less likely to refuse large-scale changes.

I kept AGENTS.md lean, with a docs/specs dir available to the coding agent if it wanted to create or update internal specs.

Every program included output, usually based on algorithms, which was used to check for correctness of generated backend code used to produce the binary.

The main agentic coding loops used variations of:

  • Run a sample program correctly, add missing features to the compiler
  • Improve the performance of generated code for a sample program
  • Identify critical bugs, and fix them sequentially

Overcoming refusals on large-scale work used variations of:

  • Write a spec for the remaining work
  • Just start on the next part of the spec

Sometimes it was necessary to start a fresh session before starting on a large piece of work.

The blazeup utility aims to automate those loops (with input from Tavily).

To support the runtime, a fast embedded C http library was vendored: Facil.io (https://facil.io/).

Challenges we ran into

As Blaze is a new research compiler, adding new features to support building and running even simple programs was an ardeous task. The required work for each feature typically spanned frontend, IR and backends. There were also typically dependency trees for each new feature. This meant carefully choosing which programs to support in Blaze for the hackathon.

Smaller models could handle finding and fixing bugs in the compiler, and some of the small-scale work. However they often refused big implementations or changes. In those cases I had to make use of the more advanced LLMs. This was often through the use of stealth models which have been increasingly available.

The compiler's test suite contains over 1,200 tests, and takes some time to run. Making the test suite concurrent made it 1.8x to 2x faster.

The Nebius Token Factory doesn't use the prepaid model I'm familiar with. When utilizing Nemotron 3.5 Super VL through the platform, the account balance was not in sync with my usage in real-time. This led to an overspend of $68. My recommendation is that the platform adds an option to prevent going into arrears, preferably enabled by default.

Accomplishments that we're proud of

Blaze was only started recently (September 2026), and can compile a limited subset TypeScript programs into C or machine code.

I focused on programs in the Vercel benchmarks site: https://programming-language-benchmarks.vercel.app/

This helped to test Blaze's performance against languages such as C, Rust and Go.

Blaze has a test suite for compiler internals. This helps to validate that new fixes and changes don't cause logic or performance regressions.

What we learned

LLMs are sophisticated enough to write compilers. But to do this they need an approach which relies heavily on tests to verify their correctness.

What's next for Blaze

I'd like to keep advancing Blaze as a useful tool for generating highly optimized code for high-level languages use cases that have very high performance needs.

Future work:

  • Expand the support for large, complex Python and TypeScript applications.
  • Ability for the Blaze compiler to compile itself.
  • Full support for the WASM backend.
  • Full support for a Nimony (Nim v3) backend.

Built With

  • agentic-coding
  • nebius-token-factory
  • nextjs
  • tavily
  • typescript
Share this project:

Updates

Submission history