{"slug": "stop-being-the-code-review-bottleneck", "title": "Stop being the code review bottleneck", "summary": "PostHog engineers share four workflow changes to stop being a code review bottleneck when using AI-generated code, including having multiple agents review each other's code and triaging results to escalate only ambiguous issues to humans. The approach aims to offload simpler reviews to agents so developers can focus on PRs that genuinely need human attention.", "body_md": "# Stop being the code review bottleneck\n\n### 4 ways to make AI code review suck less (with prompts)\n\nAgents are writing code faster than any human can review.\n\nThe naive solution would be for developers to review code faster. The 500 IQ take is for developers to review as little code as possible.\n\nIf you need to be involved in every code review, you will always be the bottleneck. Instead, put yourself outside of the code review loop by building a pipeline that delegates tasks to agents.\n\nWe asked engineers at PostHog how they’ve been reviewing AI-generated code to keep shipping fast without losing quality.\n\nHere are four workflow changes you can steal (with prompts included) to make your life easier.\n\n## 1. Make agents review code for you\n\nThe number one thing to add, if you haven’t yet, is a way for agents to review code for you.\n\nThe goal is to offload the simpler reviews to agents, and flag if something genuinely needs a human.\n\nThe key is that the agent that wrote the code can’t be the one that reviews it. Agents are bad at checking their own work since they’re often unaware of their own blind spots.[1](#footnote-1)\n\nFor the same reason, it’s better to have multiple agents with different instructions and goals to cover more gaps,[2](#footnote-2) as well as different models and providers for different reviewers.[3](#footnote-3)\n\nHere’s how one of our engineers, [Paul D’Ambra](https://posthog.com/community/profiles/30173?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=code-review), makes his own custom agent review system work:\n\nFirst,\n\nspawns four reviewer agents, each with their own special instructions:[qa-swarm](https://github.com/pauldambra/dotfiles/tree/main/ai/skills/qa-swarm)**qa-team**– spawns technical subagents that hunt for security, database, performance, etc.** security-audit**– probes for vulnerabilities like SQL or prompt injections** paul-reviewer**– uses Paul’s voice and focuses on observability, rollouts, naming** xp-reviewer**– applies an Extreme Programming lens to review\n\nThen,\n\nsorts those reviews to classify threads into three categories:[review-triage](https://github.com/pauldambra/dotfiles/blob/main/ai/skills/review-triage/SKILL.md)**actionable**→ gets fixed and pushed** nits**→ get resolved and replied to with a comment** ambiguous**→ escalated and sorted for Paul to work through with the agent later\n\nAn outer loop iterates up to three times or until no new actionable threads appear.\n\nFrom there, you can connect this to another loop that shepherds the PR until it’s ready to merge – more on that in the next section.\n\nThe takeaway:Save time reviewing code by making[agents]review each other. This knocks out easier reviews so that only the PRs that really need human attention get flagged.\n\n### Steal this\n\nYou can check out and copy Paul’s [qa-swarm](https://github.com/pauldambra/dotfiles/blob/main/ai/skills/qa-swarm/SKILL.md) and [review-triage](https://github.com/pauldambra/dotfiles/blob/main/ai/skills/review-triage/SKILL.md) skills, or use this prompt to design your own review loop based on his:\n\n```\nRead Paul D'Ambra's qa-swarm skill, plus its sibling review-triage in the same folder, then help me design my own version: https://github.com/pauldambra/dotfiles/blob/main/ai/skills/qa-swarm/SKILL.md\n\nIt should take in a single PR, spawn a reviewer panel, triage every finding and existing PR thread into actionable / nit / ambiguous, and keep going until nothing's left but the ambiguous ones flagged for me.  \n\nInterview me about my stack, tooling, available models, and how autonomous it should be — what gets auto-fixed vs. only reported, and what it may post to GitHub — before writing the final SKILL.md, then install it.\n```\n\nThat said, these systems can get token expensive:\n\n*“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.” *– Paul\n\nSo if running multiple agents or loops isn’t an option for your team, look for single agent designs like [this one](https://github.com/kunchenguid/no-mistakes) by Kun Chen.\n\n## 2. Delegate PR babysitting to loops\n\nThe context switching that comes with agentic coding is exhausting. One easy way to reduce that fatigue is by automating code review-adjacent tasks that don’t need your attention.\n\nFor example, babysitting a single PR can involve tedious tasks like monitoring CI, re-running flaky tests, checking notifications for comments, and keeping the branch up to date.\n\nWhy waste your most precious resource – your energy – when you can just delegate all of it to a [loop](https://posthog.com/newsletter/loops?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=code-review)?\n\nThe takeaway:Reduce context switching and fatigue by delegating simple tasks like PR babysitting to a loop.\n\n### Steal this\n\nYou can implement your own PR babysitter skill, based on [babysit-prs](https://github.com/haacked/dotfiles/blob/main/ai/skills/babysit-prs/SKILL.md) by [Phil Haack ](https://posthog.com/community/profiles/32501?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=code-review)with the prompt below. (It works best if you run it after creating a review loop skill from the previous section.)\n\n```\nRead https://github.com/haacked/dotfiles/blob/main/ai/skills/babysit-prs/SKILL.md and adapt it for me: same sweep/state design, but it dispatches my own single-PR review skill via a spawned agent per unreviewed PR. \n\nBefore writing SKILL.md, interview me on: which skill it dispatches and where my skills live, my stack/tooling/models, and which extra tasks to include — CI monitoring, branch freshness, flaky-test reruns, lint/format autofix, regenerating drifted artifacts, description sync. \n\nGround the interview in  facts you can discover yourself (my open PRs, gh auth, clone layout) rather than asking about them.\n```\n\n## 3. Add a PR auto-stamper\n\nFast-moving teams generate a lot of small, low-risk PRs, and every one still needs approval on GitHub (a.k.a., a stamp).\n\nAt PostHog, we used to handle this in Slack where you drop your PR in #dev-stamp-exchange and wait for someone to give it a quick approval and react with a stamp emoji. We even built a [leaderboard](https://stamphog.vercel.app/) for it.\n\nIt worked, but each stamp required another engineer to take themselves out of their flow to approve a change they had little to no context on.\n\nNow, most of those are done by our StampHog agent instead. And in just one quarter, it gives the final stamp on roughly 1 in 3 PRs merged into our main repo.\n\nOur engineers add a `stamphog`\n\nlabel on their PR in GitHub, and it runs a few safety checks based on:\n\n**PR state.** No merge conflicts or changes requested**Blast radius.** Deny list keywords (auth, secrets, billing, public APIs, etc.)**Diff size.** Under 500 lines and 20 files**A simple LLM check.** For basic showstoppers\n\nIf the agent approves, it’ll leave a bare GitHub approval with no line comments.\n\nOtherwise, it refuses or escalates with a 1-2 sentence reason, risk level rating, and next steps. Usually that means routing to a subject matter expert based on [CODEOWNERS-soft](https://github.com/PostHog/posthog/blob/master/.github/CODEOWNERS-soft) and git-blame familiarity.\n\nWe still use #dev-stamp-exchange when the agent can’t auto-accept or route, but it’s way less active now. Last month, the StampHog agent took care of 1.6K PRs on its own – that’s *1.6K fewer Slack interruptions* for our engineers.\n\nThe takeaway:Let an agent can take care of low-context PR approvals and routing to reduce distractions. Use deterministic checks to route sensitive code to humans.\n\n### Steal this\n\nThe code for StampHog is available [here](https://github.com/PostHog/posthog/blob/master/tools/pr-approval-agent/). Many of its inner workings are specific to PostHog, so instead of copying it, here's a prompt to start customizing one for your repo based on ours:\n\n```\nRead https://github.com/PostHog/posthog/blob/master/tools/pr-approval-agent/README.md and build the equivalent for the repo at <path>. \n\nCopy the architecture; preserve its safety invariants exactly (fail closed, never request changes or merge, LLM can tighten gates but never loosen). \n\nTheir deny-list and thresholds are calibrated to their codebase — re-derive mine: mine my git history for high-blast-radius deny candidates and calibrate size/tier ceilings from my merged PRs, then propose the full gate config for my sign-off before writing any code. \n\nAt the same time, ask me whatever you can't derive from the repo — at minimum the CI system and trigger label, escalation routing if there's no CODEOWNERS, and which LLM/SDK to use and how CI gets its credentials. \n\nLeave the result as uncommitted files on my working tree.\n```\n\n## 4. Verify by observation, not reasoning\n\n[Agents](https://posthog.com/newsletter/building-ai-agents?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=code-review) are good at explaining why their code works. The explanation is often convincing... but also wrong.\n\nIf you run the code end to end, you’ll frequently find errors the agent never reasoned about, or output that’s just slightly not what you asked for.\n\nThat’s why [Daniel Visca](https://posthog.com/community/profiles/43453?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=code-review)‘s rule of thumb is observability over** **reasoning**.** Don’t accept an argument that the code works when you can *watch* it work.\n\nThe gold standard is something you can observe directly, like sending a real API request and reading the response. If the behavior is in front of you, you don’t have to trust the agent’s rationale at all. But this has a scaling problem since a 3,000-line PR would be challenging to trust and observe.\n\nHis approach is to make agents decompose the work. For example, for a large change (like building a metrics pipeline end to end), he instructs the agent to produce a stack of small, single-purpose PRs and then uses[ Graphite](https://graphite.dev) for its “stacking” functionality. This makes each diff independently runnable and observable:\n\nAt each step of the stack, you can run a real check and confirm the output matches what you expect. Then, as you merge bottom-up, each layer only builds on behavior that’s already been verified.\n\nThis way, early mistakes can’t compound, and when something does break, you’re debugging one small diff instead of the whole change.\n\nAs a bonus, this lets StampHog from #3 auto-approve the small and focused PRs. You end up with two different checks: the agent reasoning about the code first, and a human observing its actual behavior.\n\nThe takeaway:When you can't trust an agent's reasoning, don't read more code; decompose the change until you can watch each piece run. Observation scales better than review.\n\n### Steal this\n\nYou can set this up by using Graphite to stack smaller PRs produced by your agents with these instructions:\n\n```\nSplit work into a stack of small PRs, each under 400 changed lines and focused on a single change, building only on the PRs below it. \n\nEvery PR must ship with its own tests and end with a way to observe it working directly — a command to run and the output I should expect.\n```\n\nThis approach is especially valuable for frontend work since deterministic tests don’t always capture the visual or behavioral functionality you’re looking for.\n\n[Pawel Cebula](https://posthog.com/community/profiles/33209?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=code-review) says it’s a huge timesaver to have an agent take screenshots and GIFs for each step, with something like this:\n\n```\nFor each PR with frontend work, run the affected screens and capture evidence from the branch's final state: a screenshot of each relevant state (empty, loading, error, populated) and a GIF of the key interaction end to end. Where behavior changes, include before/after. \n\nAttach it all to the PR so the change can be reviewed by observation, not by reading the diff — and re-capture if the code changes after.\n```\n\n*Words by Jina Yoon who was, admittedly, the bottleneck for this post.*\n\n## Blogs worth human review\n\n[Why we rebuilt our data warehouse and how it unlocks self-driving products](https://posthog.com/blog/why-we-rebuilt-our-data-warehouse?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=code-review)– Eric Duong[Agentic Failure Modes](https://dylanamartin.com/2026/03/24/agentic-failure-modes.html)– Dylan Martin[Better Models: Worse Tools](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/)– Armin Ronacher[Agentic Code Review](https://addyo.substack.com/p/agentic-code-review)– Addy Osmani[Understanding is the new bottleneck](https://x.com/geoffreylitt/status/2072522251300409556)– Geoffrey Litt", "url": "https://wpnews.pro/news/stop-being-the-code-review-bottleneck", "canonical_source": "https://newsletter.posthog.com/p/code-review-tips", "published_at": "2026-07-10 09:35:34+00:00", "updated_at": "2026-07-10 10:05:26.694178+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["PostHog", "Paul D'Ambra"], "alternates": {"html": "https://wpnews.pro/news/stop-being-the-code-review-bottleneck", "markdown": "https://wpnews.pro/news/stop-being-the-code-review-bottleneck.md", "text": "https://wpnews.pro/news/stop-being-the-code-review-bottleneck.txt", "jsonld": "https://wpnews.pro/news/stop-being-the-code-review-bottleneck.jsonld"}}