A stylized sketch of a penguin at a computer with a coffee.

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”.

Look, let’s get one thing straight: 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? It’s the humble, blinking cursor of the command line.

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

🚀 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

This isn’t just a command; it’s a sentence. It’s four separate, expert tools working in concert to solve a complex problem. It’s like having a set of LEGO bricks for your code, and the only limit is your imagination.

🧠 One Interface to Rule Them All

Instead of juggling a code editor, a Git client, 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. There’s no context switching, no reaching for the mouse. Just pure, unadulterated, keyboard-driven flow.

💻 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.

🤖 + CLI = A Match Made in Heaven

Here’s the kicker 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.

But It’s Not All Sunshine and Shell Scripts

Let’s be real. 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. The simplicity of the interface allows for a complexity of thought that I find hard to achieve when I’m distracted by a thousand panels and notifications.

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.