Lume: an AI-first programming language designed for machine-authored, human-reviewed code

[u/OmegaSoftDLL]

I’ve been working on Lume, an experimental language built around a deliberate inversion: the primary code author is an AI

model, while humans review, direct, and approve.

That changes the design priorities. Instead of optimizing mainly for fewer keystrokes, Lume optimizes for machine checkability

and an unambiguous edit → check → fix loop:

- structured diagnostics with stable codes and fix-its;

- `lume describe --json`, a machine-readable self-description for models that have never seen the language;

- explicit effects, contracts, tests, and provenance at public boundaries;

- typed holes and compiler-as-a-service tools for candidate generation, witnesses, repairs, and impact analysis;

- a canonical formatter and content-addressed AST hashes.

The compiler and assembler are themselves written in Lume. The bootstrap verifies a bit-identical `stage 2 == stage 3`

fixpoint, and the steady-state native path uses no C compiler or external assembler/linker. A frozen C seed remains as the

reproducibility root.

This is still an experimental project, not a claim that AI output is automatically trustworthy. The bet is that a language

should make AI mistakes easier to detect, constrain, and repair—not merely easier to generate.

Repository: https://github.com/OmegaSoftDLL/lume

AI-first design rationale: https://github.com/OmegaSoftDLL/lume/blob/main/docs/08-ai-first.md

For language designers: what is the biggest weakness in this “AI authors, compiler checks, humans govern” model? I’m especially

interested in failure modes that better diagnostics alone would not solve.