TL;DR — Treat Codex like a fast junior engineer with no long-term memory: give it tight scope, repo context, and explicit tests. The first week is about building the feedback loop — sandboxed tasks, deterministic verification, and a short prompt library — not chasing headline demos.

Week one with a new coding agent is where most teams either build a durable habit or quietly let the tool rot in a side tab. The difference is rarely the model. It’s the scaffolding around it: the way you scope tasks, the way you verify output, and the small library of prompts you accumulate by day five. This post is a day-by-day plan built for engineers who already ship code for a living and want Codex to actually pay back the subscription.

Day 1: Set Up the Repo Context Properly

The single biggest mistake on day one is treating Codex like a chatbot. It isn’t. It’s a tool that reads files, runs commands, and writes diffs. The quality of every later day depends on how you prepare the repository it operates in.

Start with a minimal but real AGENTS.md at the root. This is the file Codex reads first when it opens a session. Keep it short, opinionated, and specific to your stack:

# AGENTS.md

## Build
- Use `pnpm install` (not npm). Node 20 LTS.
- Run `pnpm typecheck` before any commit.

## Test
- Unit: `pnpm test` (vitest).
- Integration: `pnpm test:int` requires Docker; starts Postgres on :5432.

## Style
- 2-space indent, single quotes, no semicolons.
- Prefer `fs/promises` over `fs`.
- Never edit files under `generated/`.

## PR Conventions
- One logical change per PR.
- PR title format: `[area] short imperative`.
- Include a "How I tested" block in every PR body.

That file will save you from dozens of “why did it use var” moments. The official OpenAI Codex CLI docs explicitly recommend project-level instructions and treat them as a first-class configuration surface.

Next, wire up the CLI properly. The install is unremarkable, but the auth flow is what trips people up:

# Install
npm i -g @openai/codex

# Authenticate (opens browser)
codex login

# Confirm
codex --version

For teams, prefer the API key path with a service account and a spending cap, rather than personal logins. You’ll thank yourself on day seven when you want to audit usage.

Patterns in Production: The Context Window Is the Product

A working engineer’s instinct is to dump the whole repo into context. Don’t. Codex works best when you point it at the relevant slice. Two habits pay off immediately:

  • Pass file globs explicitly when launching a task: codex "refactor the billing reconciler under src/billing/".
  • Keep a codex/ directory with task briefs as markdown. When a task fails, the brief survives; when a task succeeds, you have a template for the next one.

Day 2: Learn the Three Task Shapes

By the end of day two you should be able to categorize every task you give Codex into one of three shapes. This taxonomy comes from watching dozens of PRs flow through code review.

Shape 1: Greenfield in a Sandbox

Generating a new module, script, or scaffold where there’s no existing code to break. Examples: a new Cloudflare Worker, a fresh SQL migration, a brand-new CLI subcommand. Here Codex is at its best because there’s nothing to disagree with.

Greenfield work is where Codex feels magical. The mistake is assuming that magic transfers to the next shape.

Shape 2: Mechanical Edit in Existing Code

Renaming a symbol across a codebase, upgrading a dependency’s API surface, converting await chains to Promise.all. Boring, repetitive, and exactly what Codex was made for. The trick is to narrow the surface: point Codex at the directory, tell it the old API and the new API, and let it rip.

Shape 3: Reasoning-Heavy Refactor

Replacing a hand-rolled retry loop with a circuit breaker, splitting a god class, introducing a repository pattern. This is where Codex needs the most babysitting. You’ll spend more time steering than generating.

Day 2 Exercise

Pick one task from each shape and run all three before dinner. Note in a scratch file: how many turns it took, how many tokens it burned, and what the first wrong answer was. That file becomes your personal Codex benchmark.

Day 3: Build a Prompt Library You Won’t Be Ashamed Of

Day three is when most engineers write their first truly useful prompt. It’s also when they realize that “write me a function to parse CSV” was leaving 80% of the model’s capability on the table.

A good Codex prompt has four parts:

  1. Goal — one sentence, imperative.
  2. Context — files, constraints, prior decisions.
  3. Definition of done — what success looks like, including tests.
  4. Out of scope — what the agent should not touch.

Example, refined over a real billing migration:

Goal: Replace the manual retry loop in src/payments/charge.ts with
the shared `withRetries` helper from src/lib/retry.ts.

Context:
- Charge failures are classified in src/payments/errors.ts.
- Latency budget per request is 800ms; the helper caps at 3 retries.
- We do not want to change the public function signature.

Definition of done:
- All call sites in src/payments/* updated.
- `pnpm test src/payments` passes.
- No new dependencies added.

Out of scope:
- Do not modify src/lib/retry.ts itself.
- Do not touch the Stripe adapter.

Compare that to the prompt most engineers type first:

“use the retry helper in charge.ts”

The second version will sometimes work. The first version works on a Monday morning after a bad weekend.

Architecture: Prompt Library as Code

Store these briefs in codex/tasks/ as markdown. Version them. When a brief produces a great PR, promote it to a template. When it produces a bad one, annotate it. Within a month you’ll have something better than any “awesome-prompts” repo on GitHub, because it’s tuned to your codebase.

Day 4: Verification Is Your Job, Not Codex’s

This is the day the honeymoon ends. Codex will produce code that compiles, passes lint, and even has tests — and still be subtly wrong. The model does not know your business. It knows what “looks right.”

The cure is a verification pipeline that Codex cannot opt out of. At minimum:

# In a Codex task, make this the explicit verification step:
pnpm typecheck && pnpm test && pnpm lint && pnpm build

Better: put that behind a single make verify target so Codex can’t accidentally skip a phase. Even better: add a smoke test that hits a real Postgres in CI, the way the Bytebase engineering team describes for database-touching changes.

Patterns in Production: The “Trust Ladder”

I think of Codex output in four rungs:

  • Rung 1 — Trivial: doc comments, type annotations, formatting. Trust by default.
  • Rung 2 — Mechanical: renames, API migrations. Trust after a glance.
  • Rung 3 — Logic: business rules, validation, error handling. Trust only with tests.
  • Rung 4 — Security: auth, payments, PII handling. Trust zero; treat Codex as a draft author.

If your team can’t articulate which rung a task is on before starting, you’re not ready to use Codex on it.

Day 5: The Multi-Step Workflow

By day five, single-turn prompts start to feel small. The real productivity unlock is chaining Codex across a feature branch. A pattern that has worked well for me:

  1. Plan turn: ask Codex to read the issue and produce a step-by-step implementation plan in codex/plans/<id>.md. No code yet.
  2. Scaffold turn: approve the plan, then ask Codex to generate the file structure and stubs.
  3. Implement turn: one logical change per turn, with verification between each.
  4. Review turn: ask Codex to review its own diff against the plan and flag anything missing.

This is essentially how the GitHub Copilot Workspace and similar agentic tools are architected under the hood. Splitting work into small, verifiable turns also keeps individual token bills sane — a long, rambling conversation costs more than five tight ones.

A Concrete Multi-Step Example

Say you’re adding webhook signature verification to a Go service.

  • Plan: Codex reads internal/webhooks/, produces a 7-step plan covering the verifier, the middleware, tests, and config wiring.
  • Scaffold: empty files created, interfaces defined, no implementation.
  • Implement per file: verifier first, with unit tests, then middleware, then config.
  • Review: Codex re-reads the plan, confirms each step landed, and proposes commit messages.

The whole feature ships in about 25 minutes instead of the usual two hours. The bigger win is that the plan survives even if you reject every line of generated code — you can hand it to a junior engineer or do it yourself on a slow day.

Day 6: Cost, Latency, and the Boring Stuff

Day six is when finance asks questions. Here’s how to answer them.

The cost drivers, in order:

  1. Conversation length. Long, exploratory sessions cost more than focused ones.
  2. Model selection. Codex offers multiple model tiers; reserve the strongest for reasoning-heavy tasks.
  3. Context bloat. Re-pasting large files every turn.
  4. Wasted runs. Tasks you abandon because the prompt was bad.

The levers you actually control:

  • Set a hard --max-turns on long sessions so a stuck loop doesn’t burn budget.
  • Use the smaller model for Shape 1 and Shape 2 tasks; escalate to the larger one for Shape 3.
  • Write briefs, not chat. Each brief should be reusable.
  • Audit weekly. The OpenAI dashboard breaks down spend by model and day; export it and look for outliers.

A reasonable target for a working engineer is under $15 of Codex spend per merged PR once you’ve found your rhythm. Teams I’ve talked to who are well above that number are almost always using the strongest model for Shape 2 work.

Latency Realities

On greenfield tasks Codex is fast enough that you can stay in flow. On reasoning-heavy refactors it can feel slow — multi-minute pauses are normal for the larger model. The fix is structural: start those tasks in the morning, kick them off, and do code review while you wait. Don’t context-switch to Slack every 30 seconds; that is a worse productivity tax than the latency itself.

Day 7: Plugging Into the Real Workflow

By day seven, Codex should be touching your real branches. A setup that has held up across several teams:

  • Feature branches only. Never point Codex at main.
  • Pull requests, not direct pushes. Let CI and humans review.
  • A CODEOWNERS-adjacent rule: for any file under src/payments/, src/auth/, or infra/, Codex output requires an explicit human approval before merge. This is your Rung 4 enforcement.
  • A weekly retro. What worked, what didn’t, what briefs need updating.

The other day-seven ritual: write a RUNBOOK.md for your team. It should answer, in plain language:

  • When should engineers reach for Codex vs. just typing the code?
  • Which prompts have worked well, and which are banned?
  • What’s the escalation path when Codex produces something subtle and wrong?

This is the kind of artifact that turns “we tried AI” into “we have a practice.” The folks at Stripe’s engineering blog have written about similar lightweight governance for code-generation tools, and the principles translate directly.

Key Takeaways

  • Day one is about repo context, not model selection. A good AGENTS.md pays for itself by day three.
  • Categorize every task into greenfield, mechanical, or reasoning-heavy. Each has a different prompt, model, and trust level.
  • Write briefs, not chat. Goal, context, definition of done, out of scope. Store them as files in the repo.
  • Treat verification as your job. Use a make verify target Codex cannot skip.
  • Chain Codex across plan → scaffold → implement → review turns. Smaller turns cost less and fail less.
  • Track cost per merged PR and set hard ceilings on conversation length.
  • Land Codex into the team via a RUNBOOK.md and CODEOWNERS-style guardrails for sensitive paths.

Further Reading