Tara Seshan, product lead for OpenAI’s Codex and ChatGPT Work, said the ability to produce a long document no longer proves that someone has thought deeply about a problem.
Speaking in an 81-minute interview on Lenny’s Podcast, Seshan said AI can now generate a replacement in minutes that matches the original in length, structure, and polish. She offered a second blunt view as well: building for today’s models will fail, and building for what you think models will look like a year from now will fail too.
From chat to co-pilot to persistent agents
Seshan broke AI product development into three stages.
- The first is chat, where a user asks and the model answers.
- The second is the co-pilot phase, where AI helps with work in a specific setting such as coding.
- The third is the persistent AI coworker, or agent, which stays online, retains context, and handles complex tasks with more independence.
She said the boundary between human work and AI work is moving upward at visible speed. What began as help with the next line of code is turning into workflows where a person sets the objective and the system carries out the execution in the background.
She pointed to Codex on desktop, described as an agent command center, and to ChatGPT Work, which spans spreadsheets, reports, and business analysis, as examples of the same shift: execution is being handed over to AI.
Her phrasing was simple. Agents row; humans steer.
The human role narrows to five core jobs
Once AI takes on the rowing, Seshan said, people are left with five core responsibilities:
- setting direction;
- owning outcomes;
- judging quality;
- adding point of view and expression;
- collaborating with, caring for, and motivating teams.
That is the division of labor she sees emerging inside AI-enabled work.
Why OpenAI dropped the one-year roadmap
Seshan said product teams run into trouble both when they optimize too tightly for present-day model limits and when they bet too heavily on what a model might become in a year.
If a team spends its time designing around current weaknesses, those product mechanisms can lose value as soon as the next model update lands. But building around assumptions about a much later model is also risky, because the product ends up resting on guesses that may never materialize.
She referred to a well-known line in tech: the model you use today is the dumbest it will ever be. In her telling, the contradiction is that many people say this out loud yet still schedule work as if the current model were the stable baseline.
OpenAI’s response, she said, was to cut the rigid one-year roadmap and shrink planning to a two- to three-month window. In the interview, she said products need to be built for what models will be able to do in the next few months; building for the present or betting on a distant horizon both miss the mark.
That does not mean product planning turns into random trial and error. Her point was that product teams have to stay tightly synced with research. The teams need frequent communication and a shared understanding of which capabilities are likely to improve next, and roughly when.
Once that picture is clear, product iteration can move in step with the underlying technical progress. Rather than a fixed plan on a wall, the roadmap becomes something closer to live navigation.
At OpenAI, long documents are now written for the author
Seshan said she came from Stripe, where writing culture placed heavy weight on polished briefs. Her habit used to be to refine a document until it was clean before circulating it.
At OpenAI, she said, that changed. Long documents are now mainly written for herself. A complete packet of material no longer stands in for deep thinking, and the idea of the long memo as proof of intellectual rigor has lost its force.
Working prototypes, A/B test data, and user feedback have taken that place.
She did keep one rule. When a proposal is about 70% done, she brings it to the people whose approval is needed and finishes the last 30% with them. Her reasoning is practical: when a plan looks perfect, other people’s ideas bounce off it. Leave rough edges, and they are more likely to join in shaping it.
What can be outsourced to AI, and what cannot
Seshan divided writing into two groups.
- Reporting-style writing — weekly updates, summaries, abstracting, and format conversion — can be handed to AI and automated where possible.
- Thinking-style writing — project logic, route selection, and judgment over disputed questions — should not.
Her reasoning was that outlining, drafting, and revising are themselves part of how a person clarifies thought. If AI writes the text, the words may appear on the page, but the act of thinking through the issue may never happen in the writer’s mind.
To keep her own thinking sharp, she follows two rules: if a document is going to be read by a certain number of people, she reads it that many times first; if a meeting will consume a given amount of collective time, preparation should add up to at least the same total.
As AI lowers the floor, ambition becomes the separator
Seshan said AI has pushed down the barriers to design, analysis, code, and prototyping. Work that once required a team can now, at least in broad outline, be pushed forward by one person.
That changes what separates one knowledge worker from another. Her answer was ambition.
The strongest operators, she said, do not stop at automating repetitive work. They use AI to stretch the boundary of what they themselves can do. In that shift, the job of a product manager — and, more broadly, a knowledge worker — moves away from ceremony such as scheduling, documentation, and review, and toward identifying the few questions that decide success, making sharp hypotheses, and testing them quickly.
Part of the job is also to raise the ambition of the team. When someone proposes a plan, the value is often in asking whether the ceiling can be pushed higher and whether the same objective can be reached 10 times faster.
Three internal questions at OpenAI
In the interview, Seshan described three lines of internal questioning that she said line up with repeated self-checks inside OpenAI.
The first asks whether the work can be done faster.
The second asks whether the level of ambition is high enough, and whether the target can be pushed up.
The third is harsher: do you personally use the product from the moment you wake up, are you already dependent on it, and have you put your full taste and judgment on the line in deciding whether it is actually good to use?
Host Lenny also asked why, over the past three to six months, conversation on Twitter appeared to shift from Claude Code toward Codex, and what had changed internally. Seshan’s answer was that nothing had changed. The team had been using the product heavily itself, collecting feedback, and iterating fast all along. The only difference, she said, was that outsiders had started noticing.
Knowledge work does not have a clean compile-and-test loop
Seshan closed with a contrast between coding and knowledge work.
Code can be judged by outcome. An agent edits code, tests run, and the result passes or fails. Knowledge work is different. If a presentation says the success rate is 90%, that figure alone is not enough. You need to see the source inputs and the reasoning path that produced it.
That, she said, is why ChatGPT Work is designed not simply to hand over a polished final artifact. It surfaces sources, inputs, and partially completed work so the user can keep control through the process.
Her example was a customer meeting 20 minutes away. If ChatGPT Work produces slide 8 in 2 minutes and 30 seconds, the user should still be able to see what material the system went through.
As tools become widely available and baseline capability converges, Seshan’s argument is that the real differentiator is whether a person can steer — and where they want to take the boat.