AI-First Programming Languages: What They Are, and Whether You Should Use One Yet

There's a language whose compiler doesn't print error messages. It prints JSON.

Not JSON as an option behind a --format flag, which most compilers have had for years. JSON as the only thing it emits. No English prose explaining what went wrong, no helpful little arrow pointing at the offending token, no suggestion phrased as a sentence. Just a stable error code, a source location, and a typed repair hint.

That's Zero, which Vercel Labs released in May. The reasoning behind it is blunt: the thing reading your compiler output is no longer a person, so why is it still writing for one?

Zero is one of a whole crop of projects that appeared in roughly the last twelve months around the same idea. Collectively they've picked up the labels "AI-first" and "AI-native", and if you haven't been following closely they're easy to dismiss as a gimmick. Some of them are. But the category is real, one part of it already earns its keep today, and it's worth understanding the difference before you either write it all off or bet a project on it.

Two completely different things get called "AI languages"

This trips people up constantly, so let's separate them first.

The old category is languages for building AI. Python is the obvious one. Mojo belongs here too, a Python-flavoured language built for the GPU kernel work underneath model training and inference. In this category the human writes the code, and the code happens to be about AI. Nothing about the language design is unusual. This category has existed for as long as machine learning has.

The new category is languages where the AI writes the code. The human states an outcome. A model produces the program. A compiler or verifier checks it. The human reviews the result, or increasingly doesn't. The language is designed around that loop rather than around a person typing into an editor.

That second category is what "AI-first" and "AI-native" actually mean when someone uses them carefully, and it's what this post is about. It didn't meaningfully exist two years ago.

Why anyone thought a new language was needed

To understand the pitch, you have to look at what an agent actually does when it writes code. It isn't one shot. It's a loop, and it runs a lot of times.

Three things in that loop are more expensive than they need to be, and each one has spawned its own school of thought.

Error messages are prose. Rust's borrow checker writes a paragraph. It's an excellent paragraph, carefully crafted over years to teach a human what they got wrong. An agent doesn't need teaching, it needs a routable fact. Every time a model reads that paragraph it spends tokens and takes a small chance of misreading it.

Syntax is optimised for human reading. Significant whitespace, flexible ordering, three ways to write the same thing, decades of accumulated idiom. All of that costs tokens and introduces ambiguity at generation time. Token efficiency became a real topic of discussion in 2026 for exactly this reason: every token spent on boilerplate is a token not spent on the actual logic.

Text files are the interface. This is the one I find most interesting. When an agent edits your code it is doing string manipulation on a file. It doesn't move a symbol, it replaces characters and hopes the result still parses. The meaning of the program is something the compiler reconstructs afterwards, and the agent only finds out it broke something once the build fails.

None of those are new observations. What's new is people building languages around them.

The three camps

The clearest map of this space I've found is agentlanguages.dev, a community-edited catalogue of the field. It sorts projects into three camps, and the split holds up well because the camps genuinely disagree about what the problem is.

Syntactic: make the code cheap to generate

This camp treats the problem as one of tokens and ambiguity. Fewer ways to express the same thing, more explicit structure, machine-readable diagnostics.

MoonBit is the most mature example, and notably it predates the current wave. It started in late 2022, right as ChatGPT landed, and its team published research at ICSE 2024 on designing a language around model-guided code generation, including real-time semantics-aware token sampling to steer inference. It compiles to WebAssembly, ships a full toolchain, and is heading toward 1.0.

Zero is the newest and most aggressive. Its v0.3 release moved the whole thing to what it calls graph-first authoring: the compiler's actual input is a binary zero.graph store, and the .0 source files you read are just human-readable projections of it. Agents don't edit text. They query the graph and submit patches guarded by hashes, so a stale or type-incorrect edit is rejected before it's ever written.

Below that tier is a long tail of one-person projects. GlyphLang and B-IR both showed up on Hacker News in January 2026 with variations on "optimised for how LLMs tokenise." Most of these will not survive the year, which is normal for a new field and not an argument against the field.

Verification: don't trust the model, check it

This camp's position is the one I have the most sympathy for. If a model produces a plausible-looking function, the question isn't whether it looks right, it's whether anything mechanically confirms it. So make the contracts machine-checkable and let the model attempt as many times as it wants.

Most of the energy here is going into existing verification-aware languages rather than new ones. Dafny has design-by-contract built in and a research community actively benchmarking model-generated proofs. Lean 4 got a serious push in March 2026 when Mistral released Leanstral, an open-source agent built specifically for it.

Then there's Prove, which reached 1.0 in February 2026 with refinement types (type Port is Integer:[16 Unsigned] where 1..65535) and requires/ensures contracts. Prove is the strangest entry in the whole catalogue, because it starts from the same diagnosis as everyone else and arrives at the opposite conclusion: it uses verification to make the language resistant to AI generation, and its licence explicitly prohibits using the source for model training. Same problem, inverted answer. I don't agree with where it lands, but it's a coherent position and I'd rather read that than another token-efficiency benchmark.

Orchestration: the language isn't the problem

The third camp thinks the other two are solving the wrong thing. Your application code is fine. What's broken is the seam where your typed, tested program calls a model and gets back a blob of text it has to pray is valid JSON.

So instead of a new general-purpose language, you get a small domain-specific language (DSL) that owns just that seam. You declare the shape of what you want, the prompt that asks for it, and the model that serves it. A code generator hands you a typed function in your real language.

This is the boring camp, and it's the one that's actually working.

Which of these do people actually use

Star counts aren't adoption, so treat all of these as a rough signal of attention rather than production usage.

BAML (Boundary, YC-backed, Apache 2.0) is the clear leader, around 8,700 stars and used in production by companies including HumanLayer and Mentum. Its most useful feature isn't the syntax, it's Schema-Aligned Parsing, which handles the real-world mess of model output: markdown fences around your JSON, reasoning text before the answer, trailing commas, all the things that make json.loads() throw.

POML (Microsoft, MIT) takes the markup route, with HTML-like <role>, <task> and <example> components plus data components that embed files, tables and images. It landed in August 2025 and has picked up momentum largely through the Azure AI and Copilot Studio tooling.

MoonBit is the most credible thing in the syntactic camp, because it's a complete language with a real toolchain and published research rather than a design manifesto.

Zero has moved fast: past 5,000 stars and up to v0.3.4 within about three months of launch, quick going for a systems language. It's also the one whose own README tells you not to use it: "Zerolang is experimental. Expect breaking changes, rough edges, and security issues. Run it in isolated workspaces, not against production systems or sensitive data." Worth respecting that.

Trying Zero: install to hello world

Zero is the more interesting one to actually put your hands on, precisely because it's the one you mostly don't write by hand. It's worth doing once even knowing it isn't production ready, if only to see what "the compiler talks to the agent, not you" feels like in practice.

Zero ships as a prebuilt binary, Apache 2.0 licensed, with native builds for Linux, macOS and Windows, so there's nothing to compile yourself unless you specifically want to build the toolchain from source. Install it and put it on your PATH:

curl -fsSL https://zerolang.ai/install.sh | bashexport PATH="$HOME/.zero/bin:$PATH"zero --version

Add that export line to your shell profile (~/.zshrc or ~/.bashrc) if you want zero available in new terminals without re-running it. zero --version confirms the install worked before you go further.

If you'd rather build the compiler yourself instead of using the install script, the repo includes a native build:

git clone https://github.com/vercel-labs/zerolang.gitcd zerolangpnpm installmake -C native/zero-cbin/zero --version

That path needs pnpm and a C toolchain (make and a C compiler), since the native compiler builds out of native/zero-c. The install script is the one to reach for unless you're planning to hack on the language itself.

With zero on your PATH, create a project and write your first program, hello world:

zero initzero patch --op 'addMain' \  --op 'addCheckWrite fn="main" text="hello from zero\n"'zero run

zero init sets up the project's graph store. That patch command is the point of the whole language: you're not editing a text file, you're submitting a semantic operation against the graph, and it either type-checks and applies or it's rejected outright. zero run compiles and executes it, printing hello from zero to your terminal.

You can read what you just built as ordinary source at any point with zero export, which projects the graph into a .0 file:

pub fn main(world: World) -> Void raises {    check world.out.write("hello from zero\n")}

Notice world: World and the explicit raises. Effects are capability-based and declared in the signature, so a function touching I/O has to say so and the compiler enforces it. That's smart design for machine-generated code: an agent can't quietly slip a network call into a function you believed was pure, because the type system won't have it.

Beyond hello world, the daily loop is five commands: zero query to inspect the graph, zero patch to submit an edit, zero check to validate it, zero test to run tests, zero run to execute. Every one of those talks to an agent in structured data rather than prose, which is the entire pitch in five verbs.

It's a legitimately good set of ideas. It is also, by its authors' own description, an experiment: the README says plainly to run it in isolated workspaces, not against anything you care about.

Trying BAML: ten minutes to a typed client

Here's the thing that made orchestration DSLs click for me. They don't ask you to replace anything. You add one file.

Say you're pulling structured data out of resumes. Install and initialise:

brew install bamlbaml init

Then define the shape you want, the model you're calling, and the prompt, all in one .baml file:

client GPT4 {  provider openai  options {    model gpt-4o-mini    api_key env.OPENAI_API_KEY  }}
class Resume {  name string  job_title string  company string  years_experience int @description("Total professional years, 0 if unclear")}
function ExtractResume(resume: string) -> Resume {  client GPT4  prompt #"    {{ _.role('system') }}    Extract the following information from the resume.
    Resume: <<<< {{ resume }} <<<<    Output JSON schema: {{ ctx.output_format }}    JSON:  "#}

Two things are doing real work there. {{ ctx.output_format }} generates the schema description from the Resume class, so the prompt can never drift out of sync with the type. And @description puts the field-level guidance where the field is, instead of buried in a prompt string three files away.

You can test it without writing any application code:

test SeniorEngineer {  functions [ExtractResume]  args {    resume "Jane Chen, Staff Engineer at Atlassian since 2019..."  }}

Run the generator and you get a typed client. From TypeScript:

import { b } from './baml_client';
const resume = await b.ExtractResume(rawResumeText);console.log(resume.years_experience + 1);

resume is a real Resume object with a real number on years_experience. Not any, not a parsed blob you cast and hope about. If the model wraps its answer in a markdown fence or thinks out loud before answering, Schema-Aligned Parsing deals with it rather than throwing.

BAML generates clients for Python, TypeScript, Go, Ruby, Java and more, so adoption stays incremental. One function, one file, no rewrite.

So would I actually use any of this?

Split answer, because the camps deserve different verdicts.

Orchestration DSLs: yes, now. I'd put BAML in a production service without much hesitation, and the reason is blast radius. It isn't a language you write your application in. It's a typed, tested boundary around a model call, generating a client in a language you already use. If the project stalls tomorrow, you delete one file and hand-write the function it was generating. That's a small bet against a genuinely annoying problem, and "our LLM call returns unpredictable garbage" is one I've watched eat weeks. This slots neatly alongside the testing approaches that actually work for AI features.

Verification: yes, if you already had the problem. If you're generating code where being wrong is expensive, and you were already the kind of team that would reach for Dafny or Lean, then agents make that case stronger, not weaker. Machine-checkable contracts are exactly what you want when the author is a machine that produces confident, plausible, occasionally wrong code. If you weren't already in that world, an agent isn't a good enough reason to move there.

General-purpose agent-native languages: not yet. Not because the ideas are bad. Because of training-data gravity.

A model is good at Python because it has read an enormous amount of Python, along with every Stack Overflow answer, every library, and every bug report about it. That corpus is the single biggest input into how well an agent writes in a language. A brand new language has none of it. So the pitch for Zero is that its toolchain advantages beat the corpus disadvantage, and the honest answer is that nobody knows yet. Every one of these projects is making the same unproven bet, and the ones that solve it will probably do it by shipping the language as an agent skill with enough structure to compensate. Zero does ship one (npx skills add vercel-labs/zerolang), which tells you they know exactly where the gap is.

There's also a straightforward operational reason to wait. A language at v0.3 with breaking changes and a security warning in the README is not something to build a product on, and nothing about that being AI-related changes the usual maths.

My actual prediction is that the syntactic camp wins by losing. The ideas leak. Structured machine-readable diagnostics, semantic edits instead of string edits, effects declared in signatures: those all work fine in languages that already have millions of developers, and I'd expect to see them turn up as flags, LSP extensions and compiler modes in Rust, TypeScript and Go long before anyone ships a production service written in a language designed in 2026. That's not a failure for Zero. Being the experiment that proves the idea is a perfectly good outcome, and it's roughly what happened with a lot of type-system research in the 2000s.

The category is worth understanding, and one third of it is worth using this quarter. That's a better hit rate than most things that arrive with this much noise attached.

If you've shipped something using one of these, particularly outside the orchestration camp, I'd like to hear how it went. That's the data point this field is missing.