Recursive Self-Improving Websites Are Here
Late last year, our customers started taking our data out of Noibu.
Not leaving. Exporting. A heatmap screenshot pasted into ChatGPT. A one-person Shopify operation doing about $50 million a year that had wired every tool it owned into Claude, and wanted ours in there too. A merchant who had never opened a terminal copying two Noibu issues into Claude Code, letting it write the fixes, and shipping them.
For nine years our product had ended at a dashboard. What happened after that was somebody else's job. Now the somebody was a model, and it was already doing the job badly: on screenshots, without context, and with no way to check whether what it suggested had worked.
In January, AI came up in about 1% of our customer conversations. By late June it was 80%. Now it's 100%.
So we stopped ending at the dashboard. We built connectors so the models could read the data directly, agents to run the workflows our best customers were doing by hand, and the plumbing so what they drafted could ship and be measured — with one rule underneath all of it: nothing reaches a live store until a human approves it. You approve what ships. We built the whole thing around that.
By July, a significant amount of merchants were running this loop organically. They're the reason for this post. People weren't asking for reports. They were asking for changes, and then asking whether the changes worked.
The first store we watched improve itself
At Totally Bamboo, one person runs all of DTC across 600+ SKUs. She used the store's own data to test a collection-page filter, and the variant converted 24% better. Before that, a product-data error had been firing about 40 times a day for months. The agent found it in the same data and wrote the fix; it was live the next morning, and two weeks of debugging became half a day. Thirty days later, conversion was up 7% on the prior 30. A CLS score in the red since 2024 went from 0.53 to 0.02.
One store, improving itself cycle after cycle, with one person saying yes.
It's not the only one anymore, so we'll say it plainly: recursive, self-improving websites are here. Not in a lab. Not on a roadmap. On stores run by one person, and inside brand groups running eight storefronts off one small team.
What we mean by "recursive"
The phrase comes from AI research. In 1965, I. J. Good described a machine smart enough to design a better machine, which designs a better one still — "provided that the machine is docile enough to tell us how to keep it under control." Most people quote the first half. The second half is the whole point.
The plain version: a process is recursive when its output becomes its own input. A change ships to your store. The store's own data tells you what shoppers did with it. That result is the starting point for the next change. Run it every week and the store improves on a schedule. Headcount stops being the limit.
Good's condition has a concrete form here: the merge button. Nothing in the loop reaches a live store until a human approves it — no, yes, or not like that. That's the docility. Everything else is the machine.
What the loop looks like when it's running
Every cycle has the same shape.
Find. Scan the store's own behavior for something worth changing: a checkout step mobile shoppers abandon and desktop shoppers don't, a variant selector getting rage-clicked on iOS, paid traffic looping from checkout to the contact page and out, a four-second LCP, an error firing on add-to-cart.
Draft. Write the change: an A/B test with a hypothesis, a success metric and two variations — or a code fix as a pull request.
Approve. Someone who knows the store says yes, no, or not like that.
Ship and measure. The change goes live, gets logged as a release, and the same data that found the problem reports whether the pattern is gone and what the metric actually did.
Repeat, sharper.
No single test is the point. A hypothesis is not an improvement, and neither is a pull request. A change that shipped, got logged, and had its metric checked a week later against a control is. The point is how many of those land per week — and that number no longer tracks how many people you have.
An ecommerce manager at a brand in trial with us traced a theme error that fired 232,599 times in a single day, shipped the fix in a theme publish, and watched the count drop to zero. The following week she came back and ran the analysis that proved it. The agent's log for that check reads: "checking for a theme release around Aug 17–19 that could explain the error's sharp drop-off."
She measured her own fix. That's the loop.
Why "here" and not "coming"
Eighteen months ago the models weren't good enough. They were unreliable at calling tools and made things up when they couldn't see the data. Then they got good at tools, very good at code, and MCP gave them a standard way to reach into a store's data.
Over the last 30 days, the average merchant on our connector ran roughly 320 Noibu tool calls from inside the AI clients they already use. About a quarter of those calls weren't typed by anyone. An agent made them.
Here's what surprised us most. When we looked at what merchants ran in August, a category that didn't exist in June — release and deploy verification — was already 6% of all calls. Nobody asked them to build that. They wanted proof last week's change worked before they asked for the next one.
The hard part is the plumbing
Every pitch in this category leads with the insight: the AI reads your analytics and tells you what to change. Any frontier model handed a conversion report will tell you where the drop-off is. That part is a commodity.
The part that isn't is everything after the suggestion — and it's where a self-improving website is actually built or lost. Miss any one of three things and you don't have a loop. You have a very confident intern.
Something has to serve the change. A model can suggest an A/B test. It can't serve one. You need to bucket a visitor and keep them there, render the variant without the page flashing the control first, and survive how merchants actually behave — which is checking results every morning. (Anti-flicker snippets that hide the page until the test loads are their own tax: DebugBear measured one site's LCP going from 2.7s to 6.0s with that trick on.) A flag failure has to be a no-op, not a broken page.
Every change has to be logged. A loop without a change log isn't a loop; it's activity. Nobody can say whether the checkout dip on the 15th was the theme update on the 14th or the app install on the 13th unless every change lands as a release event the data can see — CI/CD webhooks, theme publishes and app installs detected automatically, merged PRs — each with a seven-day before-and-after. (One catch: Shopify's checkout deploys change the build hash in asset filenames, and on one store that turned a single bug into 609 "different" issues. Normalize the signature or the log lies to you.)
The data pipeline has to be yours. In the absence of proprietary data there's no alpha. A model reasoning over GA4 can tell you conversion dropped; it can't tell you why, because the why lives in sessions, scroll depth, click maps, journeys, Core Web Vitals, errors, and checkout events your platform may not even expose. This is why the screenshot era didn't last — a picture of a heatmap can be described, but not joined to the journey that led there, the release that went out that morning, or the test variation the shopper was in. For the loop to work, all of it sits in one place, unsampled and skeptical (stores get hit hard by bots; a "lift" that only shows up in unknown-source traffic is not a lift).
And it's different on every platform. The model doesn't care whether a store runs on Shopify, Salesforce Commerce Cloud, Adobe Commerce, BigCommerce or headless. The plumbing cares about nothing else — what counts as a release, where a variant can be served, what checkout lets you see. Perfectly gathered data isn't one build. It's five. The loop runs where that work has been done, and nowhere else.
What "here" means
Until now, a store got better at the speed of the people working on it. That constraint is gone. A store can land a measured improvement every day, whatever its headcount, and the team's job narrows to the one decision that should stay human: whether it ships.
The gap between the stores that run the loop and the stores that don't won't open as a leap. It will be one more improvement a week than the store next door, until it stops looking small.
One customer described the old way in a sentence we haven't been able to shake: nobody was accountable for closing the loop, because there was no loop.
There's a loop now. How many changes shipped to your store last week, and how many did you measure?
— Kailin Noivo, Robert Boukine and Filip Slatinac, co-founders of Noibu
