From Assistant to Agent

A coding assistant can return a suggestion. A coding agent may be able to take actions in a development environment.

That difference changes the risk model.

The model still generates candidate decisions. Tools can turn those decisions into file edits, commands, tests, searches, or other project changes.

Separate model capability from tool capability

A useful architecture is:

TASK / CONTEXT
      ↓
MODEL
proposes next action
      ↓
TOOL BOUNDARY
read / search / edit / run / test
      ↓
OBSERVATION
      ↓
MODEL proposes next action

A tool-using loop may repeat several times.

The important point is that the model does not gain authority merely because a tool can execute its proposal.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Four words prevent a lot of confusion

Capability

What the model or connected tool can technically do.

Examples:

read repository files
edit a file
run pytest
execute a shell command
search project text

Permission

What this particular task authorizes.

Example:

Allowed files: reports.py and tests/test_reports.py
No dependency changes
No configuration changes

Scope

The work needed to satisfy the stated goal.

Permission and scope overlap, but they are not identical. A file can be technically allowed while a change inside it is still irrelevant to the task.

Authority

Who decides whether the resulting change becomes accepted project state.

For this course, that remains the human developer/reviewer.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Capability does not expand permission

Suppose the environment lets an agent edit the whole repository.

Task:

Add format_leaderboard(players) to reports.py.
Add tests in tests/test_reports.py.
Do not change the Player data model.

Agent plan:

1. Add formatter.
2. Add formatter tests.
3. Rename Player.score to Player.points across the project.
4. Rewrite storage to use the new field.

Classify it:

1  in scope
2  in scope
3  outside scope
4  outside scope

The agent may be capable of steps 3 and 4. That does not make them permitted or useful.

An action loop can optimize the wrong target

Imagine an agent receives:

Make all tests pass.

One path is to repair the implementation.

Another path is to change the tests.

Another path is to skip or delete failing tests.

If the task specification never protects the behavior being tested, “all tests pass” can become a badly defined objective.

The correct target is closer to:

Implement requirement R4 without changing existing expected behavior.
Existing tests must remain intact unless a requirement change is separately approved.
Run the relevant suite and report evidence.

Tools are powerful. Ambiguous objectives remain ambiguous.

Tool output is evidence, not necessarily interpretation

Suppose an agent runs:

12 passed

That is evidence that a particular test invocation reported 12 passing tests.

It does not tell you:

• whether the intended tests were collected;
• whether the agent changed the tests first;
• whether a required integration check was omitted;
• whether uncommitted changes remain; or
• whether the task stayed inside scope.

The reviewer still needs repository state and requirement context.

Read-only tools can still be useful

A tool-using agent does not have to begin with write access.

A safer planning phase can use read/search capability only:

inspect relevant files
find call sites
locate tests
summarize current architecture
propose plan

Then a human reviews the plan before any edit capability is used.

This reduces the cost of a misunderstanding.

Not every command is equally safe

A tool that can run commands may be able to do far more than the current task requires.

For this course, never approve commands you do not understand merely because the agent proposed them.

Be especially cautious with commands that:

• delete files/directories;
• overwrite or reset repository state;
• install or execute unfamiliar software;
• expose environment variables or credentials;
• publish/push/deploy changes;
• modify permissions;
• contact external services; or
• operate outside the project directory.

A development agent is not a reason to stop reading shell commands.

The same lesson works without a live agent

If your environment has no coding agent, use a simulated record:

TASK
AGENT PLAN
PROPOSED PATCH
CLAIMED TEST OUTPUT

Then perform the human steps yourself:

check scope
inspect diff
run/inspect tests
find unsupported claims
accept / revise / reject

The learning target is repository control, not access to a commercial agent.

Build a permission table

For one proposed task, classify capabilities before any work begins:

Then explain one denial.

A useful agent task is often defined as much by what it cannot do as by what it can.

What changes from Unit 16

Unit 16 controlled generated changes through specifications and slices.

Unit 17 adds another layer:

SPECIFICATION
   ↓
PERMISSION BOUNDARY
   ↓
TOOL-USING ACTIONS
   ↓
REPOSITORY CHANGES + OBSERVATIONS
   ↓
INDEPENDENT REVIEW

Lesson 2 turns those boundaries into a task specification. Lesson 3 handles the moment after the agent claims it is finished.