PBX Ship turns winning tests into production code

PBX 2.0 covers every step of experimentation through five agents: Ideate, Build, Configure, Analyze, and Ship.

Winning experiments should not die in the backlog. PBX Ship turns winning client-side variations into native production code behind a feature flag, right from the developer’s own IDE.

Originally, PBX stopped when you could declare one test the winner. Now, PBX 2.0 can carry the win into the production codebase.

Many winning experiments never reach production

It’s a familiar story: the variation drives uplift; the test has won. The team lets engineering know and waits to see their results live.

Except engineering doesn’t have the bandwidth to manually rebuild every winning variation in native code. With Kameleoon, the variation runs as injected JavaScript. To turn a winning experiment into production code, the CRO team needs to give developers an implementation-ready handoff: the winning result summary, final Figma/design, functional spec, targeting rules, acceptance criteria, and rollout or rollback plan.

That means days or weeks per test, and, in a strong experimentation culture, dozens of winners waiting for their turn. Most of them simply sit in the backlog, their change too small to be worth prioritizing. In the end, the ROI of the experiment never lands.

Tests in the browser become what ships in production

PBX Ship closes the gap between client-side experimentation and server-side production. It acts as an MCP server, allowing the developer to prompt their AI coding assistant inside their IDE:

“Give me all winning tests sorted by the date they reached reliability.”

PBX Ship retrieves the results and lists the winning variations. The developer follows up:

“Take the first one and build that into our React codebase behind a feature flag.”

From here, PBX Ship pulls all the context required: variation code, the URL of the page, and the prompts that were used to build the variant. It then passes that context to the LLM the developer uses in their IDE every day. 

It reads the existing repo conventions and re-implements it as native React. Components, hooks, and styling systems all match the project’s patterns. It then creates the feature flag inside Kameleoon, wraps the new code behind it, and validates the rollout.

From here, the developer can run a quality check and deploy the change using the flag.

Feature flagging and experimentation included

Every implementation lives behind a Kameleoon feature flag, which means the team gets the full feature experimentation toolkit: rules for progressive rollout, rollback, targeting and scheduling, and continued experimentation by rearranging variables into new variations. What was tested in the browser becomes what runs in production.

Kameleoon, called from inside the IDE

Through this full process, the developer never needs to open Kameleoon. Their AI coding assistant, whether in Cursor, Claude, Codex, or another IDE that supports MCP, calls Kameleoon as a tool, retrieving experiment results, fetching variation code, and creating, toggling, and validating feature flags.

PBX Ship means that Kameleoon stops being a UI the developer visits and instead becomes a tool the AI assistant operates.

Closing the loop

The line between “we identified a winner” and “the winner is live” used to take days or weeks. With PBX Ship, it can take minutes. Once the winner is in production, PBX Analyze captures it via Takeaways and PBX Ideate uses that result to suggest the next test. 

The full lifecycle, from idea to production to next idea, runs through the same agent system.

PBX 2.0 is an agentic AI system dedicated to the full experimentation cycle.

• Generate impactful test ideas with Ideate
• Create any web variation with Build
• Prep for launch with Configure
• Assess results with Analyze
• Push winning tests live with Ship

{{cta-block}}