Self-driving FAQ

Skeptical questions, answered straight. If yours isn't here, ask us via in-app support or the community.

Won't this fill my repo with AI slop?

That's the failure mode, and the whole system is built to avoid it. Three things stand between a signal and your main branch:

1. Reports are investigated before anything is written. An agent has to confirm the problem is real in your data and your code before a PR exists at all. Reports that don't clear the bar never become code.
2. Every change is a pull request a human reviews. It arrives with your CI and review rules attached, and nothing merges itself.
3. You pay per PR, and we refund PRs that miss the bar. A business model that charges for slop dies quickly. Ours only works if the PRs are worth merging.

Self-driving also stays in its lane: maintenance, fixes, and optimization. It doesn't attempt speculative rewrites of your architecture.

Why can't I just point Claude Code or Cursor at my repo?

You can, and you should – they're great at the coding half. But a coding agent starts from a prompt or a ticket and sees only your repo. It can't originate work from "users are rage-clicking the confirm button and revenue dipped," because those signals don't live in your code. They live in your product data, and that's what PostHog has.

That's the honest difference: general-purpose agents are cruise control, keeping you moving in the lane you already picked. Self-driving finds the road. And if you want your own agent to have that context too, connect it via the PostHog MCP.

What can the agents actually touch?

Less than a contractor with repo access:

• Work happens in an isolated sandbox in the cloud, on a clone of your repo, never on your machines or infrastructure.
• Agents work on a branch and open a pull request. They follow your branch protections, CI, and review rules, and they can't merge.
• Every action is logged. Open the agent log on any report to see exactly which files it read, which queries it ran, and how it reached its conclusion.

Nothing reaches production without a human clicking merge.

Do you use this on PostHog itself?

Yes, heavily. A troop of more than 90 scouts – the canonical fleet plus dozens our own teams have written – watches the PostHog app, and reports about posthog.com become pull requests on the public repo that builds this site, where you can read them. We're the first customer of every part of the loop, and the first to feel it when something's off.

What happens when it gets something wrong?

It will sometimes; it's in open beta and we say so on every page. The system is designed so that being wrong is cheap:

• A wrong report costs you nothing. Reports are free, and you can decline or snooze them.
• A wrong PR costs you a review, and then nothing: we refund PRs that misdiagnose the problem or don't fix what they claim to.
• A wrong merged change gets caught by the loop itself. PostHog measures whether the targeted metric actually moved, and a validation scout re-checks fixes after a soak window.

Is my code or data used to train models?

Your private repos stay private and your data stays in PostHog. We do train our own models, but not on your code. Self-driving relies on AI, so your organization needs AI data processing turned on – the setup wizard checks this for you.

The scouts themselves aren't a black box either: every canonical scout is a readable skill published in the PostHog repo.

How is this different from alerts and monitoring?

Monitoring tells you something broke, then the work begins: triage the alert, reproduce the bug, find the owner, write the fix. Self-driving does that pipeline for you. A signal is investigated, grouped with related evidence, root-caused against your code, and handed to you as a reviewed-and-ready pull request. The anatomy of a pull request walks through the difference on a single bug.

Do I need scouts or signal sources?

Usually both, and they're not competing – they make a trade against each other.

A signal source is deterministic and exhaustive: turn one on and every qualifying item in that stream is processed, continuously, with no bar to clear and nothing skipped because an agent judged it uninteresting. A scout trades some of that for judgement: it runs on a schedule, explores rather than following a fixed stream, and decides what's worth surfacing, so it can weigh and rank and stay quiet – but it's selective by design rather than exhaustive.

Use a source when the stream is well-defined and missing an item would be unacceptable. Use a scout when everything in the stream is technically "something" and you need judgement applied, when what you care about spans several surfaces, or when "worth knowing" is a matter of opinion only your team can define. They stack, too: a scout can sit on top of an existing detector, bundling related items and flagging what nobody actioned, while the source keeps its guaranteed coverage.

Sources or scouts? has the side-by-side breakdown.

Will a scout miss things?

By design, yes – that's the difference between a scout and a source, and it's the point rather than a bug. A scout holds a bar, so most runs close out having found nothing worth your attention, and it deliberately stays quiet on a quiet day. If it talked every day you'd stop reading it.

If you need guaranteed handling of a specific stream, use a signal source for that stream, and let scouts cover the questions nobody is holding. If a scout is holding back things you do want, you don't have to edit it: dismiss a report with a note explaining why, or leave a scout note in plain English, and later runs read both.

How do I control what it watches, and what it costs?

Everything is a toggle, and every dollar has a ceiling:

• Turn individual signal sources and scouts on or off per project.
• You pay a flat $15 per pull request. Reports are free, and your first three PRs each month are free.
• A default $150 billing limit is set for you, and you can lower it. When you hit the limit, PR generation pauses until the next billing period.

See pricing for the full picture.

Convinced, or at least curious?

Setup is one command, and most teams are done in a few minutes: