10k PRs in a month? easy!

[pauldambra]

Changes

Adds a new blog post: "10k PRs in a month? easy!" — how agentic development has changed developer experience at PostHog.

Covers: no token budgets, skill-driven dev machines and cloud runners, CI at 21.6M minutes/month, quality signals under 10–50% MoM PR growth, StampHog/ReviewHog, and agents testing PRs next.

Still TODO (draft)

• Fill in reliability fact (marked $$$some reliability fact here$$$ in the Validation section)
• Add a featuredImage (none set yet)
• Prose is still in spoken-draft form — needs an editing pass

Checklist

• Words are spelled using American spelling 🇺🇸 (mostly — draft)

[github-actions]

Deploy preview

Status	Details	Updated (UTC)
🟡 Building	View logs	Jul 22, 2026 08:50PM

[github-actions]

Vale prose linter → found 12 errors, 13 warnings, 0 suggestions in your markdown

Full report → Copy the linter results into an LLM to batch-fix issues.

Linter being weird? Update the rules!

contents/blog/10k-prs-in-a-month.md — 12 errors, 13 warnings, 0 suggestions

Line	Severity	Message	Rule
16:106	warning	Capitalize 'Workflows' for PostHog's product. Use 'workflows' for the general industry concept.	PostHogBase.ProductNames
22:19	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
24:23	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
33:313	warning	'ci' is a possible misspelling.	PostHogBase.Spelling
43:58	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
43:60	warning	'macbooks' is a possible misspelling.	PostHogBase.Spelling
45:17	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
48:320	warning	Use 'Macbook' instead of 'macbook'.	Vale.Terms
52:101	warning	'devex' is a possible misspelling.	PostHogBase.Spelling
58:4	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
59:35	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
61:3	warning	'Dogfooding' is a possible misspelling.	PostHogBase.Spelling
63:35	warning	'ci' is a possible misspelling.	PostHogBase.Spelling
63:68	warning	'ci' is a possible misspelling.	PostHogBase.Spelling
63:103	warning	'ci' is a possible misspelling.	PostHogBase.Spelling
63:130	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
85:95	warning	'PRss' is a possible misspelling.	PostHogBase.Spelling
93:74	warning	Use 'GitHub' instead of 'github'.	Vale.Terms
99:39	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
102:45	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
105:233	error	'super' is repeated!	Vale.Repetition
131:3	warning	'perf' is a possible misspelling.	PostHogBase.Spelling
146:54	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
149:5	warning	'StampHog' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
187:31	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash

[github-actions]

Bundle report

Total JS (gzip)

6.74 MiB (no change)

Eager graph (modules shipped in each entrypoint's initial chunks)

Entrypoint	Eager size	Budget	Modules
✅ app	16.16 MiB (no change)	report-only	1970

Largest modules in the app closure

Module	Size
./src/data/mcp-tools.json	883.3 KiB
css ./node_modules/.pnpm/css-loader@5.2.7_webpack@5.101.3/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[1]!./node_modules/.pnpm/postcss-loader@4.3.0_postcss@8.5.6_webpack@5.101.3/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[2]!./src/styles/global.css	743.0 KiB
./src/components/Stickers/Stickers.tsx	696.4 KiB
./node_modules/.pnpm/@radix-ui+react-icons@1.3.2_react@18.3.1/node_modules/@radix-ui/react-icons/dist/react-icons.esm.js	481.4 KiB
./node_modules/.pnpm/rehype-raw@7.0.0/node_modules/rehype-raw/lib/index.js + 29 modules	395.1 KiB
./node_modules/.pnpm/@posthog+icons@0.36.6_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.cjs.js	364.8 KiB
./src/hooks/useCustomers.tsx + 54 modules	355.1 KiB
./node_modules/.pnpm/@posthog+icons@0.36.6_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js	354.8 KiB
./node_modules/.pnpm/react-markdown@8.0.7_@types+react@16.14.66_react@18.3.1/node_modules/react-markdown/lib/react-markdown.js + 88 modules	351.4 KiB
./node_modules/.pnpm/cloudinary-core@2.14.0_lodash@4.17.21/node_modules/cloudinary-core/cloudinary-core.js	281.9 KiB
./src/components/ProductComparisonTable/index.tsx + 120 modules	278.6 KiB
./src/components/SearchUI/index.tsx + 87 modules	271.9 KiB
./node_modules/.pnpm/d3@7.9.0/node_modules/d3/src/index.js + 208 modules	247.4 KiB
./src/components/Pricing/PricingSlider/Slider.tsx + 87 modules	239.9 KiB
./gatsby-browser.tsx + 43 modules	225.2 KiB

---

Eager-graph budgets are report-only until a baseline is established. Sizes are gzip of public/**/*.js; eager size is webpack module source bytes for the modules actually shipped in the entrypoint's initial chunks (post-tree-shake).

[gantoine]

i think a "why" here would help, like "we're building for 10K/month so we can support our dev team at any scale" or w/e

[rnegron]

100%... this goes directly to the most likely response from negative folks: "10,000 slop PRs is a meaningless metric". and I agree we should not chase it for chasing's sake

[pauldambra]

Suggested change

	The north star for internal developer experience at PostHog is "10,000 PRs in a month is easy". As agent workflows accelerate what is possible. We're sharing what we're changing and how we've been able to increase the volume of engineering work and keep delivering reliable systems
	The north star for internal developer experience at PostHog is "10,000 PRs in a month is easy". As agent workflows accelerate what is possible. We're sharing what we're changing and how we've been able to increase the volume of engineering work and keep delivering reliable systems. That's not because we think that more PRs is a good thing in and of itself, but because we hire talented, driven people and we're investing in agentic automation. That means that the number of PRs will climb.
	If it doesn't... well, then we've made local dev, CI, and validation faster and better. That's a great outcome whatever the reason driving it

[pauldambra]

how about that?

[rnegron]

Humans review way less

i am not sure this is true; according to https://us.posthog.com/project/2/dashboard/1860936

Another useful dashboard fyi https://us.posthog.com/project/2/dashboard/1812721

[pauldambra]

As in the trajectory will be that as PRs grow humans have to review less, and we have to figure out how to make that safe

[pauldambra]

Suggested change

	- Humans review way less, reviews way more effective — focus on understanding, safety, value
	- As PRs arrive faster and faster humans simply have to review less, and we have to figure out how to make that safe

[rnegron]

can also mention we tried github codespaces in the past but saw even less adoption; we have to meet developers where they are more and more for any new tooling introduced

[pauldambra]

"we have to meet developers where they are more and more for any new tooling introduced" love this

[rnegron]

btw one neat trick that we (devex) have used to steer agentic behavior is... enforce agents read the PR template before creating a PR and then adding instructions there. not sure if this fits somewhere in local dev section but wanted to mention it as it powers auto-mermaid diagrams, PR screenshots etc

[MattPua]

would love to see something more on the actual numbers of PRs open at any given time/per user (not power users per say but average), and how we've changed processes to have that happen (beyond just token spend, like slack bot, etc)

[pauldambra]

@MattPua

would love to see something more on the actual numbers of PRs open at any given time/per user (not power users per say but average), and how we've changed processes to have that happen (beyond just token spend, like slack bot, etc)

i guess that's a "dev" thing rather than a "ci" thing

i don't imagine we can get historic data for how many open PRs each of us have i can measure it today, and we can ask folk if it has changed for them

why is that a thing to comment on?
the cognitive load of balancing multiple things?

what do you think is making it work or not?

i actually think this is interesting enough to be a follow-up piece!

[MattPua]

i think the more interesting story IMO (CI story is great, dont get me wrong), is the way we are perceiving pRs and how many people are opening and juggling how many tasks at a given time. I think if you asked this a year ago, people might have had one or two PRs at a time, and that was all that they could fit in their context window of their heads. That made sense.

I think for us, because we are trying to be as AI-pilled as possible, we're trying to go really far ahead with the concept of how many PRs is too many, almost. What is that limit? What do we as PostHog do to enable people to even write and open that many PRs to begin with? If you think about it, we're talking about something like more than 20 PRs a person a month. Probably for a lot of orgs, that's a crazy number to think about. Probably what they would care about is: how does that even happen, or what can they do to enable their orgs to make that happen?

I think a lot of teams, from the CI perspective, already are kind of experiencing this problem: how does CI handle the workloads of this many PRs? GitHub is already a prime example ofthat. But I think you have a lot fewer teams, at least engineering teams, that are talking about how they make that culture happen. I think that's going to be the more interesting and unique thing we could talk about that's very PostHog.

[pauldambra]

i used to start to worry at around 15 open PRs (have always multitasked)

and now i start to worry at about 40