Your coding agent finished. What would make you reject the result?
A discussion on a dev community forum explores reasons for rejecting coding agent results, even when code and tests appear satisfactory. One scenario involves an agent building a CSV export that passes tests and is approved, but then a requirement changes to exclude personal email addresses. Another point raised is the distinction between partial completion and an unknown outcome, where restarting a process after a failed announcement could duplicate a release, or a timed-out creation request requires checking if the release exists before retrying. These are proposed tests for reviewing agent-generated work.
Unlike typical discussions focusing on code correctness, this forum post highlights the critical, often overlooked, reasons for rejecting agent-generated code due to evolving requirements or uncertain process states.
时间与来源
时间显示为 UTC
显示时区：UTC
本地时区尚不可用，暂时显示 UTC。
发布当时偏移：UTC+02026年10月9日 00:57 UTC
收录当时偏移：UTC+02026年10月9日 06:00 UTC
- 发布
- 2026年10月9日 00:57
- 收录
- 2026年10月9日 06:00
- 来源类型
- 开发者社区
- 档位
- 社区
- 信源状态
- 同步延迟
档位是按信源手工设定的编辑判断，不是逐条打分。
讨论趋势
百分比基于采集到的讨论信号，不代表新增评论数或独立参与人数。曲线仅用于同一话题在不同时段的比较。
Here’s a review scenario I’d want to test: an agent builds a CSV export, the tests pass, and someone approves it. Then the requirement changes: personal email addresses must be excluded.
Nothing in the code has changed. The old tests are still green. But I wouldn’t accept the result against the new requirement.
That’s why I’d want a completion record to tie together the code revision, the requirement it was checked against, and the review. Not just a green task.
A few other checks I’d add:
- Let a second worker take over, then have the first return. Its old claim shouldn’t let it overwrite the current work.
- Approve a preview deployment, then attempt production. The approval should not carry over.
- Restart without the original chat. Can the next worker identify what’s finished, what’s uncertain, and what it’s allowed to do next?
A useful distinction came up in a discussion on my earlier checklist: partial completion isn’t the same as an unknown outcome. If a release was created but its announcement failed, restarting everything could duplicate the release. If the creation request timed out, we first need to establish whether the release exists.
I’d want recovery to follow that distinction, rather than a single “retry” button.
These are proposed tests, not results from a benchmark. When reviewing agent-generated work, what makes you send it back even though the code and tests look fine?