What does building with Codex actually look like?

What does building with Codex look like when you review every diff?

It looks like a proposal, not a fait accompli. You describe the change, Codex reads the codebase and comes back with a multi-file diff, and nothing happens until you approve it. On a codebase with clear conventions the proposal usually lands close enough to accept with one or two adjustments. On a codebase without them, you spend the review arguing about structure instead of substance.

The propose-then-approve loop is the whole character of working this way, and it rewards preparation differently from an agent that just runs.

Why conventions matter more here

When an agent executes directly, a wrong structural choice shows up as a failing test. When an agent proposes, a wrong structural choice shows up as a diff you have to evaluate, and evaluating structure is much slower than evaluating behavior.

So the highest-value thing you can do before the first prompt is make the right structure obvious:

• A guide file (AGENTS.md) stating the rules that are not negotiable.
• A worked example of the shape you want copied, sitting in the codebase already.
• A single verification command so that after you approve, there is an unambiguous check.

With those, the proposal arrives already shaped like your codebase, and your review is about the product decisions rather than the file layout.

A real request

Add subscriptions to the billing flow for a new "team" tier.
Follow the conventions in AGENTS.md.

The second line does more work than it looks like. It tells Codex that there is a document with opinions in it, which changes what it reads before proposing.

Reading the proposal

A diff spanning six files is easy to skim and easy to skim badly. There is an order that catches the most problems for the least reading, and it is not top to bottom.

First, the migration. Schema changes are the most expensive to reverse once there is data. Check the column types, the null constraints, the indexes, and above all the foreign key to the account. If a table holding customer data has no account reference, stop there; nothing downstream can be correct.

Second, the permission policy. This is where a subtle mistake is invisible and serious. The question to ask is not "does this allow the right people" but "what does it do when it is unsure". Deny by default, and every query filtered to the current account.

Third, the query in the controller. Look for lookups that go through the model directly instead of through the current account. Thing.find(params[:id]) and Current.account.things.find(params[:id]) look almost identical and differ by whether a customer can read another customer's record by guessing a number.

Then everything else. Screens, copy, and formatting are cheap to change later and rarely dangerous.

What Codex is good at here

Consistency across files. A change that touches a model, a policy, a controller, screens, and tests is exactly the kind of thing where a human forgets the fifth file. A proposal that arrives as a complete set is easier to reason about than five separate edits.

Matching existing style. It reads the surrounding code and writes in it. On a codebase that is internally consistent this is close to free; on one that is not, it will faithfully reproduce whatever it happened to read first.

Not surprising you. The thing people actually like about this loop is that nothing runs until you say so. That is worth real money on a production codebase.

Where it goes wrong

Vague requests produce large diffs. "Improve the billing flow" is an invitation to touch fifteen files. Ask for one change at a time; the review cost of a proposal grows faster than its size.

It cannot tell a convention from an accident. If your codebase does something inconsistently in two places, the proposal picks one, and it may pick the one you were planning to remove. This is not a failure of the tool, it is a failure of the codebase to have an opinion.

Approval is not verification. A diff that reads correctly can still fail. Run the checks after approving, every time. The propose-then-approve loop makes it tempting to treat your read as the check, and your read is not the check.

The thing to keep doing after the first week

Fix the example, not the copies.

Every feature Codex proposes will resemble the nearest existing feature. That makes your worked example the highest-leverage file in the repository: improve it once and every future proposal improves. Let a flaw sit in it and you will review the same flaw ten times, approving it each time because it matches what is already there.

What this does not solve

The four things where generated code looks right and is not are exactly the four things a diff review is worst at catching, because they are correct-looking by construction. If sign-in, payments, email deliverability, and customer data separation already exist and are tested in your codebase, they are not in the diff, and the review stays about your product.

That is most of the argument in what a starter kit is.

The same loop with other agents: Claude Code, Cursor, Hermes, and OpenClaw.