Moving my development to the terminal

· Tech

When I got my first computer around 2000, everything was Windows. A year later I installed Linux and started playing with it. My first computer had an Intel Celeron 600MHz, a Riva TNT2 graphics card, 20GB HDD, and 64MB of RAM. One of my first distributions was Gentoo. I think it might still be my favorite, but I do not have time to play with it anymore.

With Gentoo, I was compiling the entire system from source. There were stages, stage zero or one. I do not remember exactly. I compiled every program, the kernel, everything. On my hardware, it took ages. The most time-consuming parts were huge GUI apps like GNOME, OpenOffice, and so on.

At some point I realized that most of my work was already happening in the terminal. I was using Irssi for IRC, CLI programs for instant messaging, text-based music players, and lynx, links, or links2 for browsing the web. So I thought, maybe it is time to just drop the graphical interface completely.

And I did. My machine became so much faster. I spent a couple of months living entirely in the terminal, and it was really nice. The biggest problem was that most websites were not designed for text-based browsers, but it worked. I remember that at some point there was even a way to display images in the terminal, and I used that. From time to time I installed a lightweight window manager for websites, PDFs, or games. But the terminal was my home.

The GUI years

Over the following years, I moved back to graphical interfaces. For the last 20 years, I have mostly used Fedora/GNOME and macOS, along with editors like Sublime Text, VS Code, and later WebStorm.

I would not call myself a power user. I do not code with my eyes closed. I do not have hundreds of shortcuts memorized. I use the trackpad a lot and click around. It is probably slow, but to be honest, I am not coding all the time. Most of my work in recent years has been more about thinking. How to do something, how to make it more efficient, how it should look. It is more thinking, more testing, more trying than writing code.

The terminal never left

Even with a full IDE like WebStorm that has everything integrated, I still use the terminal for running tests, linting, debugging, creating commits, running git pull, and so on. I know WebStorm provides all of that. But I always go to the terminal instead. I am not sure why. It is just easier for me.

And that got me thinking. If I already spend so much time in the terminal, why do I keep switching back to a GUI editor?

AI pushed me over the edge

The thing that finally made me want to go all in on the terminal was AI.

Now, AI writes most of the initial code for my workflow. Which is probably fine for now. Let us see how it goes. As a web developer working with backends, React, and other frontend work, AI is great at this kind of thing. When you have good documentation, clear prompts, and existing code to build on, AI can handle a surprisingly large part of it.

So what I do now is I use a lot of AI. If AI cannot do something, or I need to adjust it, then I go to the file and write the code myself. Then I can ask it to review that, improve it, or suggest alternatives. It is very different from one or two years ago. The flow is evolving.

When I started using more AI tools for coding, I first tried the desktop apps for Claude, Codex, and similar tools. They worked fine, but they were very slow, memory-consuming, and I had a lot of performance issues. Then I tried connecting CLI tools to WebStorm through IDE integrations, but I did not like how they worked and behaved. So I tried the CLI version directly in my terminal.

And it was like, wow.

Faster, more efficient, lighter on memory. I just liked the experience more than the graphical interface. AI interaction is fundamentally text-based, so the terminal feels like a natural home for it. That was the moment I thought: maybe I should move everything here.

Why the terminal feels better

This made me think about something I had not really put into words before. Graphical interfaces are full of visual noise. An IDE like WebStorm has panels, tabs, sidebars, toolbars, icons, menus, status bars, notifications. And every IDE looks completely different. WebStorm looks nothing like VS Code. VS Code looks nothing like Xcode. Even within one IDE, every plugin adds its own UI elements. You are constantly surrounded by things competing for your attention.

In the terminal, everything looks similar. You have one font for everything. Every line has the same height. There is a kind of baseline. If you want something like a heading, you do not make the font bigger. You use bold, a different color, or a different background. The colors come from your theme, and you can use the same theme for every CLI program, every tool. Git output, test results, linter warnings, AI responses. It all looks consistent.

Everything is readable, clean, and unified. And that is actually an advantage.

After some time working in the terminal, it becomes really easy to read everything. I can scan the screen and quickly find the information I need. There are fewer UI elements than in a GUI, but for me, it is easier to process. Less noise, fewer distractions.

With graphical tools, every application looks different. You learn how one works and how to navigate it. Then you switch to another, and everything is completely different. Your brain has to adjust every time.

In the terminal, your brain already knows what to expect. Everything follows the same pattern. You read faster and find information faster.

When I compare what I see in the terminal to what I see in graphical apps, I honestly like the terminal much more. I can use my font. I can use my theme. Everything looks the way I want it to, not the way someone else decided. That matters more than I thought.

tmux

So I decided to try to move as much of my development workflow to the terminal as I can.

I started with tmux. I had it installed before but was not really using it. Before tmux, I was using Ghostty tabs and split windows. It was okay, but with tmux it is much better. I have a bar at the bottom of the terminal that shows me which windows I have. I configured shortcuts to easily create new windows, split them, close them, and switch between them. I can rename windows, so I know what is in each one. I can have multiple sessions running in the background without closing them.

After one or two hours of configuration, I was really comfortable. I do not have to think about how to create, switch, or organize windows anymore. It just works.

Neovim is next

My next step is learning Neovim. I have tried to learn Vim a few times in my life. I use Vim because I do a lot of server work, and every time I need to edit a config file, I do it in Vim. I know how to quit Vim, which is the most important part. I know how to edit files, but usually I have to navigate around with basic commands. I do not know a lot of shortcuts.

But I realized something this time. I always wanted to make Vim or Neovim into a copy of WebStorm. A full IDE replacement with every feature. But I do not need that. What I really need in a code editor is: syntax highlighting, go to definition, search for functions or text, file navigation, maybe a file tree. Nowadays, I also want AI-powered autocomplete and auto-formatting on save. Maybe live error and type checking for TypeScript, so when I write something wrong, it is immediately visible. That is it.

I do not need git integration in my editor. I can use Lazygit. I can use the terminal for committing, for linting, for code formatting, for auto-generating commits. I can run a watch command that auto-formats on every change or verifies errors on every change. I do not need all of that inside my editor.

I will probably use something like Lazygit with delta or similar tools for code reviews and conflict resolution.

This is basically the Unix philosophy. Small tools that do one thing well, composed together. The editor edits. The terminal handles everything else. And when you work this way, you actually learn the real tools. You learn git, not your IDE’s git panel. You learn your linter’s CLI, not a sidebar icon. That knowledge transfers everywhere, especially when you work on servers where there is no GUI at all.

Keep the editor minimal. Handle everything else in the command line.

Let us see

Basically, AI in the terminal was the push I needed. The experience is just better there. And once I realized that I already spend most of my time in the terminal, it made no sense to keep switching to a GUI editor for the remaining part.

I will try to learn Neovim, configure it step by step, and move in this direction. I will write an update in a month or two to share how it goes. Maybe I will fail. But I really want to try.