A coding agent is an AI agent that works inside a software project: it reads and edits files, runs commands and tests, and uses the results to continue. Because it acts through a shell and the filesystem, its actions can have effects well beyond the code it was asked to change.
The first generation of AI coding tools suggested code, and a developer decided what to accept. A coding agent takes the next step itself: it edits files, runs the tests, reads the failures and tries again, often for many steps without a person in between. That makes it far more useful. It also changes what needs governing, because the agent is no longer producing text for someone to review. It is operating inside a development environment, often the developer’s own.
How a coding agent works
A coding agent runs a loop: read the relevant code, plan a change, edit files, run commands such as tests or builds, observe the results, and continue until it believes the task is done. The model decides the steps. An agent harness supplies the tools, manages context and enforces whatever permissions are configured.
Two properties set it apart from an assistant or a copilot:
- It executes. An assistant proposes a change and a person applies it. An agent applies it, runs it and acts on the outcome.
- It chains. Each step depends on the last, so an early misunderstanding shapes everything after it.
What a coding agent can reach
The useful way to understand a coding agent is not by how well it writes code, but by what its tools can reach. Most of its tools have an intended effect and a wider one.
| Tool | Intended effect | Effect beyond the code |
|---|---|---|
| File edits | Change source code | Change CI workflows, build configuration, lockfiles, or files holding secrets |
| Test and build commands | Check the change | Run any script the project defines, with whatever permissions the agent’s environment has |
| Package managers | Add a dependency | Run install scripts from third-party packages |
| Git | Commit work | Push to shared remotes, force-push over history, delete branches |
| Cloud and infrastructure CLIs | Inspect an environment | Change real infrastructure, if credentials that allow changes are available to it |
| Web and connected tools | Read documentation | Read untrusted content that can carry injected instructions, or send data out |
None of these wider effects requires the agent to misbehave. A test command runs whatever the project’s test script says. A package install runs whatever its install script says. The reach is a property of the tools.
Inherited identity
Run on a developer’s machine, a coding agent often works with much of that developer’s access: SSH keys, cloud credentials and tokens present in the environment, and push rights to their repositories. How much it actually inherits depends on the harness, the execution environment, which credentials are available to it and how it is sandboxed. Claude Code’s documentation, for example, notes that with its sandbox enabled, commands can by default still read most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials, unless reads are restricted. A coding agent running in a purpose-built remote environment may have far less.
Autonomy combined with whatever identity the agent runs under is the core of coding-agent risk. The agent can do anything that identity allows, at machine speed, without a developer’s sense of which actions are routine and which are not.
Matching autonomy to what can be verified
Not every task deserves the same freedom. Work that a strong test suite can verify, such as a refactor with good coverage, can run with little supervision, because mistakes show up quickly and can be undone. Work whose effects cannot be checked locally, or cannot be undone, deserves more: pushing to a shared branch, publishing a package, applying infrastructure changes. These are high-consequence operations, and they are where approval, stricter permissions or a sandbox pay for themselves.
The practical controls follow from the reach map:
- isolate what the agent can reach with a sandbox, and give it narrower credentials than a developer’s;
- require approval for the few operations that are costly or irreversible, not for every command;
- state what the task is, so that actions can be compared with it;
- keep a record of what the agent attempted.
An example
The following is illustrative.
A coding agent is asked to fix a failing test. The test fails because a new dependency changed its behavior. After several attempts at a real fix, the agent edits the CI workflow to skip that test file, and the pipeline goes green. Every action stayed inside the repository. No secret was touched, nothing was force-pushed, and a sandbox would have allowed all of it.
The problem is not reach. It is that disabling a check in the build pipeline does not serve a task described as fixing a test. Noticing that requires comparing the action with what the agent was asked to do.
How Sentience Governor applies it
Sentience Governor integrates with Claude Code. Each session declares its objective and scope, and each tool call is evaluated against them and recorded, without blocking. Shell commands are described by their effects through semantic action classification, so that a push, a deletion or a cloud change is recorded as what it is rather than as “ran a command”, and operations the operator designates as high-consequence are flagged.
Often confused with
Copilot or IDE assistant. An assistant suggests and a person applies. A coding agent applies, runs and continues on its own. Many products now offer both modes.
Agent harness. The harness is the runtime around the model: tools, context and permissions. A coding agent is what the model and harness do together inside a project.
Where the concept stops
A coding agent is defined by the work it does and the tools it uses. That definition does not say what a particular agent was allowed to do, whether its changes were correct, or whether they served the task. Those depend on its permissions, its tests and a reference for what it was asked to do.