Every few months I carve out time to evaluate tools I’ve bookmarked but never actually used. Most don’t survive the first hour. They solve problems I don’t have, or they solve real problems in ways that create new ones. But occasionally something sticks, and when it does, it tends to reshape how I work in ways I didn’t anticipate.
The current batch of CLI tools feels different from what I was evaluating a few years ago. Back then, the trend was rewriting Unix classics in Rust for speed gains that rarely mattered in practice. Now the interesting work is happening at the interface level — tools that understand context, that present information in ways optimized for how humans actually read terminal output, that integrate with the broader ecosystem rather than standing alone.
The git problem, revisited
I’ve used git from the command line since I started programming. The muscle memory is deep. But lazygit made me question whether that muscle memory was serving me or just making me feel competent. The elevator pitch resonated immediately: git is powerful, but that power often manifests as pain when you’re doing anything beyond the basics. Interactive rebasing shouldn’t require editing a TODO file. Staging partial hunks shouldn’t involve arcane patch syntax.
Lazygit gives me a TUI that makes complex operations visual and reversible. I can stage individual lines by just highlighting them. I can reorder commits by moving them up and down in a list. The undo functionality actually works across operations that would be tedious to reverse manually. What surprised me most is that I’m not slower — the visual feedback makes me more confident about what I’m doing, so I spend less time double-checking with status commands and diff reviews.
Reading code that isn’t mine
A significant chunk of my time goes to reading code and logs rather than writing them. The standard tools work, but they weren’t designed for readability. bat started as a cat replacement with syntax highlighting, which sounded trivial until I actually used it. Seeing code with proper highlighting when I’m quickly checking a file makes a real difference in how fast I can parse what I’m looking at. The git integration that shows modified lines is the kind of feature I didn’t know I wanted.
The pattern repeats with ripgrep. Yes, it’s faster than grep, but the speed rarely matters for my use cases. What matters is the default behavior: it respects .gitignore, it shows context around matches, it presents results in a format that’s easy to scan. The Qodo team’s roundup of CLI tools makes the point well — modern CLIs succeed by having better defaults, not just better performance.
Context-aware assistance
The most significant shift is tools that understand what I’m working on. AI coding assistants that run in the terminal can now read my repository, understand my codebase structure, and generate or review code without me leaving the environment where I’m already working. This changes the workflow more than any other category of tool. Instead of context-switching to a browser or a separate application, I stay in the terminal and get help inline.
I’m still figuring out where these tools fit best. They’re genuinely useful for explaining unfamiliar code, generating boilerplate, and catching obvious mistakes in pull requests. They’re less useful when the problem requires deep domain knowledge or when the codebase has unusual patterns the model hasn’t seen. The key is treating them as a fast first pass rather than a replacement for actual review — they compress the time spent on routine tasks, leaving more attention for the parts that actually need human judgment.