Executable safeguards for coding agents

Code-assistant teams should split repository editing into three measured steps: a viewer that returns only task-relevant code blocks, an editor that applies a high-level patch request, and a verifier that runs the real tests and feeds structured failures back into repair. This is a buildable change for IDE assistants, CI repair bots, and internal coding agents that already call file-read, grep, edit, and test tools.

SWE-Edit gives a practical shape to the read and write split. Its Viewer receives a path plus a natural-language query and returns relevant blocks; its Editor receives a path plus an edit instruction and applies the change. On SWE-bench Verified, the paper reports resolved rate rising from 69.9% to 72.0%, edit success from 93.4% to 96.9%, and inference cost falling 17.9%. SAFEdit adds the test loop for instructed edits: a Planner writes the edit plan, an Editor changes the code, and a Verifier runs unit tests with up to three repair rounds. It reports 68.6% EditBench task success, above a GPT-4.1 ReAct baseline at 60.0%.

A cheap adoption test is to wrap an existing coding agent without changing its base model. Route reads through a block-returning viewer, route edits through a patch executor, run the project’s tests after each patch, and compare edit success, unrelated diff size, resolved tasks, and token cost on a fixed issue set. The Claude Code regression report adds one implementation warning: repeated safety reminders inside Read and Grep results can cause subagents to refuse ordinary refactors and waste context. Safety text in the file-read path needs its own regression tests, including parallel subagent runs on benign repositories.

Teams running coding agents can treat the harness as code under review. Store system prompts, tool descriptions, tool implementations, middleware, skills, sub-agent settings, and long-term memory as editable files. After a benchmark or internal task rollout, convert traces into task reports, attach each proposed harness change to the failure it addresses, record expected gains and regression risks, then keep the change only after a replay shows the prediction held up.

Agentic Harness Engineering gives this workflow a concrete evaluation. It exposes seven harness component types as files, uses cleaned rollout traces to produce evidence, asks an Evolve Agent to edit harness files, and records a manifest for each change. The next iteration checks task-level outcomes and can revert rejected edits at file level. After 10 iterations, the paper reports Terminal-Bench 2 pass@1 increasing from 69.7% to 77.0% across 89 tasks. On SWE-bench-verified, the frozen harness used fewer tokens per trial than the seed harness while reaching similar aggregate success.

The first user is an engineering team that already has agent traces but handles harness changes through ad hoc prompt edits. A minimal trial can start with 30 to 100 representative tasks, a versioned directory for harness files, and a required change manifest for every prompt, tool, middleware, memory, or skill edit. The pass/fail check should include token use and regression cases, since the AHE ablations found gains mainly in memory, tools, and middleware, while system-prompt-only changes underperformed the seed.

Python maintainers can add a pre-triage job that scans code outside current test coverage and creates a small queue of ranked bug reports for human review. The job should include coverage discovery, LLM-generated issue reports with reproduction steps and suggested fixes, reranking, and a test run for candidate patches so reports that break existing tests lose priority.

IssueSpecter gives a concrete version of this workflow. SlipCover finds uncovered Python segments. GPT-5-mini reviews each segment and generates issue reports with severity, affected operating systems, reproduction steps, and suggested fixes. A selection step keeps the top reports per project, and GPT-5-mini reranks them by impact, scope, and urgency. Across 13 active Python projects, the system generated 10,467 reports. Human review of 130 top-ranked reports found 49 valid bugs, 61 needing further investigation, and 20 invalid reports. The paper reports that LLM-based ranking beat rule-based ranking by 50% at precision@3 and 41% in mean reciprocal rank.

This is most useful for projects with meaningful test suites and persistent uncovered modules, where maintainers already distrust raw AI issue floods. A controlled pilot can run weekly, open no public issues by default, and send only the top three reports per repository to maintainers with coverage location, reproduction steps, proposed fix, and test outcome. The review metric should be valid-or-actionable reports per maintainer hour, since the reported false positives still require triage discipline.