Basically they shift the process into the code generation by abstraction. But if agents write intent and acceptance criteria into the PR, and this seems to be the case, the point is moot, really. Either you check them there or in the PR and if the code change is acceptable still needs sb to decide.

If something breaks, you likely want to be able to at least react and roll-back?

The agents can check this and mitigate.

Question is, what is more effective? Using less tokens, writing cleaner code or, and I think that one matters most, number of inline comments on a PR the agent created that got actually fixed, ie defects. The time and token that go into the review/push cycle before merging. I personally would focus on the latter.

Makes a lot of sense to have the small improvements coming. So running /codex review again on the fixes is acting as a judge, correct? Wouldn’t it be worth considering flipping the reviewer again, so the fixes get an adversarial review again?