# Coding Agents Change the Unit of Software Work > AI coding tools have been judged where code appears on screen. The boundary moves when the agent owns a task instead of a snippet. By Alain Tural, Founder, Pixedi. Published 2025-05-19. Canonical: https://alaintural.com/writing/coding-agents-change-the-unit/ For years, AI coding tools have been judged at the point where code appears on screen. Autocomplete a line. Generate a function. Explain a stack trace. Produce a snippet that a developer then copies into the real project. Codex changes the boundary. OpenAI's May 16 research preview runs each coding task inside its own cloud sandbox with the repository already loaded. The agent can read and edit files, execute commands, run tests, linters and type checkers, then return a diff or propose a pull request. It can work on several tasks in parallel while the developer continues elsewhere. The interesting unit is no longer the completion. It is the software task. ## A code answer is not a software change Generating code and changing a codebase are related, but they are not the same problem. A function can look correct in isolation and still break an import, violate a type constraint, fail an existing test, duplicate a utility that already exists, or ignore a project convention that only becomes visible after reading several files. Software work has state around the code: repository structure, dependencies, tests, build scripts and branch state. So does the evidence that the requested change actually works. SWE-bench captured this difference before today's coding agents. Its tasks start from real GitHub issues and real repositories. An agent has to modify the codebase so previously failing tests pass without breaking tests that already worked. SWE-bench Verified tightened that evaluator by having professional developers remove underspecified or broken tasks from the dataset. The result is much closer to a software change than a code-generation benchmark. That evaluation shape now looks increasingly like the product itself. ## The environment becomes part of the model's capability Codex does not receive only a prompt. Each task receives an environment. OpenAI says a Codex task runs in an isolated cloud container preloaded with the user's repository and development setup. Inside that sandbox, the agent can inspect files, edit them and execute commands, including tests, linters and type checkers. The codex-1 model was trained on real-world software-engineering tasks and to iteratively run tests until it reaches a passing result. That makes the environment part of the capability stack. The model decides what to change. The repository gives it context. The terminal gives it feedback. Tests provide an external signal about whether the change worked. The sandbox limits where execution can happen. The final diff gives the developer something concrete to inspect. Remove those pieces and the same model becomes a different engineering system. We saw an earlier version of this shift in April with Codex CLI. OpenAI described it as a lightweight local coding agent that connects reasoning models such as o3 and o4-mini directly to a developer's computer and code. The interface was intentionally minimal: give the model repository access and a terminal, then let reasoning interact with execution instead of stopping at generated text. Anthropic's Claude Code, released in research preview in February, points in the same direction. Coding models are moving toward environments where reading, modifying and testing an existing project are normal operations rather than something the developer manually performs after every response. ## Verification changes the meaning of output The most useful output of a coding model used to be text. For an agent, the real output may be a changed repository state. This changes what I want to inspect. I care less about whether the generated explanation sounds convincing and more about which files changed, what commands ran, which tests passed, and whether the change remained inside the requested scope. OpenAI says Codex provides citations to terminal logs and files so users can verify what the agent did. When a task finishes, the result can be reviewed, refined or exported as a diff and turned into a GitHub pull request. That is a better contract for engineering work than a confident paragraph saying the bug has been fixed. A software agent should leave evidence. The same applies to production automation. If a Blender export or game localisation task claims success, I still want the artifact and a machine-checkable validation result. Natural-language output is useful for communication, not proof. ## The developer moves from author to supervisor for some tasks This does not mean developers stop writing code. Some categories of work can move to a different interaction model. A small bug fix can be delegated while I investigate another issue. A test can be added in a separate task. A repository question can be assigned without manually collecting files into a chat. Several independent changes can run in parallel because each Codex task gets its own isolated environment. The developer's job then moves upward for those tasks: specify the outcome, provide the right environment, review the evidence and decide whether the patch should enter the codebase. That resembles ordinary engineering delegation: define the right change, understand constraints, review implementation and catch consequences outside the narrow task description. Coding agents make that delegation available as a software primitive. ## Repository instructions become part of the production interface There is another detail in the Codex release that I think will matter more over time: AGENTS.md files. OpenAI recommends putting repository-specific guidance into these files so Codex can learn how to navigate the codebase, which commands to run and which project conventions to follow. This looks like documentation for a model, but it is closer to an interface between the repository and future agents. Teams already encode knowledge in README files, CI configuration, linters, tests and build scripts. Agent-readable instructions become another layer of that operational documentation. Clear test commands, deterministic setup and machine-checkable conventions should make a repository easier for both humans and agents to modify. The quality of the codebase becomes part of agent performance. ## Current agents still need tight review Codex is a research preview, and its current limitations matter. OpenAI says the cloud agent cannot yet receive image inputs for frontend work and cannot be course-corrected while it is executing. At launch, task containers have no internet access after setup. The company recommends reviewing generated code before integration. Those constraints are useful reminders that delegation is not autonomy without supervision. A passing test suite can still miss a bad product decision. A change can satisfy the local request while creating architectural or maintenance problems outside the evaluator. For that reason, I would give coding agents bounded tasks with strong verification before trusting them with broad architectural changes. The better the task can be checked by the environment, the better fit it is for delegation. ## My takeaway: the task is replacing the prompt as the unit of interaction I think coding interfaces are moving through a clear progression. Autocomplete operated on tokens and lines. Chat operated on questions and answers. Agentic coding operates on tasks and resulting repository state. That changes product design around the model. The important components become sandbox creation, repository context, execution tools, tests, logs, diffs, task queues and review surfaces. The model is one part of the system that turns an instruction into a proposed state change. For founders building developer tools, I would design around that state change rather than around a better chat window. For developers, I would invest in the things that make delegation verifiable: tests, reproducible environments, clear project instructions and small reviewable diffs. My expectation is that coding agents will keep moving toward longer tasks, but the biggest gains may come from changing how software work is packaged around them. A model that can edit files is useful. A system that can take a bounded engineering task, work inside the correct environment, verify the result and return reviewable evidence is a different category of tool. The code is still important. The unit of work is becoming the task that changes it. ## Sources 1. OpenAI, *Introducing Codex*, 16 May 2025. 2. OpenAI, *Addendum to o3 and o4-mini system card: Codex*, 16 May 2025. 3. OpenAI, *Introducing OpenAI o3 and o4-mini* / Codex CLI, 16 April 2025. 4. OpenAI, *Introducing SWE-bench Verified*, 13 August 2024; updated 24 February 2025. 5. Anthropic, *Claude 3.7 Sonnet and Claude Code*, 24 February 2025.