RSI, everywhere, all at once
For a long time, a self-improving AI was just a recurring sci-fi theme (see above), however, it is already silently happening in the real world. Let’s dive into the why and the how.
Software ate the world, now, AI is eating software, creating fast growing demand for new high performance and cost-efficient infrastructure. However, only a handful of players are equipped with the talent needed to meet that demand.
AI usage is exploding, in both volume and variety with new model types, ways of serving them, and hardware to run them on. It’s driving demand for novel optimized systems (by system, we mean anything from a distributed memory system to low level GPU code).
While this frontier work was historically conducted by a small pool of experts, systems architects, compiler specialists, AI researchers, performance engineers, today, leading players hoard those scarce talents at a price nobody else can match. It’s estimated that there is “probably one good GPU kernel engineer per 100,000 software developers”, and Nvidia spends around $800m per year on its GPU performance engineering workforce (cf. appendix).
It’s obvious that AI systems are now scaling faster than the people who optimize them. As a consequence, design and engineering result in inefficiency, with increasing cost combined with low-grade performance, e.g. DeepSeek-V3 is estimated to have left about 80% of its GPUs theoretical maximum compute on the table.
We need another way to tackle this problem: a new infrastructure layer, one where AI self-optimizes its infrastructure. Researchers call this, “Recursive Self-Improvement” (RSI).
After months deep in the research with the people who know it best, here’s our view on what’s coming up and what challenges remain to be solved.
Our conclusion is simple: the key bottleneck arrives during the evaluation of systems, not generation. Evaluation has to be quick and robust enough to enable fast and cost-efficient iterative improvement, while in parallel confronting the system with real world conditions. Cracking that problem will unlock compounding value.
Given those requirements we built the conviction that the early winners we want to back will emerge from the systems engineering layer.
First let’s have a look at the four layers we identified in the AI stack where we can apply this self-improvement concept.
Strip any of these systems down and you find the same anatomy: propose candidates, evaluate them, learn from the scores and iterate on that loop. The core idea is that the probabilistic nature of the LLM output allows for broad exploratory search while the evaluation score grounds the result in “truth”. Once you integrate that process within a loop and repeat that at scale it can lead to powerful automated discoveries.
The search method varies: some research lineages use evolutionary loops descending from FunSearch, others use reinforcement learning, as in AlphaChip or the RL-trained kernel generators from Cognition. What every variant shares is a total dependency on its evaluator. A cheap and trustworthy optimize-and-verify cycle is the key to unlock gains at scale.
For low level code, kernels are the most active arena
Within the low level layer AI kernels are the low-level computations that actually run the core math of AI models. If an AI hardware platform is a Formula 1 engine, a kernel is the technical strategy for a specific corner of the track. AI has started automating the expertise required to find the optimal strategy.
This layer has seen the most progress because the feedback loop is tight and verifiable: compile*, run, profile*. Those different steps can be quickly executed meaning you can iterate at a high volume on the generate-evaluate process: the key to delivering breakthroughs. From Nvidia’s own benchmark, the share of AI-written GPU code that actually works, meaning it runs and returns the right answer, climbed from 61% to 93% in under a year.
Two things still resist:
1. Trusting the result. Correct is not the same as honest: a 2026 study found reward hacking in 73.8% of kernel-optimization* runs meaning the systems find ways to “pretend” to be correct. We’ll circle back to this key challenge in a moment.
2. Beating the best humans. Even if new methods can make AI-generated kernels precise & correct more often, performance has yet to consistently beat the best human optimizations. Frontier kernels are still written by a handful of world-class engineers, and models rarely deliver meaningful improvements, because they train on finished kernels scraped from GitHub and never on the optimization trajectory that produced them.
Dali Kilani, serial entrepreneur and AI infra builder, shared that he expects even these limits to fall within 12 to 18 months. Until then, the real prize is levelling the playing field: automated kernels can shorten timeframes for non-Nvidia silicon to catch-up on the software side (e.g., AMD’s ROCm and Apple’s Metal). For non-incumbents, it’s a big deal, especially in Europe.
It’s worth pointing out that kernels aren’t the only low level components that could be tackled with these methods e.g. assembly code*, collective communication libraries* and compilers.
Kernels are the crowded arena with highest risk of incumbent bundling especially because everyone runs on the same benchmarks e.g. KernelBench. We believe the companies that endure will be built one layer up.
Systems engineering: our winning bet
Upstream, sits the systems engineering layer, where the goal is to coordinate a whole fleet of chips working together to optimally serve a model. Examples of distributed systems problems include smart request routing and batching or hierarchical KV cache.
This is a huge, interdependent configuration space where very few teams operate with real sophistication. Berkeley’s Sky Computing Lab demonstrated in its research paper, Barbarians at the Gate, that the loop already works: automated search beat humans on real world distributed systems problems. Evaluation is based on the performance of the optimized system against real workload traces and we understand early production in this area to be extremely valuable IP (cf. Fireworks, Modal and others).
This is the arena we care most about, because its defensibility is structural.
Unlike kernels, for large production systems, there is no universal objective: no two clients share the same type of workloads. Each customer defines ‘better’ differently, so the surface area for customized optimization can always grow.
So, the winning asset is not the search method, which is largely open source, but the tailored evaluation pipeline which is hard to copy (we’ll come back to why below).
The more workloads you serve, the sharper your evaluator, the better your optimization, the more clients will trust you with their workloads. This flywheel is why we believe the enduring companies of this layer are being built here.
Two arenas we are watching
1. Models:
At the top of the stack sits the holy grail: AI that self-improves models. It draws the biggest cheques (Recursive Superintelligence raised $650m, Poolside signed a $6B deal with Nvidia for their AI model factory) and it is the hardest to make work, for a simple reason. To know whether a new model design is any good, you have to train the model, which usually means one enormous, expensive run for every idea you want to test. You cannot try thousands of ideas in parallel that way. The obvious shortcut, testing ideas on small models first and betting on the scaling laws, is only partially effective: simple things like tuning settings carry over nicely to larger models, while new architectures can often look brilliant when small and disappoint at scale.
However, a few corners of this layer do work today without an expensive, giant training run. The kind of tasks that could be evolved recursively include: giving an agent a better memory, curating better training data, or deciding how a team of AI agents is wired together. SOTA research is even looking ahead to meta-improvement of the evolution method itself. As investors, this is where we think value could come from.
Courtesy Monty Python and the Holy Grail, assembled with Canva.
2. Hardware:
At the bottom of the stack, where the hardware AI runs on is built, applying recursive improvement in this field is far from straightforward, mainly due to evaluation.
Granted, It’s estimated that there ithere are parts of the hardware process that teams have already started automating (e.g. floorplanning and drafting RTL). In chip design the early parts of the building process rely on simulation, offering quick generation-evaluation iterations. Yet, closing a production-ready self-improving loop is a much harder task. The missing link is formal verification*, ensuring the system is mathematically demonstrated to adhere to a set of constraints.
Filip Van Aelten from GlobalFoundries and Filipe Dantas Simas Procópio from Qualcomm describe expensive formal verification runs that can take longer than one day on a simple chip and up to several weeks for a frontier version. As you can imagine, it’s too lengthy an evaluation to be scalable and sometimes they even fail to converge.
Finally, unlike software, chips need a physical component. Producing chips for individual variant testing isn’t viable at current production costs. This is the hardest problem to tackle.
With the above in mind, we believe overall value will accrue to whoever manages to significantly shorten the end-to-end feedback loop by making both formal verification quicker and physical testing cheaper.
1. Overwhelming majority of these players are US-based. Europe needs to catch up. 2. Company logo size is proportional to total amount raised except for undisclosed early-stage rounds.
A recent full-stack survey paper argues that all layers from models to silicon share similar challenges - given the common technical methods employed for each stack, it’s not surprising. Let’s dive into it.
The verification crisis.
In early 2025, Sakana AI, a leading Japanese neolab, claimed 100x-plus GPU kernel speedups, until people found its agent had conveniently “forgotten” to check if the improved kernels actually calculated the right answer matching the original version. Even if tested, a kernel could still be incorrect, given that testing can only be done for so many inputs.
A real fix is formal verification, a mathematical proof that an optimized system matches its reference. However, it does not yet work at scale. When we looked at the publicly available testing of kernel generation systems (e.g., Makora, StandardKernel, Cognition (Kevin) etc.), none had yet publicly demonstrated formal verification.
Courtesy imgflip.
The data bottleneck.
Performance optimization is a craft mastered by a small number of experts, and its most valuable output, the optimization trajectory (the sequence of attempts engineers go through to improve the code), is generated inside private profiling loops. As a result, models never get trained on the reasoning process.
The moat that follows is access to proprietary, continuously refreshed PRs*, CI/CD* and production systems’ performance data: the traces that tell an optimizer what “better” means for a given customer.
That data allows companies to improve the optimization capability of their model and tailor it to specific customer environments.
The missing pipelines.
Generation is accelerating and getting cheaper, but challenges persist for those trying to build trustworthy evaluation pipelines. The degree of difficulty varies across layers: a kernel can be profiled in seconds, whereas a distributed configuration requires a production-scale cluster. These are evidently challenging to scale.
The need to co-design across siloes.
A locally optimal kernel is not a globally optimal system, as kernel speed says nothing about end-to-end performance. Local wins can actually lead to worse overall performance because the layers are tightly interdependent. The same holds higher up the stack, a model architecture that looks best in isolation can be the wrong choice for the silicon it runs on or the serving system around it.
As a recent full-stack survey puts it, cross-boundary end-to-end feedback is the missing piece given the vertical nature of the AI infra stack.
Local wins can actually lead to worse overall performance because the layers are tightly interdependent.
A few of our thoughts on what next steps need to be achieved (and our suspicions on the next developmental phase):
AI delivers better results than the experts.
For the next successes to arrive, we need AI to beat fine-tuned human optimizations across a few categories. The AI-generated kernel layer is most likely to be solved first. Model architecture and E2E hardware design will be much harder to crack, if at all.
Neither labs nor open-source commoditize this tech first.
Performance engineering is not the core competency of AI labs, and the “bitter lesson”* does not automatically win here. Robust evaluators grounded in client workloads require more than just extra GPUs.
The faster threat is open-source quickly matching any “point solution” product. Defensibility will come from access to private production data and continuous improvements.
Viable GTM strategies must emerge.
Options for GTM, especially for the systems engineering layer we care most about, include:
Scaleups without infra talent must ship agentic products where inference cost is a key concern and/or with stringent performance SLAs.
Enterprises want to run and fine-tune open source models, to ease margin pressure and leverage proprietary data, but currently lack both infra and research talent.
Research-first neo-labs would rather spend on science than systems.
Neo-clouds and serverless inference contenders need to level up their stack to compete with market leaders. This is a rapidly expanding TAM, yet it is a hard sell as those infra providers are usually well equipped with the internal talent.
Ship vendors building out their AI software stack to tackle the CUDA moat*.
Vertical integration is confirmed as an option to capture value.
The enterprise buyers might prefer a one-stop end-to-end offering. AI for AI infra players becoming inference providers themselves could be the key to their success. Owning the full stack gives you both better margins and access to the proprietary production data.
The optimization potential doesn’t hit a ceiling.
A core risk with optimization based value proposals is being stuck at one-off wins. Given the exponential development of the stack across layers and constantly changing usage patterns, we don’t see this being a problem in the short to mid-term.
If you’ve made it this far, you can guess that we’re already knee-deep in this field (with news coming soon on this front).
For founders: if you are building in Europe at the intersection of performance engineering, AI infrastructure, program synthesis, formal verification and especially if your moat is an evaluation loop grounded in data nobody else has, we want to meet you! Get in touch via smahjoub@elaia.com
Sources:
Barbarians at the Gate: How AI is Upending Systems Research, arXiv:2510.06189
Reward Hacking in Self-Improving Code Agents, ICLR 2026 Workshop on Recursive Self-Improvement (OpenReview)
ProofWright: Towards Agentic Formal Verification of CUDA, arXiv:2511.12294
GenAI for Systems: Recurring Challenges and Design Principles from Software to Silicon, arXiv:2602.15241
LLM-Generated CUDA Kernels: Are We There Yet?, NVIDIA GTC 2026 (NVIDIA developer-tools team and the GPU Mode community platform, source of the correctness figures and the optimization-trajectory diagnosis)
The February 2025 “AI CUDA Engineer” episode and its subsequent public correction
A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve, 2026 arXiv:2507.21046
Tensor Programs V: Tuning Large Neural Networks via Zero-Shot Hyperparameter Transfer, arXiv:2203.03466
AlphaGo Moment for Model Architecture Discovery (ASI-ARCH), SJTU/SII/GAIR, 2025, and its follow-up ASI-Evolve: AI Accelerates AI, arXiv:2603.29640
PostTrainBench: Can LLM Agents Automate LLM Post-Training?, ICLR 2026 RSI Workshop
Towards Execution-Grounded Automated AI Research, arXiv:2601.14525
Learning to Continually Learn via Meta-learning Agentic Memory Designs, arXiv:2602.07755
KernelBench, arXiv:2502.10517
ICLR 2026 Workshop on Recursive Self-Improvement (110 accepted papers)
What is the MFU for DeepSeek-V3 Training?, dlrover, Medium
Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents, arXiv:2505.22954
Autodata: An agentic data scientist to create high quality synthetic data, arXiv:2606.25996
https://tech.eu/2026/05/13/recursive-superintelligence-emerges-from-stealth-with-650m-raise/
Kevin (Cognition), arXiv:2507.11948
FunSearch (DeepMind, Nature 2023)
Technical glossary:
Compilation: translating a program from the language a human wrote it in into a lower-level language a machine can understand.
Profiling: dynamic analysis that measures where programs spend time and resources.
Assembly code: lowest-level human-readable code a chip understands.
Collective communication libraries (e.g NCCL from Nvidia): the software that coordinates data exchanges between chips.
Reward hacking: when a system optimizes the score it is given instead of the real goal, finding loopholes that look like success.
KV cache: the intermediate state a model stores so it does not recompute earlier tokens, managing it well is central to fast serving.
Formal verification: mathematically proving code is correct for every possible input, unlike testing, which only checks the inputs you try.
RTL (Register-Transfer Level): the code-level blueprint of a chip, the “source code” that describes its logic before it is turned into a physical silicon layout.
PR (Pull Request): a proposed set of code changes submitted for review before being merged into the main codebase.
CI/CD (Continuous Integration/Continuous Deployment): the automated pipeline that builds, tests, and ships code changes as they’re merged.
The bitter lesson: the observation that general methods leveraging more compute have historically beaten approaches built on hand-crafted human knowledge.
CUDA moat: the deep lock-in Nvidia created by making its proprietary CUDA software the near-universal standard for AI development.
Neo-cloud: a new class of GPU-specialized cloud provider (e.g. CoreWeave, Nebius), as opposed to the general hyperscalers.
Napkin math for Nvidia GPU performance engineers annual spend:
Using linkedin recruiter search with relevant key words we find 1.6k GPU performance-related engineers at Nvidia.
According to Waleed Atallah, CEO of Makora, a leading AI for AI infra company, avg performance engineer at Nvidia is paid $500k. (podcast link)
→ Nvidia spends $800m per year on GPU performance engineering.
AlphaChip (Google, Nature 2021 / 2024 update)
[PLDI 2026] Tensor Algebra Equivalence Checker (Conference talk by Jubi Taneja from Gimlet Labs at 6:00:00)