Two more posts crossed my feed on Saturday saying the same thing from different microphones. Andrew Chen (@andrewchen) tweeted five words on May 3: “bullish on the PM role quietly becoming the most important role in tech again.” 140K views, 1.4K likes, 203 replies, 166 retweets. Aakash Gupta expanded it on LinkedIn the same day, with 1,210+ reactions and 71 comments, citing the actual numbers behind it from Boris Cherny’s Claude Code team at Anthropic.

Both posts make the same argument from different angles: when building got cheap, the person who decides what to build became the last scarce resource.

The Boris Cherny numbers that don’t have a PowerPoint version

Aakash cited the Claude Code team at Anthropic. The figures Boris Cherny himself, as team lead, has shared:

• 5 Claude instances running in parallel.
• 20 to 30 pull requests shipped per day.
• Cowork, a complete product for non-engineer users, built in roughly 10 days.
• +70% productivity per engineer, measured while Anthropic tripled headcount over the same period.
• PMs review live working software at 9am every day. By noon, they have killed 80%. Whatever survives ships that Friday.

PMs at Anthropic do not write traditional PRDs anymore. They review running prototypes on screen and decide which three of the fifteen earn the second pass. The decision lives at the cadence of a workday, not a sprint.

The number nobody quoted

It shows up two paragraphs from the close of Aakash’s post, no bold: “AI PM offers at OpenAI, Anthropic, and Google DeepMind now run past $1M total comp.” Past one million. A PM with a calibrated kill rate by 9am earns what a VP of Engineering earned five years ago.

The market priced the new scarcity before the chorus finished arguing about it. When a PM took six weeks to land a release, that decision could be hired at PM salary. When a PM makes the same decision every morning against working software, that decision is worth what building the software was worth five years ago.

The chorus around Aakash’s post

Seventy-one comments, several with weight. Worth reading the full chorus, not just the agreeing voices:

• Kath Champion: “The bottleneck didn’t move to PM. It moved to decision quality under speed.” When building takes 45 minutes, bad decisions scale instantly and prototypes become distraction. The skill is not building fast. It is looking at multiple working versions and knowing which is genuinely the right call.
• Palash Somani, shorter: “Speed didn’t make decisions easier, it just made bad decisions cheaper to recover from.” The cost of being wrong used to be measured in sprints. Now it is measured in hours.
• Saeed K dropped the useful objection: framing people and functions as “bottlenecks” is wrong unless they are an actual dysfunction. Partly right. The bottleneck isn’t the PM, it is the judgment. The judgment can live in different seats depending on the case. What matters is that it is explicit and named, not that it carries a job title.
• Rakesh Kothari flagged the inverse risk: “Beware of shadow PMs, i.e. senior engineers who think they have product taste but unfortunately don’t.” When building goes cheap, anyone who can build feels entitled to decide.
• Yasir Ahmed Sheikh landed it in enterprise terms: “In enterprise AI, judgment isn’t just valuable, it’s load-bearing.” A bad call in a consumer app gets fixed next sprint. A bad call embedded in an ERP workflow gets inherited by every downstream process.
• Rohit Gajaraj dropped the sharpest short line: “Taste without exposure is just opinion.” Judgment is not trained by reading Jobs or Karpathy; it is trained watching 50 customers use the product and killing the 47 that did not work.

Five cycles since 1990. Cheap layer changes. Scarce layer always moves up one floor.

I have been in computing for 36 years. Started in 1990, at 15, on a Commodore 64 and a Texas Instruments. Five times I have watched this exact move. The structure is always the same: a layer goes cheap, the layer above goes scarce. The industry then spends three to five years complaining about the new bottleneck, until somebody puts a price on it.

Early 1990s — assembly to high-level languages. Writing code went cheap. Designing the right system in the first place stayed brutal. The industry spent the decade complaining “we can’t find architects” before accepting that the scarce resource was no longer the coder.

Mid 2000s — on-prem to cloud (AWS). Provisioning a server went from six weeks to six minutes. Architecture choices for a distributed system stayed exactly as hard. Five years of complaining about “no cloud engineers” while the real scarcity was architecture judgment, not SDK familiarity.

Late 2000s — manual QA to test automation. Automation made running tests cheap; the criterion of what to test and which signal to watch never automated. Teams ended up with 8,000 green tests that did not catch regressions because nobody had decided which 200 were worth the wall-clock.

2010s — custom to SaaS. Tooling cost collapsed. The decision of what to integrate, into which process, under whose ownership, did not collapse with it. Companies ended up with 47 paid SaaS, 12 actually used, and 35 contracts auto-renewing because nobody was assigned to make the call.

2026 — model to harness. Generating 15 prototypes in a morning is now a coffee-break exercise. Choosing the 3 worth scaling is the part that did not get faster. Anthropic put a price on it. The rest of the industry has not yet.

Five cycles. Same move. The difference this time is not the direction. It is the speed: the previous cycle took five years to reveal where the bottleneck landed. This one revealed it in six months.

The sister piece from April 14

Three weeks ago I wrote about taste debt. That piece covers the downstream side of the problem: what accumulates when humans get pulled out of the execution loop too early — the deliverable’s quality decays because nobody reviews with judgment. This piece covers the upstream side: when building got cheap, deciding what to build became the new scarcity.

They are sister pieces. The first measures the quality of finished work. The second measures the quality of the choice of which work to do. They carry equal weight; both require explicit and named judgment; and they share the same failure mode: nobody in the room feels comfortable saying “no” to something already built and looking polished.

What we do at IQ Source about this

AI Maestro names which 3 of the 15 prototypes are worth scaling. The audit does not produce more prototypes. It produces the short list and the criteria behind each call, in a format that survives the manager change or the senior engineer who thinks they know. It is the institutional version of what Boris Cherny does at 9am inside Anthropic, translated for a company that does not yet have 5 Claude instances running in parallel but soon will.

Tech Partner applies when your product is not just a customer of this problem but also a producer of it. Software companies whose roadmap is the moat have a different governance question to answer: how the criterion of “what we build” gets documented and versioned, so the next person in the seat can defend the decision six months later. The answer does not live in slides. It lives in the list of what we killed and why.

On April 27 I wrote that code is not cheap: the real cost lives in the decisions about what code to have. Runtime commoditized three weeks ago. Harness revealed itself as engineering on May 1. And today, the role that decides what runs on top of the harness revealed itself as the new scarce resource.

Five questions for your next product standup

If your team is coming off a week where nobody believes the right calls got made, there are five questions worth pushing before the next one:

1. Volume. How many prototypes did your team ship last week, and who decided which 1 or 2 to keep? If the answer is “we don’t measure that,” the bottleneck has already moved past building, but nobody on the team knows it.
2. Kill rate. What is your prototype kill rate? Below 50% and you are not building enough. Above 95% and you may be building, but you are picking poorly at the front end.
3. Time of day. Who on your team reviews running software at 9am, not slides at 2pm? If the answer is “the slides are for alignment,” the alignment is being paid for with the opportunity cost of the 14 prototypes nobody reviewed.
4. Defendability. Is there a named owner of “what we shipped” who can defend the call six months later? Not “the committee approved it.” Defend, with the list of what was killed and why.
5. Pay. Are you paying for confidence (resume, prior titles) or for demonstrated calibration (track record of what they killed, not just what they shipped)? Anthropic just rewrote the ceiling on the second group. Worth checking before the next offer goes out.

If your next release has 30 prototypes in backlog and nobody has decided which 3 ship, you have the right problem. If nobody is building 30, you also have a problem, but a different one. A ninety-minute conversation gives you a clean view of your real kill rate, where the bottleneck actually lives, and which decisions have been sitting in backlog for three months waiting for somebody to make them with judgment. info@iqsource.ai.