Varun Vemulapalli

Day 64 of 100 ยท Phase 8: OpenAI Codex

Codex for tests, refactoring and code review

2 min readBy Varun Vemulapalli

The riskiest code in a company is often the code nobody dares to touch.

The safe way to change it: pin down what it does today, clean it up, then get a second pair of eyes. Codex helps with all three.

Video explainer ยท 1:35
Key takeaway

Have Codex write tests first, refactor second and review third, and keep a human as the final approver.

Day 64 visual: Codex for tests, refactoring and code review
The visual from the original post.

The concept

  • Tests: small programs that check the code gives the expected answer.
  • Refactoring: restructuring code to make it clearer without changing what it does.
  • Code review: someone (or something) reads the change and flags problems before it ships.

The order matters. Tests first means you can prove the refactor changed nothing.

Walkthrough: a hotel-booking price module

Illustrative module: one long function prices a stay.

  • $100 per weeknight, $120 per Friday or Saturday night.
  • 7 nights or more: 10% off the total.

Step 1: tests. "Write tests that capture what calculate_price does today. Don't change it." Codex adds cases like:

  • 2 weeknights + 1 Saturday = $200 + $120 = $320
  • 7 nights (5 weeknights + 2 weekend) = $740, minus 10% = $666
  • 6 nights gets no discount; 7 nights does

Run them. They pass, so they describe today's behavior.

Step 2: refactor. "Split calculate_price into nightly_rate and stay_discount. Keep every test passing." Codex edits, reruns the tests and shows the diff.

Step 3: review. Two places:

  • CLI: type /review. Codex reviews your uncommitted changes, focusing on behavior changes and missing tests.
  • GitHub: with your repo connected, comment @codex review on a pull request. Codex posts a normal GitHub review flagging only high-priority issues. Automatic reviews are optional.

You can add a "Code Review Rules" section to AGENTS.md (Day 63), e.g. "Discount changes need a test at exactly 7 nights."

An AI review is a second pair of eyes, not a sign-off. A person still approves the merge.

Where you see it at work

  • Banking: tests around fee calculations before an old module is cleaned up.
  • Insurance: reviewing every change to claim-payout logic.
  • Healthcare: tests on dosage-unit conversions before refactoring.
  • Retail: pinning down promotion rules before a pricing rewrite.
  • Product owners: "tests added and reviewed" in your definition of done.

Try it today (10โ€“15 min)

1. In a practice repo, pick one function and ask Codex for tests of its current behavior.
2. Commit, then ask for a small refactor that keeps the tests green.
3. Run /review and decide whether you agree with each finding.
4. Read the GitHub review setup: https://learn.chatgpt.com/docs/third-party/github
5. Slash commands reference: https://learn.chatgpt.com/docs/cli/slash-commands

In one sentence

Have Codex write tests first, refactor second and review third, and keep a human as the final approver.

Which part of your system needs tests before anyone touches it? ๐Ÿ‘‡