Part 7 of 7 · Chapter 1 of 4

Agents and Background Work

Long-running agents, parallel worktrees, and handing off work you do not want to sit and watch.

Advanced14 min read

Worth reading first: Git and GitHub for Vibe Coders

Everything so far has had you in the loop for every step. An agent removes you from the middle: you describe an outcome, it works until it gets there. That shift is powerful and it changes which mistakes are possible.

What actually changes

Assistant mode

You prompt, it responds, you review, you prompt again. You see every step and approve every change. Slow, and very controlled.

Agent mode

You describe the destination. It reads files, edits, runs commands, reads the errors, and tries again — for minutes at a time — then reports back.

The important part is not speed. It is that the agent can run your code and read the result, which means it can correct itself without you relaying error messages back and forth.

What makes a good agent task

Agents succeed when there is a machine-checkable definition of done, and drift badly when there is not.

1
Good: “make the failing tests pass”
Unambiguous finish line the agent can check itself.
2
Good: “fix every type error in this directory”
The type checker is the judge, not the model's taste.
3
Good: “add tests until this file is covered”
Measurable, and low risk if imperfect.
4
Bad: “improve the code quality”
No definition of done, so it will keep going and touch everything.
5
Bad: “redesign the homepage”
Aesthetic judgement it cannot verify. You will get changes you did not want.

Setting it up so mistakes are cheap

An agent runs commands on your machine and edits many files without pausing. Do three things before letting one loose.

1
Commit first, always
A clean tree means the entire run can be discarded with one command.
2
Work on a branch
So even a committed mess costs nothing to abandon.
3
Give it the check command
Its stopping condition should be your real verification, not its own opinion of doneness.

A well-formed agent task

The tests in src/lib/pricing.test.ts are failing. Fix the implementation in src/lib/pricing.ts so they pass.Do not change the tests. Run npm run check when you think you are done. If it fails,keep going. If you get stuck on the same error twice, stopand tell me what you tried.

Note the last sentence. Without a stop condition, a stuck agent will keep trying, and each attempt piles more changes on top of the previous failed one.

Parallel work with worktrees

A git worktree is a second checkout of the same repository in another folder, on its own branch. That lets an agent work in one folder while you work in another, with no conflicts:

Terminal

$ git worktree add ../myapp-agent -b agent/fix-pricing$ cd ../myapp-agent# let the agent work here while you keep working in the original $ git worktree remove ../myapp-agent    # when finished

Reviewing what comes back

An agent run produces a large diff you did not watch being made. Review it differently from a change you steered.

1
Read the full diff on GitHub
Not in the terminal transcript. You want the finished state, not the narrative.
2
Check for scope creep first
Files it touched that have nothing to do with the task are the strongest signal something went sideways.
3
Verify the check actually passed
Run it yourself. “It says it passes” is not the same as it passing.
4
Look for deleted tests
The fastest way to make tests pass is to remove them. Confirm the count went up, not down.

Key takeaways

The real shift is that an agent can run your code and read the result, so it self-corrects.
Good agent tasks have a machine-checkable finish line. If a script cannot judge it, stay in the loop.
Commit and branch before every run — that is what makes a bad run cost nothing.
Always give a stop condition, or a stuck agent piles failures on failures.
Worktrees let an agent work in parallel with you, in a separate folder.
Check that tests were fixed, not deleted. That is the shortcut you must look for.