TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Software engineer Neil Kakkar reports merging 11 times as many pull requests per month at AI-native startup Tano as he did at PostHog before AI agents became part of his workflow. His account is a personal comparison, not a controlled study, and describes new costs including context switching, weaker shared context and concern about AI usage limits.
Software engineer Neil Kakkar says he merged 11 times as many pull requests per month after joining AI-native startup Tano than he did at PostHog, in a personal account published by The Pragmatic Engineer. The comparison offers a snapshot of how AI coding agents can change one engineer’s pace, while also describing new workflow problems that raw output counts do not capture.
Kakkar says he joined Tano as its first engineer and worked there for eight months, helping build an affiliate platform, improve a content monitoring system and migrate the company’s agent architecture. Before that, he spent four years at PostHog, where he worked across product areas including analytics, experimentation, surveys and feature flags. He compares the PostHog period with Tano’s early growth, not with equivalent jobs or teams.
He reports that his monthly pull-request output at Tano was 11 times his PostHog rate; he also says his PostHog rate was 2.4 times his earlier rate at Bloomberg. At PostHog, where his figures are from before late 2024, AI use was largely tab completion, he writes. At Tano, he says, coding agents could take on larger pieces of implementation. The source does not provide a controlled measurement of code quality, business impact or time saved.
The Pragmatic Engineer says it received 125 submissions for an essay challenge and selected Kakkar’s piece as the winner. Its editor describes Kakkar as a London-based engineer with nine years of professional experience. The article says pull-request counts can be gamed; Kakkar presents his own figures as an honest account of his work, but they remain a measure of activity rather than a complete measure of engineering performance.
Higher Output, New Workflow Costs
Kakkar’s account illustrates why AI-assisted engineering is not just a matter of adding a tool to an unchanged process. If agents let a developer produce more code and open more pull requests, teams may need to revisit how they review, coordinate and maintain that work. He says the older process involved substantial communication and peer review; at Tano, moving faster reduced some of those constraints but brought different risks.
He identifies context switching, lost shared context and less attention to design as problems in the faster workflow. He also says it is harder to pace himself and that AI plan limits can become a concern. Those observations matter to engineers and managers weighing productivity claims: a higher count of merged changes does not by itself show that a team is delivering more value, or that the work is easier to sustain.
The report also points to culture as a factor. Kakkar argues that teams need broad participation and room to experiment to gain from AI tools. That is his assessment based on experience at three workplaces, not a finding from a broad industry survey.
Products Worth Considering
LG UltraGear 34GX90SA-W 34-inch WQHD Curved OLED Gaming Monitor
Apple Watch SE (2nd Gen) GPS 40mm with Starlight Aluminum Case and Sport Band (S/M)
Anker SOLIX C1000 Gen 2 Portable Power Station
As an affiliate, we earn on qualifying purchases.
From Bloomberg to an AI Startup
Kakkar’s comparison spans three very different organizations. He describes Bloomberg as a company of about 20,000 people with defined processes, PostHog as a startup that grew from roughly 10 people to around 200 during his time there, and Tano as a company of about 10 people. He says he was early in his career at Bloomberg and later encountered a faster startup culture at PostHog.
At Bloomberg and PostHog, he says, code had to undergo peer review, and his responsibilities increasingly included reviewing colleagues’ work. He characterizes PostHog as a fast-moving, pre-AI baseline, but cautions that the company has since adopted AI tools and that its output is increasing. The comparison is therefore about his own work across different periods and workplaces, not a claim that PostHog’s current engineering process has stayed the same.
Kakkar says he joined Tano after AI agents had emerged and used tools with agent support. His previous work at PostHog included building products and handling infrastructure at scale; at Tano, he says, he covered a similar breadth of work in a shorter period. Differences in company size, role, project mix and career stage all limit how far the reported multiplier can be generalized.
“I’m shipping 11x more PRs at Tano than at PostHog.”
— Neil Kakkar, software engineer, in his essay for The Pragmatic Engineer
What the PR Count Cannot Show
The figures come from Kakkar’s own work history. The report does not publish a standardized audit of the pull requests or comparable measurements of defects, rework, customer outcomes, code quality or total hours worked. Kakkar acknowledges that PR counts can be gamed, and the source does not establish that AI alone caused the difference.
The workplaces differed in size, project mix, processes and Kakkar’s seniority. The article also says PostHog’s figures reflect its pre-AI period and that the company now uses AI extensively. It remains unclear how much of the reported gap reflects AI agents, the startup setting, role changes or other factors, and whether the same pace can be sustained without affecting quality or developers’ workload.
Further Essays and Team Changes
The Pragmatic Engineer said it would publish a follow-up highlighting runner-up submissions and linking to other essays from the challenge. Kakkar’s account does not announce a new product or company policy; its next value will depend on how readers and engineering teams test the observations against their own work.
For teams adopting coding agents, the open questions are practical: how to preserve review and design standards, share context across people and agents, and track outcomes beyond the volume of merged changes. The report offers no universal benchmark or timetable for answering them. It presents one engineer’s comparison as evidence of a rapid change in his own workflow, alongside costs that remain difficult to quantify.
Key Questions
What is the main finding in Kakkar’s account?
Kakkar reports merging 11 times as many pull requests per month at Tano as at PostHog. The comparison is based on his personal work history and is not a controlled study of AI productivity.
What role did AI play in the comparison?
Kakkar says his PostHog figures come from a pre-AI period when he mainly used tab completion, while Tano’s workflow included coding agents able to handle larger implementation tasks. The report does not isolate AI’s effect from other differences between the jobs.
Does the report show that AI improved code quality?
No. It focuses on Kakkar’s pull-request output and work examples. It does not provide comparable data on defects, maintainability, customer impact or rework.
What problems did Kakkar associate with the faster workflow?
He points to context switching, loss of shared context, less focus on design and difficulty pacing himself. He also raises concern about AI tool usage limits.
Can the reported increase be applied to other engineers?
Not on the evidence in this report alone. Kakkar’s roles, companies, projects and career stages differed, and the figures are his own. They should be read as an individual comparison rather than a general productivity benchmark.
Source: newsletter.pragmaticengineer.com
