Andrej Karpathy’s latest project is not a new model, a benchmark-smashing paper, or a corporate platform. It’s a 630-line open source script called autoresearch, released under the MIT License on GitHub — and it is sparking serious conversation about what happens when AI starts running the scientific method on its own.
Rather than helping humans write code faster, autoresearch is designed to make progress without humans at all. Karpathy’s stated goal: engineer agents that “make the fastest research progress indefinitely and without any of your own involvement.”
For AI engineers, ML researchers, and business leaders, the experiment is a concrete glimpse of something often discussed in the abstract: autonomous experimentation loops that iterate all night while humans sleep.
What autoresearch actually does
At its core, autoresearch is an autonomous optimization loop wrapped around a training script and a fixed compute budget, typically five minutes on a GPU. The agent repeatedly runs the following cycle:
First, it reads and reasons about its own source code and training setup. This includes hyperparameters and architectural choices exposed in the script. Based on that, it forms a hypothesis for improvement — for example, changing a learning rate, adjusting depth, or tweaking regularization.
Next, the agent modifies the code accordingly, runs an experiment within the allowed budget, and evaluates the outcome. The primary metric in Karpathy’s demo is validation loss in bits per byte (val_bpb), a common measure in compression-style language modeling tasks. If the val_bpb improves, the change is kept; if not, the system reverts and tries a different hypothesis.
This loop requires no additional human prompts once configured. In one overnight run, Karpathy reports that the agent autonomously executed 126 experiments, improving validation loss from 0.9979 to 0.9697. He later left an agent tuning a “depth=12” model for two days; it processed roughly 700 autonomous changes and surfaced about 20 additive improvements that transferred cleanly to larger models.
Stacking those discovered changes reduced a “Time to GPT-2” leaderboard metric from 2.02 hours to 1.80 hours — an 11% gain in efficiency on a setup Karpathy already considered well-tuned. For practitioners used to squeezing out single-digit percentage improvements with weeks of manual work, those numbers immediately stand out.
Karpathy described seeing the full workflow run end-to-end “all by itself” as “wild,” noting that the agent identified oversights in attention scaling and regularization that had survived two decades of his own manual experimentation. The script may be small, but the pattern it demonstrates — AI autonomously exploring a search space of code and hyperparameters — is what has captured attention.
From lone script to swarm: how the community is scaling the loop

The broader response has been fast and highly visible. Karpathy’s initial post on X drew more than 8.6 million views in two days, as builders and researchers quickly began to adapt and extend the idea of what some have started calling the “Karpathy loop.”
One notable experiment comes from Varun Mathur, CEO of Hyperspace AI, an AI tool aggregator platform. Mathur took the single-agent autoresearch loop and distributed it across a peer-to-peer network. In this setup, each node running the Hyperspace agent effectively became an autonomous researcher, operating under its own hardware constraints yet sharing insights with peers.
On the night of March 8–9, 35 such agents ran 333 unsupervised experiments on the network. While the core mechanism was the same loop Karpathy demonstrated, the distributed setting introduced new dynamics — including diversity in hardware, communication of findings, and rapid “rediscovery” of known techniques.
Because the original project is open source and permissively licensed, these experiments are unfolding in public, with logs, results, and reflections being shared across X and GitHub. The effect is that autoresearch is moving quickly from a personal research script to a reference pattern for autonomous experimentation systems.
Inside the Hyperspace swarm: hardware diversity, gossip, and compressed history

The Hyperspace overnight run illustrates how the same basic loop behaves in a heterogeneous ecosystem. Mathur highlights three emergent patterns that are particularly relevant for engineers thinking about scaling these systems.
First, hardware diversity became a feature rather than a limitation. Agents running on high-end H100 GPUs could use “brute force” — exploring aggressive learning rates and compute-intensive configurations. In contrast, CPU-only agents on laptops had no such luxury. Constrained by throughput, these “underdog” agents focused on more strategic levers such as initialization methods (like Kaiming and Xavier) and normalization schemes. The result: qualitatively different hypothesis spaces emerged from different hardware classes.
Second, the agents shared discoveries via a gossip-style protocol (GossipSub). When one node found that Kaiming initialization reduced loss by 21%, that result propagated across the network “like a digital virus.” Within hours, 23 other agents had incorporated the idea and were building their own hypotheses on top of it. Instead of each agent rediscovering the same trick independently, the network collectively moved its baseline forward.
Third, the swarm compressed years of machine learning history into hours of autonomous search. Over roughly 17 hours, the agents independently rediscovered techniques such as RMSNorm and tied embeddings — methods that originally took human researchers at places like Google Brain and OpenAI nearly eight years to fully formalize and standardize. That does not mean the agents invented new theory; rather, they navigated a known search space far faster than isolated human teams could.
For ML practitioners, this suggests a future where entire clusters of agents explore architectural and training-design spaces, share findings, and converge on strong baselines orders of magnitude faster than conventional team workflows.
Why business leaders care: turning the loop on marketing

While ML researchers focus on loss curves, some in the business world are already mapping the autoresearch pattern onto commercial experimentation. Eric Siu, founder of ad agency Single Grain, framed the shift in terms of marketing teams’ experiment throughput.
Most marketing organizations today run on the order of a few dozen experiments per year — perhaps 20 to 30, or around 52 if they are particularly disciplined. Typical tests might include a new landing page, a refreshed creative, or an email subject-line A/B test. That cadence is often considered “data-driven” by current standards.
Siu envisions using an autoresearch-style loop to scale that up to more than 36,500 experiments annually — effectively one experiment per minute, running continuously, including while teams sleep. In his framing, the training script in Karpathy’s demo is replaced by a marketing asset: a landing page, ad creative, or cold email template.
The agent then plays the role of an autonomous marketer: it tweaks a variable (subject line, call to action, layout), deploys the variant, measures a key outcome such as positive reply rate, and either keeps or discards the change. Over time, this process builds what Siu calls a “proprietary map” of what resonates with a particular audience — an asset rooted not in code but in accumulated experiment history.
In this view, competitive advantage comes less from having “better marketers” and more from operating “faster experiment loops.” For data-driven business leaders, autoresearch becomes a template: define the asset, define the metric, and let an agent spin through iterations at a pace no human team could sustain.
Limits and risks: overfitting, validation leakage, and meaningful gains
Not everyone is treating the early results as unqualified progress. Discussion threads on the project’s GitHub highlight open questions that any serious deployment of autonomous research agents will have to confront.
One concern is over-optimization against fixed validation sets. Researcher alexisthual asked whether running large numbers of experiments risks “spoiling” the validation set — effectively tuning models to idiosyncrasies in that specific slice of data rather than improving generalization. With many agents probing the same benchmark, the chance of subtle overfitting increases, even if the system never explicitly trains on validation labels.
Another thread questions the practical significance of specific quantitative gains. User samionb challenged whether a drop in val_bpb from 0.9979 to 0.9697 is truly noticeable in downstream behavior. Karpathy’s reply was straightforward: the purpose of the loop is to optimize performance per unit of compute, and by that metric the gains are “real and substantial.” For teams that pay directly for GPU time, even increments of this size can translate into material efficiency improvements.
There is also a human-systems angle. On X, user witcheer, Head of Growth at Yari Finance, shared results from an overnight run on a Mac Mini M4. In that run, 26 of 35 experiments failed or crashed. Yet the seven successful runs surfaced a key insight: “the model got better by getting simpler.” The agent gravitated toward simplifications that improved performance, and it did so with no human guiding which direction to explore.
Together, these discussions underline that autonomous loops do not remove the need for careful evaluation, benchmark hygiene, and interpretability. They amplify both the upside of rapid search and the risk of optimizing for the wrong objective or the wrong dataset.
From coder to experimental designer
The release of autoresearch points to a shift in how ML work is organized. If agents can generate hypotheses, modify code, run experiments, and retain improvements, the human role naturally migrates upstream and downstream.
Upstream, humans define the problem space: which scripts, models, and data are exposed to the agent; what constraints are imposed on compute and architecture; which metrics truly matter. Downstream, they interpret results, decide what transfers to production, and ensure that “wins” are not artifacts of overfitting, data leakage, or mis-specified objectives.
Karpathy himself has framed the bottleneck less as raw coding ability and more as our capacity to define the right search constraints. As other tools like DarkMatter, Optimization Arena, and NanoClaw emerge to support swarms of such agents, the limiting factor may increasingly be human curiosity and experimental design, not the “meat computer’s” raw ability to type out model code.
This reframing is particularly relevant for organizations already operating complex ML stacks. Instead of asking “How do we hire more people to run more experiments?”, the question becomes “How do we design loops and guardrails so agents can explore safely and productively at scale?”
What to watch next
autoresearch is not a polished product, and Karpathy has been explicit about its simplicity. But the early experiments — both his and the community’s — hint at a broader pattern: AI systems treating code, parameters, and even business assets as search spaces to traverse autonomously.
For AI engineers and researchers, this raises practical near-term questions: how to structure experiments so that agent-discovered improvements transfer to larger models; how to protect validation sets from being “gamed” by relentless search; and how to integrate such loops into existing training and deployment pipelines.
For tech-savvy business leaders, the lesson is that experimentation itself is becoming a domain for automation. Whether in model tuning or marketing, the organizations that adapt fastest may be those that reimagine their teams as designers and stewards of autonomous loops, rather than sole executors of every experiment.
Karpathy’s small script has, as he often does, shifted the conversation. We are not only coding models anymore; we are beginning to seed ecosystems of agents that learn — and sometimes surprise us — while we sleep.

Hi, I’m Cary Huang — a tech enthusiast based in Canada. I’ve spent years working with complex production systems and open-source software. Through TechBuddies.io, my team and I share practical engineering insights, curate relevant tech news, and recommend useful tools and products to help developers learn and work more effectively.





