PostHog 月 PR 破万：AI 代理与 CI 优化实践

Shipping cadence is accelerating at PostHog. In the last 6 months, we've gone from shipping 1,441 PRs in January to 4,725 PRs in June while increasing engineering headcount by only 10%.

This is heading towards our north star for internal developer experience: "10,000 PRs a month is easy." We thought we would have until December to hit this number, but we might get there as early as September.

More PRs isn't a good thing in and of itself. It happens as a result of hiring talented, driven people and investing in agentic automation. Even if we don't hit these numbers, working toward our goals means making local dev, CI, and validation faster and better.

Here's how we've increased the volume of engineering work while still delivering reliable systems, and the changes we're making to make sure this remains the case.

Where has this acceleration come from?

The simple answer: people using AI a lot more.

There's no token budget set by some higher-ups at PostHog. We want people to figure out how we make use of new tools and create new tools. It's up to them as individuals to use the right amount of tokens, and none of us are going to pretend we know what that amount is.

This works because it's a big part of our culture to value trust and feedback over process. If we get to the point where we're uncomfortable with someone's spend, we'll dig into that with them and figure out if the spend is reasonable. Everyone else can learn from that too.

Everybody's using agents and writing skills, but our self-driving loop is further fueling the accelerated cadence. Over the last 4 months, we moved from around 20% of our monorepo PRs being opened by agent to 70%. Self-driving is around 4% of our PRs right now but growing fast.

Speeding up the rate we create PRs doesn't necessarily mean speeding up the rate we can handle them. For that, we're relying on agentic loops getting those PRs ready for human attention. Things like:

• Keeping up to date with trunk
• Making sure that CI is passing
• Making sure that reviews have been acted on

The folks who are pushing the limits of what they can achieve have written their own applications, like review and PR management tools or qa-swarm and babysit-prs skills. They have maybe 40 PRs open at the same time, but we want to push this further and get more people on board. Something like 60% of my token spend is burned automating the toil of handling CI and review and I don't regret a single dollar.

Getting off local machines

The PostHog stack is very heavy for local development, so we've always needed powerful dev machines. This was fine until people started wanting to run multiple copies of the stack to test PRs. We're hitting the limits of what's possible now; there's only so much RAM and disk you can put into a MacBook.

So, we're building out cloud dev machines. They're skill-driven so you just ask your agent to start a dev machine with a prompt like:

Start a dev box, run this PR in it, and record me a video of the changes that we're making so I can see the output of the test.

This is powered by our internal developer CLI hogli, which also pushes CI checks down into local dev by helping agents better test code locally. It also includes a tool to quickly send feedback to our devex team when something is difficult (for people or agents), which helps our devex team make specific improvements fast.

Battling the bottleneck of CI

Like many companies, CI has always been a challenge at PostHog because of the breadth of our product. That means increasing the number of PRs created by 50% month over month was like spraying a house fire with gasoline.

Depot, the compute infrastructure for our CI, has handled this incredibly well – in June 2026, we used 21,643,653 minutes of CI time. That's 41 years of CI time in a single month.

The key to making our CI more efficient is defining the work that does not get done. Basically, we want to skip the CI more, but not too much; we need it to be in the Goldilocks zone. This means working on:

• Ways of quarantining flaky tests. We can mark tests so they run and report, but can't fail the CI, blocking everyone.
• Building out the abstract syntax tree (AST) for changes so we can more selectively run tests. Right now, we have too many PRs where the whole test suite is running unnecessarily because the CI can't tell when a change is contained from the static analysis of paths.
• Merge queues, since we're increasingly seeing passing PRs break main when merged together.
• Increasing the speed of CI jobs like using a pre-migrated database schema (which decreased backend CI times from ~23 to ~15 minutes).

Alongside all this, we're streaming GitHub data into PostHog. This gives us engineering analytics that we can look at using PostHog AI:

• What workflow jobs cost the most money?
• Which take the most time?
• Which fail most frequently?

This lets us make targeted improvements on the CI and get PRs to green faster.

How we validate PostHog isn't breaking

We've always cared more about making it easy to quickly fix things rather than avoiding breaking them in the first place. This is especially true when dealing with UI, charts, access, and filters. It's much more important that we find out if the change is actually useful instead of wasting time getting it perfect on the first try.

But in reality, there are many services we can't break. For example, accepting and displaying your data – it's the core reason many users come to PostHog. Failing at this would be catastrophic, so we rely on a lot of automated testing and validation, including a quarter of a million Python tests for our backend. They're paying off even more now because they give us higher confidence in agent-driven work where validation says it's safe.

Safety is not quality though, so we have some measures to help us see how things are changing.

The first is size. Line count is a rough proxy for quality. Less is better as past some threshold people stop reviewing carefully and quality drops. Agents are writing bigger PRs, especially at the extreme, but the average PR is not hugely bigger. Partly that is our engineers driving quality.

Another way to judge quality is through PR titles. We use conventional commits like fix, feat, and revert to signal the type of work in the PR.

The distribution of PR types is stable across the last year. AI isn't just creating more fixes or refactors. More importantly, the percentage of reverts has barely changed, and we are eager to revert whenever we need to. This is a sign production isn't breaking more under the load of agentic PRs.

The ultimate goal is reliability for all of PostHog, which has remained solid:

Humans don't need to review every PR

With agents creating more and more of the PRs, code review becomes a bigger part of the work. Engineers spend less time on each review, so we need to find ways of making that safe while maintaining momentum.