Codex Is Not Just a Coding Tool: OpenAI's Plan for an Agent That Behaves Like a Teammate

Embiricos joined OpenAI about a year ago, after five years running his own startup and an earlier stint as a product manager at Dropbox. What stands out most, he says, is the speed and ambition: every founder claims to move fast with a high talent bar, but working at OpenAI made him rethink what those words mean. The explosive growth of Codex itself is his clearest example, and it has left him feeling he has to be far more ruthless with his time.

He describes an organization that is genuinely bottoms-up, because nobody knows which capabilities will arrive, which will work technically, or which will land with users. So the team is humble and empirical, and tries things quickly. Aiming is still part of the process, but it is fuzzy: a research lead told him that OpenAI can talk well about a year or more ahead, and about the next weeks, but not about the awkward stretch in between.

Embiricos adds that this model depends on talent. He was struck by the individual drive and autonomy of his colleagues, and he cautions that few companies could simply copy the approach without adjusting it. He also believes that even if model progress stopped today, the industry would still be well behind on product.

Concretely, Codex is OpenAI's coding agent, available as an IDE extension or a terminal tool. You pair with it to answer questions about code, write code, run tests and handle the thick middle of the software development cycle. Embiricos says that is only the beginning: the aim is a teammate that joins ideation and planning, and then validation, deployment and maintenance.

His analogy is a smart intern who refuses to read Slack and never checks Datadog or Sentry unless asked. However capable such an intern is, you would not trust them to work alone. A good human teammate, by contrast, learns how to be prompted, takes on starter tasks, and eventually decides for themselves what is worth doing, and he calls that last stage proactivity.

He thinks proactivity is critical to OpenAI's mission, because AI products are hard to use: you have to work out when the model could help, and if you aren't prompting it, it isn't helping. People prompt AI tens of times a day, he says, but could usefully get help thousands of times. The goal is an agent that is helpful by default without the developer having to think about invoking it.

Embiricos says Codex has grown explosively since the launch of GPT-5 in August: well over 10x, and in fact about 20x. Its models now serve many trillions of tokens a week and are the team's most served coding model. Other major API customers are also beginning to adopt them, which he credits to a tightly integrated product and research team that iterates on the model and the harness together.

The first version, Codex Cloud, gave each task its own computer in the cloud so you could run many in parallel. But it was hard to configure, hard to give the model the tools to validate its changes, and hard to learn to prompt. Embiricos likens it to hiring a teammate you are never allowed to call. That is still where he thinks delegation is headed, but it was hard to adopt first.

The unlock was to land in a more intuitive place: an IDE extension or CLI where the agent works interactively on your machine inside a sandbox. It can run commands without any environment setup and ask you when something won't work in the sandbox. Over time, configuring the agent becomes a byproduct of working with it, which prepares the ground for later delegation. OpenAI's own dogfooding had pointed the other way, he notes, because its staff are used to reasoning models and parallel, asynchronous prompting.

Models matter, and Embiricos points to GPT-5.1 Codex Max, which shipped the previous Wednesday. It is roughly 30% faster on tasks the earlier model handled, and smarter at higher reasoning levels. He sees it carrying the mantle of the Karpathy-style tweet about handing it the gnarliest bugs. But he says the team has moved from thinking only about the model to thinking about the whole agent.

He describes that stack as a reasoning model, an API that serves it, and a harness around it. Compaction, the feature that lets Codex work continuously for 24 hours or more by moving into a fresh context window, needed all three. The model must understand it, the API needs an endpoint for it, and the harness must prepare the payload. He expects more features to work this way.

A second advantage is focus. Coding products have very different tool harnesses, some built around semantic search and others around specialized tools, and training a model for every variant is slow. Codex deliberately just uses the shell, made safe with a sandbox the model is used to operating in. Building and tuning the three layers in parallel, with a unified product and research team, is what Embiricos credits for much of the acceleration.

Asked how OpenAI wins, Embiricos says the answer is a teammate or super assistant that people don't have to learn. If a research lab ships a startling new capability every week, no human can keep up with all of it, so the assistant should simply know how to help. He thinks chat is the right interface when you don't know what to use AI for, with a GUI to go deep in specialist domains such as code.

He then lays out what he calls a plausible, one-year-horizon argument. A super assistant has to do things, and models do things best when they can use a computer. Clicking through screens is slow and unpredictable, so the most effective way for a model to use a computer is to write code. To a non-technical user, he suggests, it may never matter that a coding agent is involved, the way nobody thinks about whether they are using the internet.

Code also has a property that pointing and clicking lacks: it is composable and interoperable. Teams want configurable behavior, such as different crash-analysis prompts for different sub-teams, and deterministic guarantees about what an agent may do. The aim is that anything an agent does often is stored as a reusable competency, so scripts one agent writes can be used by teammates. Embiricos thinks coding agents are already pretty great, but agents outside coding are still very early.

On what this means for engineers, Embiricos expects code to become even more ubiquitous and therefore to need more people who are competent with it. As a product team, the question he keeps asking is whether a feature leaves people more accelerated or more confused about their role. Writing code is one of the most fun parts of engineering, he notes, while reviewing AI-written code is less fun, so his team ships code review features and works on letting agents validate their own work.

That reasoning shapes micro decisions too. In Codex web, for example, he argues that a reviewer should see the image preview of what the agent built before the diff. On higher levels of abstraction, he sees people already using plan-driven development, where you write a plan.md with the agent and it works longer if the plan has verifiable steps. He is unsure spec-driven development will win broadly, since many people dislike writing specs, and jokes about "chatter driven development".

He also offers a deliberately provocative picture of a future solopreneur: a mobile app of vertical videos, one per idea the agent has, where you swipe left or right and hold to give voice feedback. He stresses OpenAI is not building it. The serious point is that an agent consuming signals from every system and surfacing ideas in the lowest-effort way is plausible, as is the mixed-initiative model that made autocomplete such a successful AI product.

Today the real bottleneck for that kind of world, he says, is validating and reviewing code. People already at-mention Codex in Slack to ask why a bug is happening or why a metric moved, and get answers straight back. But once it writes code, a human has to check it. So he wants people to configure coding agents to be much more autonomous in those later stages.

As a product manager, Embiricos says he mainly feels more empowered. He cites Scott Belsky's idea of compressing the talent stack: when one person can do more, a communication boundary disappears and the team gets more efficient. He now asks Codex questions, uses it to understand what is changing, and finds prototyping often faster than writing specs. He has also seen a lot of throwaway code, such as an interactive data viewer built just to understand a dataset.

Designers show the same pattern. One vibe-coded an animation editor in order to build the coin animation in Codex, and then checked the animation into the repo. The design team has a standalone, vibe-coded prototype of the Codex app, and good ideas get turned into real pull requests. Depending on their comfort with the code base, the designer lands it or an engineer helps them finish.

The Sora Android app is his biggest example. It was built in 18 days to reach employees and went to the public 10 days later, 28 days in all, with two or three engineers, and it became the number one app in the App Store. He calls it a bit of easy mode, since Codex is very good at porting from an existing platform: it studied the iOS app, wrote plans of work, and implemented them. On the Atlas browser, one engineer told him work that once took two to three engineers two to three weeks now takes one engineer a week.

Embiricos expects the boundaries between roles to blur, but gradually. He compares it to writing Swift without having to speak assembly: people will still need to understand the details of what they build, but which details will change as abstraction layers rise, now reaching natural language. For a while, humans will curate which connectors and components the agent needs to master, and he imagines a later stage in which Codex tells you how to set itself up in a repo.

On the second-order effects, he doesn't think ideas are worth as much as some people believe, because execution and distribution remain hard. If he could choose only one competency, it would be a meaningful understanding of a particular customer's problems. A founder with a good network of customers underserved by AI tools is set, he says, while someone who is merely good at building websites will have a harder time.

To measure Codex's progress, he watches early retention such as day-7, and signs up from scratch to feel like a new user, because a power-user tool can drift toward over-solving for deep adoption. The team also reads Reddit and Twitter constantly. Reddit, he says, is more negative but real, and its upvoting mechanics give better signal about what matters.

Embiricos worked on Atlas for a while but no longer does. His story begins with his screen-sharing, pair-programming startup, which joined OpenAI to build a contextual desktop assistant. He thinks it is annoying to supply all your context to an assistant, so it should understand what you are trying to do, and he still sees Codex as a contextual assistant that starts from coding.

A browser makes that context a first-class matter, he explains. Much work happens on the web, and from within the rendering engine the product doesn't have to hack other software's accessibility trees or rely on slow, unreliable screenshots. He likens it to the contextual action button in video games, where the game knows what you are attempting and can simply help.

The deeper reason is notifications. If an agent helps you thousands of times a day, pushing a thousand alerts would be unbearable. Instead, if you are looking at a dashboard where a metric has dropped, an agent could surface its view of why, and a possible fix, right there. Users also keep clear control: open something in the AI browser if you want the agent to act on it, and use another browser if you don't.

Most real traction outside engineering is still coding-adjacent, such as data analysis, and the team is staying focused on coding for now. For anyone trying Codex, Embiricos's advice is unusual: give it your hardest real problem, such as a bug whose cause you can't find, rather than a trivial test. Just keep it to one question or task, since it won't build a unicorn business for you. Language support roughly tracks how common each language is in the world.

His tip for beginners is to try several things in parallel and build trust the way you would with a new teammate: ask it to understand the code base, form a plan with it, then have it implement bit by bit. Doing so teaches you how prompting Codex differs from other models. He says it is a powerful agent and model, but it is a little different to prompt.

For people planning careers, he first says to be a doer: students and new graduates can now accomplish far more, and when hiring early-career people he looks at how productive they are with the latest tools. He adds that systems engineering and communication still matter, since humans will configure agents. One Atlas engineer made Codex verify its own work by repeatedly asking why it couldn't and fixing it. Finally, he says the frontier of any field is worth pursuing, because agents will be weaker there and working on it forces you to use them.

Inside OpenAI, Embiricos says, Codex writes much of the code that helps manage training runs and their infrastructure. Its code review has caught some interesting configuration mistakes. The team is beginning to see glimpses of Codex being on call for its own training: today humans watch the graphs of a run, which he calls babysitting, and he describes the idea of Codex evaluating how those charts move over time and acting when a system goes down or an error appears.

On AGI, he focuses on when the hockey stick appears in the acceleration curve. A current, underappreciated limiting factor, he says, is literally human typing and multitasking speed, together with the need to review everything an agent produces. Unblocking those loops means rebuilding systems so agents are useful by default and can validate their work.

He doesn't expect this to be binary. Next year, he imagines, a new startup could adopt a stack where agents are largely self-sufficient, while a firm with many complex legacy systems, like SAP, would need to replace or update them over time. So early adopters should see hockey-stick productivity starting next year, larger companies in the years after, and somewhere in that fuzzy middle the gains flow back into the AI labs, which is when he thinks we reach AGI territory.