Intelai
GPT-5-Codex Moves the Bottleneck to Review
The agent can write more code than a team can inspect. The constraint is no longer generation, it is the review record that makes code defensible.
The demo is the easy part.
An agent that can take a task, edit several files, run the tests, and iterate on the failures is a real change in how software gets built. It is not a change in what makes software defensible. That still depends on someone reading the diff and being able to explain why it is correct.
GPT-5-Codex is a version of GPT-5 tuned for Codex, OpenAI's coding environment. The pitch is delegated work rather than autocomplete: describe a task, let the agent plan and execute, review the result. For a team that already has tests, a build, and a review process, that is useful. For a team that does not, it is a faster way to produce code nobody can vouch for.
The unit of work changed
Autocomplete suggested a line. An agent takes a task. That shift matters more than any benchmark.
A task has a scope, a definition of done, and a set of files it may touch. The agent can hold that scope across a longer run, which means the human's job moves from typing to specifying and checking. The agent can also generate tests, which is helpful and dangerous: a test written by the same system that wrote the code can confirm the implementation rather than the requirement.
The productivity gain is real when the task is well bounded. The gain shrinks when the task crosses a system boundary, touches a security control, or depends on a piece of institutional knowledge that is not in the repository.
Review is the constraint
If generation gets cheap, review becomes the bottleneck. That is not a new observation. It is the observation that most agent adoption plans ignore.
A diff is a claim. Someone has to check that the claim is true, that the change fits the architecture, that the tests exercise the requirement, and that the error paths behave. An agent can produce more diffs in a day than a team can review in a week. At that point the team has two options: slow the agent down or lower the review standard. Lowering the standard is how a productivity tool becomes a security incident.
There is a second failure that is easier to miss. Agent-generated code often looks clean. It follows patterns, names things reasonably, and passes the linter. The defects are in the parts that are hard to see: a race condition, a missing authorization check, a retry that duplicates a side effect. A reviewer who skims for style will miss them.
The agent can write faster than the team can verify. The team's review capacity is the real limit.
What a defensible workflow looks like
The workflow that works is boring and specific.
Scope the repository. The agent should work in a branch with a build it can run, tests it can execute, and a clear list of files it may change. A broad "fix the codebase" task is not a task. It is a wish.
Write a task contract. State the goal, the constraints, the files in scope, the tests that must pass, and what the agent must not touch. Include the security boundary: no changes to authentication, authorization, secrets, or deployment configuration without a separate review.
Require a record. The record should include the task, the plan, the diff, the test output, the model and version, and the human who approved the change. That record is what lets you answer an audit question six months later. It is also what lets you debug a bad change.
Keep the human merge. The agent can propose a merge. A person with domain knowledge should approve it. The approval is not a formality. It is the control.
Have a rollback path. If the change breaks something, you need to know how to revert it without reconstructing the agent's reasoning.
What changes for regulated work
DFARS and CMMC do not prohibit AI-written code. They require evidence that the code is protected and the process is controlled. An agent can fit that requirement if the record shows who approved the change, what was reviewed, and what tests passed.
The data handling question is separate. A hosted coding agent sees your repository, your prompts, and sometimes your build output. If the repository contains controlled unclassified information or export-controlled technical data, that is a boundary question, not a productivity question. An on-premises model avoids the egress and creates a provenance question instead. Either way, the tool has to fit the data boundary you already have.
The supply chain question is the third. A model is a dependency. You need to know which version produced a change and whether you can reproduce the result. A team that cannot name the model version in its commit record has a supply chain gap.
How to start
Measure review capacity before you buy seats. If the team cannot review the diffs it already produces, an agent will not help. It moves the queue.
Start with low-consequence repositories: internal tools, test harnesses, documentation. Build the task contract and the record there. Then move to code that touches a customer or a control boundary.
Train reviewers to read for the failure modes agents produce: missing authorization, duplicated side effects, silent exception handling, tests that assert the implementation instead of the behavior. That training is more valuable than a prompt library.
The model is not the developer. It is a fast contributor with no memory of the last incident and no accountability for the next one. The review is what turns its output into engineering.