I was deep in a production refactor last month when I realized something uncomfortable: I'd been asking my IDE's AI assistant to make changes across fifteen files without actually understanding the cascade of consequences. The tool was fast, confident, and mostly right. But "mostly" isn't good enough when you're shipping to users.
That's when I started thinking differently about how I work with AI coding agents. The tooling landscape has genuinely shifted. It's not just about having an AI that can code anymore, it's about maintaining actual control and visibility over what happens to your codebase. This is where CLI-based agents started making sense to me in a way GUI tools never quite did.
Why I'm Paying Attention to Terminal-First Agents
For years, I've been the IDE person. Cursor in the sidebar, VS Code extensions doing their thing. But there's a real problem with that approach at scale: when your agent is living in your text editor, you get this false sense of collaboration. You're in the same window. Everything feels integrated and safe.
Then you realize the agent just modified your test utilities without running the test suite. Or it changed a shared component API in three places but missed the fourth because it wasn't in its context window.
CLI agents force a different workflow. They demand explicitness. You're passing context deliberately. You're triggering actions from your shell, which means you're aware each time something's about to happen. It's friction, but that friction is actually valuable.
The Current State: What Actually Matters
There are genuinely solid options now if you know what to look for. Claude Code is the obvious pick if you want raw reasoning power and don't mind paying for it. I've run it on architectural problems where a cheaper model would've suggested something naive, and the reasoning justifications alone were worth the subscription.
But here's what actually caught my attention from that landscape overview: vendor lock-in is becoming a real problem, and more developers are finally taking it seriously. When Google sunset their Gemini CLI, everyone using it had to scramble. That's the kind of situation that makes you rethink your tool choices.
OpenCode solving this with "bring your own model" is genuinely smart. You can point it at Ollama running locally, or AWS Bedrock, or whatever. You're not betting your workflow on one company's API staying stable or affordable.
My Take: I'm Still Cautious About the Hype
Here's my honest take: these tools are powerful, but I'm seeing teams treat them like they're supposed to replace good development practices. They're not. They're supposed to augment them.
The best practice mentioned, always branch before letting an agent modify your code, that's correct, but I'd go further. I scope aggressively. I tell the agent which files it can read and which it can modify. I run my test suite after every change, not because the documentation says to, but because I've watched hallucinations slip through.
The MCP (Model Context Protocol) integration point is interesting though. Connecting these agents to your actual project data, Jira tickets, Slack context, Notion documentation, that's where I see real potential. Right now most agents work with a pretty narrow window of what your project actually needs.
What I'm Actually Using
# My actual workflow for agent-assisted refactoring
git checkout -b agent/refactor-auth-module
# Scope the agent to specific directories
opencode --model gpt-4o \
--read-only="src/types/" \
--allow-modify="src/auth/" \
"Refactor login flow to use new session pattern"
# Force manual review before any shell execution
opencode --no-auto-exec
# Run tests immediately after
npm test -- src/auth/
# Only then decide if this branches back to main
This workflow takes longer than just saying "fix my auth code" to an IDE assistant. But I actually know what changed and why.
The Question I'm Still Wrestling With
Here's what keeps me up: as these agents get better at reasoning across huge codebases, do we actually maintain understanding of our own systems? Or do we drift into a mode where we're just trusting the agent's mental model of the codebase?
I don't have a good answer yet. But I know that if I'm not writing the agent's instructions carefully and reviewing its output deliberately, I'm probably building technical debt disguised as productivity.
What's your experience been? Are you using these tools in production, or are you still in the "experimenting in side projects" phase?
Source: This post was inspired by "Mastering the Terminal: Top 5 CLI Coding Agents for October 2026" by Dev.to. Read the original article
