GitWeave
PostHog/posthog
6,125 merged PRs · 194 engineers · 28 bots excluded · computed just now
    Adjust weights
    Bus factor by product surface
    Methodology and limitations
    Switch to light theme
    Top 5 by impactof 194 active
    Impact fingerprintarnohillen vs cohort median
    Connector
    high confidence · 88 merged PRs
    new in window
    Impact fingerprint for arnohillen, percentile rank within the active cohort
    DimensionarnohillenCohort median
    Ownership9350
    Leverage9750
    Reach9950
    Initiative9950
    Problem Shaping10050
    How this score is built101.8
    centrality x blast-radius weighted change, owned surfaces, sustained weeks. Percentile 93 of 100 within the active cohort, x weight 0.28.27.3
    24 PRs on blast-radius paths5 active weeks
    consequential review threads, breadth of people/areas unblocked, x responsiveness. Percentile 97 of 100 within the active cohort, x weight 0.30.30.7
    0 review threads that changed code0 engineers unblocked, 0 areas4.0h median response to review requests
    effective product areas (exp of entropy), stacks, teams, boundary PRs. Percentile 99 of 100 within the active cohort, x weight 0.18.18.8
    35 areas (22.9 effective)6 stacks, 0 teams31 cross-boundary PRs
    files created, surfaces founded, others' PRs shepherded to merge. Percentile 99 of 100 within the active cohort, x weight 0.14.14.5
    93 new files created3 surfaces founded0 of others' PRs merged by them
    smoothed rate x quality of problem statements, discussion on others' work. Percentile 100 of 100 within the active cohort, x weight 0.10.10.5
    94% of PRs state the problem53% mean problem-statement quality75 substantive comments on others' work
    A multiplier, never a headline. It can temper a high rank but cannot manufacture one, and it is floored at 0.85 so it never becomes a blame score.×1.05
    0 reverts
    0 reverts, 7 rapid-fix follow-ons across 88 merges.
    Share of this engineer's merged output that began as an agent-opened PR they committed into, reviewed, or merged. Neutral statistic — it is not scored up or down.2%

    2 of 88 merges were agent-opened and human-driven (2 of their own commits inside them).

    Evidence — highest-weighted contributions behind this scorearnohillen · click any row to open it on GitHub
    #75155feat(replay-vision): let users set and see per-scanner credit limitsTouches a blast-radius path (CODEOWNERS / migrations / infra) · 14 review threads resolved with a code change · Created 5 new files · Well-articulated problem statement
    blast radius
    frontend-shell
    replay_vision
    +902 -63 · 33f · Aug 13     #75133feat(replay-vision): enforce per-scanner credit limitsTouches a blast-radius path (CODEOWNERS / migrations / infra) · 17 review threads resolved with a code change · Created 1 new file · Well-articulated problem statement
    blast radius
    replay_vision
    services
    +1,130 -46 · 27f · Aug 13     #75086feat(replay-vision): per-scanner credit budget accountingTouches a blast-radius path (CODEOWNERS / migrations / infra) · 10 review threads resolved with a code change · Created 7 new files · Well-articulated problem statement
    blast radius
    core/management
    replay_vision
    +802 -20 · 17f · Aug 13     #81454feat(replay-vision): add organizational tags to scannersTouches a blast-radius path (CODEOWNERS / migrations / infra) · 2 review threads resolved with a code change · Created 6 new files
    blast radius
    frontend-shell
    core/api
    +903 -46 · 30f · Aug 13     #75128feat(replay-vision): add golden-dataset eval loop for scanner prompts18 review threads resolved with a code change · Created 8 new files
    replay_vision
    +1,650 -31 · 12f · Aug 14     #78624feat(replay-vision): goal-based ai scanner creation flowTouches a blast-radius path (CODEOWNERS / migrations / infra) · 9 review threads resolved with a code change · Created 3 new files · Well-articulated problem statement
    blast radius
    frontend-shell
    replay_vision
    +1,322 -18 · 15f · Aug 13
    Focus sentinel

    GitWeave scoring model

    How should impact be weighted?

    Close

    There is no single correct definition of engineering impact. These are GitWeave's defaults, not a claim of truth — Leverage is weighted highest because multipliers matter more than individual producers at this scale, and because it is the signal every other tool under-counts. Change them and the ranking re-sorts live.

    0
    100
    0
    100
    0
    100
    0
    100
    0
    100

    Weights are normalised, so only their ratio matters. Reliability is applied separately as a multiplier in [0.85, 1.10] and is not adjustable — it can temper a rank but must never manufacture one. Defaults: Ownership 0.28, Leverage 0.3, Reach 0.18, Initiative 0.14, Problem Shaping 0.1.

    Focus sentinel
    Focus sentinel
    Close

    Methodology

    How GitWeave measures impact

    warning icon
    Read this before you act on any number here
    GitWeave measures observable GitHub activity only. It cannot see design docs, incident response, customer calls, interviews, architecture debates, or the conversation that stopped a bad project. Use it to generate questions, never to conclude answers. Do not use it for stack ranking, PIPs, compensation, or headcount decisions without human context — a low score frequently means the person's highest-impact work does not happen on GitHub.
    What we deliberately do not measure

    Lines of code as a positive signal · commit counts (squash settings make them meaningless) · hours, time-of-day or weekend activity (surveillance, not impact) · approval counts (PostHog's approve-to-request-changes ratio is ~30:1, so approval is a formality) · issue-closure counts (only ~6% of PRs here link an issue).

    The five dimensions
    DimensionWhat it asksWhy it resists gaming
    Ownership
    Do they own hard, load-bearing things?
    File centrality is derived from other people's behaviour — editing a file more does not make it more central, because that raises the denominator too.
    Leverage
    Do they make others faster and better?
    Only counts review threads the author answered with a code change. Nitpicking earns nothing; approvals earn exactly zero.
    Reach
    How far across the codebase do they operate?
    Uses effective area count (exp of Shannon entropy), so five areas at 20% beats 96/1/1/1/1.
    Initiative
    Do they start things, or only execute?
    New surfaces and files, plus taking responsibility for others' work landing.
    Problem Shaping
    Do they frame the problem, not just the patch?
    Rate-based and Laplace-smoothed, so shipping more PRs neither helps nor hurts.
    Bots excluded from this cohort

    Without this filter the top reviewers on PostHog are all bots — stamphog, posthog[bot], greptile-apps, veria-ai and copilot-pull-request-reviewer. 15,428 bot reviews were discarded in this window.

    chatgpt-codex-connector
    claude
    coderabbitai
    copilot-pull-request-reviewer
    copilot-swe-agent
    cursor
    deployment-status-posthog
    exe-dev-github-integration
    force-merge-posthog
    github-actions
    graphite-app
    greptile-apps
    hosthog
    mendral-app
    parameterai
    posthog
    posthog-bot-comment-resolver
    posthog-js-upgrader
    posthog-local-dev
    posthog-security-review-bot
    pr-assigner-resolver-posthog
    scheduled-actions-posthog
    socket-security
    stamphog
    talyn-app
    tests-posthog
    trunk-io
    veria-ai
    Agent-authored PRs

    574 of 6,125 merged PRs in this window were opened by PostHog's self-driving agent. Crediting the bot would put a robot at rank 1; dropping those PRs would erase the humans who committed into them and merged them. GitWeave attributes them at commit and steward level to the humans involved, and reports “agent leverage” as a neutral statistic rather than scoring it.

    Known limitations
    • Tenure is inferred from first activity inside the window; contributions before it are invisible.
    • Only merged PRs are ingested, so follow-through on abandoned work is not yet measured.
    • Multiple accounts belonging to one person are not yet merged into a single identity.
    • Percentiles are relative to this repo's active cohort — they are not cross-company comparable.
    Focus sentinel
    Focus sentinel
    Close

    Ownership

    Bus factor — key-person risk by product surface

    Area = volume of change. Colour = concentration of ownership. Red means one person authored 75%+ of the change in that surface (or is its only author) — fund a second owner before you need one.

    8 surfaces with concentrated ownership
    SurfacePrimary ownerTheir shareContributorsRisk
    warehouse_sources
    Gilbert09
    87%
    3
    high
    desktop
    puemos
    18%
    13
    low
    frontend-shell
    pauldambra
    11%
    41
    low
    tasks
    tatoalo
    41%
    13
    low
    nodejs
    meikelmosby
    18%
    15
    low
    signals
    andrewm4894
    61%
    8
    medium
    logs
    jonmcwest
    84%
    3
    high
    ci
    webjunkie
    24%
    10
    low
    replay_vision
    TueHaulund
    39%
    4
    low
    services
    andrewm4894
    11%
    27
    low
    customer_analytics
    arthurdedeus
    100%
    1
    high
    core/temporal
    carlos-marchal-ph
    20%
    10
    low
    workflows
    mayteio
    38%
    5
    low
    data_warehouse
    Gilbert09
    75%
    3
    medium
    metrics
    DanielVisca
    90%
    2
    high
    error_tracking
    hpouillot
    73%
    3
    medium

    Shares are computed over the engineers loaded into this view, so a surface owned mostly by someone outside the top cohort may read as more concentrated than it is.

    Focus sentinel