Agentic Coding: When the AI Has Access to Your Terminal

The first time I let an AI tool run a shell command in my project, I watched the terminal like a parent watching a toddler near stairs.

That instinct was correct. Not because the tool did something dangerous — it ran pnpm test and reported the output — but because the relationship had changed. This was no longer a tool that suggests. It was a tool that acts.

Chat-based copilots live inside a text box. You paste code in, you get code back, you decide what to do with it. The worst outcome is a bad suggestion you ignore. Agentic tools — Claude Code, Cursor’s agent mode, Gemini CLI, Windsurf — operate differently. They read your files, edit your code, run your commands, and interact with your git state. The worst outcome is a bad action you did not review.

That is a fundamentally different contract, and most developers have not updated their habits for it.

What changed

A chat copilot works like a consultant in a meeting. You describe the problem, they suggest an approach, you go implement it. If the suggestion is wrong, nothing happened.

An agentic tool works like a developer with SSH access to your project. You describe the problem, they open files, make changes, run tests, and sometimes commit. If the approach is wrong, something already happened.

The practical difference shows up in three places:

Scope. A chat tool cannot accidentally edit a file you did not mention. An agentic tool can. It will follow imports, discover related files, and make changes across the project if you let it.

Side effects. A chat tool produces text. An agentic tool produces file changes, command output, and sometimes network requests. Every action has a real effect on your working tree.

Reversibility. A bad chat suggestion costs you the time to read it. A bad agentic action costs you the time to understand what changed, revert it correctly, and verify nothing else was affected.

None of this means agentic tools are dangerous. It means they need the same discipline you would apply to any tool that modifies production-adjacent state.

The trust model is not binary

The question developers ask is usually: should I trust the AI to run commands?

That framing is too coarse. The useful question is: which commands, in which scope, with which review step?

Running pnpm test is low risk. The command is read-only against the codebase. The output is informative. If the tool runs it automatically, you save time.

Running git commit -m "fix: resolve edge case" is medium risk. The commit captures the current state. If the tool made bad edits, the commit preserves them. You want to review the diff first.

Running rm -rf or npx with an unfamiliar package is high risk. The side effects may not be reversible. You want explicit approval every time.

Most agentic tools let you set these boundaries. Claude Code has permission settings and hooks. Cursor asks for confirmation on shell commands. The default should be restrictive, with explicit upgrades for commands you trust.

Safe to auto-approve:
  pnpm test
  pnpm lint
  pnpm build
  git status
  git diff

Require review:
  git add / git commit
  file creation or deletion
  any install command
  any network request

That is not a universal list. It is the starting point for a project-specific policy. The right boundaries depend on your project, your workflow, and how much of the output you are actually reading.

Scope control is the most important habit

The biggest risk with agentic tools is not a single bad command. It is scope creep across files.

You ask the tool to fix a CSS overflow on a card component. It opens the component file, notices the data fetching could be improved, refactors the props, updates the parent page, modifies a test, and adjusts a utility function. Each change may be individually reasonable. Together, they turned a five-minute CSS fix into a twenty-file diff you now have to review line by line.

The fix is the same one that works with human developers: scope the work before it starts.

Fix the horizontal overflow on ProjectCard at mobile widths.
Only edit ProjectCard.astro and the related CSS.
Do not change props, data fetching, or parent components.
Do not modify tests until I review the visual fix.

That prompt is not clever. It is a clear ticket with boundaries. The same principles from the prompt engineering post apply here, but with higher stakes — because the tool will actually execute the work, not just describe it.

When I skip scope constraints, the quality of the output drops. Not because the tool is worse, but because the review burden exceeds what I can do carefully. Five focused changes are easier to verify than fifty scattered ones.

The review loop changes shape

With a chat copilot, review happens before implementation. You read the suggestion, decide if it is right, then apply it manually.

With an agentic tool, review happens after implementation. The tool makes the changes, then you inspect the diff.

This is a meaningful shift. Post-implementation review is harder than pre-implementation review because the code already exists, the tests might already pass, and there is a psychological bias toward accepting work that looks done.

The habit I have built is to always ask for a summary before inspecting the diff:

Summarize the changes you made.
Group by behavior change, not by file.
Flag anything that changed public API, data flow, or error handling.

Then I read the diff with that summary as a map. The summary tells me what the tool intended. The diff tells me what actually happened. When those two diverge, there is a problem.

The other habit is running the full verification sequence after every agentic edit session, not just after the final change:

pnpm test && pnpm lint && pnpm build

A tool that edits three files and runs tests after each edit may miss a regression that only appears when all three changes interact. The full suite is the safety net.

What agentic tools are genuinely good at

The best use case is not “build the feature for me.” It is “do the mechanical work while I focus on the decisions.”

Exploring an unfamiliar codebase:

Trace how writing posts are loaded, rendered, and added to RSS.
Include every file involved and the data flow between them.
Do not suggest changes.

The tool reads dozens of files, follows imports, and builds a map faster than I could manually. The output is a starting point for understanding, not a final answer.

Scaffolding repetitive work:

Add a new writing post with this frontmatter.
Follow the existing markdown structure in src/content/writing.
Use the same heading style as the Laravel posts.

The tool creates the file, matches the format, and gets the boring parts right. I write the actual content.

Debugging with reproduction:

pnpm test fails in ProjectCard.test.ts with this error:
[paste error]
Find the root cause. Explain it before editing.
Propose the smallest fix.

The tool can run the failing test, inspect the assertion, trace the component, and identify the mismatch. That diagnostic loop is where agentic access pays for itself — the tool does not just reason about the failure, it observes it.

What they are bad at

Architecture decisions. The tool will happily create a new service layer, add an abstraction, or split a module if you ask. It will not tell you whether that abstraction earns its complexity. That judgment is still yours.

Knowing when to stop. An agentic tool does not have a sense of “this is enough.” It will keep improving, refactoring, and polishing if you let it. The discipline of shipping a small, correct change is a human constraint, not a tool feature.

Understanding why code is the way it is. Legacy code often looks wrong for reasons that are not visible in the file. A workaround for a vendor bug. A performance hack that matters under load. A naming convention that matches an external system. The tool sees the code. It does not see the history.

The practical version

Agentic coding is not a different kind of programming. It is the same kind of programming with a faster, more capable assistant that can touch real files.

The habits that make it productive are not new:

• Scope the work before it starts
• Set explicit boundaries on what the tool can touch
• Review changes by behavior, not just by file
• Run the full test suite after every session
• Keep the tool on a short leash for anything irreversible

The developers who use agentic tools well are not the ones who give the tool the most freedom. They are the ones who give it the right freedom — enough to be fast, not enough to be unsupervised.

That is the same principle behind good delegation with humans: clear scope, explicit constraints, and review before trust.