AI Won't Invent a Language. It'll Grow One.
Mojo just hit 1.0 on top of MLIR, where every compilation step is machine-verified. That points at a two-world stack - and a governance question nobody is asking.
Mojo hit 1.0 this month. It is worth paying attention to, not because you should rewrite anything in it, but because of what sits underneath it.
Mojo is built on MLIR - a compiler framework where code descends through progressively more hardware-specific dialects, and every stage of that descent is machine-verified. That is the interesting part. Not a new syntax. A stack designed so that a machine can transform code and prove it did not change the meaning.
The wrong question
"Will AI invent a programming language?" gets asked a lot, and it is the wrong shape. Languages are not invented in one go; they accrete. C did not arrive whole, and neither did Python.
The better question is what happens when the main author of code is no longer the main reader of it. Because every language we have is a compromise between those two roles - readable enough for people, precise enough for machines. Remove the constraint that a human must comfortably read every line, and the compromise moves.
The signals are already here
MLIR exists specifically so new dialects can be minted for new hardware, with verification at each lowering step.
Mojo and Triton show you can create a language aimed squarely at performance on specific accelerators, and get adoption, without waiting a decade.
Systems like AlphaDev and AlphaTensor have found genuinely novel algorithms - sorting routines and matrix multiplication approaches that humans had not landed on.
Equality saturation techniques let a compiler explore an enormous space of equivalent program forms and pick the best one, rather than applying rewrite rules in a fixed order.
None of that is speculative. It ships.
The two-world stack
Where this points is not one language replacing another, but a split:
A machine-facing representation tuned for optimisation and verification. Dense, explicit about cost and effects, unpleasant to read, and not intended to be read. This is where transformation and proof happen.
A human-facing view on top: intent, specifications, types, contracts, tests, and an explanation of what the thing does and why. This is what you write and review.
In that world, "the code" stops being a text file and becomes a bundle - the intent, the spec, the implementation graph, the evidence that the implementation satisfies the spec, and a readable view generated for humans.
We already live with a weak version of this. Nobody reads the assembly their compiler emits. We trust the compiler because it is deterministic and heavily tested, and we read the source. The change is one of degree: more distance between what you write and what runs, and consequently more weight on the evidence in between.
High-level or low-level? Both, and neither
The framing that dies here is the high-level versus low-level axis. You will write intent, constraints and tests at a very high level. The system will make decisions about memory layout, parallelism, and kernel selection at a very low one. The middle - the part where most of us spend our careers - is what gets compressed.
Which is uncomfortable, because the middle is where most current expertise lives.
What I would actually bet on
Most developers will never see the machine-native layer, the same way most of us never see assembly. That is fine, and it is not new.
Verification becomes the load-bearing skill. If a machine writes the implementation, your job is specifying what "correct" means and being able to tell whether the evidence supports it. Types, contracts, property-based tests and formal specs stop being niche enthusiasms and start being the interface.
Review changes shape. Approving a proof-backed diff is a different activity from reading a hundred lines of code. Better in some ways - you check the claim rather than the implementation - and worse in others, because a proof only covers what you thought to specify.
Timelines will disappoint everyone. The infrastructure exists; the tooling, trust and culture do not. Compilers took decades to become boring. This will too.
The part worth worrying about
If the machine-facing representation becomes the real artefact, then whoever controls it controls the ecosystem in a way no language ever has. Programming languages have historically been open, standardised, forkable. Optimising compilers for proprietary accelerators are not, particularly.
The technical future here is genuinely exciting. The governance one deserves more attention than it is getting, and almost nobody is asking who owns the interlingua.
I am happy to let a polite compiler-thing sweat the cache lines while I think about the product. I would just like to know who wrote its rules.
I work on architecture decisions that are expensive to reverse - the kind where being early or late both cost you. More here.
Sources: Mojo 1.0 (The Register) · MLIR