A GitHub Copilot agent generates a plan to delete several files from a production repository. Before executing, the agent must validate the plan. Which validation approach is most appropriate for this scenario?
Select an answer to reveal the explanation.
Short Explanation
Before a demolition crew tears down a wall, a structural engineer checks if it's load-bearing — you don't just count bricks. For irreversible actions like file deletion, you need automated dependency analysis plus human sign-off as the right combination of safety nets.
Full Explanation
Plan validation is the step between plan generation and plan execution. For high-risk actions — particularly irreversible ones like file deletion — validation must be both automated (checking objective correctness) and human-supervised (checking intent alignment).
The approach that runs automated checks to verify the files are not referenced by other modules, and requires explicit human approval before execution, is correct because automated checks can verify whether the targeted files are imported, referenced, or depended upon by other parts of the codebase. This catches objective errors. Human approval then ensures the deletion aligns with team intent — a machine cannot know whether deleting a 'dead' file is actually safe in the broader project context. Combining both is the correct pattern for high-risk actions.
The approach that asks the agent to re-read the plan and self-validate by checking its own reasoning is wrong because self-validation by the agent is inherently unreliable. An agent that generated a flawed plan is likely to also validate that plan as correct, since both operations use the same reasoning model with the same biases. External validation is needed.
The approach that skips validation for file deletions since they can be recovered from Git history is wrong because, while Git history preserves deleted files, restoration takes time, may lose uncommitted changes, and the downstream impact of a missing file (broken builds, failed tests) can cause significant disruption. 'Recoverable' does not mean 'low risk.'
The approach that validates only the number of files to be deleted to ensure it does not exceed a configured limit is wrong because checking only the count of files to be deleted misses the point of validation. A plan that deletes one critical configuration file is far more dangerous than one that deletes 100 redundant log files.