The OpenAI Codex Product Philosophy: How AI Engineers Are Shifting from Writing Code to Managing Agents

At the AI Engineer conference, before an audience of over 7,000 AI engineers, OpenAI's Romain and Alexander delivered an in-depth talk about "the future of AI engineering." They put forward a counterintuitive proposition: AI won't spell the end of engineers—rather, it will make "AI engineers" the new species that eats the world. This article distills the core ideas of the talk, along with the deeper logic behind the Codex product philosophy.

Engineers Won't Disappear—They'll Return to Their Essence

There's a popular claim in the industry: as coding gets abstracted away layer by layer, we'll eventually no longer need engineers. The OpenAI team directly rebutted this assertion.

Their core argument: Software ate the world, AI ate software, and now AI engineers are eating the world. The origin of this line of thinking can be traced back to venture capitalist Marc Andreessen's famous 2011 Wall Street Journal article, "Why Software Is Eating the World." He pointed out that more and more industries were being disrupted and reshaped by software companies—from retail (Amazon) and music (Spotify) to movies (Netflix), software was becoming the core infrastructure for value creation in every industry. OpenAI extends this argument: AI drives the marginal cost of creating software toward zero, making "engineers who can harness AI's capabilities" the new generation of value creators—just as those who mastered software engineering once disrupted traditional industries.

Engineering has never been just about writing code; it's about solving problems for yourself and others—combining the latest science, design, taste, judgment, and above all, imagination, to build things people can actually use. In this sense, AI hasn't ended engineering; it has brought engineering back to its roots. When the model takes over tedious code generation, engineers are freed to direct their energy toward higher-order judgment and creation.

The pace of technological iteration also confirms this trend. OpenAI used to release a new model roughly every 15 months; now that cycle has shrunk to about 6 weeks—the rhythm of product evolution can only be described as "relentless."

From Code Completion to Long-Horizon Goal Agents

Romain looked back at several "stunning" leaps in capability over the past two years:

• Completion
• Inline Prediction
• Command K: lets the model make changes, but doesn't verify the results
• The model begins to test its own work
• The model takes over long, difficult goals until completion

This evolutionary path corresponds to several key leaps in the underlying capabilities of large language models (LLMs). Early code completion relied on statistical language models that could only do local token prediction. After GPT-3, models gained cross-context semantic understanding, making "Command K"–style instruction following possible. The emergence of the "build-test" loop depended on the maturation of tool-calling (Function Calling/Tool Use) capabilities—the model can not only generate code but also invoke external tools like code interpreters and terminal commands to verify its output. This capability was significantly enhanced in OpenAI's o1 series of models, which, by introducing Chain-of-Thought reasoning, enabled multi-step planning and self-correction.

Interestingly, this "build-test" loop wasn't even part of the models' capabilities two years ago. At a past Dev Day, Romain used the o1 preview version at the time to build a mini drone interface from scratch, but the model couldn't run code or verify its own work—all he could do was "pray" the demo would succeed. Today, the model can already test itself autonomously, capable enough to control an entire camera and lighting system live on stage.

Behind this lies a key idea: Agents can now do any task you can do on your own computer. This means they don't just help you write code; they help you handle what comes before coding (understanding why to do something) and after coding (review and deployment). Connect an agent to the "why," and it can initiate more work; connect it to the "what comes next," and it can ship more results.

Product Philosophy: Not to Automate Engineers, but to Empower Them

When models can already outperform humans on many medium-difficulty tasks, a fundamental question emerges: what should the product look like?

OpenAI's answer is unequivocal—the goal is absolutely not to automate engineers, but to maximally empower them.

Borrowing intuition from science fiction and superhero movies, they argue that the ideal product form is actually quite simple, comprising two modalities:

Chat

"Some people say chat is dead. I think chat is severely underrated." You need a single entity you can turn to anytime, anywhere, for help with anything.

Hands-on

When you want to inspect, steer, or shape things yourself, you need a powerful collaborative UI that lets you dive into the deepest details.

The analogy for this model is "working with a team": most of the time you just chat and let teammates get on with it, without needing to watch every unit of work; only occasionally, when you need to dive deep, do you drill into the details together. Building on this idea, the team built the Codex app—a simple chat interface that can be used for coding and anything else.

Worth mentioning: initially there was plenty of internal skepticism about this product, with many insisting they'd "never leave the terminal, Vim, or Emacs." Yet today, those same people are all using it. Behind this shift lies a profound difference in tool design philosophy: the command-line interface (CLI) centers on text streams, emphasizing precise control and scriptability—an embodiment of the Unix philosophy of "do one thing and do it well." The integrated development environment (IDE), by contrast, organizes around code files, providing visual tools like syntax highlighting, debuggers, and version-control integration. The team's insight: the CLI struggles to serve as a collaborative interface for arbitrary work, while the IDE's order is "backwards"—traditional IDEs assume the engineer already knows what to write and then provide tools to assist writing; but in the AI era, the starting point of work has become the conversation about "why we're doing this," with code being just one of the final outputs. This inversion of workflow gave rise to the "conversation-first" product design philosophy, whose inspiration can be traced back to Alan Kay's classic HCI (human-computer interaction) principle that "user interfaces should match the human mental model."

The Open Codex Tech Stack: Anyone Can Build on It

Romain particularly emphasized that Codex cannot be a closed product that only OpenAI can improve. The team deliberately designed it as a layered structure that anyone can build on:

• Model layer: Developers use the models via the Responses API, and OpenAI itself builds the Codex app with the same API and models. When Codex needs a new capability (such as context compaction for long tasks), it's prioritized into the API first, so everyone benefits.
• Codex Harness (runtime framework): Fully open source, inspectable, forkable, and modifiable. The model is the default but not hardcoded—you can swap in an open-source model and keep the same agent loop.
• AgentsMD: Rather than inventing a new format, they chose a naming convention that other agents can use universally too.
• AppServer: The open-source path that uniformly controls the harness—this is exactly the path OpenAI itself uses to build the VS Code extension and the Codex app. Developer Toma built his own native app, Codex Monitor, on top of AppServer before the Codex app was even released; he has since joined the team and developed the iOS version of Codex.
• Application-layer plugins: such as browser use, computer use, and plugins tailored for specific roles like data science and design—all open source.

The "agent loop" in the Codex Harness is the core architectural pattern of modern AI agent systems, usually referring to the iterative cycle of "perceive-plan-act-observe": the model receives environmental state (such as the codebase or error messages), generates an action plan, invokes tools to execute actions (such as running tests or reading/writing files), and then feeds the execution results back into the model as input for the next round. This pattern originates from the agent-environment interaction framework in reinforcement learning, and was widely adopted and popularized by early open-source frameworks like AutoGPT, LangChain, and LlamaIndex. The strategic significance of open-sourcing the harness lies in building a "moat" for the technology ecosystem—when community developers build tools on the same loop framework, the edge cases and capability demands they surface flow naturally back to the platform, creating a data flywheel effect.

There's just one core message: OpenAI didn't build one system for itself and a simplified one for developers. We use exactly what we give you. Every time the community forks the framework and pushes against the boundaries of its capabilities, it becomes fuel for OpenAI to learn and improve.

Value Maxing: From Consuming Tokens to Maximizing Value

As agents become explosively useful, the real question is how to extract value from them. The team proposed a core concept—Value Maxing, rather than token maxing. Around this theme, they shared progress in three directions:

Cost Efficiency

Everyone wants frontier intelligence, but they also want as much intelligence as possible—and that comes down to efficiency. GPT 5.6 Terra delivers GPT 5.5–level intelligence at half the cost. The Luna model beat several well-known models in evaluations, at a price of just $1 per million input tokens and $6 per million output tokens.

Speed

GPT 5.6 Solve runs on Cerebras, achieving frontier-intelligence inference at 750 tokens per second—roughly equivalent to writing a substantial PR in about 10 seconds. This breakthrough has a hardware foundation: Cerebras Systems' flagship product, the WSE (Wafer-Scale Engine), uses a wafer-scale integration approach, turning an entire silicon wafer into a single chip, with on-chip memory bandwidth far exceeding traditional GPU cluster architectures. Traditional GPU clusters must transfer the KV Cache (key-value cache) between multiple chips, whereas the WSE's on-chip SRAM can be accessed directly, eliminating the cross-device communication bottleneck. More importantly, it's about the possibilities speed unlocks—when the time cost of generating a single answer is low enough, an agent can try five or six different approaches in parallel and then pick the best result, taking even less time than it once took to produce a single answer. This makes it feel less like "waiting for the AI to reply" and more like a colleague who "shows you results as they work."

Runtime Environment

Many people leave their laptops open to keep agents working continuously. The ideal state should be: close your computer and let multiple tasks run in parallel on their own isolated machines. In the future, there shouldn't be an awkward distinction between "local tasks" and "cloud tasks"—you just talk to an agent, and it decides which environment suits the current work.

From Operating a Single Agent to Managing a Team of Agents

The climax of the talk was a segment by guest speaker Peter Steinberger, known as the "claw father," who described a fundamental transformation in his way of working.

A few months ago, he was still juggling more than 10 terminal windows, waiting for one to finish so he could grab it and assign new work. He joked at his own expense: "I thought I was orchestrating, but really I was just polling—I had become the scheduler, the router, and the memory."

Today, he mainly talks to a single long-running "manager" agent that delegates work to a team. Only when he hits a thorny problem does he drop down to pair directly with a particular worker. The default mode has changed: he manages a small company of agents.

This transformation relies on three key changes:

1. Server-side compaction: makes long tasks reliable enough that you no longer need to optimize around new sessions. The core idea of this technique is similar to operating-system memory compaction: when the context approaches its limit, the model or a dedicated component summarizes and compresses historical information, retaining key decision points and task state while discarding redundant intermediate-step details, thereby freeing up room for new actions. Server-side implementation means the compaction logic is handled uniformly by the platform, so developers don't have to manage the context lifecycle themselves at the application layer.
2. Coordination: lets one thread create and steer the right projects
3. Automated triggers: can wake up the same manager when something happens

Persistent context, delegation, triggers—these form the complete "loop."

Peter also observed an interesting phenomenon: the bottleneck keeps moving. Early on he was limited by tokens, later by compute, and now mainly by attention—a resource you can't simply scale up. This insight aligns closely with classic propositions in cognitive science and information economics. Nobel laureate economist Herbert Simon pointed out as early as 1971 that "a wealth of information necessarily creates a poverty of attention"—later regarded as the theoretical origin of the "attention economy." In the age of AI agents, when AI can generate code, plans, and reports without limit, the core scarce resource for human engineers becomes the bandwidth of judgment—"deciding what to look at, what to believe, and what to approve." This is consistent with the description of "Bounded Rationality" in management theory—human decision-makers have inherently limited cognitive resources, and when the volume of processable information exceeds a threshold, decision quality actually declines. Therefore, the most important skill becomes "deciding where to spend your attention."

He put it bluntly: staring at an agent while watching code fly by is already a waste of time, because the latest models understand intent well enough not to need real-time supervision. His envisioned ideal form: someone files an issue on an open-source project; the manager agent wakes up, judges whether it's appropriate against the project's goals, creates a worker to investigate, implement, and run tests, then has another agent review the results, and finally returns a PR, the original issue, a proposed diff, and even a video or a running build you can VNC into. He just reviews once, leaves a note, and approves—and the loop continues. This is precisely the core value of the "review once, leave a note, approve" workflow—the design goal of an agent system isn't to maximize information output, but to present the most critical decision points to humans at the right time and at the right granularity.

Conclusion: The Next Engineering Problem Is Designing Better Loops

Peter's summary captured the core of the entire talk: Models are evolving faster than the frameworks and organizations around them. Designing those frameworks is the next engineering problem.

"The future isn't 20 terminal windows—it's a better loop." When model capabilities are already strong enough, the value of the AI engineer is shifting from "operating a single agent" to "designing the looped systems in which agents collaborate." This is perhaps the core proposition the conference wanted to convey to those 7,000 engineers—the stage for engineering hasn't shrunk; it has moved up a dimension.