I tried a bunch of terminal coding agents last month. Some I reopened every morning. Some I uninstalled by Friday. What surprised me is that the ones I dropped were not worse at writing code. The model quality was roughly the same across all of them.
The difference was entirely in how the tool showed me its work. Once I noticed that, picking one got easy, because it stopped being a question about the model and became a question about three things the CLI either does or does not do.
The short version: an agent CLI is a UX problem wearing an LLM costume. Here are the three things I check now.
Does it show me the plan before it touches anything?
The CLIs I kept all do the same thing first. Before writing a single file, they print what they intend to do: which files they will read, what change they will make, which commands they will run, and then they wait.
The ones I dropped just start. You type the task, it prints "working..." and it is already editing files. By the time you can see where it is going, it is two files deep in the wrong direction and you are cleaning up.
The reason plan-first wins is simple. An agent run is not one answer, it is a stack of changes you cannot easily undo. Reviewing that stack at the end is reviewing a crash. Reviewing it up front is just engineering. And the plan has to be editable, not just visible. Being able to say "skip step three, run the tests this other way" is what turns the tool into something you steer instead of babysit.
Does it name every action, or hide it behind a spinner?
The second thing separates the trustworthy CLIs from the rest completely.
The bad pattern is a spinner and then "done, three files changed." What did it actually do? Did it edit the right files? Did it run a shell command? Did it delete something? You read the final diff and hope, and if the diff is wrong you have no idea which of forty steps caused it.
The good pattern narrates as it goes. It names each file it reads. It shows a diff before it writes, so you can accept or reject. It prints the full shell command it is about to run, not "running command." When something fails, it tells you which tool failed and why, instead of quietly retrying and handing you a wrong answer at the end. That running commentary is the entire difference between an agent I let run on its own and one I have to watch keystroke by keystroke.
When it goes wrong, can I undo cleanly?
The third thing is where most of them fall apart, and it is the one that decides whether you trust the tool on a real codebase.
Three levels matter, and I want all three. I want to reject one bad step without killing the whole run, so the agent adapts and keeps going. I want to undo everything from a session with one command when it goes truly sideways. And ideally I want to restart from step six of an eight-step run with a corrected instruction, instead of starting over.
The CLIs that get this right usually lean on git under the hood, treating each change as a commit so undo is a real, first-class action. The ones that get it wrong leave you doing git stash and manually inspecting a dozen modified files to figure out what it touched. If your tool cannot cleanly undo a whole run, treat it as a toy for experiments, not something you point at production code.
How I actually pick now
The thing I stopped doing was choosing a CLI based on which model sits behind it. The model is a setting. You can swap it. The way the tool surfaces its work is what you live inside every single day, and that is sticky.
So my test is just those three questions, run against my own real tasks, not a demo: does it show me an editable plan, does it name every action as it happens, and can I undo a run without a fight. A tool that does all three earns a place in my terminal. A tool that misses even one quietly trains me to distrust it, and that is when it gets uninstalled.
If you want the fuller version, with a five-task scoring rubric and how the same three axes hold up when you run these things in CI, this piece lays it out.
I am curious which one you settled on and why. And more specifically: did you pick it for the model, or for the way it behaves in the terminal? I keep meeting people who chose on the model and quietly regret it.
Top comments (0)