The full experiment lifecycle in Claude Code: Create -> run -> decide -> ship

Claude Code can move through the whole experiment lifecycle. The hard part is keeping each phase honest.

The lifecycle is not "ask Claude to build a variant and ship it." It is create, run, decide, and ship. Each phase has a different owner, different failure mode, and different evidence threshold.

Use Claude Code for code generation, test creation, repository inspection, and workflow automation. Use GrowthBook for flags, assignment, metrics, guardrails, experiment results, and rollout decisions.

Create: turn an idea into a controlled change

Start with a problem statement:

Users are abandoning onboarding before connecting a data source.
Create a guided checklist treatment behind a GrowthBook flag.
Keep current onboarding as control.
Do not remove the old path.

Then ask Claude Code for an experiment spec before it edits files. The spec should include hypothesis, audience, primary metric, guardrails, runtime surface, flag key, fallback behavior, and cleanup owner.

This is where the GrowthBook MCP Server helps. Claude Code can create a feature flag, search the GrowthBook docs, create an experiment, and inspect existing GrowthBook objects. The Claude Code documentation and Claude Code commands explain how the agent works inside a terminal session, while the Model Context Protocol introduction explains the tool-connection model behind MCP.

Run: deploy code separately from exposure

Once the flag is created, Claude Code can implement the variant and tests:

const showGuidedSetup = useFeatureIsOn("guided_data_setup");

return showGuidedSetup ? (
<GuidedDataSetup account={account} />
) : (
<CurrentDataSetup account={account} />
);

The deploy can go out with the flag defaulted off. Exposure starts later through GrowthBook targeting or experiment assignment. That separation matters because Claude can generate a plausible treatment faster than a team can prove it is safe.

Use GrowthBook's feature flag experiment docs to connect the flag to an experiment when the decision requires evidence.

Decide: use metrics, not vibes

The decision should be written before traffic enters the experiment:

Ask Claude to summarize the result, but not to bless its own implementation:

Summarize the GrowthBook experiment.
Include primary metric direction, guardrail status, sample ratio issues, and implementation risks.
Do not recommend shipping unless the predefined decision rule is met.

GrowthBook's experimentation platform and metrics docs keep the decision tied to shared measurement instead of chat history.

Ship: graduate or remove the flag

If the treatment wins, ship means two things: expose the treatment and clean up the temporary branching logic. Claude Code can help with the cleanup PR:

The guided_data_setup experiment has shipped.
Remove the old control path.
Keep analytics events intact.
Delete dead tests.
Search for stale references to guided_data_setup.
Return a cleanup summary.

If the treatment loses, ship the learning instead. Close the experiment, document the result, remove the treatment branch, and keep the control path.

Where GrowthBook fits

Claude Code is the implementation partner. GrowthBook is the system of record for exposure and evidence. The full lifecycle works only when the two stay separate: Claude proposes and changes code; GrowthBook controls who sees the code and whether the result justifies shipping.

If the workflow becomes a standard team pattern, document it in the same place you document release rules. Use GrowthBook AI-native development for the product pattern, GrowthBook SDK docs for runtime implementation, Claude Code CLI reference for command-line behavior, Claude Code slash command docs for reusable commands, and developer discussion of Claude-generated code review as a reminder that generated code still needs ownership.

Operating model for the Claude Code experiment lifecycle

The workflow needs an owner model before it needs more automation. AI coding tools can propose changes, but the team still needs clear accountability for release control, measurement, and cleanup.

Use this ownership split:

This does not need to become a heavyweight approval process. The point is to make sure the agent never becomes the only system that knows why a change exists. The flag, experiment, metric, and pull request should each point back to the same decision.

Minimum governance that does not slow the team down

A practical AI-native release process can stay lightweight:

• Store agent rules in the repository or team workspace.
• Require a named GrowthBook flag for user-facing changes.
• Require default-off behavior unless the change is purely internal.
• Require tests for flag-off and flag-on states.
• Require a GrowthBook owner before production exposure changes.
• Require metrics before calling a rollout an experiment.
• Require cleanup notes before the flag ships broadly.

Those rules are small enough to fit in a prompt, a pull request template, or an internal playbook. They also give AI tools a consistent target. The agent is much better at following explicit constraints than inferring release norms from scattered code.

Metrics that make the workflow useful

The release system should measure more than whether the agent produced code. Useful operating metrics include:

• Time from idea to first reviewed pull request.
• Share of AI-assisted user-facing changes shipped behind a flag.
• Share of flags with a named owner and cleanup date.
• Share of experiments with a primary metric and guardrails defined before exposure.
• Number of rollbacks or pauses caused by guardrail movement.
• Number of stale flags removed after decisions.

These metrics keep the team focused on the actual outcome: faster product learning with controlled exposure. A high volume of generated code is not a win if review slows down, flags pile up, or experiments become impossible to interpret.

Four-week rollout plan

Start narrow:

By the end of the fourth week, the team should know whether the workflow is real. If developers are still pasting flag names between tools by hand, improve the MCP setup. If experiments are missing metrics, improve metric ownership. If reviews are slow, narrow the agent prompts and split unrelated refactors out of the feature work.

Practical implementation playbook

Treat Claude Code experiment lifecycle as a workflow, not a one-off prompt. The teams that get the most value from AI coding tools do three things consistently: they narrow the task, keep release state in GrowthBook, and make the final output reviewable by humans who were not in the original chat.

Step 1: Write the release contract

Before code changes, define the contract in a few sentences:

Change:
User-visible behavior:
GrowthBook flag:
Default value:
Fallback:
Owner:
Primary metric:
Guardrails:
Cleanup condition:

The agent can help fill missing fields, but it should not silently invent them. If the primary metric or owner is missing, the right next step is a gap report.

Step 2: Inspect before editing

Ask the tool to inspect existing patterns first:

• Where does the app initialize the GrowthBook SDK?
• Which helper functions or hooks evaluate flags?
• How are tests written for feature-flagged behavior?
• Where do analytics events fire?
• Which files are likely to change?

This keeps the first implementation from creating a second GrowthBook client, duplicating SDK logic, or placing a flag check too high in the component tree.

Step 3: Make one controlled change

The first pass should be deliberately small. Create or reference one flag, preserve one fallback, and test both states. If the agent discovers a useful refactor, capture it as a separate follow-up. Do not let a flag implementation turn into a cleanup project, design-system rewrite, and analytics migration in the same pull request.

Step 4: Review for release risk

Use the agent again, but switch it into review mode:

Review this AI-assisted change for release risk.
Check flag key consistency, fallback behavior, test coverage, analytics parity, targeting assumptions, and cleanup notes.
List blockers first.
Do not modify files.

This prompt usually finds a different class of issues than normal linting. It looks for the ways a change can be technically valid but operationally unsafe.

Step 5: Expose gradually

Deployment and release should stay separate. Deploy the code with the default safe value. Use GrowthBook to expose the change to internal users, a beta segment, a percentage rollout, or an experiment audience. If the change needs evidence, connect it to an experiment before broad exposure.

Step 6: Close the loop

The workflow is not done when the flag turns on. It is done when one of these outcomes happens:

• The treatment ships and temporary branching logic is removed.
• The treatment loses and the new path is removed.
• The test is inconclusive and the next iteration is defined.
• The rollout is paused because a guardrail or QA issue appeared.

Ask the agent for cleanup only after the human-owned decision is clear.

Example review packet

A good final packet should fit in a pull request comment:

• GrowthBook object: new_checkout_summary flag and linked experiment.
• Default: false for all production users.
• Fallback: existing checkout summary component.
• Treatment: new summary component with revised copy and layout.
• Tests: unit tests for off/on states and one integration smoke test.
• Metrics: checkout completion as primary, error rate and latency as guardrails.
• Rollout: internal staff, beta accounts, then experiment traffic.
• Cleanup: remove losing branch or graduate winning branch after decision.

This packet is not bureaucracy. It is the artifact that lets someone review the work without trusting a chat transcript.