Bounded Coding Agent Control

Teams using Claude Code or similar agents can turn growing instruction files into scoped rule directories and an MCP server that exposes only the context needed for the current task. The concrete build is a migration and audit tool: scan a large CLAUDE.md, split rules by topic and project path, flag contradictory rules, then publish lookups such as get_context(topic) plus resources for verification status and budget.

The pain is easy to recognize: a single agent config becomes too long to remember, rules apply to projects where they do not belong, and teams have no clean update path for shared defaults. A small pilot can use one active repo, move project-specific rules into path-scoped files, and compare agent mistakes before and after the split. The check should look for rule conflicts, irrelevant context loaded into sessions, and failed verification steps, since the source example reports better behavior after contradictory rules stopped living in one file but gives no benchmark numbers.

A constrained coding agent is practical for routine Rust work where shell access is the main adoption blocker. The concrete test is a Rust-only TUI agent that can edit files and run Rust-specific actions, while blocking arbitrary terminal commands. That gives maintainers a safer setting for small refactors, diagnostics, and test-driven edits on local machines.

Agent Joe is an early example: it removes shell access, narrows the action set to Rust operations, and is described as usable, while still behind Codex because its prompts are weaker and it lacks a plan mode. A useful next step is to add an explicit plan step before edits, then run the same issue set through Agent Joe and a general CLI agent. Track completed tasks, user interventions, unwanted command attempts, and failed cargo checks. The value comes from making the safety tradeoff visible enough for teams that currently avoid CLI agents on their own machines.

AI coding sessions need a visible stop point when the user is still prompting after the original task has drifted. A lightweight implementation can sit in an IDE, terminal wrapper, or agent chat: capture the user’s stated goal at session start, pause the agent every 30 minutes, hide the prompt box, and ask the engineer to review the goal without model output on screen.

The checkpoint should ask for three decisions: whether the current work still fits the user problem, whether the architecture is getting more complex than the task requires, and whether the level of testing or cleanup matches the blast radius. Those questions match the human judgment described in the engineering “taste” piece: product thinking, system thinking, and quality calibration. The first validation can be a small team trial that compares scoped tasks with and without the pause, measuring extra files changed, unplanned refactors, abandoned branches, and whether the original issue was closed.