---
id: "lib-2026-11-03-how-software-engineering-is-changing-a-tale-of"
type: "library"
title: "How software engineering is changing: a tale of two eras"
lang: "EN"
org: "The Pragmatic Engineer (essay by a Tano founding engineer)"
source_type: "Practitioner post"
date: "2026-11-03"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-03-how-software-engineering-is-changing-a-tale-of/"
original_url: "https://newsletter.pragmaticengineer.com/p/how-software-engineering-is-changing"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "The winning reader essay in The Pragmatic Engineer, by a London engineer with his own PR data across Bloomberg, PostHog and an AI-native startup; detailed and candid, but one person's self-reported numbers."
summary_basis: "full-text"
original_minutes: "20"
tags: ["future of work", "coding agents", "code review", "velocity"]
frames: ["verification-capacity"]
---

# How software engineering is changing: a tale of two eras

Tier B (Useful, limited): The winning reader essay in The Pragmatic Engineer, by a London engineer with his own PR data across Bloomberg, PostHog and an AI-native startup; detailed and candid, but one person's self-reported numbers.

Summary based on the full text.

## In short

On 3 November 2026 The Pragmatic Engineer published the winner of its essay challenge (125 submissions): Neil Kakkar, a London engineer with nine years' experience at Bloomberg, PostHog and now Tano, a roughly ten-person AI-native startup. Using his own PR history, he reports shipping 11 times more PRs than at PostHog, with Claude Code agents doing most of the writing and an agent as the only reviewer. He is as specific about what broke and about the cost to his own focus and energy.

## Key numbers

- 11x: merged PRs per month at Tano (AI-native startup) vs PostHog for the same engineer
- 200+: PRs per month now, against eight to 20 per month until last year
- 6x lower: PR revert rate at Tano than at PostHog, mostly because the team fixes forward
- about 30: PRs merged a day at Tano, with no human code review for experienced engineers
- $8,000+: monthly cost of the author's usage at API rates, against one 20x Claude Max plan

## What it reports

- Output: eight to 20 PRs a month before; 200+ a month at Tano. PostHog was 2.4x Bloomberg; Tano is 11x PostHog.
- He runs 3-5 workstreams at once; agent runs take 1-2 hours per feature, with an HTML summary generated for every PR.
- Code review: a Claude Code GitHub Actions reviewer runs on every PR and is usually the only review. Median time to merge is under an hour; revert rate is 6x lower, mostly from fixing forward.
- Failures: an agent assumed every currency has 100 minor units (the Bahraini dinar has 1,000 fulūs), fixed within an hour; a blocking migration on a 25 GB, 6 million-row table stopped ingestion and deploys; a migration missed guardrails and paid creators twice.
- Each new failure type is added to the review agent's prompt, for example a list of large tables where blocking migrations are refused.
- Two agent-architecture migrations at Tano took weeks; a comparable PostHog migration took a year.
- Costs to the person: context switching, reactive "thrashing", loss of shared context once reviews stopped, mental exhaustion by mid-afternoon; he leaves his laptop at work with agents running overnight.
- Gergely Orosz notes an industry-wide twofold rise in PR output on average this year, and that iteration speed means little without revenue or product fit.

## How they got it

Personal essay built on the author's GitHub history at PostHog (May 2021 to January 2025) and Tano (January to September 2026), with rough figures for Bloomberg. Charts compare PRs per month, PR size, review ratios and time of day.

## Limits

- One engineer; PR counts are an easy-to-game metric, and PR size and scope differ across employers.
- The comparison mixes AI with company size, culture and role (founding engineer with no product manager).
- No measure of business outcomes, defect cost or customer impact.

## Why it matters for companies

The essay shows that agent productivity depends on removing the old bottleneck, human code review, and that the risk moves into production incidents such as duplicate payments. Large firms cannot accept that trade as made here, but the method transfers: capture each failure type as a rule in an automated reviewer, and decide explicitly which systems may fix forward. It also flags costs that rarely appear in business cases: engineer fatigue, a bus factor of one per product area, and token budgets.

Original: https://newsletter.pragmaticengineer.com/p/how-software-engineering-is-changing