Eleven Times the PRs, Zero Reviewers · Morning Gist
Thursday, November 51 story · 4 min
Eleven Times the PRs, Zero Reviewers
One essay tests what happens when an engineer stops waiting for human review and lets agents ship, with the failures counted alongside the gains.
Picked from 71 new articles across 34 sources · arrow keys for other days
Today in 30 seconds
30s left
Neil Kakkar reports an 11x rise in merged pull requests using agents without human review, comparing his work at PostHog and Tano. story 1 ↓
The costs he lists include a blocked Postgres table, duplicate payments and a bus factor of one. story 1 ↓
Treat it as a case study: the evidence comes from one engineer at a small startup, not a controlled comparison. story 1 ↓
1/1The Pragmatic Engineer· Gergely Orosz· Nov 3
Agents, no human review: one engineer's 11x rise in merged pull requests
Neil Kakkar went from 8–20 to 200+ merged pull requests a month after moving from PostHog to Tano, using coding agents and automated review only. He documents the speed, the breakages and the exhaustion.
Why it matters · It shows which review, ownership and migration safeguards one team dropped for speed, and what broke, though the evidence comes from one engineer at a small startup.
Know this first
Context from the editor, not the article · 36 sec
1 · Coding agents
Tools such as Claude Code, Anthropic's coding agent, can plan a change, edit files, run tests and open a pull request with little supervision. That makes producing code cheap, which puts pressure on the slower steps around it: review, testing, deployment and deciding what to build.
2 · What code review provides
Mandatory peer review catches defects, but it also spreads knowledge: reviewers learn what colleagues are building and spot existing code that could be reused. Removing review therefore costs more than bug detection. It also removes one of the main ways a team keeps a shared picture of its system.
3 · Postgres index builds
A plain CREATE INDEX in Postgres blocks writes to the table until the build finishes, which can take a long time on large tables. CREATE INDEX CONCURRENTLY allows writes to continue, but it runs more slowly and cannot run inside a transaction.
Monthly merged PRs at Bloomberg, PostHog and Tano, showing the scale of the jump across employers.1 / 4
Remember
Removing one bottleneck exposes the next: at Anthropic, review gave way to CI limits, then source control.
A review agent's prompt can accumulate past incidents as rules, such as listing large tables and rejecting blocking migrations.
Lower revert rates prove little when a team fixes forward; defect and incident rates would be better evidence.
Neil Kakkar won a $10,000 essay contest run by The Pragmatic Engineer newsletter, with a data-heavy account of his own output. At Bloomberg and 1, an open source product analytics company, he merged eight to 20 pull requests (PRs, proposed code changes) a month. At Tano, a roughly 10-person influencer marketing startup, he merges 200+, or 11x his PostHog rate.
Why agents alone don't explain it
Kakkar argues that dropping today's tools into pre-AI PostHog would yield 1–2x at best, because mandatory peer review would become the limit and its queue would just grow. So Tano removed the surrounding steps. One engineer owns design, frontend and backend. There are no product managers. Once engineers know the codebase, after three to eight weeks, human review is optional. An agent running in continuous integration (the automated checks on each change) is usually the only reviewer.
He runs three to five workstreams in 2, Anthropic's coding agent. Runs take one to two hours, and median time to merge is under an hour.
What broke
Currency: generated code multiplied minor units by 100, but one Bahraini dinar is 1,000 fulūs. It ignored an existing currency utility, and the team fixed it within the hour.
Blocking index: adding a 3 (covering only rows that match a condition) to a 25 GB, 6-million-row Postgres table blocked writes, halted ingestion and broke deploys. The review agent now lists the largest tables and rejects blocking migrations on them.
Double payments: a migration without enough guardrails paid some creators twice. Kakkar calls that an acceptable trade for speed.
Migrations
PostHog's 4 project, which copied person data onto 20 billion+ event rows so queries could avoid joins, took a year. Two complex Tano migrations took weeks each. Kakkar concludes that architecture has become largely reversible. That comparison flatters agents, since the two systems differ enormously in scale.
The new bottleneck
The limit is now the engineer. Because any bug is about an hour of agent time, Kakkar reacts constantly and neglects his planned work, a form of 5 (more time switching than doing). Without review he no longer tracks colleagues' work, and the 6, how many people could leave before a project stalls, is often one. He was once exhausted by 3 PM, and now limits parallel work and leaves his laptop at the office.
Caveats
This is one engineer's self-reported data, and PRs are easy to game. The 6x lower revert rate partly reflects shipping fixes rather than rolling back, and no defect rates are given. Newsletter author Gergely Orosz puts the industry average nearer a twofold PR increase, and notes that speed means little without a working business.
Neil Kakkar, a London-based engineer with nine years of experience, won a $10,000 essay contest run by The Pragmatic Engineer newsletter, chosen from 125 entries. His essay compares his own output at three employers using detailed data.
At Bloomberg (about 20,000 people) and 1, an open source product analytics company (about 10 people when he joined, 200 now), he merged between eight and 20 pull requests (PRs, proposed code changes) a month. At Tano, an influencer marketing startup of about 10 people where he was the first engineer, he merges 200+. That is 11x his PostHog rate, which was itself 2.4x his Bloomberg rate.
The multiplier matters less than Kakkar's explanation of it. He argues that coding agents alone would not produce it.
The bottleneck moves
Kakkar's thought experiment: drop an engineer with today's tools into pre-AI PostHog, where review was mandatory. He estimates a gain of 1–2x at best, because colleagues still could not review faster and the queue would simply grow. The logic resembles 2 (an analogy, not his framing): speeding up one stage does little while another stage still limits the whole.
So Tano removed the other stages:
Coordination. Building PostHog's surveys product took two engineers and a designer a month, and backend discoveries often forced frontend changes. Kakkar argues one person should now own design, frontend and backend for well-understood work. Engineers still talk through big architecture decisions and unknowns.
Review. Once an engineer knows the codebase, which takes three to eight weeks, human review is optional. An agent running in continuous integration (CI, the automated checks on every change) reviews every PR, and a deeper one is available for risky changes. In most cases, that is the only review.
Product management. Bloomberg had a product manager per team, PostHog had one across several teams, and Tano has none. A Monday roadmapping session, with most prioritisation context from the CEO and CTO, sets the week's work.
In practice, Kakkar runs three to five workstreams at once in 3, Anthropic's coding agent. He goes through a plan, then lets an agent work for one to two hours until the PR is ready. He then checks an HTML summary the agent generates. Median time to merge is under an hour. He writes 100k+ lines a month this way, and his usage would cost more than $8,000 a month at API rates, though he is on a flat subscription with limits he sometimes hits.
What broke
Kakkar is specific about the failures.
Currency units. A reporting change handled minor currency units by parsing them as floats and multiplying by 100. Not every currency has 100 minor units: one Bahraini dinar is 1,000 fulūs. As an illustration, 5 dinars would become 500 rather than 5,000, a factor of ten off. The codebase already had a currency utility, and Kakkar says a human reviewer would have noticed it wasn't used. The team saw reports not matching after deployment and fixed the problem within the hour.
A blocking index. Tano's posts table in Postgres reached about 25 GB and 6 million rows. Adding a 4 (one covering only rows that match a condition) through a blocking migration stopped writes, so the ingestion pipeline stopped saving posts. The migration also timed out, so new deploys failed. These migrations must now run concurrently. The review agent's prompt now lists the largest tables and rejects blocking migrations on them, and the team adds each new failure mode there. In effect, the prompt works as an accumulating checklist of past incidents.
Duplicate payments. During an architecture migration, Kakkar missed guardrails and some creators were paid twice for the same work. He calls this an acceptable trade for getting the new architecture in place sooner.
Migrations as reversible decisions
Kakkar's strongest architectural claim comes from comparing migrations. PostHog's 5 project took a year. Funnel and unique-user queries joined an events table of 20 billion+ rows to a persons table, and were unusable for large customers. The fix copied person identifiers and properties onto events, which required hand-updating every query to drop the joins. Because repeating that work was unfeasible, the team built it to last.
At Tano, moving every creator from a free-form agent checklist to defined workflows, then fixing missing context across conversation threads, took weeks each. Kakkar concludes that architecture has gone from "a mostly irreversible decision to a reversible one", so a team can learn in production and iterate instead of getting every detail right first.
The two cases are not equivalent, though. One touched 20 billion rows and a company-wide query layer. The other changed a young product at a small startup. How much of the speedup comes from agents and how much from scale can't be separated from this data.
The constraint becomes the engineer
The bottleneck then lands on Kakkar himself:
How far to trust it
This is one engineer's self-reported data, and he concedes that PRs are easy to game. The 6x lower revert rate is weak evidence of quality because he attributes it partly to fixing forward, shipping a new fix rather than rolling back. The essay gives no defect or incident rates. Two of the three failures involved money or financial reporting, which sits awkwardly with the "reversible" framing, and the essay doesn't describe any cleanup after the double payments.
Newsletter author Gergely Orosz adds context. He says the industry average is around a twofold PR increase this year, and that iteration speed means little without product-market fit and healthy unit economics. He also suggests that established companies move carefully because they have working businesses to lose. Kakkar's own example of constraints moving is Anthropic: after automating review, CI became the limit, then source control, which it redesigned. Whether Tano's approach holds up as its team, data and customers grow is left open.
Thrashing. In operating systems, 6 means spending more time switching tasks than doing them. Because any bug is about an hour of agent time, he fires off fixes reactively and neglects his sprint goals.
Lost shared context. Kakkar used to read every PR at PostHog to track the company's work. That stopped being possible as PostHog grew to 30 PRs a day. Tano also merges about 30 a day, with far fewer people. His ratio of PRs reviewed to merged is near zero. Silos follow, and the 7 (how many people could leave before a project stalls) is often one. His proposed remedy is writing context into AGENTS.md files, instruction files that agents read. He offers no evidence yet that this works.
Fatigue. Early on he was spent by 3 PM. He now limits parallel work, avoids important changes when tired, and leaves his laptop at the office, where agents finish overnight. He opens 18% of his PRs between 9 and 11 AM, against 9% at PostHog.
Design. Tano's site ended up in generic AI-generated neo-brutalism, and the team is now working on what its brand should be.
