The new bottlenecks in AI-era engineering are human, not process

The bottlenecks didn't disappear. They moved.

That's the core finding in Neil Kakkar's essay for The Pragmatic Engineer, which tracks his output across Bloomberg, PostHog, and Tano—an AI-native startup where he's the founding engineer. He went from roughly 8–20 pull requests a month at PostHog to 200+ at Tano. Eleven times more output. The old constraints—mandatory code reviews, communication overhead between engineers, waiting on product managers—are mostly gone.

But read past the multiplier. The new constraints are worth taking seriously, because they're fundamentally different in kind from the old ones.

Old constraints were external; new ones are internal

Waiting for a code review is annoying, but it has an accidental benefit: it forces a natural rhythm. You open a PR, you wait, you pick up something else, you get feedback. That rhythm created shared context. At PostHog, Neil describes reading every incoming PR as a way to stay aware of what his colleagues were building. At Tano, with 30 PRs merging per day and no mandatory reviews, that awareness is gone. The bus factor—the number of people who need to leave before a project stalls—has effectively dropped to one for large patches of the codebase.

The new constraints are cognitive. Thrashing is the word Neil uses: running so many parallel workstreams that you're context-switching more than you're building. The speed that makes it trivial to fire up a Claude session for every incoming bug is the same speed that makes it easy to drift from your sprint goals entirely. And unlike a review queue, you can't automate your way out of mental exhaustion.

The design problem is underrated

One detail that deserves more attention: Neil notes that AI-native startups are quietly deprioritizing design work, because AI can produce something that looks acceptable. The result, as he describes Tano's own situation, is a neo-brutalist site indistinguishable from dozens of others using the same off-the-shelf component kit. PostHog hired an artist and a designer among its first ten people, and the brand is unmistakable. That choice compounded. The equivalent choice at an AI-native startup is often not made at all, because there's no forcing function—AI fills the gap cheaply enough that no one feels the absence until later.

This matters for anyone building a product that has to earn trust or stand out in a crowded market.

What this means in practice

If you're building a small team around AI agents, the process changes you need aren't the ones that speed things up further. The ones worth making are:

• Protect shared context deliberately. If code reviews are gone, something else has to carry the information they used to carry. AGENTS.md files and architecture decision records aren't glamorous, but Neil's point about them is correct: they're how you keep the bus factor above one.
• Treat cognitive load as a first-class constraint. Neil's guardrail—leaving his laptop at the office so agents run overnight without him—is an engineering decision, not a lifestyle preference. The pacing problem is real and it doesn't self-correct.
• Be skeptical of the design discount. "Good enough" design is easy to rationalize early and expensive to fix later. The gap between a forgettable product and a memorable one is rarely technical.

The story of AI-native startups isn't that constraints disappeared. It's that the old constraints were mostly external and process-shaped, so they were replaceable. The new ones are human-shaped. That's a harder problem.

Sources

• How software engineering is changing: a tale of two eras (original)
• Found via the TLDR newsletter