Silicon is scaling. The optimization process is not.
Compute is being bought faster than anyone can learn to use it well. Every new model, shape, framework and accelerator creates another compiler problem, and the supply of people who can solve those problems has not moved.
This page is the case for why that gap exists, what it costs, and why none of the existing layers close it. What we are building comes last, and only after the problem is on the table.
Combinatorial variation
Model × shape × precision × target. Every combination is a fresh optimization problem.
Hardware fragmentation
Each accelerator rewards different decisions. A win on one part is not a win on the next.
Scarce specialists
Kernel and compiler tuning still takes weeks to months, done by people who are hard to hire.
Knowledge resets
Most wins end as local patches. The next workload starts from nothing.
Evo company overview. Current evidence and target architecture are distinguished throughout this page.
AI is scaling faster than performance engineering
Every new model, shape, framework, and accelerator creates another compiler problem. The money going into hardware is growing far faster than the ability to extract what that hardware can do.
the current system
New models
Changing workload, operators, shapes, precision
General compiler
Strong default optimization — for the average program, not yours
Expert tuning
Bespoke kernel and compiler work, by hand, per target
where it breaks
The default is deliberately generic
A general-purpose compiler has to be correct and reasonable for every program that will ever pass through it. That constraint is what makes it trustworthy, and it is also what caps it: the decisions that would win big on your kernel are exactly the ones it cannot make in general.
The expert path does not scale
The gap gets closed today by people — kernel engineers, compiler engineers, architects — working one workload at a time, for weeks or months. They are scarce, expensive, and already fully booked. Their output does not grow when capex does.
The target keeps moving
By the time a workload has been tuned, the model has changed shape, the framework has changed defaults, or the fleet has a new accelerator in it. Optimization is treated as a project with an end date, but the thing being optimized never stops moving.
Silicon is scaling. The optimization process is not.
Market context from the IEA; specialist-workflow framing from PyTorch KernelAgent.
Nobody sees the bill, because it never arrives as a bill
Unrealized performance does not show up as an outage or a line item. It shows up as hardware that was bought and not used, and as designs shaped around software that was never given a chance to be good.
If you ship software
You pay for hardware you never fully use. The gap between what the part can do and what your build gets out of it is invisible on the invoice, and it shows up instead as more instances, more power, and a latency number you have learned to live with.
If you design hardware
You are evaluated against whatever the stock toolchain emits. Weak software makes a good architecture look mediocre, and it quietly pushes you to add units, width, and area to compensate for performance the compiler simply failed to reach.
If you fund either
Capex is being committed against benchmark numbers produced by general-purpose toolchains. The delta between those numbers and what the same silicon does under serious optimization is real, repeatable, and almost never priced in.
why it is still open
This is not an unnoticed problem. It is a problem where every existing approach runs out of room at a different point.
- 01
General-purpose compilers
Cannot specialize aggressively, because they must stay correct and predictable for every program. Their generality is the feature and the ceiling.
- 02
Autotuners and search libraries
Explore a fixed, hand-authored space. They find good points inside the space someone already thought to describe, and nothing outside it.
- 03
Hand tuning
Works, and produces the best results available today — but it is bound to individual people, individual workloads, and does not transfer to the next part or the next model.
- 04
Agent demos
Show that search can find real wins. They stop short of the part that matters in production: deciding, mechanically and without trusting the model, which of those wins is safe to ship.
The search problem is getting solved. The trust problem is not.
Framing of the remaining gap follows the 2026 verified-kernel evaluation results discussed below.
Discovery is being productized. Trust is not.
Search now works well enough to be sold as a product. What nobody has solved is deciding, mechanically, which of its output is safe to put in front of users.
AlphaEvolve is now a cloud product
Google Cloud · Jul 2026
KernelAgent vs default torch.compile
PyTorch · Mar 2026
Best model vs PyTorch under verified protocol
KernelBench-Verified · Jun 2026
Where the gap sits
Discovery engines
Search for new code, algorithms, or heuristics. This part exists and is improving quickly.
Compiler learning layer
Turn a winning experiment into reusable, trusted compiler knowledge. This is the missing piece.
Deterministic deployment
Formally validated equivalence, shipped through ordinary build and runtime systems. Non-negotiable in production.
Frontier results validate search while exposing the verification, baseline, and transfer gaps that remain open.
No existing layer closes the loop
Each of the closest alternatives owns one layer well. The right-hand column is not a product claim — it is what any solution to this problem would have to do, including ours.
| Capability | Traditional compilers | AlphaEvolve | Kernel agents | What closing it requires |
|---|---|---|---|---|
| Production build integration | △ | |||
| Open-ended algorithm search | △ | |||
| Semantic projection across frontends | △ | |||
| Independent mechanical admission | △ | △ | ||
| Cross-workload method transfer | △ | |||
| Hardware outcome memory | △ | |||
| Deterministic deployable artifact | △ | △ |
The right-hand column is a requirement set, not a shipped feature list. Our own implementation proves the control loop today; GPU scale and semantic transfer remain open.
Finding the optimization is the easy half
A model that proposes a thousand rewrites is useful only if something other than the model can decide which ones are correct. That decision has to stay frozen, deterministic, and independent of whatever produced the candidate.
Agents are allowed to be wrong.
- LLM and evolutionary proposals
- Algorithm, kernel, layout, and schedule search
- Parallel populations and learned cost models
- No authority to edit the gate or promote itself
Model progress expands the search space
Anything that ships must survive checks the model cannot influence
- Verified numerical equivalenceSame observable behavior
- Explicit preconditionsKnown legal domain
- Untouched repository codeCatches integration failures
- Target-hardware measurementProves the gain is real
Only independently admitted methods become compiler infrastructure
Model capability improves the search. It never weakens the trust boundary.
Target trust model informed by the internal proof architecture and 2026 verified-kernel evaluation failures.
A new category: continuous compiler infrastructure
Everything above is the problem. This is the shape of the answer we are building, stated briefly: discovery engines propose, Evo verifies and remembers, and existing backends emit the artifact.
Learning time
- 01
Discover
Use the best agent loops to discover algorithms
- 02
Raise
Recover the algorithm and its constraints
- 03
Prove
Check equivalence, legality, and preconditions
- 04
Measure
Run hidden tests and target hardware
- 05
Admit
Store a guarded method and its outcomes
The next workload begins with proof-bearing methods and measured target behavior — not a blank prompt.
Target architecture: replaceable search, deterministic admission, reusable methods, existing compiler backends.
Performance is becoming a capacity market
AI infrastructure spending is enormous. Better software converts the same hardware into more throughput, lower latency, and fewer GPUs.
2025 capex by five large technology companies
IEA, 2026
Projected increase in that capex during 2026
IEA, 2026
NVIDIA fiscal 2026 revenue
NVIDIA, 2026
Initial wedge
AI inference kernels
PyTorch → Triton / CUDA / CUTLASS
Performance is directly monetizable and the workloads are benchmarkable.
HPC · databases · scientific computing
Hot numerical and data-intensive regions
Clear bottlenecks, expensive compute, repeatable workloads.
General C/C++ · legacy systems · custom design
Whole-program and repository specialization
Broad market, deeper integration, higher proof burden.
Optimization creates virtual hardware capacity.
IEA “Key Questions on Energy and AI” (Apr. 2026); NVIDIA FY2026 results (Feb. 2026). Data-center demand is projected to roughly double by 2030, with AI-focused demand growing faster.
Make every workload teach the compiler
Each workload teaches Evo what the code means, which transformations are legal, where they win, and how to deploy them again.
We are looking for seed partners who believe compilers should improve as fast as models and chips do.
The long-term control point sits between software intent and deployed silicon.
Selected public references
The category is moving quickly. These are the primary sources behind the frontier and market claims on this page.
All quantitative claims are sourced above; internal results are labeled as screening evidence.