AI Engineer Code 2025
Future-Proof Coding Agents
Read the talk
Future-Proof Coding Agents
A coding agent depends on more than model intelligence: its tools, prompts, and runtime must fit the model’s habits without making every upgrade a rebuild.
From a talk by Bill Chen and Brian Fioca
Before you start: Familiarity with command-line tools, model tool calls, and basic software development workflows will help you follow the integration examples.
Why does a new model mean rebuilding the agent?
Why should a better coding model force you to rebuild the agent around it? That is the opening problem for Bill Chen and Brian Fioca, who work on coding agents on OpenAI’s Startups team. Software engineering can serve as a general medium for solving problems, which makes progress in coding especially consequential. But rapid model releases keep shifting the foundations beneath the applications built on them: prompts, tools, and orchestration that fit one model may need adjustment for the next.
The way through that problem starts by separating the model from the software that makes it an agent. From there, the practical questions are what Codex bundles together, which parts a product should reuse, and where a custom integration still adds value.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Interface, model, and harness
A coding agent has three main parts:
| Part | Responsibility | Examples |
|---|---|---|
| User interface | Let people request and follow work | CLI, IDE, cloud or background agent |
| Model | Supply reasoning and coding capability | GPT-5.1 series, other providers’ models |
| Harness | Connect model inputs and outputs to actions | Prompts, tools, core agent loop |
Chen’s model examples include GPT-5.1 and the then newly released GPT-5.1-Codex-Max. The harness is the collection of prompts and tools organized into the loop that lets the model keep working.
The harness is the model’s interface to the working environment. It gives the model access to users, code, and actions through tools. It also supports the continuity needed to interpret a request, work over many turns, and produce changes. That layer can be a product’s differentiator, but owning it means owning the work required to keep it fitted to changing models.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Where the fit breaks down
An innovative tool is not automatically an effective tool for a model. It may be out of distribution: unlike the tools the model encountered during training. Even when the operation is familiar, the prompt may need tuning to the model’s learned behavior. A harness therefore has to account for more than whether a tool’s schema is valid. It has to make that tool usable by the particular model doing the work.
Several other responsibilities change with the model and its interfaces:
- Latency and progress: Which tasks cause prolonged reasoning? Should instructions change, and what should the user see while the model works—direct communication or a summary of progress?
- Context and compaction: What stays in the context window, and how does work continue when it fills? Fioca points to automatic compaction with Codex Max. That launch-era behavior applied to Codex applications using the model; it did not remove context-management responsibilities from arbitrary custom harnesses, and direct API access was still forthcoming.
- API evolution: Moving among interfaces such as Completions and Responses changes the integration surface. The relevant question is which interface lets the model use its capabilities effectively.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When thorough instructions become unnecessary work
Fioca separates model behavior into intelligence and habits. Intelligence covers competence in programming languages, frameworks, and code generation. Habits are the learned ways of applying that competence: planning a solution, looking around the repository, gathering context, thinking before editing, and testing afterward. Effective prompting requires a feel for both. Instructions that seem helpful in isolation can conflict with, or amplify, behavior the model already learned.
At the launch of GPT-5, some developers transferred prompts from other models into their existing harnesses. Those prompts told the agent to examine the context very thoroughly, including inspecting every file before making an edit. OpenAI had already trained the model to gather context. The extra instructions pushed that habit further, and Fioca reports that the resulting work took a long time. Reducing the over-prompting let the model follow its usual behavior more effectively.
Fioca describes asking the model what he could change in the instructions to get to a satisfactory solution faster. Its answer identified the demand to inspect everything as the source of unnecessary work. This was an instruction-debugging anecdote, with no measured latency comparison supplied. Its practical lesson is to examine whether a prompt is compensating for a missing capability or duplicating a habit already present in the model. Joint development of the model and harness makes that interaction easier to understand; Fioca presents it as a reason Codex combines both.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What the Codex harness has to operate
Codex exposes that combined system across development surfaces. Fioca describes a VS Code plugin, a CLI, and cloud tasks invoked from the plugin or from ChatGPT on a phone. A specification or prompt becomes a plan, repository navigation, file edits, command execution, and runnable code. Slack invocation and GitHub pull-request review add other entry points to the same kind of work.
Those interfaces conceal substantial runtime machinery. When Fioca asked a Codex team member what belonged on the harness slide, the response was “It's way harder than you think.” The concrete responsibilities explain why:
- Concurrent execution: Manage parallel tool calls and merge their threads of work.
- Security and connectivity: Handle sandboxing, permissions, port forwarding, and port management.
- Long-running context: Decide when to compact, when to reintroduce context, and how those choices affect cache efficiency.
- Tool and media support: Implement MCP plumbing and choose image resolution and compression before sending images to the model.
Each capability also creates maintenance work as new features arrive.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The terminal extends the task boundary
Once the harness bundles those capabilities, the agent can write tools to address problems it encounters. Fioca calls the result a computer-use agent for the terminal. His description of safely generating tools depends on the execution boundary: sandboxing and permissions constrain what generated code can do, and human review remains necessary before deployment.
Chen connects this to an older way of using computers. Before graphical interfaces, writing programs and chaining commands were ordinary ways to get work done. A coding agent can use the same medium. Chen uses Codex to organize desktop photos into a folder; he also gives analysis of large collections of CSV files as an example. The task need not be software development if it can be accomplished through files and command-line tools.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use an agent inside your agent
That broader task boundary makes Codex useful as a component inside another agent. Drawing on work with customers such as Cursor and VS Code, Chen proposes the harness as an abstraction layer: a product integrates an agent whose prompts and tools are maintained alongside its models, instead of retuning those details for every upgrade. These are integration patterns, not a complete recipe for a coding startup.
Does that leave the product as merely a wrapper? Chen and Fioca reject the premise. Reusing infrastructure allows a team to spend more effort on the part customers experience as differentiated value. The architectural choice is where to own complexity: inside the model-facing runtime, or in the product built above it.
The programmable entry points include a TypeScript SDK, CLI invocation from programs such as Python scripts, and a GitHub Action for workflows such as resolving pull-request merge conflicts. Python invocation here means calling the CLI, not a native Python Codex SDK. A small TypeScript caller can use the same codex exec boundary to request analysis before making changes:
typescript
import { execFileSync } from "node:child_process";
const result = execFileSync(
"codex",
[
"exec",
"Inspect the current merge conflicts and explain a resolution plan. Do not edit files."
],
{
cwd: process.cwd(),
encoding: "utf8",
stdio: ["ignore", "pipe", "inherit"]
}
);
process.stdout.write(result);
This call requests a plan; applying a resolution would be a separate task governed by the agent’s execution permissions.
A richer integration puts Codex behind a tool in an agent built with the Agents SDK, with MCP connectors back to the host product. Fioca describes a progression: first a chatbot can converse, then it can use tools, and then it can invoke a tool that creates tools it lacks. For enterprise software, that could mean generating a customer-specific API connector on demand—a task previously assigned to professional services. His concrete example is a DevDay Kanban board that he says could fix its own bugs.
Zed’s Codex integration illustrates a different division of responsibility. Through Agent Client Protocol and the codex-acp adapter, the editor provides the interface for user interaction and code changes while Codex supplies agent execution. That lets Zed concentrate on the editor rather than maintaining the entire underlying harness. Chen also cites GitHub as a partner integrating through the SDK, and describes using the SDK in CI/CD pipelines or for interaction between agents.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keeping a custom harness in distribution
Reusing the complete agent is not the only option. Chen describes working with Cursor to improve its integration with Codex the model, explicitly distinguishing that from Codex the agent. Cursor retained its own agent layer while aligning its tools with the model’s training distribution and its harness with the open-source Codex CLI implementation.
The distinction gives builders two meaningful levels of control: embed the maintained agent, or use the public implementation to inform a custom harness. The source is available to inspect, use, and fork. Choosing the latter preserves control over the agent layer while retaining responsibility for how its tools and prompts fit the model.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Building for longer work and a broader SDK
At the time of the talk, Fioca describes Codex as less than a year old and calls it OpenAI’s fastest-growing model by usage. Fioca reports dozens of trillions of tokens served per week, with usage doubled since DevDay. Those are his usage claims; the passage does not specify the token accounting or precise product scope.
His forecast is that improving models will handle longer tasks without supervision and raise the level of work people trust them to perform. He describes already trusting them with harder work than he would have six months earlier. The target is increasingly demanding software environments: sprawling codebases, non-standard libraries, closed-source systems, and projects whose existing templates and practices must be followed.
The SDK is expected to evolve with those capabilities. Fioca anticipates support for learning during a task, avoiding repeated mistakes, and exposing more of a general agent’s ability to solve problems through code and a terminal. These are directions for future capability, with the SDK serving as the route through which products would gain access to them.
The closing recommendation is to make a deliberate choice about who maintains that foundation. Codex offers an off-the-shelf harness and source code for teams that want to examine or adapt it. Building above that layer leaves the provider responsible for ongoing model compatibility while the product team applies the agent to useful work—including work outside coding.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The model's launch announcement explains compaction, long-running tasks, availability, and safety boundaries.
Public source and installation instructions for the Codex terminal coding agent.
Run Codex in GitHub Actions workflows with configurable prompts and execution permissions.
Zed explains its Codex integration through ACP and the separation between editor UI and agent execution.
Updates since the talk
Current documentation for embedding Codex in applications and automated workflows.
Current guide to connecting Codex with the Agents SDK through an MCP server.
Cursor's December 2025 account of adapting tools, prompts, and reasoning continuity for Codex models.
Read the complete timestamped transcript
- 0:00
[upbeat electronic music] Hello, everyone.
- 0:22
Um, today we'll be talking about how to build coding agents.
- 0:27
And, uh, I'm Bill. I work on the Applied AI Startups team at OpenAI.
- 0:32
And I'm Brian. I work with Bill on the OpenAI Startups team.
- 0:35
And we specifically, uh, focus on, uh, building coding agents here at OpenAI.
- 0:41
Um, yeah, so why are we talk- giving this talk? Why, why are we, you know, uh, talking about coding agents? Well, it's really quite interesting because it's been booming for the, the, the past year.
- 0:54
Actually, it's just ... If you think about it, it's not that much time ago, like only been a year or so. The ground keeps shifting really under the, uh, harness on, on the coding agents.
- 1:04
But if you think about it, it's really, like, why it's interesting is because it's really a signal on how close we are to AGI. Software engineering can be set as a universal medium for problem-solving.
- 1:15
But because the ground is shifting so fast, uh, we ha- kept having to rebuild the agent on top of the model whenever a model is released. And today, we're going to talk a little bit about how we might be able to get around that.
- 1:29
So here's what we're gonna go over today. We'll start with the anatomy of a coding agent, especially going into the details of models and harnesses and how they work together.
- 1:39
We'll share some lessons that we learned from putting them together ourselves, and we're specifically gonna talk about Codex here, which is our own coding agent. We'll talk a little bit about emerging patterns that we're seeing from all of you for using agents like Codex in your own products.
- 1:56
And lastly, we'll talk a little bit about what to expect from Codex in the future so that you can build along with us if you want to.
- 2:06
To start, let's talk a little bit about what makes a coding agent an agent as a whole. Um, it really is quite simple. I think, you know, people kind of overcomplicate things a little bit these days.
- 2:19
It's made out of three parts. It's a user interface, it has a model, it's a harness, right? Uh, the interface, quite self-explanatory. Could be a, a computer, uh, a c- uh, like a CLI tool, or it could be an, a, uh, integrated developer environment.
- 2:34
Could be also cloud or a background agent. Um, models, also very quite self-explanatory, are, you know, the things like the latest and the greatest, the GPT-5.1-Codex, uh, Max that we just released yesterday, uh, or the GPT-5.1 series of models or other, uh, models from other providers as well.
- 2:56
And the harness, uh, is an, a little bit more of an interesting part. This is the part that directly interacts with the model. Uh, in the most reductive way, you can sort of think of it as a collection of prompts and tools combined in a core agent loop, which provides input and outputs, uh, from a model.
- 3:15
Uh, the last part will be our focus for today.
- 3:21
As touched on a bit earlier, coding is one of the most active frontiers in applied AI, and, uh, how models are constantly getting released, and we're not making the problem, uh, easier for everybody [laughs], is that people have to constantly adapt, uh, the agents to the new models.
- 3:44
So, um, Bill's done a great job of giving us an overview of coding agents, what they're made up of. So let's zoom in a little bit on the harness.
- 3:55
Um, turns out that's a little bit tricky. So what is a harness? A harness is really the interface layer to the model. It's the surface area the model uses to talk to users and the code and perform actions with tools.
- 4:10
It's made up of all of the pieces that the model needs to work over many turns, call tools, and, and really write code for you and interpret to, what the user is actually asking.
- 4:22
Um, for some, the harness might actually be the special sauce of the product. But as we're gonna go into a little bit more, it's really challenging work to build a good harness, and we'll talk about how we did that.
- 4:39
So let's see. What are some of these challenges? Um, just to name a few, AV is one. Um, your [laughs] um, your brand-new innovative custom tool that you're giving to your agent might not actually be something the model is using, is used to using.
- 4:55
It may not have ever seen that tool before in training. And even if it is, you need to spend time tuning your prompt to that particular model and the habits that it comes with.
- 5:07
And new models are coming out all of the time. What about latency? Like, does the model take a while to think about certain things? Which things? Do you prompt it not to?
- 5:17
How do you expose the UX of what a thinking model is doing while it's thinking? Is it communicating with you while it's thinking, or do you have to summarize it?
- 5:27
Managing the context window and compaction can be really challenging. We just launched Codex Max that does that out of the box for you. You don't have to worry about compaction and context window management.
- 5:40
It's really hard to do. Um, and so if you were to do it yourself, have fun. Um, and then also, like, the APIs keep changing, right? So we have completions, we have responses, we have whatever else is coming in the future.
- 5:52
What does the model know how to use and get, to get the most intelligence out of the box?
- 5:59
And so- This is the interesting part. Fitting a model into a harness takes a lot of prompting. [laughs] It turns out that how the model is trained has side effects.
- 6:13
I like to think about it this way,
- 6:15
intelligence plus habit. Intelligence, what is the model good at? What languages does it know really well? What is, what is its capabilities in terms of, like, how well it can write code in certain frameworks?
- 6:30
And then what habits did it learn to s- to use to solve those problems? We've trained our models to have habits of, like, planning a solution, looking around, gathering context, and, and thinking about a problem before diving in and writing code, and then testing its work at the end.
- 6:51
Developing a feel for these habits is how you become a good prompt engineer. If you don't instruct the model in ways that it's familiar with, you can have problems.
- 7:03
We saw this when we launched GPT-5. A lot of people who weren't used to using our models in coding tried to take prompts that existed for other models and put them into their harness and have GPT-5 follow those instructions.
- 7:17
And it turned out that we taught our model to do some of the things that the other models didn't really do out of the box. And so when they were prompting them to look really hard at the context and, like, examine every single file before making a, a code edit, our model was being very kind of thorough
- 7:37
about that, and it was taking a really long time, and they weren't seeing the best performance. And so we figured out that if you let the model just do the behaviors that it's used to and don't over-prompt it, it'll actually perform really better.
- 7:50
We found out by asking. I was literally like, "Hey, like, I like the solution, but it took you a long time to get there. What can I do differently in your instructions to help you get there faster next time?"
- 8:01
And literally it said, "Uh, you're telling me to go look at everything, and I don't really need to, so that's what's taking forever." [laughs]
- 8:12
And so you can actually see the advantages of building both the model and the harness together because you just, like, know all of that while you're building it, and that's why Codex is both a model and a harness combined.
- 8:26
So let's dig deeper into Codex and what it can actually do.
- 8:31
So we built Codex to be an agent for everywhere that you code. It's a VS Code plugin. It's a CLI. You can call it in the cloud from the VS Code plugin or from ChatGPT from your phone.
- 8:43
Um, at its very basic, you can use it to turn your specs into runnable code, starting from a prompt, um, having a plan. It navigates your repo to edit files, it runs commands, executes tasks, and you can call it from Slack, or you can have it review PRs in GitHub.
- 9:02
So all of the things that you would expect.
- 9:06
And that means that the c- that Codex, um, the harness of Codex needs to be able to do a lot of really complex things. Uh, when I talked to a member of the Codex team about this slide and what should be on it, he was like, "It's way harder than you think." [laughs]
- 9:21
You have to manage parallel tool calls, like thread merging and all of the things involved in that. Think about all of the security considerations you have with sandboxing, prompt forwarding, permissions, uh, port management.
- 9:33
Um, compaction is a whole thing, um, and doing that well is really complex. When do you trigger compaction? When do you reinject? How do you worry about con- uh, cache optimization during that?
- 9:45
MCP, [laughs] right? Like, all of the th- the, uh, plumbing you have to build for MCP support into the harness, uh, and then not even mentioning images and what is the resolution that you need to compress them to to send them to the model.
- 9:58
All this, all of this is, like, work that you have to do if you're gonna build this from scratch, and keep it updated as new features come online.
- 10:07
So since we've bundled all of these features together for you in an agent that can safely write its own tools to solve new problems that it encounters...
- 10:20
Oops. [laughs] Uh, we actually have here, uh, a computer use agent for the terminal.
- 10:33
Wow. That sounds quite a bit powerful than just plain old coding agent, doesn't it? Um, but just think about it again. Well, before browser and graphic user interface was a thing, wasn't that how we always operated a computer, with the writing code and chaining them together in a command line interface?
- 10:51
Uh, so that means if you can express your task in command line as well as files, tasks, Codex will be able to know what to do. Um, the example is, I like to use Codex to organize a lot of the photos from my desktop into a folder.
- 11:06
N- and that's a very simple use case. But what it can also do is it can analyze huge amounts of CSV files inside of a folder, uh, doing data analysis.
- 11:17
It does not have to be a coding task, and if it can be accomplished by running tools from command line, you can use Codex.
- 11:24
So now that we see Codex as such a cool harness, um, I want to also share a little bit about how you can use it to build your own agents.
- 11:33
And what you can do is you can use Codex the agent inside of your own agent.
- 11:41
Um, how does that work? Well, if you want to build, uh, a coding, uh, an- the next coding startup, we don't really have all the answers, but we do have a few patterns, uh, that we s- thought, uh, might help you, having worked with some of the top coding customers, uh, like Cursor and VS Code.
- 12:01
Uh, one of those patterns is, uh, harness becoming the new abstraction layer. The benefits of this is quite obvious. Um, you no longer have to care about prioritize, uh, optimizing the prompt and tools with every mo- model upgrade.
- 12:18
But, um, does that mean you're just building a wrapper?
- 12:21
Well, I disagree with that take. [laughs] I disagree.
- 12:26
I would disagree with my colleague here. Um, [laughs] just like how building wrappers on top of models, I think, is really reductive on, uh,
- 12:35
on, on the whole value prop of the infrastructure layer.
- 12:37
Sorry, I used to be a VC. [laughs]
- 12:40
Focusing most of your efforts on differentiating your product is what this pattern allows you to do, and that's where most of the value lies.
- 12:52
Exactly. Okay, so let's look at some of these patterns that we've seen and actually have helped our customers build, um, along with them.
- 13:01
Codex is an SDK. It can be called through a TypeScript library. You can call it programmatically in a Python exec. There's a GitHub Action that you can plug into to have it merge, merge conflicts [laughs] on PRs that everybody hates doing.
- 13:16
Then, uh, you can also add it to the agent's SDK and give it MCP connectors back to your product. So now you have an agent, I like to say we started with chatbots that you can talk to, then we gave the chatbots tools to use, and then now you can give, uh, a tool to your chatbot that
- 13:37
can make other tools that it doesn't have. And so now you can actually build out enterprise software that does its, that writes its own plugin connectors to the API level for each customer on the spot.
- 13:51
That's something that a professional services team used to have to do. Um, so you have fully customizable software that can now talk back to itself. Um, I made a Kanban board for Dev Day that can actually fix its own bugs. [laughs]
- 14:03
Um, it's pretty fun. And then lastly, um, you can actually do something like what Zed has done. They have just decided to wrap Codex inside of a layer and give it an interface to the IDE for talking back and forth for the user and making code edits.
- 14:20
And now they don't actually have to do all the work of staying on top of all of the things that we're good at doing, and they can focus on building, like, the best code editor.
- 14:32
Uh, so our top coding cu- pa- partners, like GitHub, has used this, uh, to great effect, and well, uh, we've created an SDK, uh, for it that they use to directly integrate, uh, with Codex.
- 14:45
You can also use the SDK to, uh, control Codex as part of your CI/CD pipeline, as well as use it as an agent that directly interacts with your own agent as well.
- 14:55
Uh, if you really want to customize the agent layer, you can do it too. As an example of this, we worked with, closely, with the Cursor team to get the best performance out of the Codex, the model, not the agent.
- 15:07
We're bad at naming things. The model is different from the agent. [laughs] They did so by aligning their tools to be in distribution with how the model is trained, and they did so by aligning, uh, the harness with our open source, uh, implementation of Codex CLI.
- 15:22
All of this is publicly available. Uh, you can fork the repo, you can use it, our source code, you can use it, uh, go nuts.
- 15:34
So what does the future hold for Codex? It hasn't even been out for a year. Um, and especially with the last launch of Codex Max yesterday, like, things are really changing fast.
- 15:46
Uh, it's the fastest growing model in usage, now serving dozens of trillions of tokens per week, which has actually doubled since Dev Day.
- 15:57
It's always good to build where the models are going. It's safe to assume that the models will get better. They'll be able to get to work on much longer horizon tasks unsupervised.
- 16:09
New models will raise the trust ceiling. I trust these models now to do some way harder work than I would've six months ago, and that's gonna keep increasing. The future is about sprawling code bases and non-standard libraries and knowing how to work in closed source environments, matching existing templates and practices.
- 16:29
And the models, uh... And, and, and so you can imagine that the SDK will evolve to better support these model capabilities, letting the model learn as it goes and not repeat mistakes, and generally provide more surface area for an agent that writes code and uses a terminal to solve whatever problems it encounters.
- 16:50
And you can use that in your products via the SDK.
- 16:56
So what have we learned? Harnesses are really complicated and take a lot of work to maintain, especially with all the new models coming out. So we've built one for you inside of Codex that you can use off the shelf, or look at the source if you want to.
- 17:12
And you can use it to build new things outside of coding. And let us do all the work, making sure that you have the most capable computer agent,
- 17:21
and we're really excited to see what you craft. [outro music]