Before we start: I’m in San Francisco this week and there are a few remaining spots for these live events (registration required):
*Wednesday (4 Nov):*at the iconic SFJAZZ Center. With Diogo Almeida (creator of Jev & co-inventor of ChatGPT), and Bryan Cantrill (cofounder and CTO of Oxide).The Pragmatic Engineer Unplugged*Thursday (5 Nov):*at The Howard SF. With Karri Saarinen (Linear), Kath Korevec (OpenAI), David Cramer (Sentry) and Adam Rogal (DoorDash)System Update
Also, this week there will be no issue of The Pulse on Thursday. Regular scheduling returns next week!
In September, when The Pragmatic Engineer turned five, I announced an essay challenge, inviting readers to write about how things have changed in tech workplaces and in our projects, for the chance to win a grand prize of $10,000 awarded to our favorite article.
We received 125 submissions, covering a wide range of viewpoints and experiences. Many thanks to everyone who took part. In today’s issue, we publish the winning piece in full.
Congratulations to software engineer Neil Kakkar! We appreciate the sheer volume of data that Neil has collected about how his own output has changed over time. Neil is a dev based in London, with nine years of professional experience; he has interned at Google, and been a software engineer at Bloomberg, Posthog, and Tano. His previous workplace, PostHog, is an open source project, which must’ve been useful for gathering historic data.
In a follow-up issue, we’ll highlight runner-up essays, and link to the ones that impressed us for the effort on show and interesting thoughts.
With that, it’s over to Neil. He covers:
Two eras of shipping. Until last year, he was merging between eight and 20 PRs per month. But since joining an AI-native startup, Neil now ships 200+ PRs per month, approximately a tenfold increase.**Old constraints that disappeared.**No more communications overhead or code reviews. The tradeoff: moving faster and breaking things.**New constraints that appeared.**Too much context switching (thrashing), losing shared context, pacing yourself is harder, less focus on design, and worries about AI plan limits.**How AI is changing software engineering.**Everyone needs to be onboard with AI to get the benefits at work, encouraging experimentation makes a difference, and many existing technologies and processes crack under the change.
I’ve been working at an AI native startup for the past eight months. Before joining Tano, I was at PostHog for four years, a fast moving pre-AI startup, and started my career at Bloomberg, a big fintech private company, where I spent three years. All three workplaces are different: Bloomberg is huge, with 20,000 people and very defined processes. PostHog is smaller, at around 10 people when I joined, and now at 200. At Tano, I was the first engineer and we’re now around 10 people in total.
In each job, I’ve seen what a difference speed and culture make, and more recently, how culture needs to change to keep up with AI.
To back things up, I use in-depth stats about my work at PostHog and Tano. I also have some very rough numbers from Bloomberg. By far, I’ve written more code and made a lot more PRs at Tano than I did at PostHog, and a major part of this is down to AI. Facilitating the shift is engineering culture.
One disclaimer before we get into it: the PostHog stats are from pre-AI. I’ve been following their journey, and PostHog is as “AI-pilled” as it gets now, and output is increasing significantly. In this article, I treat it as a ‘pre-AI baseline’ for excellent engineering work. Tano is a fast-moving AI-native startup, founded after AI agents emerged.
Let’s start with some raw numbers. I’m shipping 11x more PRs at Tano than at PostHog, where I shipped 2.4x as many as I did at Bloomberg.
At Bloomberg, I was just starting my career, so I wasn’t the fastest, and moving to PostHog opened my eyes to what a fast-moving startup culture really looks like: we were encouraged to take responsibility, ship things quickly, listen to customers, and solve their issues ASAP.
At Bloomberg and PostHog there was a high bar for code: everything had to be peer reviewed, and as I became senior, I spent a big chunk of my time reviewing code.
PRs can be an easily gamed metric, but I was not trying to game the numbers, so they’re an honest representation of the work done. Below are details of everything I worked on to justify the 11x PR multiplier.
I joined PostHog as a full stack software engineer and worked across the product, from the ingestion pipeline to optimising our analytics queries for funnels and retention on Clickhouse, scaling it up to handle a billion+ events scale, and eventually building out the experimentation product from scratch. I later led the Feature Success team, where we built out two new products: surveys and early access features, while improving experimentation and feature flags.
I joined Tano as a founding engineer and focused on a similar breadth of product as at PostHog, but all compressed into eight months instead of 45. I built out our new affiliate platform, made our content monitoring system a lot more efficient, and did some big migrations, like moving the entire agent architecture to a new system with persistent memory, better tools, and superior observability.
Here’s a summary of work I did at both companies:
At PostHog until late 2024, the extent of AI was tab completion. It was great for automating menial work like repetitive test cases, but was a long way away from today’s autonomous agents that can build an entire feature with no human input.
When I joined Tano this year, Claude Code Desktop was already present with really good agent support, and could build out entire features with little hand-holding. I never got used to the command line interface (CLI), and stuck to Claude Code Desktop. I really like the integrated browser and let Claude control it, rather than with my own browser where it’s very annoying if Claude takes over and blocks me from working. Over the last year, the desktop version has caught up to the CLI in features, and has some, like the browser, that a CLI doesn’t directly have.
At any one time, I’m working on 3-5 different things. I start by running through the plan, but mostly let the agent run until it has a PR ready and the comments addressed. Then I run through what it did via a digestible HTML artifact which Claude has instructions to generate with every PR. It looks something like this:
**My agents can take 1-2 hours to run. **This is for building a full feature, end to end, and given all of the machinery of reviews, verification, and screenshots, it usually takes my agents that long. The run can go even longer if I’m doing a research task that requires investigating a lot of data, processing of images and videos, or iterating towards a goal. I don’t yet use cloud agents because the native Claude agents seem too limited to run things as you would locally.
Larger companies have invested in building their own cloud agents where these integrations are present. It makes sense for them, but not so much at our scale – just yet.
Eleven times more PRs per month at Tano wouldn’t be possible without AI; I couldn’t write 100k+ lines of code a month by hand, let alone think through that many things. Furthermore, distractions during a normal work day – like new bugs, small feature requests, emergency incidents – break flow and decrease productivity. With AI, these can be passed onto a parallel work thread and not take up focus, front and centre.**How much does the 11x multiplier stack because of everything else, apart from AI? **Imagine visiting a pre-AI PostHog where reviews are mandatory as a time traveller from 2026, and you’re the only engineer there with secret access to AI tech from the future. At best, I think you’ll hit a 1-2x productivity gain because the bottleneck shifts from writing to PR approvals – but only for you. Others still aren’t free to review your completed PRs, and your PR output being much faster makes the review queue longer.
At Tano where we’re shipping 10x more, bottlenecks like this and others appear, like communicating with colleagues about what you’re doing, reviewing code, and figuring out what to build next. Let’s talk about some of these.
Engineers at Tano work as independently as possible. We come together and talk through big architecture decisions that affect the whole product, but for most things, there’s enough trust at the company that I can go do what I think is best. They also trust that if I’m not sure about what to do, or if there’s risks involved, that I’ll flag the risks and account for trade-offs.
A big part of moving fast is having just one person responsible for things. Of course, this assumes that they can figure out how to do it themselves, and go ship it.
At PostHog, when building out surveys, two engineers and one designer worked together to ship V1 in a month. All three of us iterated on the design, backend, and frontend. When I discovered something that needed to change on the backend, it often meant the other engineer needed to change something on the frontend as well. This was the communication overhead. Even so, engineers who worked together went faster than I would, figuring out the backend, then building out the frontend, and then iterating over any new constraints.
**Now that writing code is faster, a communication overhead makes little sense. **If I imagine that we’d be building the same survey functionality today, it’s now a lot more efficient if one person owns the entire stack end-to-end; design, frontend, backend. With Claude Code, this is doable by one engineer.
There’s still value in talking about unknown unknowns and things I’m not sure about with other engineers, but where the output is mostly known and it’s a straightforward feature or product, then I think one person working solo is more effective.
**Code reviews are optional at Tano. **That is, they are optional once you have a handle on the codebase. The time to confidence is variable, depending on how quickly you can get onboarded and how quickly human PR review comments go down to zero. I felt comfortable enough three weeks after I started, but depending on experience it varies, going up to eight weeks.
I built a code review agent via Claude Code Github Actions that runs on every PR, which is now standard across the codebase for everyone and runs in continuous integration (CI). There’s also a deeper, stronger agent we can run on demand if there’s a risky change.
In most cases, this automated reviewer is the only review on PRs. There are no human PR reviews.
Sometimes, things break. For example, in one reporting update, we needed to deal with minor currency units, like cents in the dollar. The agent decided to take these minor units, parse them as floats, and multiply by 100.
Do you see the mistake?
If you’ve worked with financial systems, you’ve probably been here. It’s a dumb mistake to assume every currency has 100 minor units. For example, the minor unit of the Bahraini dinar is the fulūs, and one dinar is 1,000 fulūs. But the generated code assumed it was 100 and this caused issues!
Plus, we already had a utility to handle all currency calculations and a human reviewer would have caught the generated code not using it.
We’re willing to make the trade-off between automated agent review & moving quickly and fixing things as they break. We make it at the cost of not going through a solid human review for every PR because we can do forward fixes on these issues quickly. In this case, we noticed the issue soon after deployment that reporting numbers were not matching up, and fixed them within the hour.
Sometimes, things break in new ways. For example, our posts table in Postgres was getting large, at about 25 GB and 6 million rows. We wanted to add a new partial index to this table, and migrations at 5 million+ rows aren’t straightforward. We realised this a bit later, when we did a blocking migration that blocked writes, and our ingestion pipeline stopped saving new posts. It also timed out, so new deploys failed to run. Now, every such migration needs to happen concurrently, which ensures it doesn’t block deploys or writes to the table.
We make sure to add any new way that things can break to the review agent. Now, it has a list of the largest tables and doesn’t allow blocking migrations on them.
Given no code reviews and only agents writing the code, how has it changed velocity, PR-revert rate, and the median size of PRs? I have some interesting data. The revert rate is 6x lower at Tano because we fix things forward most of the time, rather than revert. But another part of it is that automated code reviews and agents are writing more bug-free code as the models improve.
Since I don’t have to wait for anyone to merge my PRs, the median time to merge is less than an hour.
At Bloomberg, I was shielded from customers and interacted only with our product manager who helped us prioritise what to work on. Having a clear-cut distinction between engineers and product managers is great when working at huge companies, but these roles merge as workplaces get smaller. At Bloomberg, every team of engineers had a dedicated product manager. At PostHog, there was one product manager for several teams. At Tano, there are none.
The product managers at PostHog helped with lots of research and setting of the product direction, but engineers were also expected to dive in, talk to customers, do our own research, and form our own opinions on product direction as and when needed. I thrived in that environment.
**In my current role, I am the product manager, too. **We have a roadmapping session every Monday where everyone comes up with issues they’ve faced, things we need to fix, things that will become a problem soon, such as the number of support tickets per customer increasing – which means that as we get more customers, humans could not keep up with the number of tickets to solve.
The CEO and CTO provide the most context on things to be done, and usually have a better idea of prioritisation. They give engineers context on things like customer churn risk, features needed for a new sale to close, etc. Together, we decide what makes sense to tackle, then divide the work among engineers. Usually, every engineer picks up a separate thing to work on.
What used to take a month now often takes a week. This is because agents build things much faster, and I’m typically working on multiple projects at the same time, and no longer have to wait on a product manager to feed me items to build. Hence, we just share context and priorities, and go build things to achieve our weekly goals.
Over my career, I’ve been part of five big migrations; one at Bloomberg, one at PostHog, and I’ve led three at Tano.
**At PostHog, the big migration took a year. **It was about person-on-events. We have two huge tables at PostHog: the events table, with 20 billion+ events of what some anonymous id did; the persons table, which stores persons and their properties. When building funnels or unique user queries, we needed to join these two tables, then aggregate by the person. These queries were very slow, and downright unusable for larger customers. The person-on-events migration moved the person identifier and properties onto events, alongside the anonymous id. It was a massive company-wide effort…
