Before you hand the agent its first task, it is worth answering an uncomfortable question: against what will you measure its result. Without an explicit point of reference, "the agent did something" and "the agent did what was needed" are indistinguishable. Git is that point of reference, and you set it up before the task, not after.
The naive move is to give the task straight away on top of the current state of the working tree, whatever it is. It often already holds your uncommitted edits, a rough experiment, a half-built branch. It seems not to matter: the agent will do its thing, and we will sort it out later. The logic is clear: git is always at hand, you can roll back at any moment, so order can be restored afterward too. That postponement is the trap - it moves the tidying to the moment when tidying is hardest.
It breaks at the moment you need to understand what exactly the agent changed. If the start was dirty, its edits are mixed with yours, and the diff shows the sum, not the agent's contribution. Separating one from the other after the fact is hard and risky: it is easy to revert too much or leave in someone else's change. A dirty start turns a measurable result into a tangle. This stings especially on the first session, when you do not yet know the agent's handwriting and cannot tell by eye which line in the diff is whose.
The professional move is to set up a baseline. Get a clean git status, fix the starting state with a commit, and make sure build and test run without the agent and give a known result. A few commands are enough: look at the status, branch off a separate branch for the agent's work, run the tests and the build before the task. None of these commands involves the agent - and that is the point: the baseline is taken in an environment without it, so the reference point is honest.
The point of this preparation is one: after it, any result of the agent reads as a diff against a known state. You see exactly what the agent added, and you know the tests and the build were green before it - so a red result after the task speaks of the agent's edit, not a background breakage. A known starting point turns verification from a guess into a comparison. This distinction is worth more than it seems: without it any test flakiness after the session looks like the agent's fault, even if it was there before, and you waste time debugging the wrong thing.
In an existing project a separate branch or worktree is not over-caution but a way not to mix. You do not leave your uncommitted changes in one heap with the agent's first session: large work is run in a separate branch or in an isolated worktree, where the agent's diff lives on its own. That way a parallel task does not infect the active branch, and the merge stays a controlled step. A worktree is especially apt here, because it gives the agent a separate working tree of the same repository: branches, history and remote are shared, while the files on disk are its own, and active work in the main tree does not intersect with the session.
The cost of a skipped baseline shows up at the rollback. Revert in the interface is convenient and fast, but it is an application feature, not the repository's journal. A portable, reliable rollback comes from Git: a baseline commit and a branch are visible from any client, they survive an application restart and a change of tool. Relying only on the interface revert means keeping your safety net where it is hardest to restore. The practical takeaway is not to give up the convenient revert but not to make it the only safety net: the interface rollback is good for a quick step back in a live session, while the git baseline guarantees you can always return to a known state.
A separate thread is secrets. The safety net protects against losing code but not against a leak: files with secrets are closed off by gitignore, so they do not reach a commit, and by the agent's separate permission rules, so it does not read or send them. These are two different boundaries - what reaches history and what the agent sees - and both are set up before the first task, not after an incident. Keeping these two boundaries apart matters because gitignore and permission rules solve different problems and do not replace one another: the first keeps a secret out of history, the second keeps the agent from reading what it has no reason to see.
You should check readiness against a short list, not a feeling. The working tree is clean or the changes are intentionally saved. The test and the build have a known result before the task. Secrets are closed off by gitignore and separate permission rules. If all three points hold, the agent's result has a reference point, a rollback and an access boundary - three things that are expensive to restore after the fact.
The typical failures are the same for everyone in a hurry. They give the task on top of a dirty tree and then cannot separate the agent's contribution from their own. They rely on the interface revert and lose it when the tool changes or on a restart. They forget about gitignore and permissions on secrets and find a key in the diff. The sign is the same: no baseline was set up because "it is just a quick task." Set it up - a minute of preparation is cheaper than an hour of untangling.
git status --short
git switch -c chore/devin-baseline
npm test
npm run build