Step 5: See what changed

An agent that has finished a job tells you what it did. It is a good account, written in confident prose, and it is the agent's own account of its own work. Your repository holds what actually happened. This step is the habit that sits between the two - reading the second before believing the first - and it is the one that turns an agent from something you supervise into something you trust.

About eight minutes. You need DevThrottle open with a session whose agent has changed some files - the job you gave it when you started your first session is exactly right. Come back with those changes unread.

1. Start from the badge, not the terminal

   Look at the session cards down the left. A small amber badge on a card - 4 chg - counts the uncommitted changes sitting in that session's working tree. It is a count of change entries rather than of files, so a file that was staged and then edited again is counted in both halves of its life; treat it as a rough size, not an inventory.

   Read it as the working tree's number, not this session's. Every session running in the same checkout wears the same badge, whoever made the changes, so the count can include work this session never did. And no badge means nothing to show, which is not the same as nothing changed: it never renders 0 chg, and it is equally absent when DevThrottle has not managed to produce a count at all. Start here anyway. Picking a card with a badge beats scrolling terminals looking for one.

2. Read the agent's story, then stop reading it

   Click the card and read the last thing the agent printed in the terminal: what it says it changed, and why. Hold that in your head - two or three files, a reason each. That is all you need from the terminal, and everything that follows happens somewhere else.

   The story is not evidence. It is the claim you are about to check.

3. Open Source Control and read the list against the story

   Select the Source Control tab, next to Terminal. Its Changes page names your branch along the top, and under it a Changes tree lists the files with edits, a letter on each for what happened to it - M modified, A added, D deleted, U for a new file git is not tracking yet. If nothing has been staged you will see one tree and no other, which is the ordinary case after a first job: the Staged Changes tree appears above only once something is actually staged, so do not go looking for it. The view refreshes itself while you watch.

   Now compare. An agent that said it changed the greeting in two files should be showing two files you expected. A file the summary never mentioned is not an alarm - it is simply the first one you open. Double-click it, or right-click and choose View File, and it opens: readable kinds in a tab inside the Director, anything else in whatever program your machine uses for it. A single click does nothing, and a file the agent deleted has nothing left to open - the next step is where you see what was in it.

4. Drop to the line-by-line difference

   The Source Control tab answers what changed. Before you keep anything, you want exactly what, line by line - and that lives somewhere else, because the session's tab has no Stage, no Commit and no Discard on it. Open Repositories, the pinned entry at the bottom of the left rail, and select this session's repository. You land on its Changes tab: the changed files down the left under STAGED and CHANGES, and, on the right, an empty pane reading Select a file to see its changes.

   Click one. Nothing is selected when you arrive, and until you pick a file the pane stays empty and the buttons that act on a file are not there at all. Click a changed file and its difference fills the pane - old and new line numbers down the side, added lines on green, removed lines on red - and Stage, Unstage and Discard changes appear in the header above it, for that file. The two steps below both start from a file selected here.

   Read it properly, but not evenly. Slow down in the files that matter and wherever the change is bigger or stranger than the job called for; skim the rest. If the difference is doing something the story never mentioned, you have found the thing this whole step exists for.

5. Keep what you accept

   The easy way to keep the work is the loop you are already in: go back to the session and tell the agent "commit this" in the prompt bar. Or do it here by hand - click Stage on each file you accept, write a message in the box under the file list, and click Commit staged.

   Either way, watch the screen agree with you. A commit takes everything staged: the Staged Changes tree empties and hides, and the amber count on the card drops by what was committed, while anything you deliberately left unstaged stays sitting in the Changes tree. Only when nothing uncommitted is left does the tab read No changes detected and the badge leave the card. If your branch tracks a remote, the branch bar now shows a green caret and a number - ^1 - for the commits the remote has not got yet. Read, kept, not yet pushed.

6. Send back what you do not accept

   Most changes you dislike are not wrong, only wrong yet, and the cheapest fix is the one you already have: tell the agent what is wrong with it and let it go round again. The work in the tree is the conversation, not a verdict.

   For work you want to unhappen, select the file in that same Changes tab and click Discard changes. It asks first, in plain words - This permanently deletes your changes in 1 file. There is no undo. - and lists the file above two buttons, Keep changes and Delete changes. Read the list, not just the button. Discard offers itself only on a file git can restore, which is a tracked file with unstaged edits; a brand new file the agent created has no earlier version to go back to, so if it is wrong you delete the file yourself.

Next

You can now tell what an agent did to your code without taking its word for it, which is the thing that makes it safe to run more than one at a time. That is the next step, Run several at once: starting a second and a third, reading the whole rail at a glance, and dealing with the one that has gone quiet. It is being written now. Until it is published, What your sessions are telling you teaches the reading half of it.

Going deeper on this step: See and review what changed covers the same ground more slowly and adds what this page left out - the full set of status letters, the other sync badges, staging file by file, and how untracked files behave. Every badge, tree and state on the review surfaces, as reference: Source control and history.