Why “Everyone Is a Builder” Is a Bad Product Idea in the AI Era

An English SEO-friendly adaptation of an interview with OpenAI Codex lead Andrew Ambrosino, covering how AI changes product development, why...

Introduction

As AI makes software easier to prototype, many product teams are asking a new question: do companies still need product managers, designers, and engineering roles in the same way?

Andrew Ambrosino, the lead of OpenAI’s Codex team, has a clear answer. AI may reduce the cost of implementation, but it does not remove the need for judgment. In fact, when almost anyone can create a working prototype, the harder question becomes not “Can we build this?” but “Should we build this, and is this the right form?”

This article is an English SEO-friendly adaptation of the original Chinese article published by BAAI Hub / Founder Park. The original piece is based on a conversation between Lenny and Andrew Ambrosino about Codex, product work, AI coding agents, design process, and the changing role of PMs.

Source note: The original page mainly included promotional banners, QR codes, and follow-up/contact images. No core product screenshot, workflow diagram, code block, or technical table was available for direct reuse in the article body, so no images are inserted here.

When Implementation Gets Cheaper, Taste Becomes More Important

Product development used to start before implementation

Traditional product work was built around one assumption: implementation was expensive.

That is why teams invested heavily in research, strategy documents, product requirement documents, wireframes, and prototypes before writing production code. Even in agile teams, the basic idea was similar. You tried to remove as much risk as possible before committing engineering time.

AI changes that assumption.

Today, people can describe an idea to a model and quickly turn it into a working interface, a prototype, or even a feature that looks close to production-ready. That is exciting, but it also creates a new problem: too many things can be built too quickly.

The problem is no longer only “Can we build it?”

In an AI-native company, many people may independently build different versions of the same feature. These prototypes may all look usable. Some may even look polished enough to ship.

But appearance can be misleading.

A prototype that looks finished may still be early exploration. It may not match user needs. It may not fit the product system. It may solve the wrong problem, or it may create more complexity than value.

That is why Ambrosino argues that the product process has been inverted. Implementation is no longer the most expensive part. The scarce resource is taste.

What does “taste” mean in product work?

Taste is not only about visual style. It includes several kinds of judgment:

Aesthetic judgment: whether something feels clear, polished, and appropriate.
System judgment: how a feature fits into the larger product.
Strategic judgment: whether the team is moving in the right direction.
Communication judgment: whether the idea is being expressed in the right format.
Interaction judgment: whether the motion, flow, and behavior match the intended meaning.

In a world where many things are possible, taste is the ability to decide what is worth doing, what should be ignored, and how the final product should feel.

PRDs are not dead, but the medium matters

A common AI-era claim is that PRDs are dead and prototypes are now the only useful artifact. Ambrosino disagrees.

The point is not that documents are useless. The point is that teams must choose the right medium for the right kind of thinking.

If a team is trying to clarify an ambiguous product direction, a document may still be the best format. If the goal is to stress-test a new interaction pattern, a prototype may be better. If the team needs alignment around trade-offs, a short memo may work better than a polished demo.

The danger is skipping thinking just because building is easy.

A polished prototype can create the wrong anchor

Before AI, the visual quality of a prototype often signaled its stage in the process. A rough wireframe meant early exploration. A polished product-like interface usually meant the idea had already passed research, design, and product review.

AI breaks that signal.

Now an early idea can look finished. That can make teams anchor too quickly on one direction. People may ask, “Can we ship this?” before the team has agreed whether the idea is even correct.

The solution is not to avoid prototypes. The solution is to stay clear about where the work is in the product process.

Roles Are Blending, but Product Managers Will Not Disappear

“Everyone is a builder” can erase real expertise

AI makes it easier for people to cross role boundaries. Product managers can prototype. Designers can write code. Engineers can explore UX ideas. This is a positive shift.

But Ambrosino warns against taking the idea too far.

Saying “everyone is a builder” can sound empowering, but it may also flatten important disciplines. Product management, design, engineering, research, and operations each contain hard-earned practices. Removing role boundaries should not mean pretending those practices no longer matter.

Knowing how to write a few lines of code does not make someone a full product thinker. Just as knowing how to use a spreadsheet does not make someone a finance professional.

The useful change is collaboration, not role elimination

The best version of this shift is not that roles disappear. It is that collaboration becomes easier.

People can now learn from adjacent disciplines faster. A designer can explore implementation details without waiting for an engineer. A PM can test an interaction instead of only describing it. An engineer can bring product ideas to life more directly.

The boundary becomes less about “you are not allowed to touch this” and more about where each person’s deepest expertise sits.

Codex shows stronger role overlap than many teams

The Codex team is a technical product team, so role overlap is especially visible. Designers often understand engineering language. Product managers understand technical trade-offs and can write code. Engineers are closer to product thinking than in many older workflows.

But that does not mean everyone does the same job.

A person’s role is better understood as the average of what they do across many tasks. A designer may spend time coding and thinking about product strategy, but their center of gravity may still be design. A product manager may prototype, but their core value may still be alignment, judgment, and decision-making.

PM work becomes more like zone defense

In a noisy AI product environment, product managers become curators, connectors, and alignment leaders.

When many people are producing ideas, someone has to notice gaps, reduce duplication, connect related efforts, and decide what belongs in the product. This is less like owning a narrow checklist and more like zone defense.

A good PM asks:

Where is the team over-investing?
Where is nobody paying attention?
Which ideas should be merged?
Which features should be removed?
Which prototypes are promising but not ready?
What needs a document instead of a demo?
What needs a demo instead of a document?

In other words, the PM role becomes more about judgment and coordination than controlling every step of the process.

The most valuable people can carry ideas from concept to product

Ambrosino describes a valuable team member as someone who combines deep skill with taste. They can move an idea forward, understand when it is good, and distinguish signal from noise.

That matters because AI can generate a large amount of output. More output does not automatically mean better product work. Teams still need people who can decide what deserves attention.

In an “infinite token” world, producing more content is easy. Avoiding low-quality work becomes the real discipline.

Codex Released Three Months Earlier Might Have Failed

AI product timing is now tied to model capability

AI product planning is difficult because the underlying model capability changes quickly.

A product idea may be bad today and good three months later, even if the interface stays almost the same. The missing piece may not be UX, positioning, or product strategy. It may simply be that the model is not yet capable enough.

That makes long-term planning harder. Near-term planning can be specific. Longer-term planning needs to stay loose, because too much detail becomes false precision.

A feature can be too early without being wrong

Ambrosino uses Codex as an example of timing. A product shape that works after a model improvement might have failed if released earlier.

This changes how teams should interpret failure.

Use We0 AI

Crea un sitio de presentacion y capta leads en minutos

Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.

Sin título-1

Disposición

Llenar

Radio

generando

In the past, a failed launch often revealed something about the product form, market message, or customer need. In AI products, failure may also mean the intelligence layer was not ready yet. The same product may need to be tried again after the model improves.

Match the product form to model capability

One lesson from AI coding tools is that the product should match the capability of the model at that moment.

If a tool pretends to be fully autonomous before the model is ready, it may feel unreliable. If the product keeps the user in the loop, asks questions, and makes its limitations visible, it may feel much more useful.

That is why different coding agents can succeed with different interaction models. The best product form is not always the most ambitious one. It is the one that fits what the model can actually do.

The same product can be relaunched as intelligence improves

AI product teams may need to revisit old ideas more often than traditional software teams.

A feature that failed once should not always be discarded forever. If the core blocker was model capability, the right move may be to put it aside, wait for a capability jump, and test it again.

This makes bottom-up exploration important. A mature product team still needs a mechanism for experiments that might challenge the current product direction.

Codex as a base camp for work

The vision described around Codex is broader than a narrow coding editor. It acts more like a base camp where people start work, manage tasks, coordinate agents, and interact with other tools.

In this view, Codex does not need to replace every specialized tool. It can work with them.

For example, a professional tool such as Premiere Pro can remain the best place for video editing. Codex can still help by understanding files, writing extensions, and coordinating actions around the tool. The future may be less about one AI app replacing every SaaS tool and more about agents operating across the tools people already use.

Writing Code Matters Less; Deleting Code Matters More

“AI wrote the code” is no longer the right measurement

Many teams still ask what percentage of a product’s code is written by AI. Ambrosino suggests that this question is becoming less useful.

If AI can generate most or all of the code, the more important distinction is whether the code was generated under supervision or without supervision.

The real challenge is not only creating code. It is keeping the system simple, safe, maintainable, and aligned with the product goal.

Models are good at adding complexity

Current models often add more code, more options, and more surface area. That can be helpful when building quickly, but it becomes dangerous when the goal is long-term product quality.

A great engineering agent should know when to delete code. It should know when not to build a feature. It should recognize when two ideas should be merged, when an abstraction is wrong, and when a request adds more complexity than value.

That is a harder problem than code generation.

Feature requests also require taste

The same issue appears in product requests. A model can generate feature ideas, analyze feedback, and propose implementations. But it still needs guidance on which features matter.

Good product work involves saying no. It also involves combining related requests, reframing vague needs, and removing unnecessary options.

This is another reason product judgment does not disappear in the AI era. It becomes more important because the volume of possible work increases.

AI agents are becoming management tools

For individual contributors, AI agents can act like workers that need instruction, supervision, and review. For managers, the pattern is similar, just at a different scale.

Instead of typing every character, a person may define goals, review outputs, manage multiple agents, and refine the system over time.

That makes the skill of management more broadly relevant. Even an IC may now manage automated workflows, agent tasks, and feedback loops.

Personal workflows may become future product features

Many people are building personal AI workflows: daily digests, Slack summaries, automated research, project trackers, memory systems, and task filters.

At first, these workflows are messy and personal. Over time, shared patterns emerge. When enough users create similar systems, the product team can turn those patterns into first-class product experiences.

This is one way AI products may evolve: from individual hacks to shared product primitives.

Key Takeaways

AI lowers the cost of implementation, but it increases the importance of product judgment.
A polished prototype no longer proves that an idea is ready to ship.
PRDs are not dead; teams need to choose the right medium for the job.
Product, design, and engineering roles are blending, but expertise still matters.
Product managers remain important as curators, aligners, and taste-keepers.
AI product timing depends heavily on model capability.
Coding agents need to learn not only how to write code, but also how to remove complexity.
The most valuable people can turn ideas into products while knowing what not to build.

FAQ

What is the main idea of this interview about OpenAI Codex?

The main idea is that AI changes the economics of product development. When implementation becomes cheaper, teams need stronger product judgment, clearer taste, and better coordination to decide what should actually be built.

Does AI mean product managers are no longer needed?

No. The article argues that PMs still matter, but their work changes. Product managers become more responsible for curation, alignment, prioritization, and deciding which ideas deserve to become real product experiences.

Why is “everyone is a builder” considered a bad idea?

The phrase can be useful if it encourages people to contribute across boundaries. But it becomes dangerous if it erases the value of product management, design, engineering, and other professional disciplines.

What does “taste” mean in AI product development?

Taste means the ability to judge what is good, useful, coherent, and worth building. It includes visual judgment, interaction judgment, system thinking, communication, strategy, and the ability to separate signal from noise.

Are PRDs still useful in the AI era?

Yes, when they are used for the right purpose. A PRD or memo is still valuable when a team needs product clarity, strategy, or alignment. A prototype is better when the goal is to test an interaction or make an idea tangible.

Why can an AI product fail if launched too early?

AI products depend heavily on model capability. A feature may have the right product shape but still fail because the model is not yet smart or reliable enough to support the experience.

What is the biggest engineering challenge for AI coding agents?

Generating code is no longer the only challenge. A harder problem is teaching agents to reduce complexity, delete unnecessary code, avoid bad abstractions, and decide when not to build something.

Related Tools

OpenAI Codex: OpenAI’s AI assistant for coding, research, and productivity work.
Codex Web: Official OpenAI documentation for delegating coding tasks to Codex in the cloud.
Codex App: Official documentation for the Codex desktop command center.
OpenAI Codex GitHub Repository: The open-source Codex CLI repository from OpenAI.
Claude Code: Anthropic’s agentic coding tool for terminal, IDE, desktop, and browser workflows.
Figma: A collaborative interface design platform used for design, prototyping, and product collaboration.
Linear: A product development and issue tracking tool often used by software teams.
Notion: A workspace for docs, knowledge bases, project planning, and team notes.

Summary

This article explains how AI changes product development by making implementation cheaper and faster. The key problem is no longer whether a team can build something, but whether the team has enough judgment to build the right thing.

The interview also makes a practical point about roles. AI can blur the boundaries between PMs, designers, and engineers, but it does not remove the need for professional expertise. In fact, stronger taste, clearer product thinking, and better coordination become more valuable.

For AI coding tools like Codex, the next challenge is not only writing more code. It is managing complexity, deleting unnecessary work, and helping people build systems that stay coherent over time.

The core conclusion: AI makes building easier, but it makes product judgment more important.