When AI takes the oars, product work becomes steering

Tara Seshan leads product for Codex and ChatGPT Work at OpenAI. Before joining OpenAI, she spent more than six years at Stripe and led product at Watershed. Her conversation with Lenny Rachitsky, published on August 30, runs for about 82 minutes and asks a practical question: when AI takes over more execution, what remains for the people building products? 12

Seshan's answer is a change in the shape of work. AI products have moved from chat to agents, and the next phase may be persistent coworkers that work alongside people over time. The human contribution then shifts from doing every task to choosing the direction, setting the standard, and keeping the feedback loop moving.

Seshan describes three eras of AI products. The first is chat: a person asks a question and receives an answer. The second is the agent era: the product carries out a task on the person's behalf. The third, in her description, is a persistent coworker that can keep working with a person and help get things done. 2

The important change sits in the relationship, rather than in a new label for a model. A chat session is usually a short exchange. An agent can run a defined loop. A coworker is expected to retain enough context to return to unfinished work, accept feedback, and contribute again at a higher level of abstraction.

Seshan connects this idea to an "overhang": the distance between what AI can do and what people actually ask it to do. The distance persists because capability alone does not create a useful workflow. People still have to decide what to delegate, what information an agent may access, and what quality bar the result must meet.

That distinction gives the episode a sharper thesis than "AI will automate more work." Automation describes a task disappearing from a person's hands. A persistent coworker changes how the person organizes work around the task.

Seshan's central metaphor is a shift from rowing to steering. Agents handle more of the tactical work, while people point the work in a direction and decide where it should go next. As agents take on larger tasks, human steering moves up through layers of abstraction: from a line of code, to a feature, to a product goal. 2

The metaphor becomes concrete when Seshan describes what still belongs to a person. Someone has to make an opinionated call about the future they want, even when two different product directions could both function. A person also remains accountable for whether the finished product is good and whether it does what the team intended.

Seshan compares software to filmmaking rather than real estate. Spending resources on a film does not guarantee that the film will be good. The same applies to software that an agent can assemble quickly: the code may run, yet the product still needs a point of view. Human taste determines what the product feels like, which trade-offs it accepts, and which users it is meant to serve. 2

She also places care and human connection in this category. An agent can perform work for a team, but it does not remove the human responsibility to relate to other people. As execution becomes cheaper, judgment and care carry more of the work's meaning.

The shift to steering changes the product manager's job without erasing its core. Seshan says the essential PM work remains the same: identify the most important question about a product, test it with users, study the result, and feed that result into the next iteration. The change is that the old paperwork around that loop carries less weight when the market and the underlying research move quickly. 2

Seshan prefers a prolific, empirical approach. Instead of writing a long plan for an uncertain future, a team should make its core hypothesis precise and reach a testable version quickly. The point is not to replace thinking with speed. The point is to spend thinking on the question that can change the product's direction, then get evidence from use.

AI also expands who can act on an idea. Seshan says effective users do more than automate rote work. They use the tools to widen the set of things they can build, prototype, analyze, or communicate themselves. A person who can move between product sense, design, code, and analysis can turn an idea into a working test with fewer translation steps.

That new range creates a pressure on ambition. Seshan argues that people can become more ambitious with AI, and may need to become more ambitious because easy work is becoming easy for everyone. The PM's role therefore includes raising the ceiling for the team: asking whether a larger goal can be attempted sooner, and reminding colleagues that a capability they once treated as out of reach may now be available to test. 2

Fast-changing model capability creates a specific product-planning rule. Seshan says teams fail when they build for where models are today, and also when they build for where they expect models to be in a year. Her proposed horizon is roughly two to three months. 2

The rule is a balance between two errors. A product designed around today's limitations may hard-code work that a near-future model can already handle. A product designed around a one-year forecast may depend on abilities that arrive late, change shape, or never arrive. The two-to-three-month horizon keeps the team close enough to current research to build something real while leaving room for the next capability step.

For product teams, the rule changes what a roadmap must contain. A roadmap needs a short feedback cycle and a clear view of the model capabilities underneath the experience. The team must ask which parts of the interface help the model do more, and which parts merely preserve an old workflow after the model has moved on.

The persistent-coworker idea can sound like an intelligence problem. Seshan spends equal time on a more ordinary constraint: access. Local agents are useful partly because they can reach the data on a person's machine. A cloud agent needs infrastructure that gives it controlled access to the systems where work actually happens. 2

Her comparison is straightforward. A colleague locked in a room without Google Docs, Slack, or the company database could contribute very little. A cloud agent with the same isolation will also struggle, regardless of how capable its model is. Data permissions, cloud infrastructure, and reliability determine whether the agent can complete a real task.

The next step is collaboration among agents. Seshan describes an early pattern in which colleagues shared screenshots of their individual Codex sessions to show how they reached a result. That exchange reveals the limit of one-person, one-agent work: the work exists, but the team cannot easily inspect, extend, or combine it.

Her preferred direction is closer to a multiplayer game. Several people steer a group of agents together, while the agents handle more of the tactical work. That model requires shared context, permission boundaries, visible progress, and a natural way for one person's agent to review or continue another person's work. 2

Seshan's argument leaves builders with four questions. What direction does a person still need to choose? What work can an agent carry through a meaningful loop? What evidence returns quickly enough to improve the next attempt? What data and permissions let the agent work in the same environment as its human colleagues?

Those questions separate a persistent coworker from a chat box with a longer prompt. The model supplies capability, but the product supplies continuity, access, feedback, and accountability. As more execution moves into the agent layer, the scarce work shifts toward choosing a worthwhile future and making a team capable of reaching it.