The bottleneck moved to review, not to product management

On 13 April 2026 Andrew Ng described the change in one line: as AI agents accelerate coding, we are "more constrained by deciding what to build rather than the actual building." He named it the Product Management Bottleneck and carried it into his AI Dev conference at Pier 48 in San Francisco on 28 and 29 April, whose stated theme was the future of software engineering.

He is more careful than almost anyone else making this argument. He keeps saying that software engineering is the profession AI has hit hardest and that job openings are up. The second half needs a qualifier. Indeed's US software development postings index sat near 73 in April 2026 against a February 2020 baseline of 100, up from a trough of 61 in May 2025 but nowhere near the 2022 peak. The longer view is kinder to him: the Bureau of Labor Statistics projects software developer employment rising 15.8 percent from 2024 to 2034, over 267,000 jobs, with AI expansion named among the drivers of demand. On the jobs apocalypse Ng is right and the doomers are wrong. My problem is with the word bottleneck.

Cheap implementation exposed an old constraint

Ask any engineer who has shipped for a decade what killed their projects. It was not typing speed. In my years as an engineer and then a senior engineer in Shenzhen I never once watched a product die because the team could not produce code fast enough. They died because someone picked the wrong thing and nobody could prove it until the deadline arrived. Cheap implementation did not create that constraint. It removed the schedule that used to hide it. Build time was the alibi. Take it away and a bad decision surfaces in a week instead of two quarters. That is a real gain. Calling it a new bottleneck is the error. It is an old one with the lights switched on.

Review does not scale the way generation does

Generation scales with spend. Review scales with attention, one human at a time.

Google's 2025 DORA report found over 80 percent of technology professionals saying AI raised their productivity, that higher AI adoption tracks with a rise in both delivery throughput and delivery instability, and that 30 percent of developers report little or no trust in AI-generated code. Those are the same finding stated twice. Output went up. Confidence in it did not, so a person has to check.

METR's randomized trial from July 2025 cuts both ways. Sixteen experienced open-source developers took 19 percent longer with AI tools while believing it had made them 20 percent faster. Its February 2026 follow-up was wrecked by selection effects, with 30 to 50 percent of developers declining tasks they did not want to do without AI. METR now thinks developers are likely being sped up, while calling its own data very weak evidence for the size of it. The durable finding was never the percentage. It was the gap between how fast the work felt and how fast it was, because closing that gap is exactly what review is for.

The 30 percent AI takes is where reviewers were made

Ng's advice to individuals is to stop doing the 30 or 40 percent AI can automate and build skills for the other 60 or 70 it cannot. That is correct for anyone who already has the 60. The trouble is that the 60 is not taught anywhere. It is residue. You get it from having written the naive version yourself, shipped it, then been paged at three in the morning by your own bad assumption. Judgement is what remains after the boring work.

The Stanford Digital Economy Lab, on 12 August 2026, put employment for 22 to 25 year olds in the most AI-exposed occupations about 19 percent below where it would sit had it tracked their less-exposed peers, widened from roughly 15 percent a year earlier, and driven by reduced hiring rather than layoffs. Experienced workers show no comparable gap. Ng's optimism and that finding are both true. Together they describe a pipeline problem, not an apocalypse.

So here is the sentence: the constraint moved to verification, and verification capacity is manufactured by precisely the work now being automated. Answer that AI will review its own output and you have not moved the bottleneck, you have moved the liability. Any team that wants competent reviewers in 2032 now has to pay deliberately for the training that used to arrive free, attached to the ticket queue.

Also referenced

Andrew Ng, The Future of Software Engineering (AI Dev 26 x SF talk): https://www.youtube.com/watch?v=g8um2AEf5ZA

AI Dev 26 x SF, conference site (dates and venue): https://ai-dev.deeplearning.ai/

Andrew Ng, AI engineering skills map, The Batch, 14 Aug 2026: https://www.deeplearning.ai/the-batch/the-ai-engineering-skills-map

BLS: Artificial intelligence, information technology, and employment, 2024-34: https://www.bls.gov/opub/ted/2026/artificial-intelligence-information-technology-and-employment-2024-34.htm

DORA, State of AI-assisted Software Development 2025: https://dora.dev/dora-report-2025/

DORA, Balancing AI tensions (trust, throughput, instability figures): https://dora.dev/insights/balancing-ai-tensions/

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

METR, We are Changing our Developer Productivity Experiment Design, 24 Feb 2026: https://metr.org/blog/2026-02-24-uplift-update/

Stanford Digital Economy Lab, Canaries in the Coal Mine? August 2026 update: https://digitaleconomy.stanford.edu/news/canariesaug26/

Canaries in the Coal Mine? working paper (August 2026 PDF): https://digitaleconomy.stanford.edu/app/uploads/2026/08/Canaries_August2026.pdf