I build SpaceApp, a self-hosted workspace for running AI coding CLIs side by side. This post is about the workflow, not the tool; the tool gets two lines at the end.
If your agent can't run npm test and read the failure in the same shell, you end up as the relay between the model and your codebase: copy the file in, copy the answer out, run it, paste the error back, repeat. That loop is fine for a snippet. On a real codebase it breaks down, and the reasons are worth spelling out.
What a web chat can't see
- The rest of the repo. You paste the file you think matters. The bug is often in the one you didn't paste: the caller, the fixture, the config.
- The real output. You paste the part of the error you think matters. The useful line is often 40 lines up, or in a warning you skipped.
- Whether the fix worked. The chat never runs it. "This should fix it" is a guess until a test says so.
- What changed. After five rounds of copy-paste, nobody knows exactly which version of which file is on disk.
What a terminal agent does instead
A CLI agent works in the working tree. It can grep for every caller before it changes a signature, run the test it just broke, read the compiler's diagnostics in full, edit several files in one change, and leave the result as a diff on a branch you can review. The feedback loop runs in the shell, not through your clipboard.
A small real example from our own repo: one of our contract tests passed on its own in about 1.5 seconds and timed out only when the whole suite ran in parallel. Nothing about that is visible in a pasted file or a pasted error. It took something that could run the suite, see the timing and change the test, and that was an agent working in a shell.
Where web chat still wins
To be fair to it:
- Exploring an idea before there is any code.
- Explaining a concept, an API or an error message you don't understand.
- A self-contained snippet: a regex, a SQL query, a one-off script.
- Zero setup, and no access to your machine, which is sometimes exactly what you want.
What terminal agents cost you
They are more powerful because they touch real things, and that is also the risk.
- Give them a branch, not your main checkout. One git worktree per agent keeps their work apart, and you review the diff before it lands.
- Give them only what they need. The folders for the task, read-only where reading is enough. No production credentials in the environment.
- Make tests the referee. An agent that can run tests will also happily "fix" a test to make it pass. Review test changes as carefully as code changes.
- Watch for parallel surprises. If you run several agents at once, run your suite in parallel too. Tests that pass alone and fail together are common, and some of them point at real bugs.
A worktree per agent is one command:
git worktree add ../myrepo-agent-a -b agent-a
Running several side by side
Once one terminal agent works, the next step is usually two or three: one per repo, or one planning and one executing. That works in tmux, in separate terminal windows or in a workspace that keeps the sessions for you. The rules stay the same: a worktree each, one way into main that builds and tests, and you as the reviewer rather than the clipboard.
Over to you
Where do you still use web chat for coding, and where did you switch to a terminal agent for good? And for those running more than one agent: what was the first rule you had to add?
The two lines about the tool: SpaceApp keeps CLI sessions side by side in persistent rooms on your own machine and your own provider accounts. It is MIT-licensed and installs on Linux, macOS or Windows 11 with Node.js 20.11 or newer: npx --yes run-spaceapp@latest install. Code and docs: https://github.com/oll4com/spaceapp
Top comments (0)