A Git Workflow for AI Coding Agents

An AI coding agent can produce changes faster than you can comfortably review them. Git gives that speed a useful boundary: a known starting point, an isolated task, and a history you can understand. This walkthrough follows one small change from preparation to merge, with checkpoints that protect both your code and your spending.

Start from a clean, tested baseline

Before opening the agent, inspect your working tree and identify any existing changes. Commit finished work, or set unfinished work aside deliberately. Do not let the agent mix its edits with something you were already debugging.

Run the tests relevant to the area you plan to change. If something already fails, record it before proceeding. This gives you a baseline for judging the result and prevents paid troubleshooting of a failure the agent did not introduce. Also confirm that credentials and other private material are excluded from version control.

Create a branch for one observable outcome

Create a dedicated branch from the appropriate current base. Give it a name that describes the intended change, rather than the agent or model doing the work. A branch should answer one question, such as whether an empty search result now displays a helpful message.

Keep unrelated cleanup out of scope. A small task produces a smaller diff, usually needs less context, and is easier to abandon if the approach is wrong. For a student project, this can be as simple as one branch per bug or modest feature.

Agree on the plan before allowing edits

Ask the agent to inspect the relevant code and propose a short plan before changing anything. Describe the expected behavior, acceptance checks, and boundaries. For example, specify that the change should preserve the existing public interface and avoid new dependencies unless you approve them.

Request a focused inspection rather than a tour of the entire repository. Review the plan yourself, then authorize implementation. Tell the agent not to commit, merge, rewrite history, or discard existing work without permission. These boundaries make recovery predictable.

Review the first diff before expanding the task

After the first implementation pass, pause and inspect the diff. Check which files changed, whether the edits match the plan, and whether tests were added or adjusted for the intended behavior. Watch for unrelated formatting, dependency changes, deleted assertions, and rewritten tests that merely accept incorrect behavior.

If the approach is drifting, stop early. Correct the scope or discard only the agent's identified changes after checking that no personal work will be lost. Asking for another broad rewrite can cost more than returning to a clean checkpoint.

Verify the behavior and make a deliberate checkpoint

Run targeted tests first, then broader checks when the change touches shared behavior. Read the results yourself; an agent's summary is not proof that a test ran or passed. For user-facing work, also exercise the behavior manually where practical.

Stage only the changes you understand and create a focused commit once they form a coherent unit. Write a message explaining the behavior changed and, when useful, why. If more work remains, keep it separate. Avoid asking the agent to bundle unrelated fixes into the same checkpoint.

Keep additional agents and spending isolated

If you use multiple agents, give each a separate branch and working directory, such as a separate Git worktree. Do not let them edit the same checkout concurrently. Integrate their work one change at a time, checking for conflicting assumptions as well as textual conflicts.

MyRelay can help you track the spending side with one personal key and budget across supported tools, plus per-request token and cost visibility. Create a MyRelay account if you want that shared view. Use it to compare the cost of a small, bounded task with repeated repair attempts, rather than judging value by a single request.

Merge only what you can explain

Review the complete branch against its base before merging. Remove temporary debugging changes, confirm the intended tests pass, and check that each remaining edit belongs to the task. If the base has changed, update your branch carefully and rerun the relevant checks.

After merging, verify the integrated result and retire the branch when it is no longer needed. For a bad change already shared with others, prefer a reverting commit over rewriting shared history. The final standard is simple: you should be able to explain what changed, how you checked it, and how to undo it.