Codex is leaving the code editor: the shared agent behind ChatGPT Work

The important story in OpenAI’s ChatGPT Work launch is not that a coding assistant gained a few more features. It is that the company is trying to move the agent harness built for software development into the rest of knowledge work—without pretending that every user needs the same interface.

That is the through-line of Latent Space’s conversation with Akshay Nathan, who leads core product engineering at OpenAI. The episode is useful because it explains the product logic behind the launch rather than treating it as another model release. 1

Nathan’s career gives the strategy a clear shape. Before OpenAI, he worked on products intended to make software capabilities accessible to people who did not write code, including work at Airtable. His argument is that large language models supplied a missing layer: users can now describe an outcome without understanding all the machinery underneath it. 1

The surprising evidence came from inside OpenAI. Non-developers in functions such as finance and marketing were using Codex for their own work, and some felt that the tool gave them a new “superpower.” That changed the product question. Instead of asking how to make a better tool for programmers, the team had to ask how to make the same underlying capability useful to people who work in documents, spreadsheets, planning, research, and operations. 1

The episode’s show notes put the scale of the opportunity in context: there are roughly 100 times more people who use code than people who can write code. They also report that OpenAI said Codex and ChatGPT Work reached 10 million users combined less than two weeks after the July 9 launch. That is a claim attributed to OpenAI, not an independently audited usage figure, but it explains why the company sees knowledge work as an expansion of the coding-agent market rather than a separate product category. 1

The most consequential technical detail in the conversation is easy to miss: Codex and ChatGPT Work share the same underlying agent harness. Nathan describes the distinction as a product-layer decision, not a fork in the core capability. The two experiences can therefore inherit improvements in tools such as computer use, plugins, and artifacts while presenting different defaults to different users. 1

For a developer, Git state, repositories, diffs, and sandbox behavior may need to be visible and opinionated. For a knowledge worker, those same primitives can be distracting or meaningless. ChatGPT Work can instead foreground the requested outcome, the relevant context, and the artifact produced along the way.

This is a more important design choice than the label on the product. A separate “AI for finance,” “AI for marketing,” and “AI for engineering” would encode today’s job titles into tomorrow’s software. But AI is already making those boundaries less stable: an engineer writes a strategy document, a marketer prototypes a site, and an operations lead may need to inspect code or data. Nathan’s position is that the products should guide people without boxing them into an identity-based workflow. 1

The conversation becomes concrete when it turns to artifacts and Sites. The shift is not simply from a text response to a longer text response. It is from asking a question to producing something that can be inspected, edited, shared, and used.

Nathan describes Sites as more than a prototyping feature. Inside OpenAI, he says, a corporate-finance team has begun using Sites for recurring reports that historically lived in slide decks and spreadsheets. A site can combine explanation, interaction, data, and presentation in one object. That makes it a plausible replacement for some familiar office formats—not because Excel or PowerPoint are suddenly obsolete, but because an agent can assemble a higher-bandwidth work product without requiring the user to know every feature of the underlying application. 1

That also changes the collaboration loop. A traditional assistant returns an answer that a person forwards or rewrites. An artifact preserves more of the context and reasoning embodied in the work. The episode discusses the possibility of shared, multiplayer artifacts partly because forwarding a summary is lossy: the recipient receives the conclusion, but not necessarily the context that produced it.

The product challenge is then not “how many things can the agent do?” It is “how much of that capability should the user see?” Nathan describes the central UX tension as simplicity versus capability. A general-purpose agent needs enough surface area for a user to specify an outcome, verify the tools and sources being used, and discover new possibilities. It must also get out of the way before the interface turns into a control panel for every internal operation. 1

The next expansion is temporal. The episode’s discussion of persistent computer environments, scheduled tasks, memory, and personal agents points toward a system that can continue a project across sessions rather than starting from a blank chat every time. The examples are deliberately ordinary: budgeting, meal planning, workouts, household administration, and other recurring tasks. 1

That direction creates a different value proposition from one-off automation. The agent is useful not only because it can complete a task, but because it can retain the context needed to notice what should happen next. Memory becomes valuable when it produces timely, relevant continuity; it becomes intrusive when it collects facts without knowing when they matter.

Sub-agents create a similar trade-off. Parallel workers can make a complex task faster, but exposing every branch can overwhelm the person who asked for the result. The product therefore hides much of that machinery by default and leaves deeper controls to power users. This is consistent with the shared-harness strategy: the system can become more capable underneath while the default experience remains relatively simple.

Nathan’s most useful warning comes at the end of the conversation. If agents make it easier to create code, sites, documents, and plans, teams can also become better at producing activity that looks like progress. More outputs, tokens, commits, or pull requests do not automatically mean that the underlying decision or product improved.

He suggests thinking in terms of “quality at-bats”: opportunities to make meaningful progress, rather than raw counts of work produced. That distinction matters because AI reduces the cost of trying things. The bottleneck shifts toward choosing the right problem, supplying grounded context, recognizing a good result, and stopping when an attractive artifact does not survive contact with reality. 1

The same shift may reshape technical roles. Nathan expects more people to become generalists with deep specialties, while ideas and taste become more valuable precisely because implementation is cheaper. But the episode does not present the agent as a substitute for judgment. It presents a system that can widen the range of people able to build and investigate—provided they remain responsible for deciding whether the result is actually useful.

That is why Codex’s move into ChatGPT Work matters. The product is not merely adding non-programming templates to a coding tool. OpenAI is testing whether one agent substrate can support many kinds of work while adapting the visible workflow to the user. If it succeeds, the competitive question will be less about who has the best chat window and more about who can turn a general model into a reliable, persistent work environment without confusing activity for outcomes.

Read the full episode and transcript on Latent Space.