Implementation

Once research is complete and a report is marked Actionable, an implementation agent builds the change and opens a pull request for you to review.

Sandboxed execution

The agent clones your repository into a secure, sandboxed environment. It then:

1. Creates a new git branch (for example, ai-fix/billing-null-check).
2. Applies the code changes.
3. Runs any local tests, if configured.

Pull request generation

The agent pushes the branch to your remote and opens a pull request:

• Description – an AI-generated summary of the problem, the proposed change, and the research reasoning.
• Labels – PRs are automatically labeled (for example, LLM context or PostHog Agent) so reviewers know where they came from.

Use your own coding agent

Before you start, make sure that your agent can use the PostHog MCP server. The prompt contains a link to the report, not the report itself. Your agent uses the MCP server to read the report and its work log, claim the report, and attach its pull request.

On a report that can be implemented, open the arrow next to Implement. Choose Copy prompt for your agent to copy the task and report link.

Open the agent menu beside that control to send the prompt to PostHog Desktop, Claude Code CLI, Claude Desktop, Claude Code in VS Code, Claude Code on the web, Cursor, or Codex.

Sending or copying the prompt does not start a PostHog implementation task. Review the prompt in your chosen agent before you start work.

Choose how pull requests open

Self-driving pull requests open as drafts by default. In the self-driving settings, project admins can choose Draft or Ready for review as the project default. Reviewers can set their own preference for reports that suggest them as reviewers.

Stacked pull requests

Research can split a large change into dependent layers. PostHog creates a child report and pull request for each layer. A layer starts after its dependency has a pull request. PostHog sets the base of the layer's pull request when the layer starts. If the dependency pull request is open, the base is the dependency branch. If the dependency already merged, the base is the repository's base branch.

Review and merge the layers in order. PostHog does not change the base after a dependency merges. After you merge a layer, delete its branch so that GitHub changes the base of the next pull request automatically. If you keep the branch, change the base of the next pull request yourself before you merge it.

Reviewing and merging

Your job is to review the code the same way you would any other pull request, then click Merge when you're happy with it. If something needs tweaking, you can chat with the implementation agent directly and it'll make the changes you ask for.

Nothing ships without you. The inbox is where you stay in control of what self-driving does.

Next step

Run into something unexpected? See how to debug it.