DEV Community: Hoàn Lương

Building Autolang: A Scripting Runtime for Lightweight AI-Generated Code

Hoàn Lương — Sat, 08 Aug 2026 16:03:55 +0000

Building Autolang: A Scripting Runtime for Lightweight AI-Generated Code

I have some projects but I don't have much money, so I often use Gemini Flash for UI tasks and some features.

Gemini Flash is very fast and cheap, but sometimes it is surprisingly unreliable.

It can hallucinate members or functions that don't exist, or use as any just to make everything look OK.

This made me think about a problem.

Lightweight models are becoming extremely cheap, and I want to use them in my products. But if the models are going to generate code, maybe the solution isn't always to use a larger model.

What if the runtime itself was designed around the weaknesses of lightweight models?

That is how I started building Autolang.

Project: https://autolang.vercel.app
Documentation: https://autolang.vercel.app/docs

What is Autolang?

Autolang is a scripting runtime library rather than a general-purpose programming language.

I am building it as a small runtime sandbox for AI-generated code.

The basic idea is:

Developer-defined capabilities
            ↓
       AI-generated script
            ↓
       Autolang Compiler
            ↓
          VM / Runtime

The developer decides what the AI can access.

For example, instead of exposing:

Database.query(...)

I would prefer exposing something more constrained:

Products.getProducts()
Users.getUsers()
Orders.getRecentOrders()

The AI can write the business logic, while the developer controls the capabilities available to it.

This also means the generated script doesn't need access to an entire database API or operating system.

Why build another language?

The main reason is not that I think another programming language is necessary for humans.

I am interested in compilers, so Autolang is also a project for me to learn about compiler and runtime design.

But I also want to explore whether a language can be designed around AI-generated code.

For example, static typing can provide the model with much better feedback when it generates something incorrectly.

Instead of:

something went wrong

the runtime can provide a stack trace and a type error that gives the model enough information to fix its code.

This is especially interesting for cheaper models, which may make mistakes more frequently.

Some of the features

Autolang currently has or is designed around several features:

Static typing
Stack traces
Runtime error information
Opcode limits
Managed VM memory
Native function bindings
Developer-controlled capabilities
A small standard library
No need for generated scripts to install new packages

The syntax is statically typed and is inspired by languages such as Kotlin and TypeScript.

For example:

Products.getProducts()
    .filter { |product| product.remaining }
    .forEach { |product|
        ...
    }

I want generated code to be relatively compact because the AI shouldn't need to generate package installation code or large amounts of boilerplate.

The language includes features such as ?., ??, !., as, is, fun, closures, and standard libraries.

Developer-defined bindings

One of the most important parts of Autolang is the binding system.

A developer can define a library that the Autolang program can use:

compiler.registerBuiltInLibrary(
  "company/database",
  `
    class Product(
      remaining: Bool
      price: Int
    )

    @js_object
    class Products {
      @native("get_products")
      fun getProducts(): Array<Product>
    }
  `,
  { autoImport: true },
  {
    get_products() {
      // Native implementation
    }
  }
);

The Autolang VM keeps the type information.

So when the native function returns products, the VM knows that the result is:

Array<Product>

This is different from simply exposing a generic JavaScript function and letting the generated code do whatever it wants.

If more complex objects are needed, they can also be represented as native JavaScript objects:

@js_object
class Product {
    @native("get_price")
    fun getPrice(): Int

    @native("is_remaining")
    fun isRemaining(): Bool
}

The developer decides which operations are exposed.

An example

A TypeScript application can compile and execute an Autolang script:

await compiler.compileAndRun(
  "main.atl",
  `
    var expenseCount = 0
    var normalCount = 0
    var cheapCount = 0

    Products.getProducts()
      .filter { |product| product.remaining }
      .forEach { |product|
        when (product.price) {
          >3 -> expenseCount += 1
          ==3 -> normalCount += 1
          else -> cheapCount += 1
        }
      }

    println(...)
  `
);

console.log(compiler.getOutput());

The important part is that the AI doesn't need to know how the database works.

It only needs to know that Products.getProducts() exists and what type it returns.

The developer keeps control over the actual native implementation.

Why not tool calling?

This is probably the first question people ask.

I don't see Autolang as a replacement for tool calling.

Tool calling is useful when the model needs to interact with external systems.

I am interested in situations where the model needs to perform a lot of computation or data processing after obtaining the data.

For example, imagine an internal SME application with:

Users.getUsers()

and the AI needs to classify hundreds or thousands of users:

VIP
NORMAL
INACTIVE

With a tool-calling approach, repeatedly sending requests between the model and the application can introduce additional latency and cost.

Instead, the application could expose the data to an Autolang script and let the script perform the processing inside the runtime.

So the model generates the logic once, rather than requiring a round trip for every individual operation.

Why not JavaScript, Python, or isolated-vm?

JavaScript and Python are general-purpose programming environments.

isolated-vm provides isolation for JavaScript.

Autolang is trying to solve a somewhat different problem.

I want the language itself to be small, statically typed, constrained, and predictable for generated code.

The runtime knows about:

Types
Opcodes
VM memory
Native bindings
Runtime errors
Stack traces

The goal is not simply to execute untrusted JavaScript.

The goal is to create an environment where an AI can generate a small script using a set of capabilities explicitly provided by the developer.

Is it a replacement for Docker or KVM?

No.

I don't intend Autolang to replace Docker, KVM, microVMs, or operating-system-level isolation.

Autolang is much more focused:

AI-generated code
        ↓
Developer-defined capabilities
        ↓
Autolang runtime
        ↓
Controlled execution

It is intended to be a sandbox for AI-generated scripts that operate through bound functions.

For applications that require strong OS-level isolation, I would still expect technologies such as containers or VMs to be appropriate.

Memory and runtime size

One of my goals is to keep the runtime small.

The current Autolang instance uses about 0.5 MB with the full standard library enabled.

A 1,800-line test peaked at around 3.8 MB on Windows 11.

These are early measurements rather than formal benchmarks, but they are encouraging for the kind of lightweight runtime I am trying to build.

A possible use case

The main use case I currently have in mind is internal SME software.

For example, an application might expose:

Users.getUsers()
Products.getProducts()
Orders.getRecentOrders()

Then an AI could generate small programs to answer business-specific questions:

Which customers are likely to be VIPs?

Which products are running low?

Which customers haven't ordered recently?

Which orders look unusual?

The developer doesn't need to implement every possible analysis as a separate feature.

Instead, the developer provides safe capabilities and lets the AI generate the logic.

That could potentially reduce development time for internal tools where requirements change frequently.

What I am still unsure about

Autolang is still an experiment.

I don't know yet whether this is actually better than simply using JavaScript, Python, or existing sandboxing solutions.

I also don't know how much the AI-friendly type system and error reporting will actually improve the reliability of lightweight models in practice.

That is one of the reasons I am building it.

I want to find out whether a small runtime designed around AI-generated code can provide a useful middle ground between:

"Let the AI run arbitrary code"

and

"Make every operation a separate tool call"

For now, Autolang is both a compiler/runtime project I enjoy working on and an experiment in making cheap AI-generated code easier to execute safely and predictably.

If you are interested in the implementation, the project and documentation are here:

Project: https://github.com/hoansdz/Autolang

Documentation: https://autolang.vercel.app/docs

We built a scripting language just for AI agents. Here's why.

Hoàn Lương — Mon, 25 May 2026 13:41:22 +0000

One of our AI agents deleted a directory it was never supposed to touch. The Python it wrote was valid. The model was confident. It did the wrong thing.

The agent was only supposed to query a database. But we gave it a full Python runtime, so it had access to os, shutil, everything. That's when we realized the problem wasn't the model — it was us handing it way too much power.

Why sandboxing is harder than it looks

The usual options aren't great:

Full runtime (Python/Node.js): easy to set up, hard to lock down properly. Restricting it after the fact is whack-a-mole.
Docker per agent: proper isolation, but ~200ms cold start and 100MB+ RAM each. At 50 concurrent agents that's 5GB just idling.

We wanted something lighter. Not "restricted Python" — something designed from scratch for how AI actually writes code.

AI code has a specific profile

After running a lot of agent scripts in production, the pattern is pretty consistent:

Under 100 lines almost always
Runs frequently, not once
Doesn't need filesystem, network, or OS access
Tends to produce infinite loops, wrong types, null accesses

General-purpose languages aren't built for this. So we built Autolang — a small scripting VM where AI can only call functions you explicitly registered. Nothing else is reachable.

How it works

AI writes Autolang script
    → static compiler validates types and scope
        → your registered JS / C++ functions do the actual work

You wrap your existing functions as bindings. The AI calls those. That's it. It can't reach outside what you've registered.

Here's a real example — register a database binding:

compiler.registerBuiltInLibrary("company/products", `
  class Product (val name: String, val price: Int, val inStock: Bool)
  class Database {
    @native("get_products")
    static func get_products(): Array<Product>
  }
`, { autoImport: true }, {
  "get_products": () => fetchFromYourDB()
})

The AI then writes something like:

@import("company/products")

val affordable = Database.get_products()
  .filter {|p| p.inStock && p.price <= 30 }

affordable.forEach {|p| println("- ${p.name}: $${p.price}") }

It can't touch anything outside company/products. If it writes an infinite loop, the opcode limit kills it before it hangs your process.

The numbers

	Native	npm
Cold start	~10ms	~20ms
Warm start	1–2ms	2–4ms
RAM per instance	~4MB	~12MB

50 concurrent agents: ~200MB total. Docker would be 5GB+.

When it makes sense

Good fit if you're running 5+ concurrent agents, scripts are short and frequent, and you want controlled access to existing functions without rewriting them.

Probably not worth it if you have only a handful of agents, need OS-level security guarantees, need Python bindings (not ready yet), or your AI writes long complex programs.

npm install autolang-compiler

Github: https://github.com/hoansdz/Autolang

Philosophy: autolang.vercel.app/docs/philosophy-vision

Live editor: autolang.vercel.app/docs/editor

Curious how others are handling this. What's your current setup for sandboxed agent code?