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.