From Autocomplete to Agent
When OpenAI first launched Codex in 2021, it was a GPT-3 variant fine-tuned on GitHub code. Impressive for its time, it powered the original GitHub Copilot and let you turn docstrings into functions. The mental model was autocomplete with ambition: you write the intent, the model writes the implementation.
Five years later, Codex for almost everything represents a fundamentally different product with the same name. This is not a better autocomplete. It is an asynchronous software engineering agent that takes a task, spins up a sandboxed environment, reads your codebase, writes code, runs tests, and hands you back a pull request. The interface you interact with is not a code editor but a task queue.
That distinction matters more than the marketing around it.
The Architecture Underneath
The new Codex runs tasks in isolated cloud containers with access to your repository. You describe what you want done, and the agent works through it without requiring you to stay in the loop. When it is finished, you get a PR with a summary of what it did and why. If you have CI configured, the checks run against that PR just like any human-authored branch.
This is meaningfully different from tools like Cursor or GitHub Copilot, which are still fundamentally IDE integrations where a human is present at every step. It is closer to what Devin attempted when Cognition launched it in early 2024, or what GitHub Copilot Workspace has been working toward, but with OpenAI’s more capable recent models doing the reasoning.
The execution loop matters here. Agents that operate in sandboxed environments with actual shells, actual test runners, and actual package managers behave differently from agents that only produce text. When the model runs npm test and sees red, it can iterate. When it installs a dependency and it conflicts, it has the error output to reason over. The feedback loop is real rather than simulated.
Codex uses this environment to do things like:
- Read existing test suites to understand expected behavior before changing code
- Run linters and formatters to match the project’s style without being told
- Trace through failing tests to identify root causes rather than guess at them
- Check that imports resolve before declaring a task complete
This is closer to how a new hire approaches a codebase than how an autocomplete system approaches a cursor position.
What “Almost” Is Doing in That Title
The phrase “almost everything” is OpenAI being more honest than most AI product launches. There is a real boundary here, and it is worth being precise about where it falls.
Codex handles tasks that are well-specified, bounded, and verifiable. “Add pagination to the /users endpoint using cursor-based pagination, matching the style of the existing /posts endpoint” is exactly the kind of task it excels at. The success criteria are checkable, the style is learnable from the codebase, and the implementation is largely mechanical.
Codex does not handle tasks that require context outside the repository. If the reason pagination matters is that your database is hitting query timeouts in production because of a specific access pattern, and that context lives in a Datadog dashboard and a Slack thread from three weeks ago, the agent does not have that. It will implement pagination correctly, but it will not know whether pagination is actually the right fix.
This is not a criticism unique to Codex. It is the fundamental limitation of any agent that reads only the repository. Your codebase is not the full context of your engineering decisions. The constraints that shaped architecture choices, the incidents that drove certain defensive patterns, the business rules that live in product docs or verbal agreements rather than comments, none of that is in git.
Codex is excellent at execution within a defined scope. It is not a system that can reason about whether the scope was defined correctly.
Comparing the Field
There are now several serious entries in the autonomous coding agent space, and they differ in ways that matter for actual use:
Claude Code (Anthropic) runs locally, interacts with your actual development environment, and keeps you in the loop as a collaborative partner. Its strength is the back-and-forth: it asks questions, explains tradeoffs, and adapts based on your responses. It is less “fire and forget” and more “pair programmer who types faster than you.”
GitHub Copilot Workspace integrates directly into the GitHub issue workflow. You can go from an open issue to a proposed implementation without leaving GitHub. The integration is convenient, but it is still relatively early compared to where Codex and Claude Code are.
Devin was the first product to make the async software agent pitch loudly. Early benchmarks on SWE-bench were promising, though real-world usage reports were more mixed. Devin established the category; it did not finish defining it.
Codex sits in a different spot from Claude Code. Where Claude Code wants to be present with you during development, Codex wants to be absent. You describe the task, it disappears, it comes back with a PR. If your team’s workflow already involves GitHub PRs as the unit of work, this fits naturally. If you prefer tighter collaboration during implementation, it does not.
Neither model is strictly better. They serve different working styles and different task types.
What This Means for Smaller Projects
I build Discord bots and occasionally work on lower-level systems code. For something like a Discord bot, most of what I actually spend time on is mechanical: adding commands, wiring up event handlers, updating permission checks, writing tests for state machines that manage conversation flow. These are exactly the tasks Codex is built for.
Give it a description of a new slash command, a pointer to an existing command for style reference, and a note about where the handler should be registered. The PR it returns will probably be correct or close to it. The review cost is lower than the writing cost would have been.
For systems code, the picture is more nuanced. When you are writing something that has to interact correctly with kernel interfaces, respect memory layout constraints, or handle edge cases in a protocol implementation, the mechanical parts are a smaller fraction of the total work. Understanding why the constraints exist, and verifying that generated code respects them, requires judgment that is harder to specify upfront. Codex can write the code, but you need to review it with more care.
This is not unique to AI-generated code. It is the same challenge with any junior engineer working in a domain they are still learning. The output can be syntactically and even logically correct while still missing an invariant that was never written down.
The Specification Problem
The deeper issue that emerges with async coding agents is that they make the quality of your specifications visible in a way that synchronous pair-programming tools do not. When you are working alongside an AI in real time, you can course-correct with a sentence. “No, not like that, more like how the auth middleware handles it.” The context transfer is cheap.
With an async agent, that correction does not happen until you review the PR. If your task description was ambiguous, you find out after the fact. The cost of underspecification is higher.
This is pushing some teams to get more rigorous about how they write task descriptions before handing them off to agents. That rigor tends to have compound benefits: better-specified tasks are easier to review, easier to scope, and easier to break down. The agent is forcing a discipline that good engineering practices already recommended.
For larger codebases, this often means maintaining context documents that agents can be pointed at alongside the task description. Architecture decision records, coding conventions, notes about known gotchas in particular subsystems. Not just for the agent, but because this documentation has always been valuable and consistently neglected.
What Changes and What Does Not
The shift from autocomplete to async agent is real and significant. The parts of software engineering that consist of mechanical implementation within understood constraints are now substantially automatable. This is a larger fraction of the total work than most people admit when they are in the middle of doing it.
The parts that remain human-driven are the parts that were always the interesting ones: understanding what needs to be built, deciding how it should be structured at a level that outlives the current feature, knowing when a technically correct solution is nevertheless wrong for the team or the system. These have not changed.
What has changed is the leverage available at the execution layer. An individual developer can maintain more moving parts simultaneously because the gap between “I know what needs to happen” and “the code exists and has tests” is shorter. Whether that leverage translates into faster shipping depends on whether execution was actually the bottleneck, and for most teams, it was not.
Codex for almost everything is an accurate name. The “almost” is not false modesty. It is a precise technical statement about where the boundary between agentic execution and human judgment currently runs.