Provide context to the reviewer
A review starts with the change you want to assess and the expected behavior. Provide input, desired outcome, involved files, and checks already performed. The reviewer needs to know what can be considered correct—not just receive a huge directory.
A second AI, like Codex, can offer another analysis, but it doesn’t automatically become more reliable. Treat its suggestions as hypotheses that should point to a concrete scenario. Value appears when the review finds something that can be demonstrated.
Why learn
Context reduces generic comments and prevents the reviewer from proposing changes that contradict the goal. It also limits the cost and scope of the review.
✓ Do
Relate each finding to a behavior.
✗ Avoid
Accept a review because it sounds convincing.
Key concepts
Prepare a comparable baseline
In a Git project, the diff shows what changed. Before reviewing, check the current folder and the repository state. Separate your own files from change-related materials that should not be published. A review of unversioned changes may include new files.
With the Codex CLI installed and authenticated, consult the local help and use a review compatible with the available version. The example below shows a review of changes that are not committed. It doesn’t replace testing the application.
Why learn
A clear baseline prevents the reviewer from comparing the wrong files or treating old code as part of the current change. Checking status also avoids accidentally publishing setup data.
A way to apply
- Describe the change and choose a baseline.
- Request evidence, reproduce, and classify the findings.
- Apply the smallest fix and repeat the scenario.
Key concepts
Request actionable findings
Ask each finding to describe the trigger, effect, location, and how to reproduce it. Prefer “two clicks send the same order twice” over “improve robustness.” The first statement allows building a test; the second does not define behavior.
Differentiate functional errors, maintenance, and style preferences. All can matter, but they shouldn’t all receive the same priority. An export that includes records from another customer requires a different response than a variable name that’s not clear enough.
Why learn
Actionable findings make the review a decision tool. You can prioritize by impact and verify whether the smallest change actually resolved the case.
git status --short
git diff --stat
# Check the options of the installed version:
codex review --help
# Review changes that are not committed yet:
codex review --uncommitted
Key concepts
Test repetition and interruption
Many errors appear on the second run. If an order is resent after a connection failure, the operation needs to know whether it has already been processed. An idempotency key identifies the same intent to avoid creating two outcomes.
Another scenario is an interruption in the middle of an update. Recording half of an operation can leave the data inconsistent. In exercises, simulate the failure between steps and observe the final state. Don’t conclude that a flow is correct just because it works once.
Why learn
These scenarios are easy to forget in demos. Testing repetition and interruption reveals problems that a superficial read or a single execution doesn’t show.
✓ Do
Save the case that reproduced the error.
✗ Avoid
Correct the style and critical failure as if they were the same.
Key concepts
Get out of a retry cycle
When a correction fails repeatedly, record what has already been tried and the result of each attempt. Reduce the problem to a small entry that still fails. Hand over this case for a new review.
Switching models without organizing the evidence can simply restart the same cycle. The most important change is to provide a smaller experiment, one hypothesis at a time, and a clear stop condition. Preserve the case that was failing after the correction.
Why learn
A minimal case reduces the number of possible explanations. It lets you distinguish a logic problem, an incompatible configuration, and an unavailable dependency.
| Criterion | Expected evidence |
|---|---|
| Reproduction | Two identical inputs demonstrate the problem. |
| Fix | The same intent produces a single effect. |
| Conflict | Divergent content is not silently discarded. |
Key concepts
Practice: find a duplication
Imagine a fictitious form that adds requests to a list. The same identifier can arrive twice. Describe how to reproduce the duplication and propose a rule that keeps only one effect for the same request.
It’s not enough to hide the second line on the screen. The rule must act on the operation record. Also explain what to do when the identifier is the same but the content has changed: this requires handling a conflict, not silently discarding the information.
Why learn
The practice links review, testing, and business behavior. You learn to verify the real effect of the correction and to recognize when two seemingly identical entries represent different situations.
Your exercise
The R-14 order, “review catalog,” arrives twice due to a new send attempt. Then R-14 arrives with “review contract.” Define the expected result for each receipt.
Download practice sheetCheck the commented answer
First R-14: record the order. Second R-14 with identical content: return the existing record, without duplicating. Third R-14 with different content: flag a conflict for review. Test the count and the stored content after the three entries.
Check your understanding
The reviewer wrote, “there is a risk of duplication.” What’s missing?
Key concepts
What stays from this module
A short report with a reproduced issue and its minimal fix.
- ✓ Two identical inputs demonstrate the problem.
- ✓ The same intent produces a single effect.
- ✓ Divergent content is not silently discarded.
Progress records your reading. The practice is completed when you check the submission.