Codex, and the agent that opens pull requests

OpenAI released Codex as a research preview: a cloud-based software engineering agent that runs in an isolated container with your repository, works on a task for up to some tens of minutes, and produces a diff with a log of what it did.

This is a different product shape from the coding assistants we have been using, and the difference is worth being precise about.

the three shapes#

Completion. The model suggests the next few lines as you type. Copilot's original form. Latency budget: milliseconds. You stay in control of everything.

Conversational. You describe a change, the model proposes an edit, you accept or reject. Latency budget: seconds. You review each step.

Delegated. You describe a task, close the tab, and come back to a pull request. Latency budget: minutes to tens of minutes. You review the result, not the process.

Codex is firmly the third. So is Claude Code in its non-interactive mode, so is Devin, and so is what GitHub is building into Copilot. This is where the category is going.

why the shape matters#

Delegated agents change the unit of work from "edit" to "task," and that changes everything downstream:

• You cannot course-correct mid-flight. If the agent misunderstood the task, you find out after twenty minutes of work. That makes the task description vastly more important than a prompt in a chat.
• Parallelism becomes free. Five tasks running at once is the same wall-clock as one. That is a genuine multiplier and it is the actual value proposition.
• Review becomes the bottleneck. If an agent produces five pull requests an hour and you can meaningfully review two, you have not multiplied throughput. You have created a queue.

That last point is where I think most teams are going to struggle. The constraint on software delivery in most organizations was never typing speed. It was understanding, coordination, and review. Delegated agents attack the part that was not the bottleneck.

the sandbox is the good part#

Codex runs in a container with no network access during execution — dependencies are preloaded, then the network is cut. That is a meaningful security design and more products should copy it.

The threat model: an agent that can read your repository and reach the internet can exfiltrate your repository. It does not have to be malicious; a prompt injection in a dependency's README is enough. Cutting network access after setup eliminates a whole class of attack for the cost of some inconvenience.

the practical guidance#

For delegated agents to be worth it, you need:

1. Tasks with clear acceptance criteria. "Fix the flaky test in test_payments.py::test_retry" works. "Improve the payment system" does not.
2. A test suite that actually gates. The agent's self-verification is only as good as your tests. If your tests pass on broken code, you will get broken code that passes tests.
3. A review culture that has not been eroded. See above. This is the hard part and it is organizational, not technical.

Start with the tasks you have been putting off: dependency upgrades, test coverage on a neglected module, migrating a deprecated API call across a hundred files. Mechanical, verifiable, tedious. That is where this technology is already clearly worth it, today, without any argument about whether it will replace anyone.