Claude Code turned every engineer into three. Now companies need more product thinkers

Justy So Anthropic told its growth team to hire more product managers, not fewer, because Claude Code turned the engineering org into a team that ships at three times headcount. And the article's entire argument hinges on that one detail: the bottleneck moved from the IDE to the people deciding what to build.

Cody Right, which is a claim I actually want to poke at — not because it's wrong, but because it's being used to argue something much bigger.

Justy Yeah, go on.

Cody The productivity claim is real. Spec-driven workflows do compress timelines. Kiro's two-week-to-two-days story, the 30-person rearchitecture that became 6 people in 76 days — those are checkable. But then the article jumps to 'therefore, product management is the new bottleneck,' and that's where I think it's conflating two different problems.

Justy Okay, what's the gap?

Cody The gap is: tripling engineering output doesn't automatically mean the PM funnel is the bottleneck. It might just mean the teams that deployed these tools properly — the ones with specs, with clarity, with a real understanding of what they're building — tripled their output. The teams that didn't do that work still have the same problem they had before: ambiguous requirements, shifting goals, architecture decisions made in Slack.

Justy So you're saying the article is assuming everyone's running Kiro and Amazon's discipline, and most people aren't.

Cody Exactly. The article makes a really clean argument for the teams that have already solved the spec problem. For everyone else, the bottleneck is still 'can the engineer and PM agree on what the thing is,' not 'can we ship it fast.' And Anthropic hiring more PMs makes sense — because Anthropic has already solved that problem internally. It doesn't tell you much about the industry.

Justy Fair. But I think the author is making a different move, actually. He's not saying 'the PM funnel is the new bottleneck for everyone right now.' He's saying 'this is the structural shift the industry is living through.' Like, the teams that have already deployed agentic workflows at scale — the ones reporting these compression numbers — they have moved the constraint. And everyone else is about to.

Cody Mm-hm.

Justy So the timing of the message is 'get ahead of this.' Not 'this is already true everywhere.' That's a different read.

Cody Okay, I can live with that framing. But then the part that actually gets me is the fundamentals claim. The article says fundamentals matter MORE, not less, because agents write 70% of the code and can't reliably trace their own assumptions about thread safety or transaction isolation. And the engineer who can read the diff and catch that is the leverage multiplier.

Justy Yeah, that's the line I actually think is really smart.

Cody It IS smart. But it's also setting up a false binary. It's not that fundamentals matter more or less — it's that the COST of not knowing them went up. An engineer who doesn't understand memory ownership can miss a subtle bug in their own code; the same engineer can miss a subtle bug in agent-generated code, and now it's shipped to production before anyone catches it because the review loop is faster and volume is higher.

Justy Right, right.

Cody So the bottleneck is still review discipline. The article frames it as 'fundamentals are leverage now,' which is true, but it's true in a way that might scare junior engineers who don't have fundamentals yet. The real message should be: if you're shipping faster, you need to review faster AND more carefully, and that requires knowing what you're looking for.

Justy Okay, so the article's right about the shape of the problem — review is the new writing — but it's leaning too hard on 'you need fundamentals to do this well' when the actual constraint is 'you need review discipline, and fundamentals help you review better.'

Cody Yeah. And here's the thing: that's not a reason for a junior engineer to give up on shipping. It's a reason for teams to invest in code review culture, in pairing senior and junior engineers on reviewing agent output, in building tools that surface the kinds of bugs fundamentals would catch.

Justy Which is infrastructure work, not research. Which is exactly what you said we'd see.

Cody Exactly.

Justy But — and I think this is where the author has a real point — there's also a career signal here. The engineer who DOES internalize fundamentals, who DOES read specs before code, who DOES talk to customers... that engineer is not waiting for a ticket to arrive. They're generating ideas, validating them, scoping them, and then spinning up the agent to build. And that person is going to have a very different decade than the person who's waiting for the PM to hand them a ticket.

Cody That's the part that landed for me, honestly. It's not that the PM funnel is broken right now. It's that the engineers who are already thinking like product thinkers — who are already doing customer work — they're the ones who are going to spend the next decade doing the interesting work. And the engineers who treat product as 'someone else's problem' are going to be watching agents write tickets.

Justy Which is such a visceral way to say it.

Cody It is. And I don't think it's wrong. But it's also not new — that's been true for five years. What's NEW is the speed. The engineer who would have spent two weeks building the wrong thing now finds out in two days because the agent compressed the iteration loop.

Justy So the feedback loop just got tighter.

Cody Yeah. Which means the cost of building the wrong thing is the same, but the time to find out is now measured in days instead of weeks. That's the structural shift.

Justy And that's actually more important than the PM shortage narrative, I think.

Cody Way more important. The article leads with the PM thing because it's a clean story — Anthropic hired more PMs, therefore the bottleneck moved. But the real story is: teams that have deployed agentic workflows are finding out faster whether they built the right thing, and that feedback loop is now the constraint on how fast they can ship.

Justy Which means the engineer's job is not 'write more code.' It's 'figure out what to build, prove it matters, spin up the agent, review the output, ship it.' That's five different skills.

Cody Five different skills, and the engineer who has all five is the one who's going to be interesting to work with. The engineer who has one of them — even if it's 'can write code really fast' — is going to be fungible.

Justy Fungible to an agent, basically.

Cody Yeah.

Justy Okay, one more thing. The article mentions Routines — scheduled, persistent agents that run on a cadence or overnight. And OpenClaw, which got temporarily suspended and then partially reinstated. That's not nothing, right?

Cody It's the thing that makes the whole story land. Routines turn the agent into a team member that works while you sleep. That changes what 'shipping' means. You're not just writing code anymore — you're defining a routine, reviewing what it produces, and letting it run at scale.

Cody Good news for people who like building things that matter. Bad news for people who just like writing code.

Justy And better news for product teams who finally get engineers in the room thinking about the customer.