The conclusion I reached this week: when I changed my YouTube video pipeline from a daily cadence to three times per week, a Codex review found four defects. A second review, run the next day after I fixed those four, found four more. All eight fell into the same category. I had built assumptions about external system behavior directly into the code, and I couldn't see them because I built the system knowing how it was supposed to work. A reviewer who doesn't share that knowledge can ask questions the author doesn't know to ask.
This article is the four categories, one example each, and what I'd do differently.
The pipeline and why the cadence changed
The pipeline picks one video spec from a queue, runs a quality gate on it, and if it passes, uploads the video and commits the result back to the repository. It was running daily. After observing that the pipeline was spending publish slots on rejected specs, I cut the cadence to three times per week — Sunday, Tuesday, Thursday — to give the queue more time to fill with passing specs between runs. That's a structural change: the scheduling logic, monitoring thresholds, and gate behavior were all designed for a daily run.
I ran a Codex review on the pull request. It found four issues. I fixed those and ran a second review. It found four more. Eight total. Every single one was an assumption about how some external system behaves.
