Coding agents can multiply what one engineer ships. One public ledger shows merged pull requests going from 19 a month to 207. The gain only arrives when a team removes the human steps that used to set the pace. Then the bottleneck moves. First it lands on review, then on CI and source control, and finally on the engineer.
In 60 seconds
One engineer’s merged pull requests went from 19 a month to 207 when coding agents arrived.
Across GitHub, agents started 17% of pull requests in March 2026 and more than 40% by September. Per developer, the gain was only 16.2% to 20%.
The gain arrives when teams remove human steps. 96% of his PRs at Tano never had a human reviewer, and median time to merge fell from 15.1 hours to 0.7.
Each removed step exposes the next. At Anthropic, CI jobs rose 25 times in six months, then merges went from 2,500 a day to more than 30,000 and Anthropic left git.
The last constraint is the engineer. Agent sessions sit about 80% idle waiting for a person, and follow-up fixes nearly doubled, from about 7.6% to about 13.8%.
One engineer’s merged pull requests went from 19 a month to 207
Neil Kakkar publishes his own GitHub ledger. It covers three jobs. He was at Bloomberg from 2018 to 2021. He was at PostHog from May 2021 to January 2025. He has been the founding engineer at Tano since January 2026. Tano builds agents that run influencer marketing for brands.
By his own count, he merged 8 pull requests a month at Bloomberg and 19 at PostHog. At Tano the figure is 207 per 30 days. That is 859 merged PRs in 3.7 years at PostHog, against 1,638 in the first eight months at Tano. His Tano total passed his whole PostHog total on day 139.
The jump from Bloomberg to PostHog was 2.4x. He credits that to a faster company. The jump from PostHog to Tano is 11x, and it came with coding agents. He also gives a smaller number. Comparing his best eight months at PostHog with his first eight at Tano gives 7.0x. He calls that his most conservative figure. We use both.
His peak months tell the same story. PostHog’s best month had 42 merged PRs. Tano’s best had 363. On his busiest Tano days, 44 PRs merged. Lines added per 30 days went from 2,899 to 102,239. No one types 100,000 lines a month by hand.
Two caveats come from the ledger itself. He labels PostHog “pre-agent” and says the label is approximate. Copilot and chat assistants existed for part of his time there. Autonomous agents did not. He also says a PR count measures throughput, not value. A pull request is a unit of change, not a unit of worth.
So treat 11x as an upper bound for one person in one kind of company. It is still the cleanest before-and-after we have. It is one engineer, measured the same way, across a clear change in tools and process. Most public data mixes thousands of teams with different habits. This ledger does not.
The rest of this edition asks what had to change around him for that number to happen, and what it cost.
Across GitHub, agents now start four in ten pull requests
One ledger is a story. The industry numbers give the scale.
GitHub’s Octoverse 2026, published October 28, counted 1.3 billion merged pull requests in its year. GitHub says that more than tripled. The count now includes private repositories, so it does not line up neatly with last year’s report. The share of PRs started by an agent is the cleaner signal. It was 17% in March 2026. By September it was more than 40%. GitHub says activity climbed from January and surged around June. AI code review usage rose 90% year on year. Actions now runs 1,440 jobs a second.
The Stack Overflow 2026 survey, published October 6, asked more than 30,000 developers. Among those who use AI, 66% use coding agents. Claude Code was used by 66% of them and Copilot by 59%. A third of daily users spend four or more hours a day in AI tools.
Per developer, the gain is much smaller than 11x. Faros AI studied 22,000 developers across more than 4,000 teams for its April 2026 report. The PR merge rate per developer rose 16.2%. Cortex’s 2026 benchmark found PRs per author up 20%.
So the totals tripled while the typical developer merged about a sixth to a fifth more. Both can be true. More developers, more agents and more automation add volume. The individual gain depends on what surrounds the individual.
That gap, between 11x for one engineer and about 20% for the median, is the subject of this edition. The difference is not the model. Neil and the Faros teams had access to the same agents. The difference is which human steps were still in the path between a finished change and production.
Review was the first wall, and it fell first
Code review was the step most teams kept. It was also the first to break under agent volume.
Cloudflare put it plainly in April 2026. Review is “one of the most reliable ways to bottleneck an engineering team.” Boris Cherny, who leads Claude Code at Anthropic, gave the method in June: “Find the bottleneck, solve the bottleneck.”
Faros measured what happens when review stays manual. Median time in review rose 441.5%. Pull requests merged with no review at all rose 31.3%. Volume went up, so people either queued or skipped.
Neil’s ledger shows the other path. At PostHog he reviewed 1,589 of his teammates’ pull requests. At Tano he has reviewed 67. Per merged PR, that ratio went from 1.85 to 0.04. At Bloomberg it was about 2. By his count, 96% of his Tano PRs never had a human reviewer. A bot, Claude, reviewed 98% of them. His page says engineers at Tano “own their areas end to end.”
The effect on speed is direct. His median time from opening a PR to merging it went from 15.1 hours at PostHog to 0.7 hours at Tano. The share merged within an hour went from 23% to 57%.
Picture an engineer with today’s agents dropped into a team where every PR needs a colleague’s approval. Output rises, but only until the queue fills. Every PR adds work for someone else. The faster you write, the longer the line. Faros calls review the new bottleneck for exactly this reason.
So the first removed constraint was not typing. It was waiting for another person’s attention. Teams that kept mandatory human review saw small per-person gains. Teams that replaced it saw large ones. The next question is what replaced it, and whether it holds up.
Big companies now let AI carry most review
Replacing human review is no longer a startup habit. Several large companies now publish their numbers.
Cloudflare ran AI review on 48,095 merge requests across 5,169 repositories in 30 days. That was 131,246 review runs. The median run took 3 minutes 39 seconds and cost $0.98. The average was $1.19. Engineers used a break-glass override on 0.6% of merge requests. Cloudflare sorts every merge request into one of three risk tiers and reviews each tier differently.
Intercom wrote in April 2026 that over 93% of its pull requests are agent-driven. Over 19% are “auto-approved with no human reviewer.” In four weeks, 497 PRs went fully autonomous. The backend revert rate was 0.53% for AI-authored code and 5.39% for human-authored code. Downtime fell 35% while deployments doubled.
Anthropic launched Code Review for Claude Code in March. Inside Anthropic, the share of PRs with substantive review comments went from 16% to 54%. Engineers marked under 1% of findings as incorrect. Each review costs $15 to $25. Cherny says a team of Claude reviewers catches “pretty much every bug,” and a human still approves.
Google reported the scale in April. Sundar Pichai said 75% of all new code at Google is now AI-generated and approved by engineers.
The building blocks are documented. Claude Code GitHub Actions run a review on every pull request event and post inline comments. A deeper multi-agent review, called ultrareview, costs $5 to $25 and runs for 5 to 15 minutes. Claude does not start it on its own. A person asks for it on a risky change.
The pattern across these companies is the same. A cheap reviewer reads everything. A deeper reviewer runs on demand. Humans stay for the riskiest tier. Nobody here removed review. They moved it to a machine and kept humans at the top of the risk ladder.
Agents miss what the codebase already knows: money
An AI reviewer reads the diff. It does not always know what the rest of the codebase already handles. Money is the classic trap.
Many developers assume every currency has 100 minor units, like cents in a dollar. Many do not. The official ISO 4217 list, maintained by SIX and last published September 17, 2026, gives the minor unit for each currency code. By our count of that list, 139 codes use 2 decimals. 17 use none, including the Japanese yen and the Korean won. 7 use three, including the Bahraini dinar and the Kuwaiti dinar. 2 use four. That is 26 currencies where “multiply by 100” is wrong.
Stripe’s documentation states the rule that payment APIs follow. Amounts are given “in the currency’s minor unit.” Stripe documents zero-decimal and three-decimal currencies separately for this reason.
Agents can parse a currency amount as a float and multiply by 100. That passes every test that uses dollars. It breaks in Bahrain and in Japan. The bug ships when the codebase already has a currency utility and the agent writes its own instead. A human who knows the codebase would point at the utility. A reviewer that reads only the diff may not.
There are three fixes, and they stack. Store money as integers in minor units, never as floats. Keep one currency module and make the review agent check that new code uses it. Add test cases for a zero-decimal and a three-decimal currency, so the yen and the dinar break the build before production does.
The general point is about context. A review agent is only as good as what it can see. Give it repository search. Give it a rules file that names the shared modules. Otherwise it reviews code in isolation, and the bugs that slip through are the ones that only make sense in context.
A normal index build on a big table blocks writes
The second trap is the database. Agents write migrations quickly. Some migrations are safe on a small table and dangerous on a large one.
PostgreSQL’s documentation is direct. A standard index build “locks out writes (but not reads)” on the table until it finishes. On a table with millions of rows, that can take minutes. Every insert and update waits. If your ingestion pipeline writes to that table, ingestion stops. If deploys run migrations, deploys stall behind the lock.
The fix is in the same documentation. CREATE INDEX CONCURRENTLY builds the index without blocking writes. It has its own rules. It cannot run inside a transaction block. If it fails, it leaves an “invalid” index behind that must be dropped and rebuilt.
This is old knowledge, and teams already encode it. The strong_migrations library for Rails says it plainly: “In Postgres, adding an index non-concurrently blocks writes.” GitLab’s database guide makes add_concurrent_index a requirement on populated tables. A RuboCop rule, PreventIndexCreation, blocks new indexes on tables GitLab marks as large. Squawk, a Postgres migration linter, has a rule to “Ensure all index creations use the CONCURRENTLY option.”
An agent writing a migration does not know which of your tables are large unless you tell it. A human reviewer who has been paged for this before would catch it. Remove that reviewer, and the knowledge has to live somewhere the agent can read.
The cheapest place is the review agent’s rules. List your largest tables. Forbid blocking migrations on them. Require concurrent index builds. Then add a linter like Squawk to CI, so the rule holds even when the review agent misses it. Two layers cost little. One outage on a large table costs far more.
Every incident becomes a rule the reviewer enforces
The currency bug and the index lock share a shape. Each is a mistake a human reviewer learned to catch once, through pain. Without that reviewer, the lesson has to be written down.
The tools now support this directly. Claude Code’s code review reads a REVIEW.md file in the repository. The documentation says to “add rules you want flagged on every pull request.” Each rule is a sentence the reviewer applies to every change.
Every, a company that builds several AI products, describes the habit it calls compound engineering. When something goes wrong, “add a note so the agent learns.” Each bug, failed test or insight “gets documented and used by future agents.” Every runs 12 review subagents in parallel on its code. In its words, bug fixes “eliminate entire categories of future bugs.”
GitLab’s PreventIndexCreation rule is the same idea from before agents. A past incident became a lint rule that blocks the whole class of change.
A rule that has never been tested is a guess. We would run each new rule through a short loop before trusting it.
First, trace the incident to the pull request that caused it. Second, write the rule as one sentence in the rules file. Third, replay that pull request through the reviewer and confirm the rule flags it. Fourth, run the reviewer over the last 50 merged PRs and count false flags. A rule that flags half the codebase will be ignored. Fifth, version the rules file and enforce it on every PR.
This turns a team’s scar tissue into something an agent can read. Done well, the same bug does not ship twice. Done badly, the rules file grows into noise that nobody trusts. The replay step is what separates the two.
Reverts fell. Follow-up fixes nearly doubled
The quality picture is mixed, and Neil’s ledger shows why one metric misleads.
By his count, the share of his PRs that were later reverted fell from 2.3% at PostHog to 0.4% at Tano. That looks like 6x fewer mistakes. His own page warns against reading it that way. Reverts undercount rework. At Tano, he writes, “I fix forward instead of reverting.”
So he tracks a second number. The share of his PRs that needed a follow-up fix within seven days went from about 7.6% at PostHog to about 13.8% at Tano. Fewer reverts, nearly twice the follow-up fixes. His PRs also grew. Median lines added went from 42 to 229. Median files touched went from 3 to 6. About 30% of his Tano PRs fix bugs.
The wider data points the same way. Faros found bugs per developer up 54% and the ratio of incidents to PRs up 242.7%. Cortex found incidents per PR up 23.5% and change failure rate up 30%.
Intercom’s numbers show it can go the other way. Its backend revert rate was 0.53% for AI-authored code against 5.39% for human-authored code. The difference is in the guardrails around the code, not only in who wrote it.
Fixing forward is a choice, and it is not the default advice. Google’s SRE workbook names rollback as the generic mitigation that “speeds recovery.” DORA’s metrics count a rollback and a hotfix the same way in the change fail rate. DORA also tracks deployment rework rate, the unplanned deploys caused by incidents.
The practical rule is to track three numbers together: volume, size and rework. Any one alone tells a happy story. A falling revert rate with rising follow-up fixes means the cost moved, not that it disappeared.
Fast rewrites turn big migrations into two-way doors
Speed changes which decisions are reversible.
In Amazon’s 2015 shareholder letter, Jeff Bezos split decisions into two kinds. One-way doors are hard to undo and deserve care. Most decisions, he wrote, are “changeable, reversible” two-way doors. Those should be made “quickly by high judgment individuals or small groups.”
Large data migrations used to be one-way doors. PostHog’s persons-on-events migration is a public example. PostHog moved person data onto its events table so that queries “no longer have to join tables.” PostHog said queries would improve “by up to 400%.” It had tracked over 50 billion events by then. Neil’s page dates the work from May 2022 to May 2023, about a year. He contributed to one company-wide migration at PostHog and led one.
At Tano, by his count, he has led four company-wide migrations in eight months. One moved Tano’s creator agent from a checklist design to workflow orchestration. Another moved 13,345 partners to a new model between August and September 2026.
His June post describes what changed. “A big overhaul doesn’t take weeks. It can be done overnight.” When a rewrite is that cheap, architecture becomes a two-way door. You can try a design in production, learn, and change it.
That has a cost. Moving fast through migrations means some break. A team that treats every migration as reversible needs the guardrails from the last three sections: rules for dangerous operations, tests for edge cases, and a way to measure rework.
It also changes planning. When a migration took a year, teams future-proofed it, because they could not afford a second one. When it takes weeks, the better plan is often the smallest design that works now, with the expectation of changing it. The risk is in pretending a one-way door is a two-way door. Data loss, payments and security changes still deserve the slow path.
From a checklist agent to a workflow with fewer tools
Neil’s first Tano migration is a design lesson for anyone running agents in production.
Tano’s agents work with creators for brands. Seedcamp described the company in November 2025 as an end-to-end AI marketing business whose agents “source, vet, outreach, negotiate.” Neil’s page lists a negotiation engine behind more than $1 million in accepted creator deals.
His page also lists a project called “Checklists to workflow orchestration,” from February to July 2026. The workflow engine now runs more than 97,000 collaborations. One example PR in his ledger replaces a “v1 one-shot executor” with an “agentic graph invoker.”
Anthropic’s guide to building effective agents draws the same line. Workflows follow “predefined code paths.” Agents “dynamically direct their own processes and tool usage.” The guide recommends the simplest design that works, and adding agent freedom only where it pays.
The failure mode of the free design is common. One agent gets a long checklist and a large set of tools. It picks the wrong tool at the wrong step. When it goes wrong, nobody can see why, because the steps are not separate.
The workflow design splits the job. Each task is a step with a clear input, a clear output and a short list of allowed tools. A failed step shows up in the trace. A wrong tool call is impossible if the tool is not offered.
That fits the rest of this edition. Agents remove human constraints. Production systems need new ones, built into the design. A workflow with narrow tools is a constraint, chosen on purpose. It trades some flexibility for something you can observe and fix.
If you run an agent with more than a dozen tools and a free-form plan, look at your traces. If the same wrong tool call keeps showing up, the fix is probably structure, not a better prompt.
One person can now own a whole feature
Review was one human constraint. Coordination was another. When writing code was slow, splitting a feature across several people made sense. When it is fast, the hand-offs cost more than the code.
Every runs five products. Each is “primarily built and run by a single person.” Neil’s page says the same of Tano: engineers “own their areas end to end.” In his March post on working with Claude Code, he describes his own role as “the manager of agents,” not the implementer. By his count he built 24 projects in eight months at Tano, against 17 in 3.7 years at PostHog.
Anthropic surveyed 132 of its own engineers for a December 2025 study. Claude was used in about 60% of their work. Engineers said they were “becoming more ‘full-stack’.” One said he is now “70%+” a reviewer and reviser of code.
OpenAI published a related case in February. A small team shipped a beta of about a million lines over five months with no hand-written code.
PostHog shows that single ownership predates agents. Its handbook says engineers are “normally responsible for their area of the product.” It expects product engineers to talk to users, and it built programs to “reduce the need for PMs.” PostHog had about 25 people when Neil joined in 2021.
What changes with agents is the size of the area one person can own. Design, frontend, backend and data work all fit in one head when agents write most of the code.
The cost moves to choosing. Neil wrote in February that “choosing what to build has become more important than just building.” A team of single owners needs a clear shared priority list, or each owner optimizes their own corner. The planning meeting matters more, not less. So does writing down why each area works the way it does, which is where the next part of this edition begins.
The bottleneck moved into the engineer’s head
Remove review and coordination, and the work still has to pass through one place: the person deciding what the agents do.
Anthropic said it directly in its October 16 report on employment at Anthropic. Human attention is now “the bottleneck for agent output.” Agent sessions spend about 80% of their time idle, waiting for a person. One engineer described “an army of Claudes, with every one asking for my attention.”
Simon Willison has written about this more than anyone. In February he said “the productivity boost these things can provide is exhausting.” In April he said using agents well takes “every inch of my 25 years” and is “mentally exhausting.”
Steve Yegge calls it the AI Vampire. His February essay says AI leaves “difficult decision-making for humans, which is exhausting and draining.” On the Hanselminutes podcast he said working with AI “drains human energy,” and asked: “so why is everyone so exhausted?”
The survey data agrees. Harness surveyed 700 engineering staff in February 2026. 75% said pressure to ship fast contributed to burnout.
From the inside it looks different. The ledger shows more output, and the engineer feels the cost. Agents do the typing. The person does the deciding, the checking and the switching, all day, at a pace set by machines that never tire.
That cost shows up in four places. The engineer switches between too many threads. Shared context thins out when nobody reads other people’s code. The workday stretches. And the bill for tokens sets a new kind of limit. The next sections take them one at a time, with what the leading practitioners say they do about each.
Too many agents at once is thrashing
Operating systems have a word for this. In 1968 Peter Denning defined thrashing as “excessive overhead and severe performance degradation or collapse caused by too much paging.” The machine spends its time switching instead of working. The fix was to run fewer processes at once.
Engineers with agents now face the human version. Neil’s ledger shows it. In a typical month at PostHog he had about 2 projects in flight, at most 5. At Tano he has about 6, at most 9. His March post describes going “from getting overwhelmed by two parallel branches to running five worktrees at once.”
His session logs show a more modest picture than the projects suggest. PRs in flight at the same time went from 1.85 to 2.9. Half his active agent time is a single session.
Addy Osmani of Google wrote the clearest line on it in April: “Your cognitive bandwidth doesn’t parallelize.” The cost, he says, “isn’t in the switch itself - it’s in the recovery time.” Agent decisions cannot queue up like email.
Willison describes the limit in practice. He can “fire up four agents in parallel,” and “by like 11 AM, I am wiped out.”
A Harvard Business Review study by BCG and UC Riverside, published in March, surveyed 1,488 US workers. Heavy oversight of AI came with 14% more mental effort, 12% more fatigue and 19% more information overload. Self-rated productivity fell once people used four or more AI tools.
The operating system fix still applies. Cap the number of agent sessions per person. Finish before starting. Let urgent bugs interrupt, but not every bug. Faros found 26% more in-progress tasks sitting idle for seven days or more. That is what thrashing looks like on a team board.
Nobody reads every pull request anymore
Code review did more than catch bugs. It spread knowledge. PostHog’s handbook says it plainly: “Reviews also build shared context and collective ownership.”
That benefit goes away with the review. Neil went from reviewing 1,589 teammates’ PRs at PostHog to 67 at Tano. He no longer sees most of what his colleagues change. Neither do they see his.
Anthropic’s own engineers report the same thing. In its December study, one said “More junior people don’t come to me with questions as often.” Another sends “80-90%” of questions to Claude instead of colleagues. A January Anthropic trial with 52 engineers found that people who learned a new library with AI help scored 50% on a comprehension quiz, against 67% for those without it.
Charity Majors put the stakes in one line in July: “The real product of a software team is shared understanding.”
The risk has a name. The bus factor, or truck factor, is the number of people who must leave before a project stalls. A 2016 study of 133 popular GitHub projects found that 65% had a truck factor of two or less. When one person owns an area end to end and nobody reads their code, the factor for that area is one.
The fix the industry is settling on is written context. AGENTS.md is a file that tells agents how a codebase works. Its site calls it “a README for agents” and says over 60,000 open-source projects use it. In a monorepo, “the closest AGENTS.md to the edited file wins,” so each area can carry its own. OpenAI’s Codex documentation gives the same advice.
Neil’s ledger shows the habit at work. His documentation lines at Tano reached 24,750, against 2,949 at PostHog. Written for agents, it also serves the next human.
The workday changed shape
When a person wrote all the code, the day had a rhythm. Write in the morning, open PRs in the afternoon, wait for approval.
Neil’s charts show that rhythm at PostHog. On a typical day in April 2023 he opened 2 PRs, both between about 13:00 and 14:45. At Tano, on a typical day in August 2026, he opened 10, spread from about 10:10 to 17:35. PRs now land when an agent finishes, not when he does. The share of his PRs opened before 11:00 rose from 11% to 19%, because agents keep working after he leaves.
That creates a new pressure. If the agents could always be working, every pause feels like waste. Willison described people “losing sleep” over the thought that “my coding agents could be doing work for me,” then waking “at four in the morning.”
The data shows the hours stretching. Harness found 71% of engineering staff work evenings or weekends at least weekly. A Berkeley study of 200 employees, reported in Harvard Business Review in February, found people worked faster, took on more tasks, and worked longer hours, with “constant task-switching.” Stack Overflow found a third of daily AI users spend four or more hours a day in AI tools.
The people furthest ahead set limits. Mitchell Hashimoto, who founded HashiCorp, advises you to “turn off agent desktop notifications” and decide yourself when to check in. Yegge’s advice is simpler: “close the laptop and go for a walk.”
Good pacing looks like this. Put the hardest decisions where your attention is best. Do not make risky changes when you are tired. Let agents run on clear, bounded tasks while you are away, and review them fresh. Set a hard end to the day. The agents do not need rest. You do, and your judgment is now the scarce input.
Default prompts make products look alike
Agents can build a user interface in minutes. The problem is that they build the same one.
Anthropic described this in November 2025. Its applied AI team called it “distributional convergence.” Without guidance, Claude will “almost always conform to Inter fonts, purple gradients on white backgrounds.” Users call the result “AI slop.” Anthropic’s own front-end design skill now warns against patterns that “read as AI-generated,” such as fade-and-slide-up entrances and the generic SaaS card layout.
The reason is in how models work. They produce the most likely output, and the most likely website is an average of many websites. Speed makes the average cheap. Distinctive design still takes taste and decisions.
PostHog is a useful contrast. Its first non-engineering hire was an artist, Lottie Coxon, who drew the company’s hedgehog mascot. Co-founder James Hawkins said, “We’re not going to win by being the same.” The brand that followed is one of the most recognizable in developer tools. That was a human choice, made early, before speed was cheap.
For AI-native teams the lesson is that design is now a constraint you have to add on purpose. A small team of single owners, each moving fast, will ship the default look unless someone owns the brand.
There are concrete fixes. Give agents a design system: tokens for color and type, a component library, and examples of your own pages. Anthropic’s skills approach does this, and its post shows the output change when the model is given explicit direction. Name the patterns to avoid, not only the ones to use. And review the first screen of every new product with the same care as its database migrations.
Plan limits, not ambition, now set the pace
The last new constraint is money, and it shows up as limits.
Claude’s plans set the shape of heavy agent use. As of November 3, 2026, Max costs $100 a month for “5x Pro usage every 5 hours and every week.” Ultra costs $200 a month for 10x weekly usage, with no five-hour limit. Anthropic’s support page says Pro and Max plans have “a five-hour session limit and a weekly limit.” Usage beyond that is billed “at standard API rates.”
API prices per million tokens are $4 in and $20 out for Opus 5.5, $2 and $10 for Sonnet 5.5, and $10 and $50 for Fable 5.1. An engineer running several agents all day can use far more than a plan covers.
The industry has a word for maximizing usage. Tomasz Tunguz defined “tokenmaxxing” in April as “the deliberate practice of maximizing token consumption,” and described about 250 million tokens in one day. IBM reported in September that some companies were “incentivizing employees to maximize their AI token usage,” including a leaderboard at Meta. The BCG study found firms sometimes use token consumption as a proxy for performance.
That is the wrong metric. Token spend measures effort, not results. Review shows the better frame. Cloudflare’s AI review averages $1.19 per merge request. Anthropic’s deeper Code Review costs $15 to $25. Cherny calls multi-agent review expensive, token-heavy computation. Those prices are worth paying for some changes and not others.
Autonomous monitoring, where agents watch production and open PRs on their own, is where limits bite next. PostHog’s Replay Vision, launched in September, watches session recordings “so nobody has to sit through them.” Sentry’s Seer can “open pull requests for us automatically,” but only for issues it judges fixable.
Measure cost per merged PR and cost per prevented incident. A limit is useful when it forces you to spend tokens on the work that matters most.
Anthropic sped up review, and CI broke next
The clearest record of a constraint moving comes from Anthropic itself.
In a September 14 post, Anthropic’s Sachin Malhotra described what happened after agents took over most code writing. Anthropic produces about 8 times more code per quarter than it did in 2021 to 2025. Claude writes about 80% of it. Tests grew 10 times while headcount stayed roughly flat. CI jobs rose 25 times in six months.
The post names the order. “Once PR review gets accelerated, CI starts feeling the pressure.”
The first thing to break was test selection. Anthropic ran only the tests affected by each change. A single process, called the listener, tracked which tests touched which code. It fell behind the PR queue. The first pages came in October 2025. Twenty minutes of listener lag meant tens of thousands of test updates were not applied.
The team patched it three times, and each patch lasted less time than the one before. A bigger machine bought 70 days. Sharding bought 29. Daily restarts bought less than one.
Then one engineer rebuilt it in three weeks. State moved to an in-memory store. Stateless workers append their results to a journal. The new design scales with the number of workers, not the size of one machine.
This is the pattern behind the 11x ledger at company scale. Remove the human step, and the next system in line takes the load. That system was designed for human pace. It holds for a while, with patches. Then the patches stop working and it needs a new design.
Teams adopting agents should expect this sequence and watch for it. If your CI queue time is rising faster than your PR count, CI is next. The time to redesign is when the second patch lasts half as long as the first, not after the third.
Then source control broke, and Anthropic left git
After CI, the next system was source control. Anthropic described it in an October 13 post.
Merged changes to its monorepo went from about 2,500 a day in May 2026 to more than 30,000 a day in September. The main history is about 100 GB. CI ran about 25 million checkouts a day. Fetched the naive way, that would have meant more than 600 petabytes of git traffic a day. At peak, Anthropic ran several hundred git mirrors to keep up.
Anthropic names the root cause. Git was designed to work offline. Its clients are developers who sync occasionally. Agents are always online and sync constantly. The design that served people for twenty years worked against machines.
So Anthropic built its own version control system, called Scion, and a code review system called Antique. A team of seven moved the monorepo off git in five months. The new system uses about 200 times less CPU and memory than the git mirrors. Checkouts went from minutes to seconds. CI gained 25% more CPU capacity. The cache hit rate is above 99%.
Most teams will never reach 30,000 merges a day. The lesson still applies. Each removed constraint exposes the next one. The order at Anthropic was review, then CI, then source control. Each system was built for human pace and broke under agent pace.
Google reports the same kind of change from the other direction. Pichai said an agent-assisted code migration finished “six times faster than was possible a year ago with engineers alone.”
The useful question for any team is which of your systems assumes a human is on the other end. Rate limits, queue sizes, review tools, deploy windows and on-call rotations all carry that assumption. List them before agents find them for you.
After the machines, the people became the constraint
Anthropic’s October 16 report on employment at Anthropic describes the step after CI and git. The constraint is now people.
Agent sessions spend about 80% of their time idle, waiting for human input. Human attention is “the bottleneck for agent output.” Work on the agents themselves, such as tooling, pipelines and prompts, rose from 10% of sessions in fall 2025 to 22% in spring 2026. The report also names the human side. An executive said “a workforce that is anxiously worried is not a workforce doing its best work.”
This fits a model older than software. Eliyahu Goldratt’s theory of constraints says a system moves at the pace of its tightest step. Improve that step, and another becomes the tightest. His last step is to avoid inertia and go back to the start. In agent terms: find the bottleneck, remove it, then look again.
Cherny’s line, “Find the bottleneck, solve the bottleneck,” is the same loop. It explains why the sequence keeps going. Review fell, so CI broke. CI was rebuilt, so git broke. Git was replaced, so attention is the limit.
Attention is harder to scale than a server. It cannot be sharded. That is why the costs in the middle of this edition matter. Thrashing, lost shared context and long hours are the symptoms of attention as the constraint.
The fixes at this stage look different. Fewer, better-scoped agent tasks. Agents that batch questions instead of interrupting. Tools that summarize what an agent did, so a person can review in minutes. Clear priorities, so engineers do not spend attention deciding what matters. The teams that solve this next will look less like they have more agents, and more like they ask their people for fewer decisions.
AI is necessary but not sufficient
If agents were enough on their own, every team would see Neil’s 11x. The data says they do not.
Atlassian’s State of Developer Experience 2026 surveyed more than 1,500 practitioners. Only 17% of developers and 23% of leaders said their organization has a clear, implemented AI strategy. Only 28% of developers feel less friction than before AI. Half, 49%, spend four or more hours a week reviewing AI output.
Faros’s April report is blunter: “Strong engineering foundations do not protect you.” Epics per developer rose 66%, but downstream quality got worse. Bugs per developer rose 54%.
Cortex’s 2026 benchmark found only 45% of organizations have AI policies. Its summary is the clearest single line on the subject: “AI amplifies both the best and worst aspects of your engineering practices.”
Charity Majors made the same argument in July. “Nondeterministic systems will require more engineering discipline, not less.”
Anthropic’s December study shows what the upside looks like when the organization adapts. 27% of Claude-assisted work at Anthropic was work that would not have been done otherwise. Running many Claude instances “allows you to test a bunch of different ideas.” That is experimentation built into the way people work.
So the evidence supports a simple rule. Agents are necessary for the large gains. They are not sufficient. The gains come from the changes around them: review moved to machines with guardrails, written context instead of tribal knowledge, systems rebuilt for agent pace, and limits on human attention.
Culture matters too. Teams that let people experiment with how they work find the next constraint sooner. Leaving agents running overnight, splitting work into workflows, and writing AGENTS.md files are all experiments that look odd at first. The organizations that allow them find out which ones work.
Speed is not product-market fit
Faster shipping helps a company only if it ships the right thing.
The speed is real. Stripe’s annual letter, published in February 2026, said its 2025 startup cohort is growing about 50% faster than the 2024 cohort. The number of companies reaching $10 million in annual revenue within three months of launch doubled. At Stripe Sessions in April, Stripe said top AI companies grew 120% in 2025 and 175% so far in 2026. Sam Altman said in April that the friction of starting a startup “has come down a lot.”
The retention is weaker. ChartMogul studied 3,500 companies for a December 2025 report. AI-native companies had a median gross revenue retention of 40% and net revenue retention of 48%. B2B SaaS had net revenue retention of 82%. ChartMogul’s summary: “The downside of being easy to buy is being easy to cancel.”
Marc Andreessen’s definition of product-market fit still frames the question: “being in a good market with a product that can satisfy that market.” Shipping more PRs does not answer it.
PostHog shows the order of events. It was founded in January 2020. By its own account, it reached product-market fit for its Scale product in September 2021, about 19 months after launch. Revenue grew six times in 2022. It passed 100,000 customers in October 2024 and turned cash-flow positive that December. Speed helped. Fit came first.
The edge for AI-native startups may also be temporary. Seema Amble of a16z wrote in September 2026 that “The incumbents aren’t sitting idly.” She argues that preserved context “is not a durable advantage.”
Established companies will adopt the same tools, more carefully, because they have more to lose. The startups that keep their lead will be the ones that turned speed into customers who stay.
A checklist for teams going AI-native
Here is what this edition adds up to, as checks a team can run this quarter.
Measure the change honestly.
Track volume, PR size and rework together. Use follow-up fixes within seven days, not just reverts.
Report per-developer change, not just totals.
Know your cost per merged PR and per prevented incident.
Move review to machines, with guardrails.
Route review depth by risk: a cheap reviewer on every PR, a deeper one on demand, humans on the riskiest tier.
Give the reviewer repository search and a rules file that names shared modules.
Turn every incident into a rule, and replay it against the PR that caused it before trusting it.
Encode the old human knowledge.
Store money as integers in minor units, and test a zero-decimal and a three-decimal currency.
Require concurrent index builds on large tables, in the reviewer’s rules and in a migration linter.
Write AGENTS.md files for each area, so context outlives its owner.
Protect the scarce input: attention.
Cap agent sessions per person, and finish before starting.
Turn off agent notifications and check in on your own schedule.
Set a hard end to the day. Do not make risky changes when tired.
Watch for the next constraint.
List every system that assumes a human on the other end: CI, source control, rate limits, deploy windows.
Redesign when the second patch lasts half as long as the first.
Give one person ownership of design, so speed does not ship the default look.
The two eras are not separated by a model release. They are separated by which human steps a team removed, and how well it replaced them.
Reply to this email with two numbers from your team: merged pull requests per engineer per month, and median time from opening a pull request to merging it. We will publish what readers send, without names, in a future edition.
Sources
Neil Kakkar, “Two eras of shipping” ledger, charts and table (neilkakkar.com)
Neil Kakkar, “About” and CV (neilkakkar.com)
GitHub, “Octoverse 2026”, 28 Oct 2026 (github.blog)
Stack Overflow, “2026 Developer Survey results”, 6 Oct 2026 (stackoverflow.blog)
Faros AI, “AI acceleration whiplash”, 12 Apr 2026 (faros.ai)
Cortex, “2026 Engineering Benchmark” (cortex.io)
Neil Kakkar, “Review ratio”, “Under the multiplier” and “What I built” charts (neilkakkar.com)
Cloudflare, “AI code review”, 20 Apr 2026 (blog.cloudflare.com)
Intercom, “AI is approving our pull requests”, 21 Apr 2026 (intercom.com)
Anthropic, “Code Review for Claude Code”, 9 Mar 2026 (claude.com)
Fortune, interview with Boris Cherny, 11 Jun 2026 (fortune.com)
Google, “Sundar Pichai at Cloud Next 2026”, 22 Apr 2026 (blog.google)
Claude Code docs, “GitHub Actions”, “Ultrareview” and “Customize code review” (code.claude.com)
SIX, “ISO 4217 List One”, 17 Sep 2026 (six-group.com)
Stripe docs, “Supported currencies” (docs.stripe.com)
PostgreSQL docs, “CREATE INDEX” (postgresql.org)
strong_migrations (github.com/ankane)
GitLab docs, “Adding database indexes” (docs.gitlab.com)
Squawk docs, “require-concurrent-index-creation” (squawkhq.com)
Every, “Compound engineering”, 11 Dec 2025 (every.to)
DORA, “DORA metrics guide”, updated 5 Jan 2026 (dora.dev)
Google, “Site Reliability Workbook: Incident response” (sre.google)
Amazon, 2015 letter to shareholders (sec.gov)
PostHog, “Persons on events”, 2 Nov 2022 (posthog.com)
Neil Kakkar, “AI made me braver”, 21 Jun 2026 (neilkakkar.com)
Seedcamp, “Tano announces their angel round”, 24 Nov 2025 (seedcamp.com)
Anthropic, “Building effective agents” (anthropic.com)
Anthropic, “How AI is transforming work at Anthropic”, 2 Dec 2025 (anthropic.com)
OpenAI, “Harness engineering”, 11 Feb 2026 (openai.com); InfoQ summary, 21 Feb 2026 (infoq.com)
PostHog handbook, “Small teams”, “Product engineers” and “Helping engineers do product” (posthog.com)
Neil Kakkar, “Agentic debt”, 24 Feb 2026, and “How I’m productive with Claude Code”, 16 Mar 2026 (neilkakkar.com)
Anthropic, “Employment at Anthropic”, 16 Oct 2026 (anthropic.com)
Simon Willison, “AI intensifies work”, 9 Feb 2026, and Lenny’s Podcast notes, 2 Apr 2026 (simonwillison.net)
Steve Yegge, “The AI Vampire” (yegge-ai.pages.dev); Hanselminutes episode 1035, 5 Feb 2026 (hanselminutes.com)
Harness, “State of DevOps Modernization 2026” (harness.io)
Peter Denning, “Thrashing: its causes and prevention”, 1968 (cs.uwaterloo.ca)
Neil Kakkar, “Work areas” and “Shape of a day” charts (neilkakkar.com)
Addy Osmani, “Cognitive parallel agents”, 7 Apr 2026 (addyosmani.com)
Harvard Business Review, “When using AI leads to brain fry”, 5 Mar 2026 (hbr.org); Fortune coverage, 10 Mar 2026 (fortune.com)
PostHog handbook, “How we review” (posthog.com)
Anthropic, “AI assistance and coding skills”, 29 Jan 2026 (anthropic.com)
Charity Majors, “AI demands more engineering discipline, not less”, 27 Jul 2026 (oreilly.com)
Avelino et al., “A novel approach for estimating truck factors”, 2016 (arxiv.org)
AGENTS.md (agents.md); OpenAI Codex docs, “AGENTS.md” (learn.chatgpt.com)
Mitchell Hashimoto, “My AI adoption journey”, 5 Feb 2026 (mitchellh.com)
Anthropic, “Improving frontend design through skills”, 12 Nov 2025 (claude.com); “frontend-design” skill (github.com/anthropics)
PostHog, “The first five” (posthog.com)
Anthropic, “Claude pricing”, “Using Claude Code with your Pro or Max plan” and “API pricing” (claude.com)
Tomasz Tunguz, “Tokenmaxxing”, 1 Apr 2026 (tomtunguz.com); IBM, “What is tokenmaxxing”, 1 Sep 2026 (ibm.com)
PostHog, “Replay Vision”, 22 Sep 2026 (posthog.com)
Sentry, “Automated debugging workflow”, 6 Aug 2026 (blog.sentry.io)
Anthropic, “Agentic coding is straining CI”, 14 Sep 2026 (claude.com)
Anthropic, “Redesigning source control”, 13 Oct 2026 (anthropic.com)
TOC Institute, “The five focusing steps” (tocinstitute.org)
Atlassian, “State of Developer Experience 2026” (atlassian.com)
Stripe, “2025 annual letter” and “Stripe Sessions 2026: Inside the AI economy” (stripe.com)
OpenAI Forum, Sam Altman event replay, 6 Apr 2026 (forum.openai.com)
ChartMogul, “The AI churn wave”, 10 Dec 2025 (chartmogul.com)
Marc Andreessen, “The only thing that matters” (pmarchive.com)
PostHog handbook, “Our story” (posthog.com)
a16z, “The Incumbents Are Coming”, 3 Sep 2026 (a16z.com)