Why ABMeter works the way it does, one design decision per principle.
An A/B test can go wrong in quiet ways: a user moves to the other group halfway through, two tests change the same button, a user sees the new checkout button on the old checkout page. The results still look fine, and they are wrong. Each principle is one decision that keeps a mistake like this out of your results, so you can run a sound test without having run one before.
When a step carries a risk, ABMeter explains it, and only a person can take it. Your AI assistant cannot. Start with the introduction, then read them in order.
Introduction
A unit test tells you the code does what you meant. An A/B test tells you the feature does what the customer needed. With AI writing the code, the second question is the one left for you.
In ABMeter your code asks for a value, not for a variant. The same three lines serve the default, the experiment, and the winner, so a finished test leaves nothing to clean up.
In ABMeter a variant sets several parameters at once, and a user gets all of them or none. That is what lets you test a whole experience, like a new checkout, as one thing.
ABMeter is infrastructure. Your code talks to the REST API, your AI assistant talks to the MCP server, and the web UI is where a person starts a test, decides the outcome and reads the result.
An AI assistant can design an experiment and read its results, but it cannot ship the winner. MCP only gives the assistant hints, so ABMeter keeps that rule on the server and uses the browser to bring the decision to a person.
A server SDK decides which value a user gets inside your process, from a config it fetched earlier, and sends exposures and events in the background. Your request does not wait for ABMeter. The browser is the one exception, and the reason is the salts.
When something breaks inside an ABMeter SDK, your request does not see an exception. The SDK reports the error to your logs and your error tracker, and your code serves the value it served before the test. Go returns the error instead, and the reason is Go.
Once an experiment starts, every exposed user stays in the group they were first assigned to. ABMeter refuses any edit that would move them, through the API and through your AI assistant alike. To change the split, a person stops the test in the web UI and starts over.
Unit tests show that each SDK function works. They cannot show that a user's group, exposure and purchase reach the result intact. So every ABMeter SDK runs inside a small app that plays users with a lift known in advance, and ABMeter must report that lift back.
Experiments in one ABMeter space never share a user, and experiments in different spaces run in parallel on the same users. A parameter's name is unique across all your spaces, so one knob is never under two tests at once.