Why I Use AI Coding Agents in the Terminal

I only use AI coding agents from the terminal.

No Cursor. No Codex app. No Claude desktop app for coding. No agent panel inside an IDE.

I open a terminal, go to the repository, and start Codex or Claude Code.

That is basically it.

The interesting part is not the terminal itself. The interesting part is the workflow around it. The agent can inspect the real repository, change files, run the actual build, test the result, and show me the Git diff.

And when the task is finished, I still decide whether anything gets committed or pushed.

This article shows the workflow I use and how you can copy it.

My workflow in 30 seconds

The full loop looks like this:

open repository
  -> check the current Git state
  -> give the agent one clear goal
  -> let it inspect before editing
  -> implement the change
  -> run the real checks
  -> review the diff
  -> commit only when I approve

It is not complicated.

That is one reason it works.

The model can change. The programming language can change. The repository can be a website, a Python service, a Flutter app, or a Go tool. The loop stays almost the same.

Step 1: Start with the real repository

I begin in the project directory:

cd ~/Projects/my-app
git status --short

Then I start the agent:

codex

Or:

claude

Running git status first takes a few seconds and prevents a lot of confusion.

I want to know:

• whether the working tree is already dirty
• which files were changed before the agent started
• whether I am on the branch I expect
• whether generated files are already present

This matters because an agent should not treat every existing change as its own work. If I already changed a file, I want the agent to work with that change, not silently overwrite it.

For larger or riskier work, create a branch first:

git switch -c feature/my-change

You do not need a complicated Git strategy. You need a known starting point and an easy way back.

Step 2: Give it a finish line

The biggest improvement in my results did not come from a new model.

It came from being clearer about what “done” means.

This is the basic prompt structure I use:

Goal:
What should change?

Context:
Where should the agent look first?

Constraints:
What must stay unchanged?

Done:
Which tests, build, or visual checks must pass?

Git:
Do not commit or push until I ask.

Here is a real example for this website:

Goal:
Add a new article to the existing blog.

Context:
Read the content schema, two recent articles, and my YouTube notes first.

Constraints:
Match the existing writing style and page structure.
Do not redesign the blog.

Done:
The Astro build passes.
The article renders without horizontal overflow on desktop and mobile.

Git:
Do not commit or push until I ask.

That prompt gives the agent room to explore, but not room to invent the goal.

You do not need to list every file it should edit. Let the agent inspect the repository. But be explicit about the result, the boundaries, and the evidence you expect.

Step 3: Let it inspect before it changes

For an unfamiliar or larger task, I separate investigation from implementation.

My first instruction can be:

Inspect the repository and explain how this feature currently works.
Identify the files that would need to change.
Do not edit anything yet.

Then I review the answer.

If the agent misunderstood the architecture, I can correct it before it produces a large diff. If the approach looks right, I continue:

Implement the change using the existing patterns.
Run the relevant checks and review your own diff.

This is slower than immediately saying “build it,” but usually faster than undoing a confident implementation in the wrong part of the system.

I do not split every tiny task into two phases. A typo does not need an architecture review. Use this when the cost of choosing the wrong approach is higher than the cost of one extra turn.

Step 4: Put repeated instructions in the repository

If I repeat the same correction several times, it should stop living only in the chat.

Codex reads repository guidance from AGENTS.md. Claude Code reads CLAUDE.md.

I can keep the shared rules in AGENTS.md:

# Repository workflow

## Commands
- Install: `npm install`
- Build: `npm run build`
- Test: `npm test`

## Working rules
- Follow the existing architecture and naming.
- Keep changes limited to the requested task.
- Do not replace dependencies without explaining why.
- Never commit, push, or deploy unless the user asks.

## Definition of done
- Run the relevant tests.
- Run the production build.
- Review the final diff.
- Report anything that could not be verified.

Claude Code can reuse those instructions through a small CLAUDE.md:

@AGENTS.md

Now the commands and rules travel with the repository.

They are visible to the team, reviewable in Git, and available to a fresh agent session. They also improve over time. When the agent makes the same mistake twice, add one specific rule that prevents it.

Do not turn this file into a fifty-page employee handbook. Short and accurate is better.

Step 5: Make the agent prove the result

“The change is complete” is not evidence.

For this Astro website, useful evidence includes:

npm run build
git diff --check
git status --short

For another stack, it might be:

pytest
ruff check .

Or:

go test ./...

Or:

flutter test

The checks should come from the repository, not from a generic list the model invented.

For user-interface work, a successful build is still not enough. The page can compile and look broken.

I ask the agent to start the app and verify it at the sizes that matter. For this website that means desktop and mobile. I also want it to check for horizontal overflow, missing images, console errors, and obvious overlaps.

The final report should answer four questions:

1. What changed?
2. Which checks ran?
3. What passed or failed?
4. What could not be verified?

If the answer only says “done,” the task is not done.

Step 6: Keep a human boundary

I let the agent read files, edit code, and run the checks needed for the task.

I do not automatically let every session commit, push, deploy, change DNS, rotate credentials, or run destructive commands.

My default boundary is simple:

You may inspect, edit, and verify.
Ask before committing, pushing, deploying, or doing anything destructive.

That boundary is not perfect security. You should still read approval requests and understand which permissions the tool has.

But it prevents a useful coding task from automatically becoming a release task.

It also creates a natural review point:

git diff --stat
git diff

I can accept the work, request another change, or discard it. The agent does the implementation work. I still own the repository.

A workflow you can copy today

You can try this without rebuilding your entire development setup.

1. Pick one agent

Install Codex CLI or Claude Code. Start with one. Learning two tools at the same time does not improve the code.

2. Pick a small repository

Do not begin with production infrastructure or your company’s largest monorepo.

Choose a project where a bad change is easy to see and easy to reset.

3. Check the starting state

cd path/to/project
git status --short

Create a branch if the work is substantial.

4. Give it one bounded task

Use the prompt structure:

Goal:
Context:
Constraints:
Done:
Git:

For the first task, choose something you could verify yourself: add validation, fix one bug, improve one test, or update one page.

5. Require verification

Tell the agent which test or build command must pass. If you do not know the command, ask it to find the documented checks before changing anything.

6. Review before committing

git diff --check
git diff

Do not judge only by the agent’s summary. Look at the actual change.

7. Save what you learned

At the end, ask:

What repository instruction would have helped you complete this task
with less confusion or fewer corrections?

Add only the useful answer to AGENTS.md or CLAUDE.md.

After five tasks, your workflow will already be better than it was after the first one.

Three mistakes I would avoid

Giving a vague task

“Make this app better” forces the model to choose the problem, the priority, and the solution.

Give it one outcome you can verify.

Skipping the Git check

If you do not know what changed before the agent started, reviewing its work becomes harder.

Check the state first. Review the diff last.

Automating too early

Both Claude Code and Codex can run non-interactively. That is useful after a workflow is stable.

For example, Claude Code supports piped input:

git diff --cached | claude -p "Review this diff for likely regressions"

Codex provides codex exec:

codex exec "Run the documented checks and explain any failures. Do not edit files."

But do the work interactively first.

See which permissions it needs. Find the ambiguous instructions. Decide what a failure should do. Then automate the boring, predictable part.

What I give up by using only the CLI

I do not get inline AI autocomplete, a graphical agent panel, or Cursor’s file-by-file review interface.

Large diffs can be more comfortable in a visual review tool. A graphical debugger can also be easier than reading logs and command output.

Those are real advantages.

For me, they are not enough to move the agent workflow out of the terminal.

I prefer one consistent loop built around the repository, Git, project commands, and explicit approval. It works across TypeScript, Python, Java, C#, Go, and Flutter without making the editor part of the decision.

Somebody else can reasonably choose the opposite tradeoff.

The simple version

My workflow is:

1. Start from a known Git state.
2. Give the agent one clear goal.
3. Define what must not change.
4. Tell it how to prove the result.
5. Review the real diff.
6. Keep commit, push, and deploy under human control.
7. Save repeated lessons in the repository.

The CLI is only the interface.

The real advantage is that the workflow is visible, repeatable, and easy to improve.

You can copy the whole thing. Then change the parts that do not fit the way you work.