A shift I didn’t expect
Over the last few months, I’ve noticed an interesting pattern. Even as IDE-first AI tools are getting remarkably good — especially tools like Cursor and GitHub Copilot — the developer community seems increasingly excited about terminal-based coding agents like Claude Code, Codex CLI, and (increasingly) Gemini CLI.
Is it just developer culture?
At first glance, it’s easy to assume this is just classic developer culture. The terminal has always been associated with “real engineering,” and there’s a certain credibility attached to being fluent in the CLI. So yes, if we’re being honest, there’s a small amount of identity-signaling in the mix.
The real reason: software is shipped in the execution loop
But after experimenting with these tools myself, I’m convinced that explanation is incomplete. The real reason terminal agents are catching fire is simpler: they match how software actually gets shipped.
In an enterprise environment, the IDE is not the system of record. The repo is. The CI pipeline is. The build logs are. The test outputs are. The security scans and policy gates are. In other words, what matters isn’t that the code “looks right” in an editor — it’s whether the change survives the execution loop: build, test, validate, and deploy. That loop lives in the terminal.
Why terminal agents feel like “real work getting done”
A terminal agent isn’t just generating code. It can search the repo, make changes across modules, run tests, observe failures, fix them, and rerun until everything is clean. That’s what makes tools like Claude Code and Codex CLI feel less like “autocomplete” and more like a junior engineer who can execute.
My personal takeaway: IDE-first wins for experimentation
That said, I’ve noticed something in my own workflow. I’m not using these tools to ship large-scale enterprise software every day. I’m experimenting, learning, and building practical apps faster than I ever could before. And in that mode, IDE-first AI tools shine. Using an IDE-first tool like Cursor, I’ve built a NetWorthTracker, a ShoeMileageTracker, a CashFlowTracker, a Runway Simulator, and a Retirement Planner — all in the last month. The plain-English narrative inside an IDE — “add a new screen,” “connect this API,” “build me a simulator with sliders” — is intuitive, fast, and genuinely enjoyable.
The enterprise lens: traceability beats convenience
But when the goal shifts from experimentation to production-grade delivery, the terminal agent model starts to make a lot of sense. And the enterprise angle makes it even clearer: trust requires traceability. What changed? What commands were run? What tests passed? Can we reproduce it? Can we audit it?
Terminal workflows are explicit and replayable. IDE workflows can be incredibly productive — and tools like GitHub Copilot have become a default in many development environments — but they often feel harder to standardize and govern at scale.
Conclusion: it’s not IDE vs terminal — it’s both
My conclusion isn’t IDE versus terminal. It’s both: IDE AI for creative shaping of code, and terminal AI for validation, reproducibility, and shipping.