Coding Agent Control Gates

Platform and security teams can package one repetitive maintenance class as a factory station before widening agent use. A good starting point is dependency updates or CVE fixes across a known repo set. Each job should include the advisory or ticket, target repos, allowed commands, non-goals, reproduction steps, validation checks, no-op rules, required evidence, and a fixed output state such as PR_READY, NO_OP, ESCALATE, or RETRYABLE_FAILURE.

The useful build is the wrapper around the coding agent: intake, classification, isolated workspace setup, implementation, tests, evidence capture, retry limit, and review queue. The first pilot can run on 10 repos and count how many jobs produce reviewable PRs, justified no-ops, or escalations. The safety check should live in tests, logs, screenshots, traces, ADR checks, or other reviewer-visible evidence, since the agent’s explanation is not enough for maintenance work that touches production code.

Teams using coding agents for authorization, payment, policy, or data-access logic can add a proof gate for small functions before treating generated code as ready for review. The practical version starts with a narrow interface, writes Dafny-style preconditions and postconditions, runs Z3 to check the specification, generates or edits the implementation, and stores the verification result with the pull request.

This is best tested on code where the correctness property is compact: balance cannot go negative, an authorization rule denies by default, a policy update preserves an invariant, or an input parser rejects undefined cases. The evidence supports a constrained pilot, not a broad claim that natural-language requirements can already produce verified production systems end to end. The gap to watch is specification generation: the current vericoding results are strongest when the formal spec already exists or when a human can review the generated spec before code generation.

Repositories that rely on coding agents should add a PR check for changes that increase future agent context cost. Generated clients, coverage output, build artifacts, logs, snapshots, vendored files, lockfile churn, and agent instruction dumps can pass normal tests while making later agent sessions slower, more expensive, and noisier.

ContextLevy is a concrete implementation pattern: scan the GitHub pull request diff, estimate context weight, classify risky files, and post a focused comment when thresholds are exceeded. It can run as a GitHub Action or npm CLI, and it does not call an LLM or upload code. A low-risk rollout is to comment only for two weeks, tune ignored paths and thresholds, then make the check blocking for file classes the team already agrees should not enter the repo.