A CLI workflow that survives a real working day

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

Ask an engineer to describe their day and you get a clean story. Watch the screen and you see something else. A build fails. Someone pings about a customer bug. The branch they were on is now three commits behind. A CLI workflow that only works when you have ninety uninterrupted minutes is a demo, not a workflow.

So the design constraint is recovery. Every step should leave enough on disk that you can walk away for two hours and come back without reconstructing anything from memory or from scrollback.

The four moves that make a CLI workflow durable

• Isolate concurrent edits when tasks could conflict. For a new branch, git worktree add -b feature-x ../feature-x creates a separate directory. A single agent or explicitly serialized edits can use the existing checkout; follow the repository’s worktree policy.
• Write the plan to a file before any code changes. Not a chat message. A file the next session can read.
• Commit coherent checkpoints after reviewing the diff and relevant checks. A passing test alone does not make unrelated or unfinished changes ready to commit.
• Keep the long-running thing in its own terminal. Dev servers and watchers do not belong inside the agent's shell, where a killed process takes the session with it.

What the loop looks like

Concretely, for a change of any real size:

git worktree add -b invoices-fix ../wt-invoices
cd ../wt-invoices
# describe the task, ask for a plan, read it, correct it
# then let it work, reviewing each file as it lands

The step people skip is reading the plan. It takes two minutes and it is the only cheap moment to catch a wrong approach. Once the agent has edited eleven files, correcting the direction costs more than starting over. Compare the proposed files and checks with the actual task before editing; this can expose a mistaken assumption while it is still cheap to change.

The second skipped step is the mid-task commit. Engineers treat the agent's work as one atomic thing and only commit at the end. Then the last instruction goes badly, the working tree is a mess, and the good work from an hour ago goes with it.

Where the CLI is worse than the editor

Honest limits. Reviewing a large diff in a terminal is worse than reviewing it in an editor with a proper side-by-side view. Anything visual, a layout bug or a chart that looks wrong, is faster to fix where you can see it. And a terminal session has no memory of yesterday unless you gave it one, which is the whole reason for writing plans and notes into the repo.

For a first recovery test, pause after a coherent checkpoint and ask another developer to resume using only the repository and task notes. Record what they had to reconstruct, then fix the missing command, prerequisite or decision. Use an editor or rendered preview when it makes the diff easier to assess.