Clean Commits When Coding Agents Write the Code

When a coding agent writes a patch, treat its output as a proposal, not a finished commit. Your job is to establish what changed, why it belongs, and which checks support it. This Quanta Briefings walkthrough follows a hypothetical retry-handling fix from task definition to a reviewable commit.

01 · Step 1: Define the Commit Before Requesting Code

Write a short acceptance boundary before starting the agent: fix retry handling for temporary failures, preserve existing behavior elsewhere, and add focused regression coverage. Name any forbidden changes, such as dependency upgrades or public interface changes.

Tell the agent to leave staging and committing to you. Request an implementation summary, changed-file list, and exact validation commands. Keep unrelated cleanup out of scope, even when it looks useful. The intended commit should express one coherent behavioral change, not everything the agent noticed.

02 · Step 2: Record Existing Work Before the Agent Runs

Run git status --short and record the result before handing over the task. Git status distinguishes changes in the index, changes in the working tree, and untracked paths. Use that baseline to avoid attributing existing work to the agent.

If another task already occupies the checkout, pause and isolate the new work through your normal repository workflow. Never ask the agent to clean the directory indiscriminately. Existing edits may belong to a teammate, another session, or your own unfinished investigation.

03 · Step 3: Review the Patch, Not the Agent’s Summary

After generation, inspect git diff --stat for scope, then read git diff for unstaged changes. Also inspect git diff --cached for anything already staged. These views cover different comparisons; an empty unstaged diff does not establish that nothing changed.

Read newly created files separately. For every changed file, ask:

• › Does this file directly support the requested behavior?
• › Are formatting changes obscuring functional edits?
• › Did the patch introduce debug output, credentials, local paths, or session artifacts?
• › Do tests assert the required behavior rather than merely mirror the implementation?

Ask for a narrower revision when necessary. Do not accept unrelated refactoring simply because the agent explains it confidently.

04 · Step 4: Stage Only the Intended Change

Use explicit file paths for staging, or git add -p to choose individual hunks. Patch mode lets you review changes interactively before adding them to the index. Avoid blanket staging when the checkout contains unrelated work.

Separate mechanical cleanup from behavior changes when each can stand independently. Keep a regression test with its corresponding fix. If partial staging would leave an incomplete implementation, revise the patch instead of manufacturing an artificial commit boundary.

05 · Step 5: Validate the Candidate You Will Commit

Run git diff --cached --check to detect introduced conflict markers and whitespace errors under Git’s configured rules. Treat this as patch hygiene, not proof of functional correctness.

Then run the repository’s relevant tests, formatter checks, and static analysis. Remember that local checks usually exercise working-tree files, not an abstract staged snapshot. Ensure unrelated unstaged edits are not making the candidate pass. Record exact commands and outcomes; distinguish completed checks from recommendations, and disclose anything blocked by missing services or credentials.

06 · Step 6: Write the Message From Verified Evidence

Draft the message only after the staged patch is settled. Use a specific imperative subject, such as Preserve retry limits after temporary failures. Follow the repository’s established conventions rather than introducing a new style.

In the body, explain the previous failure, the corrective behavior, and any important compatibility limits. Include validation results only when you actually observed them. Avoid unsupported claims such as “fully tested.” If you ask the agent to draft the message, provide the final staged diff rather than relying on its memory of the session.

07 · Step 7: Inspect the Commit and Keep Iterations Bounded

After committing, inspect git show --stat --patch HEAD to review the recorded change. Compare its message and patch against your intended scope before pushing.

For sustained agent work, consider Quanta’s pay-as-you-go API relay. One balance covers multiple models and works with tools including Claude Code and Codex. Calls are metered on actual tokens, with cache writes and reads priced separately. Keep each revision focused on the unresolved issue, not a request to rewrite everything. Open a Quanta account to try that workflow while keeping commit approval in human hands.