Implementation Abundance Inverts Product Work

Sources#

• Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think
• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• OpenAI Codex lead on the new shape of product work
• The state of AI in 2026: On the road to ROI

Summary#

Andrew Ambrosino's (OpenAI Codex) framing of what agentic coding does to product process: when anyone can stand up any feature by talking to a model, implementation stops being the scarce, expensive, derisk-it-up-front step — so the whole process runs backwards. The old process spent documents, research, and prototypes to derisk implementation before building, because building was expensive and "you can really only afford to build once." Now implementation is abundant across every medium, so "everybody's building everything" — Ambrosino estimates a needed feature has "90 different uncoordinated teams" implementing it at once. The costly work migrates downstream to curation: "of those 90 attempts, what's good about these? What should we fold into other aspects? How should we frame this?" That curation is taste — "dare I say taste" is his answer to what replaces implementation as the expensive part. This is the OpenAI-side, process-level statement of the shift the wiki tracks as Verification as the New Bottleneck and "deciding what to build is the bottleneck skill".

Evidence note. practitioner-opinion — a frontier-lab product leader's account, not measurement. But it converges with empirical sources (Returns to Expertise in Agentic Coding, Planning / Execution Division of Labor) that find domain/product judgment, not coding, predicts success.

The inversion, precisely#

The two states Ambrosino contrasts:

	Old process	Inverted process
Expensive step	Implementation	Curation / taste
Why	You could only afford to build once, so you derisked up front	Building any feature is ~free; the 90 builds already exist
Up-front work	Docs, research, prototypes to derisk before building	Skip straight to many parallel builds
Scarce input	Engineering capacity	Judgment: what's good, what to fold in, how to frame, what medium

"It's backwards, and it's not that people are doing fundamentally different roles or that skill sets have vanished — it's that it's backwards. The implementation is actually not the expensive part anymore."

Curation is not the same as prototyping-instead-of-PRDs#

Ambrosino is careful to separate his claim from the popular "PRDs are dead, prototypes are in" slogan — which he says he does not believe (see the pushback recorded on Prototype Over PRD). The inversion is not "always jump to a prototype." It is: because every medium's implementation got cheap, the load-bearing skill is picking the right medium for the point you're making and then curating what the cheap builds produce. Sometimes the right medium is still a document. The abundance is what makes curation — not creation — the constraint.

What "taste" means here (the curation faculty)#

Taste, in this thesis, is the curation faculty applied under abundance, and Ambrosino explicitly de-couples it from aesthetics (citing the "Paul Graham has great taste and wears cargo shorts" line). Its components:

• Systems thinking — how a build fits the whole; what theme it belongs to.
• Direction — "where are we going," what the goal is "if we can build anything."
• Presentation — how to frame and present the information.
• Semantic fit — whether an interaction/animation matches the meaning it's supposed to convey ("too snappy for what it's trying to say").
• Medium selection — which artifact makes the point.

Because taste is now the binding constraint, it becomes the hiring bar: "high agency, high taste" people who can "take an idea from idea to done." Ambrosino's steering test for an IC given unlimited tokens: "determine what's signal, what's noise, in a world of infinite content."

A second OpenAI leader, same conclusion, plus a mechanism (July 2026)#

Ambrosino's thesis was one leader's account of one org. Akshay Nathan — a different OpenAI product leader, running productivity engineering — reaches the same conclusion a month later without citing it (Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI, practitioner-opinion), asked what his team is bottlenecked by:

"I think the bottleneck becomes, like, ideas and taste. I think because anyone can build now… you're always gonna be bottlenecked by the amount of ideas and amount of things that you're doing at any given time."

Convergence between two leaders inside the same company is weak evidence — shared culture, shared tooling, shared "unlimited tokens" caveat (the third open question below). What Nathan adds that Ambrosino doesn't is a failed attempt to automate the bottleneck away, and a diagnosis of why it failed:

"The one automation that I would love to work and it doesn't work is bring me new ideas. Somehow LLMs are just not it. One interesting part about ideas is they're not in a vacuum… they usually come from somewhere — in product development they're coming from talking to users, or reacting to friction that you're seeing, or feedback, building on some foundation that you already had planned out."

That is the context-advantage explanation, not the capability explanation — and it bears directly on the second open question below ("does curation migrate into the model?"). Nathan's answer is a negative observation with a reason attached: ideas fail to generate not because the model lacks an idea-generating faculty, but because it lacks the grounding stream (user conversations, observed friction, prior planning context) that ideas condense out of. On Context Advantage, Not Taste's framing that makes the bottleneck a closable gap — pipe the grounding in — rather than a permanent human faculty, which is a materially weaker claim than "taste is the bottleneck" sounds. Nathan himself keeps the human in the loop for exactly that reason: "there will always be value in these generalists closing that loop and coming up with those ideas that are grounded in that feedback."

The same inversion, argued from the other side of the org (DHH, August 2026)#

Ambrosino's inversion is stated from inside a frontier lab. DHH reaches the same conclusion from a 20-person software company and names the constraint more bluntly (Lex Fridman #501, 2026-08-26, practitioner-opinion). Asked why established products with huge user bases are not visibly accelerating:

"As soon as you're having human teams work together on something, the bottleneck is rarely implementation. It's human bandwidth and communication. When you have a product manager and a couple of designers and a VP above them and a CTO above them, and everyone wants to be part of the shaping process because we're all justifying why we're here, that's where all the productivity goes to die."

And the second half, which is this page's thesis restated as a diagnosis: "Most organizations don't know what they want. They don't know how to make it better. They're not bottlenecked on implementation. They're bottlenecked on ideas… on vision… on taste. And if you don't have those elements in excess of your implementational capacity, it doesn't help. So you can make a lot of shitty ideas come true, then what?" His existence proof for the negative case is the incumbent with unlimited implementation capacity that shipped mediocre software anyway.

The uncomfortable corollary he draws, and this page does not. If the bottleneck is coordination, the multiplier is only available to whoever touches the agents directly: "to get that magical 10X, 100X… productivity boost, you have to interact with the agents directly, and you cannot intermediate that bandwidth with another human because it's simply too slow." That is an argument that the inversion favours very small teams and solo builders structurally, not just temporarily — and it is a disliked conclusion in his own telling ("on the one hand, that's a bit of a bummer. I mean, I like humans"). It is also unmeasured, and self-serving for someone whose case study is a distro he largely builds alone; the counter-evidence is that his own multi-person products, Basecamp and Hey, are the ones he says accelerate least.

A third naming, and a limit on the inversion (Ng, August 2026)#

Andrew Ng gives the bottleneck a name from outside the labs — "the product management bottleneck" — and the same diagnosis: "the cost of building has plummeted and so the challenge is shifting to deciding what to build" (Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think, Silicon Valley Girl, 2026-08-28, practitioner-opinion). His remedy is neither Ambrosino's taste nor Nathan's grounding stream but the outermost of his three loops run by hand: "learn AI, build fast, and talk to customers" — people who "can talk to customers get a sense for the taste of judgment on what to build and then build with AI and iterate quickly." He reports living the abundance side ("I find myself building things… every week, every weekend") and then puts a limit on it that this page has not carried:

"It turns out building a company is still really, really hard… over a weekend I can often build an LLM wrapper, build a simple application, but I wish it was that easy to build a large company… building something meaningful often takes either real technical depth and or deep customer insight and integration with customers. And yes, we can now use AI to code something in a few hours, but that's a small piece of the puzzle."

The limit is about time, not judgment. The inversion says the expensive step moved from implementation to curation; Ng says the expensive step is still expensive in calendar terms — "the really complex software that takes us like months… maybe years," or the customer insight that "takes a lot talking to people reading facial expressions surveys doing that over and over" — so cheap implementation collapses the weekend project without collapsing the company. That is what The Solo-Founder Shift measures at 399 days and what DHH concedes from his own products, and it argues for "single threaded leadership" over the sample-widely instinct abundance invites: "sampling widely but then having that focus for an individual to go really deep in a couple sectors." Everything here is one builder's self-report, from someone whose portfolio (AI Fund) is the sampling strategy he is cautioning against.

The population reading: how far the abundance got (McKinsey, August 2026)#

The state of AI in 2026 (McKinsey / QuantumBlack, 2026-08-25, empirical but wholly self-reported; 1,719 respondents in 97 nations) is the first source to test this page's premise outside a frontier lab, and it separates the premise from the thesis.

The build capability diffused. 32% of respondents report their organization decided against purchasing at least one software product or feature because it could be built in-house with agentic coding tools (Exhibit 4) — 41% in technology, but 38% in energy and materials, 38% in professional services and 28% in engineering and construction. About two in ten organizations report scaling software coding agents, 31% at $1B+ revenue against 17% below it (Exhibit 3). Implementation abundance is no longer a property of the labs that make the models; it is a procurement fact across thirteen industries, and it has its own page at Build Instead of Buy Under Agentic Coding.

The tokens are not unlimited. About 20% of respondents report AI-related operating costs, including token costs, constraining their organization's AI use (Exhibit 8) — and the constraint is sharpest exactly where this page's mechanism would run hottest: AI high performers report cost-constrained use of software coding agents at 18% against 6% of everyone else, the only tool class where the leading cohort reports more constraint than the rest (Exhibit 14). Michael Chui names the mechanism in the article's own commentary: AI "isn't 'too cheap to meter' when it comes to agentic software development," because token consumption has grown faster than per-token price has fallen.

The inversion itself is untouched. The survey counts decisions and scaling phases; it never observes parallel builds, curation cost, or the shape of a product process. Nothing here confirms or denies that the expensive step migrated to curation. What it converts is the precondition — from a lab affordance into a population fact with a price attached.

Connections#

• The Solo-Founder Shift — the inversion's limit, measured: implementation got cheap and the first thing the freed-up founder buys is still a person, at a median 399 days
• AI-Native Organization — the same inversion stated as founder advice: with the tool nearly free to build, Tan revises "scratch your own itch and hope it's a market" to "scratch your own itch because scratching itches is nearly free," and lets demand from others reveal which audience-of-one tools were companies. Problem selection as the remaining scarce input, from the accelerator side rather than the lab side
• Crystallizing Agent Work into Workflows — a partial answer to the curation-cost question from an operations domain: curation is paid down by promoting what exploration proved into deterministic workflow, making it a one-time investment per recurring pattern rather than a recurring tax — but only where patterns recur, a scope condition exploratory product work may not meet
• Andrew Ambrosino — articulates the inversion
• Design by Selection — an inside-one-team instance: when Opus 4.5 accelerated the Claude Code engineers, Nate Parrott — the team's sole designer, delivering at his old pace — became the constraint, and built Claude Design to catch up. Cheap implementation relocates the expensive step onto whatever role hasn't been accelerated. He also states the thesis outright: "the work that matters most moves earlier in the process"
• Verification as the New Bottleneck — the general form: when generation is cheap, judgment/verification is the scarce resource; this is its product-process face
• Engineer PM Convergence — "as code becomes cheaper, deciding what to write becomes more valuable" (Cat Wu) is the same bottleneck-shift; this page is its OpenAI-side, process-level statement
• Research Taste as the Human Bottleneck — the AI-research cousin (taste as the residue AI can't yet absorb); this is the product-work cousin
• Building Is Cheap, Arguing Is Expensive — the same "cheap building relocates the hard part" logic, applied to settling debates; here applied to the whole process
• Prototype Over PRD — the position Ambrosino refines: not "prototype replaces PRD," but "abundance makes medium-choice + curation the skill"
• Polish No Longer Signals Readiness — a direct consequence: the 90 cheap builds all look prod-ready, so polish stops signaling stage
• Role Averaging, Not Role Elimination — who does the curating, and why "zone defense" coverage matters when 90 uncoordinated builds appear
• Dogfooding as Product Discipline — how the curating taste is trained: relentless first-hand use
• Compute Allocator — curating 90 builds is allocation at the level of a whole feature exploration
• Harness Shrinkage as Models Improve — implementation abundance is harness-shrinkage seen from the product-process side
• Returns to Expertise in Agentic Coding — empirical support: domain/product understanding, not coding, is what predicts who succeeds once building is cheap
• Context Advantage, Not Taste — what the new bottleneck is: Andrew Ng argues the "taste" curation depends on is an information asymmetry rather than a faculty, which makes the inverted process's expensive step perishable rather than permanent
• Playbook Boundary Conditions: the Devil's-Advocate Substrate and the Prototype's Edge — promotes the medium-selection rule to the general answer for where prototype-over-PRD breaks down: pick the artifact whose observable surface covers the risk; the PRD survives only where none does
• Standardize the Infrastructure, Not the Tools — the claimed effect of making the substrate available org-wide: sales, finance and HR building "n-of-1" software without an engineering ticket
• Prototype Fidelity After Cheap Polish — the same inversion read from the design-process side: when polish is free the expensive step moves to methodology (which fidelity, what feedback) rather than to curation
• DHH (David Heinemeier Hansson) — the small-company statement of the same inversion, with the harsher corollary that the multiplier does not survive being intermediated by another human
• The Three Loops of AI-Native Building — Ng's version of the inverted process: the outer loop (talk to customers) decides what to build, and it is the loop that stays slow — his limit on the inversion is calendar time, not judgment
• Build Instead of Buy Under Agentic Coding — the procurement-side consequence, measured on a population: a third of 1,719 respondents report declining a software purchase because agentic coding could supply the feature. It carries the cost bound this page's premise does not assume
• Printing Press Software Democratization — the supply side of the same abundance: the 90 uncoordinated builds exist because building is now literacy, not craft. Cherny names domain knowledge as the scarce input where this page names taste; the two converge if taste is context, per Context Advantage, Not Taste

Open Questions#

• Curation of 90 uncoordinated builds is itself expensive and doesn't obviously scale — is there a point where the cost of curating parallel exploration exceeds the cost it replaced? ("zone defense" is Ambrosino's partial answer.)
• If taste is the bottleneck and taste is "just another capability" AI eventually masters, does the inversion invert again — does curation migrate into the model?
• The 90-uncoordinated-builds picture assumes abundant tokens and an agentic culture; how much of the inversion survives outside a frontier lab that gives everyone "unlimited tokens"? Partially answered (2026-09-22) by The state of AI in 2026: On the road to ROI (empirical, self-reported; 1,719 respondents in 97 nations, fielded May 4 - June 8 2026) — the first population-scale reading of the premise, and it splits in three. The build capability survives the trip out of the lab: 32% of respondents report deciding against a software purchase because the functionality could be built in-house with agentic coding tools, and the industry spread is narrow (41% technology, 38% energy and materials, 38% professional services, 28% engineering and construction, 17% public sector) — so this is not a tech-sector artifact, let alone a frontier-lab one. About two in ten report scaling software coding agents (31% at $1B+ revenue, 17% below). The unlimited-token premise does not survive: ~20% report AI operating costs including tokens constraining their use, and the bite is concentrated where the mechanism runs — the high-performer cohort reports cost-constrained coding-agent use at 18% against 6% of all others, the only tool where the leaders report more constraint than the rest, with Chui stating the reason (consumption growing faster than price falls). Outside the lab the abundance is metered, and the meter tightens as practice approaches the frontier. The inversion itself is untouched: the survey counts purchase decisions and scaling phases, never parallel builds, curation cost or process shape, so the specific claim that the expensive step migrates to curation remains unmeasured anywhere, inside a lab or outside one. What changed is that the precondition is now a population fact with a price attached rather than a lab affordance.

Sources#

• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH, Lex Fridman #501 (2026-08-26, practitioner-opinion): "the bottleneck is rarely implementation, it is human bandwidth and communication"; organizations are bottlenecked on ideas, vision and taste; the cannot-intermediate-the-bandwidth corollary

• OpenAI Codex lead on the new shape of product work — Ambrosino: "the implementation is actually not the expensive part anymore… it's taste"; the 90-uncoordinated-teams picture

• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI — Latent Space, 2026-07-28 (practitioner-opinion): Akshay Nathan reaching the same bottleneck independently, plus the failed "bring me new ideas" automation and the grounding-stream diagnosis of why it fails

• Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think — Andrew Ng interviewed by Marina Mogilko, Silicon Valley Girl (2026-08-28, practitioner-opinion): "the product management bottleneck," learn-AI/build-fast/talk-to-customers, and the building-a-company-is-still-hard limit

• The state of AI in 2026: On the road to ROI — Dan Tinkoff, Lieven Van der Veken & Michael Chui with Tara Balakrishnan, The state of AI in 2026: On the road to ROI (McKinsey / QuantumBlack, 2026-08-25, empirical, self-reported; online survey, 1,719 participants in 97 nations, fielded May 4 - June 8 2026, GDP-weighted). Cited here for Exhibit 4 (the 32% build-instead-of-buy figure and its industry spread), Exhibit 3 (coding-agent scaling by revenue band), Exhibit 8 (20% cost-constrained), Exhibit 14 (18% vs 6% on coding agents) and Chui's tokenomics commentary. Self-report, one respondent per organization, from McKinsey's own panel; COI — McKinsey sells AI transformation consulting. Full treatment at Build Instead of Buy Under Agentic Coding