When Anyone Can Build Anything, Taste Becomes the Product Job

Ambrosino says the hardest thing for product leaders right now is that the process has inverted. Anyone can stand up almost any feature by talking to a model, and at OpenAI, where people have effectively unlimited tokens, everybody is building everything. Traditional product process assumed implementation was costly and tried to de-risk it up front with documents, research and prototypes.

He guesses there are around 90 uncoordinated attempts at any feature the company badly needs. That doesn't mean roles or skill sets have vanished, he says. It means the expensive part has moved from building to curating: what is good about each attempt, what should be folded into other features, how the idea should be framed, and even how many segments belong in a toggle.

Ambrosino pushes back on the slogan that PRDs are dead and prototypes are in. Because building is cheap, non-engineers are tempted to jump straight to a prototype, while engineers are tempted to write many documents not worth reading. The right move is to pick the medium for the point being made: a document for clarity about a vague area, a prototype to stress-test an interaction.

Lenny Rachitsky links this to the idea of the "primal mark", where the first stroke on a canvas shapes everything after it. Ambrosino adds that the old medium carried signal about where something stood in the process. A polished prototype now looks production-ready even when it is only an early exploration, which risks anchoring everyone on an idea that doesn't match where research or users are going.

Asked what taste actually means, Ambrosino notes a recent tweet making fun of people who reduce it to aesthetics, citing Paul Graham as someone with clear taste who wears cargo shorts. He agrees there is an aesthetic part, such as an animation that is too snappy for the meaning it should convey. But there is also a systems part: how something fits the whole, which theme it belongs to, how it is presented, and what the goal is if you can build anything.

On why frontier models are weak at design, he offers practical and harder reasons, and stresses he is not a researcher. Design is harder to grade than code, since a human sense of taste is part of the feedback loop, and labs have historically invested in skills that accelerate AI research, which coding does more directly than design. Those practical gaps, he expects, will close.

The murkier problems are more durable. Good design depends on culture and novelty, and he recalls how a wave of websites copied Linear's; a model that reproduces Linear's site every time is not impressive. Software engineering, by contrast, often rewards sticking to known patterns.

He also points to a deeper abstraction layer between design and code. A rebrand is shallow if it means updating 263 components one by one, but the deep version is capturing the shared semantics between things that look different. That abstraction layer still feels out of reach for today's models, he says, and the new paradigm of the Codex app itself came from human creativity.

Lenny raises a recent guest's argument that the design process is dead because things move too fast. Ambrosino says he and that guest probably agree on a lot, and that he was never a fan of the process as practised. He recalls the "case study factory" critique from his startup days, in which designers were taught to value the process above outcomes, as if going through it guaranteed quality and impact.

The process, he says, assumes implementation is expensive and you can afford to build only once, so you must exhaustively explore the problem and solution space first. Tools like Figma and Origami pulled interactive prototypes earlier. Now all of implementation can be pulled forward, and executives see a fully polished prototype and ask whether it can ship, when in fact the team is still at an early design stage.

Designers also gain new tools. Teams can try changes in the live product or A/B test them. Many companies also keep a "baby" version of their product, a drastically simplified codebase that approximates the main interactions and is quick to vibe-code against, which is ideal for asking what a sidebar or a group-chat pane might feel like.

His verdict is that the claim is both true and false. If you are tied to the day-to-day specifics of the old process, it is dead. But the overlay, knowing which stage of the process you are in, matters more than ever.

On the Codex team, Ambrosino says role collapse is more advanced than elsewhere at OpenAI, partly because it is a technical product for engineers. Designers speak engineering, and product managers write code; he notes a colleague, Alexander, has a computer science master's degree. He describes people as defined less by the fence between disciplines and more by the average of their work, so a designer's dot sits near design even if they also write code.

He is wary of taking this too far. Companies that announce they are getting rid of the product role, which he calls a terrible idea, risk throwing away a discipline with tested best practices and past failures. Not everyone can work on everything, in breadth or depth, which is why he thinks managers aren't going away, and every discipline has a skill component that engineers are prone to underrate.

What he welcomes is the end of gatekeeping tied to a specific tool. It is easier to switch roles, learn best practices and decouple effectiveness from mastering one tool. He himself spent years feeling he shouldn't be an engineer because he didn't care about assembly language or memorizing TypeScript syntax.

Asked about the size of the Codex team, he says the answer is somewhere between 10 and a few thousand, since model research and infrastructure all feed the product. The core desktop team has double-digit engineers, roughly half that in design, and a few product people. Teams are large and mostly individual contributors, with a shared trait of agency and taste.

For product managers he describes a "zone defense" borrowed from a conversation with Alexander. If two product people work too closely together, that is often a bad sign. Instead they spread out for company-wide coverage, guiding things from inception, and hire engineers who are product-minded. He adds that everyone is now both an IC and a manager, because even individual contributors steer agents rather than type code character by character.

On roadmaps, Ambrosino says his team isn't doing anything revolutionary. The shorter-term something is, the more detail it needs, and a nine-month plan has to stay hazy because added precision is false precision. Anything planned in November might have been true in December but isn't what happened.

What the team does need is a view of what models will be able to do and when. At his previous company he saw feature process break down once models drove features: the answer was to list everything of interest, prototype it all, ship what is ready, let the rest bake, and retry each idea whenever models take a leap. Whether features were good depended on whether they were smart enough, not on their shape.

He is confident the Codex app released in February would have failed if it had been ready in November, and says the only difference was the models. He sees the same thread in the in-app browser and from Operator to Atlas to Codex and ChatGPT: a similar feature re-released with different intelligence changes the outcome. He therefore urges people not to be stubborn that a feature is bad when it may just not be ready.

The original Codex release, a web product that took a task and went off to do it, was too early because it didn't do the task well enough. Claude Code then arrived running locally and asking questions, which fit where the models were. "We were too AGI-pilled for the moment," he says, and he adds that a product may need releasing six different times before it works.

Ambrosino says maintaining quality on existing features matters, but the team keeps a culture of bottoms-up exploration because Codex itself disrupted ChatGPT in some ways and will eventually be disrupted too. One team can't be equally good at disruption and maintenance, so the company has to design a process that allows both.

Asked about the latest frontier beyond loops, he jokes that loops are so last week. If you use last year's goalposts, he says, 100% of the product is already AI-written, so the real question is whether the code is supervised or unsupervised. He mentions experiments with autonomously developed software and overnight garbage collection of a codebase, and asks research to make models better at deleting code, since they tend to add complexity.

Fully autopilot development also needs models to decide which feature requests to build, ignore or group together, and which abstractions are right. He says the team isn't yet at the point of a loop that improves the app by listening to Twitter, Slack and email, though it is trying. He declines to say whether it will ever become a "win the market" instruction.

Ambrosino describes aligning his own Codex use with whatever problem the team has. First he used it to write the code that built Codex, then for product discovery, spreadsheets, internal deep research and coordinating a May release that introduced the in-app browser, computer use and artifact creation. Today he gets a morning brief from the Slack channels he is in, as a scheduled automation he coaches by telling the app what to emphasise next time.

He admits that setting this up works for him because it is product discovery, but ordinary users shouldn't have to figure it out. At minimum the app should explain how to do it, and if a connector is missing it will offer to add one. Lenny shares that Codex used computer use to click through the Google Cloud console to set up Pub/Sub triggers for an email-filtering app.

Ambrosino says personal workflows are a source of product ideas: when a theme keeps appearing, such as people building Obsidian or Notion setups as a memory palace, it should become a first-class feature like memory. The harder question is what becomes a primitive and what is just how you do your job. He calls that the same taste and judgment discussed earlier.

Browser work shows how unsettled the shape is. After Operator, agent mode and Atlas, the desktop app now has an in-app browser, originally for testing front ends, rebuilt on the stack behind Atlas with multiple tabs and enterprise security, as well as a Chrome extension. The open question is whether the browser is only for the agent or something people use daily, which raises dull but real issues like which keyboard shortcuts to follow.

On the vision, he says Codex began as a CLI and then as an app that was neither an IDE nor a chatbot. In January and February, internal users from marketing, comms, finance and legal adopted it even though it showed them code and asked for approvals. OpenAI tried adding Codex to the ChatGPT desktop app and Atlas for these people, but, annoyingly, nobody left the Codex app.

The lesson is that developer tool versus general knowledge-work tool is not a binary. People doing Excel work don't want git information, but the product can infer their work and grow complexity as needed, perhaps with modes. The team wants extensibility primitives in a general model deep enough for finance, science and legal.

Rather than a "super app", he calls it a home base where you start, end and automate work, using whatever tools you need. The app can connect to the Excel add-in instead of replacing Excel. He tells the story of in-house videographer Brent, who used Codex on Premiere Pro projects, and when file edits weren't enough, Codex built an extension for Premiere that it could then talk to.

In the show's "fail corner", Ambrosino says this may be the first time he hasn't felt like he was failing. He was a startup founder for a long time in heavily regulated spaces and ended up selling the company for parts, then joined another startup building AI tools in a locked-down industry where things kept not working. He says he failed for something like 10 to 15 years before reaching this point.

Even now, he says, there are many micro-failures, such as a proposed product shape that gets a 2,000-message Slack thread about how wrong it is. He sees that candor as the reason OpenAI's external products turn out well. In his lightning round he picks a children's book about a man who paints his house orange, which Lenny reads as a lesson in agency.

Asked which of product manager, designer or engineer is hardest, he says they differ and refuses to start a war. He sees fluidity as refreshing for people with agency, while some things shouldn't go away. In a clip after the recording stopped, he adds that people shouldn't get married to their exact process but to the outcomes they are uniquely able to deliver.