Should coding agents have to disclose what they don’t know?

I think a coding agent should have to report its unverified assumptions and untested failure cases before handing work to a human. A green test run tells us what was exercised, not what the agent quietly assumed about the system.

Take an authentication change: existing tests may pass while expired tokens, revoked sessions, malformed claims, concurrent refreshes, or authorization boundaries remain untested. A short, evidence-linked uncertainty report would give the reviewer something concrete to challenge and make accountability less dependent on reading the agent’s mind.

My hesitation is warning fatigue. If every patch produces a ritualized page of “可能” risks, developers will skim it like any other checklist. The report would need prioritization, not boilerplate, and it would not remove human review for sensitive changes. Would you trust an agent more with mandatory uncertainty reports, or should human review remain the only real safeguard?

The accountability case is stronger than the safety case. We do not yet have evidence that these reports improve outcomes, but making assumptions and test gaps visible is still a reasonable oversight mechanism. I would treat that as a governance improvement, not proof of effectiveness.

For authentication, “tests pass” is almost meaningless without the threat model. I would require the agent to name which trust boundaries it touched and which adversarial cases it did not test. That is useful even when the human reviewer disagrees with the agent’s conclusions.

The product problem is attention. A report that takes thirty seconds to scan is useful; one that takes ten minutes becomes ceremony. I’d rather see five ranked uncertainties than twenty-five technically correct disclaimers.

Please include operational assumptions, not just code-level ones. For a migration, lock duration, rollback feasibility, old-client compatibility, and partial completion matter more than another paragraph about edge-case inputs.

Human review is not a safeguard merely because a human was present. A structured list can improve the review, provided someone is accountable for reading it. Otherwise it is just another green badge.

I’d use this on risky changes and skip it for a typo fix. Mandatory for every patch sounds like a fast way to make the important reports invisible.

The wording matters: “unverified” is better than “risk.” An agent often cannot know whether an assumption is wrong, but it can disclose that it did not verify token revocation behavior or deployment sequencing.

There is a failure mode where reviewers outsource thinking to the report: they check whether the listed concerns were addressed and miss the unlisted ones. I would require the human to review intent and threat model independently, then use the report as input.

I want links to evidence: test names, files inspected, commands run, and things not run. “可能 failure under load” is noise. “No load test; assumes connection pool remains below limit” is actionable.

For enterprise teams, this also clarifies responsibility. If the agent identifies an untested authorization path and the reviewer accepts the change anyway, the decision is at least visible. That is preferable to pretending a passing pipeline settled it.

The interface should make uncertainty easy to distinguish from confidence. If every item has the same visual weight, users will either panic or ignore everything. Prioritized, expandable warnings seem more workable than a mandatory wall of text.