My IDE is the Linux Terminal 🐧

Someone asked me the other day what all the fuss was with being able to use tools like Gemini CLI vs a fully baked IDE ……. it got me thinking beyond “just because”.

The key thought I have on this is the “best” development setup is the one that gets you in the zone (aka flow) and keeps you there. For some, it’s a feature-packed, graphical IDE. For me? Quite oftern it’s the humble, blinking cursor of the command line. The “surface” I use also changes depending on what I am doing (or trying to acheieve).

This isn’t about being a l33t h4x0r. It’s about a workflow that, for me, just feels right. It’s fast, it’s powerful, and it doesn’t hog all my RAM before I’ve had my first cup of coffee. Maybe it’s because I cut my teeth in the terminal, or maybe I just love the beautiful simplicity of it all. Since the release of Gemini CLI I have dusted off my tmux configs and also upgraded from vi to neovim (rock and the roll).

So, grab your favorite brew, and let me explain why my IDE is the entire Linux operating system.

The Zen of the Command Line

🧠 Why Your Brain Loves the Blink: The Science of “Flow”

I mentioned earlier that the CLI “just feels right” and provides a sense of “directness and control.” It turns out, there is genuine cognitive science backing up why a text-based, stripped-down environment often beats a feature-rich GUI for expert tasks.

1. The Reduction of “Extraneous Cognitive Load”: Modern IDEs are magical examples of engineering, but psychologically, they are noisy. In User Experience (UX) psychology, Cognitive Load is the amount of working memory resources used.

   • Extraneous Load: Information that doesn’t help you solve the problem (e.g., a “What’s New” popup, a bouncing icon, 15 different toolbars).
   • Intrinsic Load: The difficulty associated with the specific task (e.g., the logic of the code you are writing). The terminal drastically reduces extraneous load. By removing visual clutter, you free up processing power in your brain to focus entirely on the intrinsic load—the code itself. This explains the “Zen” feeling; your brain isn’t filtering out noise, so it feels lighter.

2. The “IKEA Effect” and Dotfiles: I call “Dotfile Gardening” a labor of love. This is a classic example of the IKEA Effect: a cognitive bias where people place a disproportionately high value on products they partially created. Because you built your .vimrc, you understand it intimately. It isn’t just a tool; it is your tool. This creates a psychological bond and a sense of ownership that a pre-packaged IDE cannot replicate.

3. The “Illusion of Control” vs. Actual Agency: Psychologically, humans have a deep-seated need for Agency—the feeling that our actions directly result in outcomes. When you click a green “Play” button in an IDE and it breaks with a generic error, you feel helpless (low agency). When you type a command and see the stderr stream, the Locus of Control shifts internally. You feel responsible for the success and the failure. This autonomy is highly correlated with job satisfaction and reduced burnout.

🚀 It’s All About the Unix Philosophy

Deep down, my love for the CLI comes from the Unix Philosophy, which has three core tenets that just make sense:

1. Do one thing and do it well: Tools like grep, sed, and awk are masters of their craft. They aren’t bloated; they are focused and powerful.
2. Write programs to work together: This is the magic of the pipe (|). Every tool is designed to be a building block, seamlessly connecting with others.
3. Handle text streams: Text is the universal interface. By treating everything as text, you can create incredibly powerful, on-the-fly workflows that graphical interfaces can only dream of.

grep "ERROR" logs.txt | awk '{print $2}' | sort | uniq -c

To a novice, this looks like a terrifying string of random characters. But experts utilize a psychological process called Chunking. You don’t read the letters; you read the “sentence.”

• ls -la = “Show me everything.”
• | = “Pass it to…”
• grep "py" = “Find the python files.”

Because you have “chunked” these complex operations into single mental concepts, your speed of thought matches the speed of the interface. This creates a dopamine feedback loop—you think it, you type it, it happens.

🧠 One Interface to Rule Them All

Instead of juggling a code editor, a Git client/plugin, a database tool, and a separate terminal window, my entire world is in one place. My text editor (nvim) lives in the terminal. My code (git or gh) lives there. My tests (pytest) live there. My AI assistant (gemini) lives there.

Science calls the disruption of moving your hand from keyboard to mouse the “Micro-Interaction Gap.” Every time you reach for the mouse to click “Run,” you introduce a micro-break in your mental context. You switch from “Linguistic/Logical” processing (typing code) to “Visuospatial” processing (navigating 2D space).

In the CLI, your hands never leave the home row. The “conversation” with the computer remains purely linguistic. This continuity maintains the neural pathways active for the task at hand, sustaining the Flow state much longer than a “point-and-click” workflow.

💻 Lightweight and Blazing Fast

A modern IDE can feel like it’s warming up the engines of a 747 just to open a file (maybe I just have too many extensions/plugins enabled). My terminal and text editor? They’re instant. They sip resources like a fine espresso, leaving plenty of power for the things that actually matter, like compiling code or running tests. This is a lifesaver on a laptop and makes remote development over SSH feel just as snappy as working locally.

🤖 If You Can Do It Once, You Can Automate It Forever

This is the real magic. Any command I type, any workflow I create, can be instantly saved into a shell script. That grep | awk | sort chain from before? Now it’s get-error-counts.sh. Automation isn’t a feature I have to find in a menu; it’s the very nature of the environment.

This also means my local environment is my CI pipeline. Because I’m not relying on “Right Click > Deploy,” I’m writing scripts that can be copied directly into a GitHub Action or a Cloud Build step. There is no “it works on my machine” ambiguity because my machine is just running the same shell commands as the build server. Having a CLI-first workflow makes you could be a better DevOps/Platform engineer by default.

🤖 + CLI = A Match Made in Heaven

Here’s the fun in the age of AI: The Gemini CLI can use any tool I can. Because it lives in my terminal, it has access to my entire toolkit. I can ask it to pipe something to jq, convert a file with pandoc, or even use a proprietary internal tool. My personal setup directly extends the AI’s capabilities.

This partnership extends beyond just writing code. I’ve found myself leveraging it to help write documents, validate their structure, and even critically review them for clarity and flow. It’s like having a co-author and a technical editor available with a single command.

To help others explore this workflow, I’ve started a cookbook of examples and patterns. It’s a living document that I expect to evolve as new capabilities are added and we all discover new ways to tackle our work: https://github.com/sapientcoffee/ai-for-sdlc.

Back in 2023 I satrted to build a demo that would use Gemini in the CLI and in 2024 I wrote about it building a code review agent. I wanted t be able to embed AI into existing process and could see great value in helping with a common friction point-code review. Back then it was very much a home grow CLI written in Go now I can focus on using Gemini CLI for value.

But It’s Not All Sunshine and Shell Scripts

Let’s be honest. The CLI isn’t perfect.

• The Learning Curve is a Cliff: It takes time. A lot of time. Mastering a powerful editor and the ecosystem of command-line tools is a journey, not a weekend project.
• Visuals Can Be Nice: A graphical debugger is a wonderful thing. Resolving a gnarly merge conflict is often easier with a three-way diff view. Sometimes, a picture is worth a thousand lines of stdout.
• Dotfile Gardening: You will spend more time than you’d like to admit tweaking your .vimrc, .bashrc, and .tmux.conf. It’s a labor of love, but it’s still labor.

I know that I need to master neovim and plugins to better navigate the file system rapidly however I am looking forward to that journey!

So, Why Do I Stick With It?

For me, it boils down to a feeling of directness and control. There’s no “magic” hiding what’s happening. It’s just me, my tools, and the code.

It turns out, that feeling isn’t just nostalgia—it’s cognitive science. The terminal quiets the noise, protects the flow, and restores agency. It turns the computer from a black box into a conversation partner.

It’s a personal preference, a workflow that feels less like operating a machine and more like a conversation with my computer. And that, for me, is where the real joy of development lies.