Merged pull requests · one author · two codebases

Same engineer.
Two eras of shipping.

PostHog25 repos: the app, SDKs, website, plugins · May 2021 – Jan 2025 · 3.7 years
Python, TypeScript, Rust, Ruby, PHP, Go · pre-agent

TanoTano monorepo · Jan 2026 – Sep 2026 · 7.8 months
TypeScript, Go, SQL · with AI agents

$ gh search prs --author neilkakkar --merged --owner PostHog | wc -l859 $ gh search prs --author neilkakkar --merged --repo <tano-monorepo> | wc -l1,638

7.0×more merged PRs in eight months at Tano than in my best eight months at PostHog.1,638 vs 235 (Feb–Oct 2023)

139 daysto pass the PR total from my entire time at PostHog.859 PRs took 1,362 days

0.7 hmedian time from opening a PR to merging it, down from 15 hours.57% merge inside an hour, from 23%

Merged PRs per month

Job change without AIBloomberg → PostHog 8→19 2.4×

Bloomberg8

PostHog19

Job change with AIPostHog → Tano 19→207 11×

PostHog19

Tano207

The jump from Bloomberg to PostHog is what more seniority and a faster company looked like before AI. The jump to Tano is several times larger.

Cumulative merged PRs

The Tano line passes a 3.7-year total in under five months

Days since my first merged PR in each repo. Hover to compare any day.

TanoPostHog

Swipe sideways to see the whole chart.

Merged PRs per month · same scale

My busiest PostHog month would be a slow week at Tano

Month 1 is each repo's first month. Both panels share one y-axis, so bar heights compare directly. PostHog peaked at 42 PRs in April 2023; Tano's busiest month was 363 PRs in August 2026.

Swipe sideways to see the whole chart.

Every metric I could pull

The ledger

Rates use each tenure's full span. Lines exclude lockfiles, test snapshots and generated files.

Metric	PostHog	Tano	Change
Throughput
Merged PRs	859	1,638	1.9×
Repositories	25	1
PRs per 30 dayswhole tenure	18.9	207	11.0×
Best 8-month stretchPostHog: Feb–Oct 2023	235	1,638	7.0×
PRs per day with a merge	1.8	11.7	6.4×
Most PRs merged in one day	7	44	6.3×
Most PRs merged in one week	15	151	10.1×
Lines added per 30 days	2,899	102,239	35.3×
Lines added, best 8 months	24,064	807,689	33.6×
Shape of a PR
Median lines added per PR	42	229	5.5×
Median files changed per PR	3	6	2×
Commits per PRbefore squash	6.0	3.2	0.53×
Deletions per line added	0.27	0.20	slightly lower
Speed and review
Median time, open to mergePostHog main repo alone: 6.0 h	15.1 h	0.7 h	21× faster
Merged within one hour	23%	57%	+35 pts
Slowest quarter of PRs take longer than	71 h	2.5 h	28× faster
Review threads per PRTano count includes an automated reviewer	1.44	1.23	slightly fewer
Teammates' PRs I reviewed or commented on	1,589	67	24× fewer
Teammates' PRs reviewed per merged PR	1.85	0.04	45× fewer
Teammates' PRs reviewed per month	~35	~8	4× fewer
PRs later reverted	2.3%	0.4%	6× fewer
What goes into the diff
Share of PRs that add features	36%	52%	+16 pts
Share of PRs that fix bugs	37%	30%	−7 pts
Test code as share of lines added	53%	42%	−10 pts
Documentation lines writtenMarkdown and MDX, incl. posthog.com docs and blog	2,949	24,750	8.4×
Distinct commit scopesthe (scope) in feat(scope):	75	231	3.1×
Distinct directories touchedfirst three path levels, all repos	706	533	0.75×

What I worked on · share of merged PRs

From one product area in many languages to many products in one repo

Sorted by conventional-commit scope and title keywords. Categories are approximate.

PostHog 859 PRs

Tano 1,638 PRs

What the numbers say

Four things that changed

PRs got bigger and faster at once.

The median PR is more than five times larger, and it merges in 42 minutes instead of 15 hours. The gain is not from slicing work into smaller pieces.

Tests held; rework rose.

Test code is still 42% of what I add, and the revert rate fell from 2.3% to 0.4%. But about 14% of my PRs needed a follow-up fix within a week, up from 8%.

Writing moved next to the code.

At PostHog I wrote 2,949 lines of docs in 3.7 years, mostly on the public website. At Tano I wrote 24,750 in eight months: design docs, runbooks and the AGENTS.md files that tell agents how each module works.

Breadth changed shape.

At PostHog, breadth meant one product area carried across 25 repos: feature flags and experiments in the app, then the same logic in SDKs for six languages. At Tano it means separate products in one repo: an affiliate platform, AI agents, workflows, data migrations and Go workers.

Method and caveats

Source: the GitHub API. Merged pull requests I authored in all 25 PostHog repositories (the app, SDKs, website, plugins) and in the Tano monorepo. The PostHog app repo alone has 592 of them; against that repo alone the best-eight-months ratio is 9.8×.
Only PRs I opened count. PRs where I appear only as a co-author are left out. That includes PRs I took over that merged under a teammate's name, and PRs where a teammate committed one of my review suggestions, since GitHub adds a Co-authored-by line for those. About 175 PostHog PRs and 22 Tano PRs carry my name only as co-author.
A PR count measures throughput, not value. A 40-line fix to the feature-flag service that serves billions of requests can matter more than a 600-line admin page.
The contexts differ. PostHog was a large, mature open-source codebase with a bigger team and strict review. Tano is a younger codebase at a smaller company. Some of the gap comes from that.
"Pre-agent" is approximate. GitHub Copilot and ChatGPT existed for part of my PostHog time. Agents that plan, edit many files, run tests and open PRs did not.
My PostHog activity tapered in 2024. The best-eight-months comparison (Feb–Oct 2023) removes that effect and is the most conservative figure here.
Lines added exclude lockfiles, test snapshots (.ambr), generated test-duration files and go.sum. GitHub lists at most 100 files per PR, which truncates a handful of PRs.

Monthly PR counts as a table