SI Agent News
DevelopingClaudeOpenAIAgents

A dev.to guide shows Claude Code running website A/B tests on its own

Coding agents can build a landing page in minutes, but judging it takes real traffic. A dev.to walkthrough hands that testing loop to the agent through MCP.

95%chance a version must have of beating the original to be kept

The short version

Why it matters

Building pages is now fast, but knowing which version works still takes time and attention. This workflow shows how to shorten that gap while keeping a person in charge of what goes live. It only pays off if your site has enough visitors to produce a clear result.

The slow step after the build

As dev.to reported in a post by a founder of a testing tool, coding agents can now produce a landing page in minutes. The harder question comes afterward: does the new page actually convert better than the old one? Answering that needs a split test, where real visitors see different versions at the same time.

Traditionally that means a testing product, a dashboard and someone to watch it. The post argues the agent can run that loop itself: add the site, install the tracking code, start a test and read the result, all from the terminal.

How the agent reaches the testing tool

The connection runs through the Model Context Protocol, or MCP. It lets an AI app such as Claude Code, Claude, ChatGPT, Cursor or Codex call tools hosted on a remote server. The server publishes a menu of actions, and the agent picks from it.

The post groups the useful actions into four kinds:

The author uses his own product, Luria, for the demo and says the same idea applies to any testing tool with an API. As an example he points to PostHog, which has an MCP server for feature-flag experiments.

The workflow, step by step

First comes connecting. One command registers the server with Claude Code, and the first call opens a browser where you sign in with an emailed link and approve access. No API key is pasted. Other editors take the same web address in a small settings block.

Next, you ask the agent to add your site and install the tag. It receives a one-line script, edits your layout file, then keeps checking until the tag reports back. Until a site is connected, the other tools reply with the next setup steps, which stops the agent from creating tests on nothing.

Then you ask for a test, for example on the homepage headline, with the current version as the control. The agent can write the new version itself or let the tool draft one from the page and the site's data.

The post stresses counting real outcomes rather than clicks. If purchases happen on your backend, such as in Stripe, the conversion can be sent from there with the visitor's ID, an event name, a value and an order number. You can also ask the agent to wire a Stripe webhook to the tool, since it can see your code.

Finally, you ask how the test is doing. The agent reads visits, conversions and each version's chance of beating the original, then can move on to the next suggested test.

Rules that keep the agent in check

The design includes several safety choices. The first live change waits for the owner's approval: the agent can propose, but a human signs off. After that, tests can run on their own. The original page stays live as a held-out control and never falls below a minimum share of traffic, so results compare people at the same moment, not before and after.

The statistical bar is explicit. A change is kept only when it is 95% likely to beat the original, after at least 200 visits per version. The post also links a sample size calculator for estimating how long that might take.

The author lists guardrails he would want with any tool: human approval of the first change, a kill switch that stops everything fast, spending caps, and read-only tools labeled as such so the app can approve reads automatically and ask before writes. He also wants error messages that say what to send next, so the agent can fix a bad call rather than guess.

Who should care, and the caveats

The idea is more incremental than new. A/B testing is old, and the agent does not change the statistics. What changes is that building, launching and measuring can happen in one working session, with less clicking through dashboards.

There are limits. You need real traffic, and a small site may wait a long time for a trustworthy gap between versions. Someone should still choose the success measure and the stopping rule before launch. Your agent must also support MCP servers, so check its documentation.

Note the disclosure: the author is the founder of Luria and mentions that new accounts get 1,000 free credits. Treat the post as a tutorial from a vendor, and judge the workflow separately from the product. Other pricing is not stated.

What to watch

Try it

If you already run a site with an MCP-capable agent, pick one low-risk element, such as a headline. Decide your success measure and stopping rule first, and keep a person approving what goes live.

Sources and links

Liked it? Say why

Add a line for other readers.

No account needed. We never show your email. Comments with links, ads or abuse are held and not shown. Your comment shows after a quick check.

Listen to the AI Wire headlines

Listen to the AI Wire

Listen to our daily AI shows every morning: on your commute, in the shower, wherever you are

Listen to the daily shows

First reported by dev.to · Read the original. Written by the SI Agent News Desk from the reporting above.Written with AI from the source above. Every number is checked against the source. Spot a mistake? Corrections.

More AI news