[I think this is the biggest achievement so far in recurring self-improving AI products → by Andrej Karpathy.]

When Andrej Karpathy released autoresearch, the part that stuck with me was not the model improvements.

It was the loop.

Make a change. Measure it. Keep it if it helps. Throw it away if it does not. Repeat. All night. No human in the loop.

In his published run, the agent executed 125 experiments on a single GPU and improved the model while Karpathy slept.

That is already interesting for ML research, and might lead to Artificial Superintellice (ASI).

But I kept thinking: what if you point this at a product instead of a model?

We started applying this inside FlowCursor, where one of the hardest problems is getting the right context to the AI model so it can answer the right question.

Think YouTube comments instead of the sidebar. The correct calendar block instead of the navigation. The right code region instead of random visible text.

We scoped an agent to the files that influence context quality. We built a benchmark around real user situations: docs, task boards, calendars, YouTube, PDFs, code editors. We built a scoring function that penalizes broken builds and rewards better extraction.

Then we ran the loop.

The gains so far are modest. Early signals, not a victory lap.

But what we did see is that better context selection and better wrong-surface filtering can move the product in the right direction on internal cases. A few of those changes survived the keep/discard gate. Most did not.

That is actually the interesting part.

Because once you have a working loop and an honest benchmark, improvement stops being only about taste or guesswork. It starts becoming a search problem.

And search scales with compute.

Once the loop is real, the bottleneck is not ideas. It is compute.

More cycles. More candidate changes. More benchmark cases. More parallel agents. More analysis of what worked and what regressed.

For years, product improvement was bottlenecked by engineering time and good instincts. With a loop like this, part of it shifts to how much honest search you can afford to run.

This is one reason tools like Cursor Pro matter in practice for this kind of work. Pro includes extended Agent limits, Cloud Agents, unlimited Tab completions, and maximum context windows. For agent-heavy workflows like this, that headroom is the difference between running 5 experiments and running 50. Not because more compute replaces judgment, but because it lets you search more around the judgment you already have.

The core idea from Karpathy stays the same. The setup changes.

For model training, he had one file to mutate, one metric, and one clear target.

For products, you need to get four things right:

Getting each of those right for a product, not a training script, is where the real work lives. And it is where most teams will get stuck if they try this without a guide.

I wrote a PDF guidance paper that walks through exactly how to set up a product autoresearch loop in your own business.

It covers:

This is the kind of applied, practical document I plan to keep producing for premium subscribers. Not just ideas, but the actual setup for applying them in products and businesses.

If you subscribe to premium today, you get the PDF guide when it ships.

And because compute is one of the scarce resources in this kind of work: the first 3 premium subscribers who reply to the welcome email will also get one of my Cursor Pro invites. I only have 3 of these. They are for new Cursor users only.