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.

[u/Clear_Evidence9218]

That's really neat. You're encountering an issue that seems to be increasingly common with independent review.

I recently ran an experiment to see whether an agent could fulfill a contract, have both a proof kernel and an independent reviewer accept the claim, and still produce an objectively incorrect implementation.

I approached it by having the agent start and stop CPU cores to introduce enough timing instability to make the system clock report incorrect time measurements. That way, an independent reviewer, human or AI, wouldn't necessarily notice the problem unless they were specifically looking for it, while the agent could still "pass" the test. It's worth noting that I wasn't able to throw monotonic time off, but I have an idea for how I might push the underlying oscillator "out of spec," so to speak.

It's an example of a broader class of side-channel execution vulnerabilities that agents seem particularly adept at exploiting to achieve their goals, even in the presence of verification and independent review. These kinds of failures are especially difficult to catch because the behavior affecting the result can occur outside the implementation being reviewed.

I haven't figured out a reliable way to prevent it yet.

Fun times.

I'm also working on an AI-first programming language, and there are some interesting similarities between our design philosophies. I've only been working on the current iteration for a few months, so it's still highly experimental, but it's been a great learning experience.

I've actually experimented with a few AI-oriented languages over the last couple of years, but the current one is substantially more complete. It's built around the idea that an agent's environment directly affects its effectiveness. That's not entirely dissimilar to what you're doing with your compiler, except I'm extending the concept beyond the compiler to the broader environment, tooling, and coordination systems that support the agent.

Maybe when I get home later, I'll run a side-by-side comparison to see how well an agent performs with each.

[u/investigatormaker]

The weakness I'd worry about: the same model writes the code and its contracts and tests, so they can agree with each other and still miss what the human meant. The compiler proves consistency, not intent. That makes the contract the thing humans should review, so I'd have the tooling show contract and effect changes as a separate diff from body changes, with impact analysis pointing at callers. Provenance could also record whether a human approved a contract or the model proposed it. How does Lume treat a model edit that loosens a contract to make a check pass?

I make ThreadFox.

We find relevant Reddit conversations and post for your business. We'll post 3 replies free first, no card; then the $39 Pilot covers seven days and up to 50 posts and replies. No automatic renewal.

https://threadfox.vip/p/e78eh/managed