What happens when machines write the implementation?
MLIR makes it possible to work across compiler dialects. A machine-written implementation would still need evidence that its behavior satisfies a human specification.
Mojo reached version 1.0 in August 2026. Its use of MLIR makes the compiler architecture worth examining before deciding whether a project needs another language.
MLIR lets a compiler transform code through dialects that express increasingly hardware-specific operations. Its verifiers check the constraints defined for those operations. Proving that a transformation preserves program meaning requires further evidence; passing those checks covers the properties the verifier actually tests.
Ask who needs to read the code
C evolved over time, as did Python. An AI-generated language could also develop through accumulated changes instead of appearing as a finished design.
If machines write more of an implementation, the role of its human readers becomes a design decision. Programming languages balance readability with precision. A representation intended mainly for automated transformation could make a different choice about which details people need to read directly.
Existing work supplies parts of the design
MLIR supports dialects for different operations or hardware requirements. Dialect definitions specify the constraints its verifiers can check.
Mojo targets performance across hardware. Triton also gives developers a way to write accelerator-oriented computations without beginning with a general-purpose language's usual level of abstraction.
AlphaDev found sorting routines through automated search. AlphaTensor applied search to matrix-multiplication algorithms. Both demonstrate work on algorithm discovery within defined problems.
Equality saturation explores equivalent program forms before selecting a form according to a cost model. Its result depends on the rewrite rules with their equivalence assumptions, as well as the cost model used for selection.
These projects already exist. Extending their ideas into a different programming workflow remains a separate proposal.
Separate implementation from its readable view
One possible design gives people a view of intent while machines transform a lower-level representation.
The machine-facing representation could express costs explicitly. It could also specify effects. It could be dense enough to make direct reading inconvenient while remaining suitable for optimization or verification.
The human-facing view would state the intended behavior. Types could express part of the contract, with tests supplying evidence about particular cases. A readable explanation would help reviewers understand the implementation's purpose.
In that design, the program would contain several related artifacts. The implementation graph would need to remain linked to its specification. Evidence about that relationship would accompany the readable view shown during review.
Compiled languages already create some distance between source code and the instructions that run. Most developers review source without reading all emitted assembly, relying on the compiler's testing record. A system that adds more transformation stages would need evidence covering the extra distance.
Intent can leave implementation choices open
A specification can state high-level requirements while the system chooses memory layout. It could also choose how to parallelize work or which kernel to use. That would move some implementation work now done by developers into the transformation process.
Developers whose expertise lies in that implementation work would need to decide which parts still require direct inspection.
The skills this design would require
Most developers might continue to work above the machine-facing layer, just as they usually work above assembly today. Whether that is sufficient depends on the evidence available when a failure crosses layers.
Specifying correctness would become more of the developer's work. Types express some requirements; contracts can express others. Property-based tests or formal specifications can supply further checks when they suit the behavior being examined.
A proof-backed change would require reviewing its claim against the specification. The proof's scope would determine what it says about the implementation. Requirements omitted from the specification would still need another form of review.
Adoption would take more than compiler infrastructure. Tooling would need to support ordinary development work, with a testing record sufficient for teams to trust it. The history of compiler adoption gives little basis for promising an immediate transition.
Establish who controls the representation
If a machine-facing representation becomes the artifact a project depends on, its ownership affects portability. Open language specifications allow implementations to be compared or replaced. A proprietary accelerator compiler can impose different limits on what users can inspect or move.
The representation's governance therefore belongs in the architecture decision. A team needs to know who can change its rules before committing the application to them.
I'd like to delegate cache-line decisions to a compiler while working on the product. I also want to know which rules it follows, so I can judge whether its choices fit the application.
I work on architectural decisions whose cost can emerge years after the initial choice, including decisions about when to adopt a new dependency.
Sources: Mojo 1.0 (The Register) · MLIR