Coding Agents keep checking but never deliver; how should stop conditions be set to be effective?

How to distinguish necessary checks from repetitive actions that haven't progressed?

Keep a short checklist of questions for the current task, clearly stating what result is needed for each item. For example, whether a modification fixes a reproduced error or affects existing calls. Explain which question the check intends to answer before executing it, and write the results back to the checklist afterward to facilitate judging what evidence is still missing.

If the next round runs the same actions without new inputs, failure information, or unresolved issues, stop first to explain why continuation is still needed. Do not use the number of checks as a substitute for task progress. This discussion concerns working methods and does not claim that the data collection project can automatically understand the relationship between all verification and business requirements.

When should the stop conditions be clearly defined?

List mandatory requirements and notes to leave if verification is impossible before implementation. Separate necessary checks from those requiring additional evidence, avoiding scope creep near delivery. If real risks are discovered during the process, update the checklist and explain its relationship to current changes.

Allow stop conditions to explicitly report incomplete parts. When the environment is unavailable or key inputs are needed, preserve completed work, failure points, and next steps, then hand them over to the appropriate person. Stopping does not mean claiming total success, nor does it require repeatedly attempting the same action just to get a completion label.

When an agent stops, how do you leave behind deliverables that can be picked up?

In the delivery, specify what was changed, which checks were run, the results, and which requirements remain unverified. This allows successors to locate the relevant code and failure messages without replaying the entire conversation. If only a plan or partial implementation is provided, clearly label the current stage to avoid mistaking a progress report for a completed result.

Check results with a fixed input

Use a deliberately failing test: save the first error, rerun it unchanged to check the repeated-attempt warning, then fix the function and check whether a new validation run is allowed. If all runs are blocked even after a code change, inspect the detection criteria. This is a proposed sequence; the plugin was not run and no token savings or success-rate improvement was measured.