Coding Agent Control Points

Agent-maintained issue workflows should add a required pre-edit step that proves the reported bug still exists before the agent changes executable code. A cheap version is a small harness that asks the agent to reproduce the failure, inspect recent commits touching the same area, and return a signed “no code change” result when the repository already satisfies the issue.

FixedBench gives a concrete reason to test this. In already-fixed SWE-bench Verified tasks, agents still made unwanted executable-code edits in 35% to 65% of cases. A direct “Abstain or Fix” prompt improved abstention for some models, but it also caused heavy under-repair on partially fixed issues, with GPT-5.4 mini incorrectly abstaining 93.6% of the time in that setting. The check should therefore score two cases together: stale reports where the right result is no patch, and partial fixes where a patch is still needed.

The first users are teams letting agents open or update maintenance PRs from issue queues. The workflow change is small: require a reproduction note and a “why no edit is safe” path before the agent can push a code diff. Human reviewers still keep merge authority, which matches current GitHub evidence: in 29,585 AI-agent-related PRs, agent-approved PRs totaled only 14 and stayed below 0.1% per tool.

Repositories using Claude Code, GitHub Copilot, Cursor, Gemini, OpenAI Codex, or AGENTS.md should maintain an agent configuration inventory in CI. The inventory should list context files, skills, subagents, commands, rules, settings, hooks, and MCP connections; record which files affect every session; and flag permissions or hooks that can run before human review.

The new GitHub configuration dataset shows that this is already ordinary repository material. It found 15,591 configuration artifacts across 4,738 repositories, with context files appearing in 4,463 repositories. These files are no longer side notes in a developer setup; they are part of how teams steer agents.

Security work points to the checks the inventory should run first. Subagent systems need bounded memory inheritance, role-scoped resource access, lifecycle controls, and safe termination rules. Runtime governance work adds a practical placement model: pre-action gates for blocked operations, action-time monitors for risky tool use, post-action auditors for trace review, and escalation routing when a policy cannot be decided automatically. A CI audit can start with static detection and move the high-risk items into runtime checks where the agent acts.

Teams writing security-sensitive libraries, parsers, payment logic, or protocol code should separate ordinary code generation from proof work. A practical first build is an internal Rust/Verus lane for a narrow set of functions: the agent proposes code, a developer or verifier reviews the specification, and the system requires machine-checked proofs plus positive and negative tests before merge.

VeriContest shows why this should be scoped narrowly. GPT-5.5 reached 92.18% pass@1 on natural-language-to-code generation, then fell to 48.31% on specification generation, 13.95% on proof generation, and 5.29% end-to-end verified generation. All evaluated models stayed below 6% end-to-end. The gap is large enough that proof generation should be treated as its own review workload with dedicated failure reports, not as a hidden add-on to a passing test suite.

The useful adoption test is small: choose ten functions with clear preconditions and postconditions, require Verus checks, and track where the agent fails: missing specification, incomplete postcondition, invalid invariant, or wrong code. VeriContest’s use of Post2Exe and large negative test suites also gives a concrete pattern for catching weak specifications before they are trusted.