Syntactic
B-IR
“Maybe the most LLM-optimized language had been inside us the whole time.” A blog-post exploration, not a project.
Python (bootstrap) · Arm64 assembly
★ — N/A mar 2026 thought experiment
A live catalogue of an emerging field. 21 projects, three camps, and a foundational argument about what the problem even is.
Originally catalogued in a blog post “Three camps alike in dignity” for Negroni Venture Studios.
The Syntactic camp says the problem is representational — strip ambiguity at the token level. The Verification camp says it’s semantic — make contracts mechanically checkable. The Orchestration camp says it isn’t a language problem at all — constrain how agents coordinate. The catalogue below treats them as evidence that this disagreement is real.
If the problem is that models trip on syntax, the fix is to strip ambiguity from the syntax itself.
The syntactic camp treats the problem as one of representation. Models choke on tokens that mean different things in different positions, on operators that need disambiguation, on whitespace that might or might not be load-bearing. Their answer: build a syntax where every token has one job.
The strongest entries replace text with structure (X07’s JSON ASTs), eliminate operators in favour of keywords (NERD), or surface intermediate representations as the user-facing form (Magpie’s SSA). The weakest are exercises in extreme density — one-character opcodes — that read more as conceptual art than as production languages.
What unites them is a belief that the LLM’s job is easier if the surface is simpler. What divides them from the verification camp is the absence of any mechanism for the compiler to catch what the model gets wrong.
The model doesn’t need to be right. It needs to be checkable.
The verification camp accepts that LLMs will keep making semantic errors and asks a different question: can the compiler catch them? Their answer is mandatory contracts, refinement types, effect systems, and SMT-backed proofs — the machinery of formal methods, repurposed as a guardrail for generative code.
This is the camp with the most established theoretical foundation (the work goes back to ML, Coq, Dafny, and Lean) and also the most mature implementations. MoonBit ships a full toolchain with ICSE-published research; Vera ships measured benchmark wins against Python on zero training data; AILANG claims to be written autonomously by its own coordinator.
The provocative entry is Prove — same diagnosis, opposite conclusion. It uses verification to make the language resistant to AI generation. The licence explicitly prohibits training use. Same camp, opposite politics.
It isn’t a language problem. It’s an agent-coordination problem.
The orchestration camp re-frames the question. The trouble with LLM-authored code, they argue, isn’t any specific defect in the code — it’s that agents need to be sequenced, sandboxed, audited, and approved by humans at the right points. The language is just the substrate; the runtime is where the action is.
Some entries here are academic (Pel from CMU, Quasar from Penn); some are infrastructure (Marsha treats the LLM as the compiler itself); one is a serious engineering effort aimed squarely at regulated industries (Boruna’s hash-chained evidence bundles and deterministic replay).
This camp overlaps the most with the others — Boruna includes a type checker and capability system; Quasar adds conformal prediction. The line between “language for agents” and “framework for agents” is genuinely blurry here, which is itself informative.
Every language designed for LLMs or agents to author code, as of 20 may 2026.
“Maybe the most LLM-optimized language had been inside us the whole time.” A blog-post exploration, not a project.
Python (bootstrap) · Arm64 assembly
Minimal indentation-based syntax, no punctuation. Compiles to C. Optimised for generation speed, not correctness.
Python · C (via gcc/clang)
SSA as the surface syntax. Every value %-prefixed and typed at definition; one canonical way to express each operation; compiles to native via LLVM.
Rust · LLVM IR / native, also WebAssembly
Replaces all operators with English keywords. Built-in MCP client operations. Claims 50–67% token savings vs JS/TS.
C · LLVM IR
Single-character opcodes for extreme density. Explicitly a thought experiment; everything Claude-generated.
Claude-generated · Zig-based native (claimed)
Eliminates text syntax entirely. Programs are JSON ASTs; edits are RFC 6902 JSON Patch operations.
Unknown · WebAssembly
Purely functional, effect-typed, deterministic. Hindley-Milner with row polymorphism. Capability-based effects. No loops.
Go · Native executables
Every function carries intent, declared effects, and a colocated verify block. Pure verify blocks export to Lean 4 theorems and Dafny lemmas; effectful ones lift through the Oracle proof export.
Rust · bytecode VM, Rust, WebAssembly GC (Lean 4 / Dafny via proof export)
AI-friendly general-purpose language. ICSE 2024 paper on real-time semantics-aware token sampling. Three years of training data.
OCaml · WASM GC, JavaScript, native (C codegen), LLVM
Intent blocks, pipeline syntax, MCP server with five tools, LSP server. Close to Aver in design DNA.
Rust · Interpreted
Intent-first language with verb-based IO, refinement types, and contracts. Source is covered by the Prove Source License v1.0, which prohibits use as AI training data.
Python (bootstrap) · C (then native via gcc/clang)
Not a new language — fix Haskell's tooling. hx replaces cabal/stack/ghcup; BHC is a clean-slate Haskell 2026 compiler.
Rust · LLVM (via BHC)
Mandatory contracts on every function. Z3 SMT verification. Typed slot references replace variable names. LLM inference is a first-class typed effect.
Python · WebAssembly
Agent-first learnability. “One obvious way to express most things.” Structured JSON output from every CLI command.
C · Native executables (linux-musl-x64)
Deterministic, capability-safe workflow execution. Every effect declared, policy-gated. Hash-chained tamper-evident evidence bundles.
Rust · Bytecode (custom VM)
LLM as compiler backend. English specs + type declarations + I/O examples produce tested Python. The model IS the compiler.
TypeScript · Python (via LLM)
Lisp-inspired language for orchestrating AI agents. Grammar-level capability control. Natural language conditions.
Unknown · Unknown
Transpiles a Python subset. Automated parallelization, conformal prediction, user-approval security. 42% time reduction on ViperGPT.
Unknown · Custom runtime (from Python subset)
Infrastructure that operates around these languages, or candidates that haven’t shipped enough to classify.
Typed coordination language for AI agent systems, built on applied category theory. Defines the wiring orchestration languages run within.
Unknown · Native (binary downloads for macOS, Linux)
Two-domain architecture separating semantic specification from language-specific implementation. v0.2 draft, mostly unimplemented.
Unknown · Unknown
“AI-native systems programming language.” Announced on Hacker News. Too little public information to classify.
Unknown · Unknown
A community-edited catalogue of programming languages designed for AI agents to author code — not languages that use LLMs at runtime, but languages whose syntax, semantics, or runtime are deliberately shaped around an agent being the primary author.
The bar is intent. A language is in scope if its designers explicitly target LLMs or agents as authors — through token-friendly syntax, mechanically checkable contracts, agent-coordination primitives, or first-class effect declarations for model calls.
A tool that calls an LLM at runtime (chatbots, autocomplete plug-ins, IDE assistants) is not in scope. A language whose only innovation is “works with Copilot” is not in scope. The line is the design intent, not the tooling.
Open a pull request adding a Markdown file to src/content/languages/. The contribution guide asks for evidence the project meets the inclusion bar and a self-classified camp with justification.
The maintainer reviews each submission for fit, accuracy, and tone (the catalogue is descriptive, not promotional). Marginal cases get discussed in the PR thread. Edits to existing entries are welcome — especially corrections from the language’s authors.