How Codex Changed the Way I Build and Ship Software

The practical workflow changes that matter when a coding agent can inspect a repository, edit files, run tools, and verify its own work.

The biggest change Codex made to my work was not typing code faster.

It changed the level at which I communicate with the development environment.

With autocomplete, I still decide the next line. With chat, I ask for an isolated function and move it into place. With a coding agent, I can describe an outcome, let the agent inspect the repository, ask it to form a plan, make coordinated edits, run the relevant checks, and review what changed.

That does not remove engineering. It moves more of my attention from producing syntax to defining the problem, supplying context, setting boundaries, and evaluating the result.

I previously wrote about switching from Claude Code to Codex and about the agentic loop. This article is about what changed after the novelty wore off: the working habits that make an agent useful on real software.

I Start With the Outcome

My old task notes often described implementation:

Add a boolean to this component, put an if around this block, then update the button.

That is sometimes appropriate, especially for a tiny change. But it can also encode a solution before the repository has been inspected.

With Codex, I get better results by describing the outcome first:

Logged-out users who open a saved project should see a read-only preview and a clear sign-in action. Existing authenticated behavior must remain unchanged. Add coverage for both states and run the relevant checks.

This gives the agent room to find the real ownership boundaries while preserving what matters. It also gives me a better review target. I can ask whether the behavior is correct instead of merely checking that the requested lines appeared.

The prompt does not need to be long. For meaningful work, four pieces are usually enough:

  • Goal: what should change for the user or system?
  • Context: which files, errors, examples, or constraints matter?
  • Boundaries: what must remain unchanged or requires approval?
  • Done when: what evidence proves the task is complete?

That structure is also reflected in OpenAI’s current Codex prompting guidance.

Exploration Became Part of the Task

Developers often receive a ticket with an assumed file or solution. The first real job is understanding the system.

I now explicitly let Codex explore before editing when the change crosses boundaries. It can search for types, routes, call sites, tests, and configuration; trace data flow; and report which parts of the repository actually own the behavior.

This is particularly useful in unfamiliar code. Search is cheap. A wrong edit based on a guessed architecture is expensive.

The useful output of exploration is not a directory dump. It is a small model of the change:

  • where input enters;
  • where state is transformed;
  • which component or service owns the decision;
  • what public contract may change;
  • and which tests currently protect it.

Once that model is correct, implementation becomes much more predictable.

Planning Became an Interface

For a complex feature, I often use Plan mode before allowing edits. The agent inspects the repository, resolves discoverable facts, asks about actual product choices, and produces a decision-complete implementation plan.

The plan is not ceremony. It is the interface between intent and execution.

A good plan exposes wrong assumptions while they are still cheap. It tells me whether the agent intends to change a public type, add a migration, reuse an existing component, or alter caching behavior. I can correct the direction before reviewing a large diff.

For small, obvious tasks, this would be overhead. I do not plan a typo fix. I plan work where an incorrect assumption could spread across multiple files or create a product tradeoff.

Repository Guidance Beats Repeated Prompting

Every codebase has knowledge that should not depend on my remembering to paste it:

  • the commands that actually work;
  • architectural boundaries;
  • formatting and naming conventions;
  • generated files that should not be edited;
  • security constraints;
  • and what “done” means for a change.

Codex supports AGENTS.md files for this durable repository guidance. A root file can describe shared conventions, while a more specific file deeper in the tree can add local instructions for that subtree. The closer guidance takes precedence.

I treat this as executable team memory. When the agent repeats a mistake, I ask whether the correction belongs in the task prompt or in repository guidance. If the rule should apply to the next developer and the next task, it probably belongs in AGENTS.md.

Short and accurate is better than encyclopedic. A giant instruction file becomes another place for important information to disappear.

I Delegate Verification, Not Judgment

The most valuable agent workflow is not:

Write this feature.

It is:

Implement this feature, add or update the relevant tests, run them, inspect the resulting diff, and report anything you could not verify.

Codex can execute the feedback loop: edit, build, test, inspect the failure, adjust, and test again. That catches obvious mistakes before they become my review burden.

But a green test suite does not mean I stop thinking. I still review product behavior, architecture, security boundaries, migration risk, and whether the tests prove the right thing. The agent supplies evidence. I make the acceptance decision.

This distinction matters. Delegating verification increases leverage. Delegating responsibility without reviewing evidence creates fragile software faster.

I Review Diffs as Decisions

An agent can create a larger correct-looking diff quickly. That makes review discipline more important.

I review in layers:

  1. Intent: does the changed behavior match the request?
  2. Architecture: is the logic placed in the correct layer?
  3. Contracts: did any API, schema, or user-facing behavior change unexpectedly?
  4. Failure modes: what happens on invalid input, unavailable services, or partial state?
  5. Evidence: which tests, builds, and manual checks ran?
  6. Diff quality: is there unrelated churn or unnecessary abstraction?

Codex can help review its own uncommitted changes and can run a separate review pass, but I do not treat self-review as independent proof. It is another chance to find mistakes before human acceptance.

Parallelism Is Useful When the Work Is Actually Independent

Coding agents make parallel investigation possible. One agent can inspect test gaps while another examines security risks and another traces an unfamiliar subsystem.

The benefit is not “more agents” by itself. It is keeping bounded, noisy research out of the main thread and bringing back concise findings.

Parallel work is a good fit for:

  • read-heavy exploration;
  • independent review dimensions;
  • documentation research;
  • log or failure analysis;
  • and separate test suites.

It is riskier when multiple agents edit the same files or make overlapping architecture decisions. Coordination overhead and merge conflicts can erase the speed gain. I use parallelism when the work divides cleanly, not as a default performance trick.

Permissions Are Part of the Workflow

An effective agent can run commands and change files. That capability needs boundaries.

Codex uses sandboxing and approvals so the scope of action can match the task. I keep permissions narrow by default, especially around network access, external systems, credentials, deployment, and destructive commands.

A useful principle is reversibility. Reading files and running local tests are low-risk. Deleting data, changing production state, sending messages, or publishing releases require much stronger intent and verification.

The agent should not need broad authority to be useful. Good context and scoped permissions usually produce a better workflow than handing every task unrestricted access.

The Bottleneck Moved

When code generation becomes faster, other bottlenecks become visible:

  • unclear product decisions;
  • missing acceptance criteria;
  • slow or unreliable tests;
  • undocumented repository conventions;
  • weak observability;
  • and review capacity.

This is why “AI writes code faster” understates the change. The organization of engineering work starts to matter more. A repository that has clear boundaries, fast verification, useful documentation, and explicit contracts is easier for both humans and agents to change safely.

Agents reward good engineering hygiene.

My Current Loop

For a non-trivial task, my default loop is now:

  1. State the outcome, constraints, and evidence required.
  2. Let Codex inspect the relevant repository paths.
  3. Resolve product choices before implementation.
  4. Review the proposed approach for architecture and scope.
  5. Let the agent implement and verify.
  6. Inspect the behavior, diff, and test evidence.
  7. Ask for a focused review of risks or missing coverage.
  8. Commit only when I understand and accept the change.

I still write code. Sometimes that is the fastest path, and sometimes writing the critical piece myself is the best way to understand it. But I no longer assume manual typing is the default unit of progress.

The unit is a verified change.

That is how Codex changed the way I ship software: less time translating an already-understood decision into syntax, more time making the decision clear and proving the result is right.