Cursor Freedom: Flow-State, FOSS, and the Switch to Gemini CLI

Setting the Stage: Context for the Curious Book Reader

This entry captures a pivotal moment in a developer’s workflow, chronicling the deliberate shift from a graphical, VSCode-based AI assistant (Cursor AI) to a command-line tool (Gemini CLI). This decision isn’t merely about swapping one product for another; it’s a practical application of a deep-seated philosophy that champions the command-line interface (CLI) for its power, longevity, and resistance to corporate “vendor lock-in.” The author delves into the importance of Free and Open Source Software (FOSS), arguing that true ownership and control over one’s tools are paramount for serious development work.

The discussion expands beyond a simple tool comparison into a masterclass on optimizing a developer’s environment for “flow-state”—a state of deep, uninterrupted concentration. The author details a meticulously crafted setup using virtual desktops and keyboard-centric navigation, arguing that such an environment is not just a matter of preference but a strategic advantage in the age of AI. This entry provides a rare, unfiltered look into the why behind a power user’s technical choices, connecting the dots between software freedom, muscle memory, and the future of AI-assisted programming.

The Tipping Point: Moving from Cursor AI to the Command Line

Well, I just added the article about my switch from Cursor AI to Gemini CLI. This is big for my workflow. It was big getting used to Cursor in the first place to not be left off the AI code assistant bandwagon, and it was a valuable experience. Despite my innate allergy to VSCode, the program from which Cursor was “forked” I had to hold my nose and take my medicine anyway. You can’t not know VSCode today and you can’t not know how AI code assistance is evolving in that environment. And I was along for the ride, but programmer’s programming tools (command-line based) are finally arriving in a fashion worth risking integrating into my day-to-day workflow for awhile just like I did Cursor.

Who knows whether I’ll stay on Gemini CLI in the long-term but one thing is for sure. It’s true free and open source software (FOSS) unlike Claude Code and OpenAI Codex that came before it, both of which I interpreted as vendor lock-in traps. I think Amazon adjusted Code Whisperer to have a command-line based version in this time, and things like Auto-GPT, GooseAI, BabyAGI, GPT-Engineer, Aider, Open Interpreter, Mentat, CrewAI came before them. Plus you could build your own agentic framework from scratch or perhaps using LangChain in order to get exactly what you wanted. But I interpreted most of that as rabbit holes I would jump down and never return from.

Principles Over Proprietary: Why FOSS Matters in the AI Age

The timing had to be right switching to a command-line agentic framework. Claude Code was the most tempting, making a big splash as it did, but I resisted because I was already on Claude through Cursor and I was detecting the vendor trap as Cursor was not FOSS and neither was Claude Code. So I was not about to swap proprietary for proprietary for the same AI and add another $20/mo. subscription or risk dropping the Cursor subscription. But that was then and this is now, and the others have all thrown their hat into the command-line driven agentic framework arena, and one of them is not only true FOSS but also my favorite coding assistant after Claude: Gemini 2.5 Pro which I had been using for awhile in 1-shot mode through the Web UI because of my GoogleOne subscription. And those 1-shot prompts were 130K token webform submits which blew every other AI coding assistant Web UI out of the water. I was ready to test this model in a command-line UI where I didn’t have to bundle everything up for a web form.

You might think just giving all your files as attachments in canvas mode is a viable alternative to an all-in-webform-textara submit. For some reason, it isn’t. The difference in quality of response is very noticeable between whether your codebase is in the textarea and whether you’re asking the model to go file-diving on a bunch of attachments. I’m a bit worried that using Gemini CLI will have the same downside as attachments and lack the upside of a vast everything-in-context single webform textarea submit. The jury is still out but so far the Gemini CLI quality has been high enough to give it a chance.

A Workflow Forged by Keyboard: The Philosophy of Virtual Desktops

That very long and not particularly well formatted article from yesterday was working Gemini CLI in my day-to-day workflow. I work on 7 virtual screens. I have this journal that I’m writing in all the way to the left (screen 1) and the public work journal where this content will be ultimately copy/pasted over to all the way to the right (screen 7). In this way I “bracket” my full day between freeform stream of consciousness thinking where I have none of the pressure of whether it’s going to get published or not and can go on even longer rambling asides than you encounter here and simply not copy/paste those parts over to the published version. Right symmetrically in the middle, on screen 4, is another terminal which I allow to get “tabbed” that I share between domains:

[(screen1), (screen2), (screen3), (screen4), (screen5), (screen6), (screen7)]

Which contains:

[(terminal1), (), (), (terminal2), (), (), (terminal3)]

This provides an incredibly strong mental model for jumping directly from screen to screen that works well on Macs, Windows and especially on Linux GNOME which is the default and what I use as my desktop manager under NixOS. You can use:

• Move to the workspace to the right: Press Ctrl + Alt + Right Arrow.
• Move to the workspace to the left: Press Ctrl + Alt + Left Arrow.

…to move left and right between the virtual desktops which is very reminiscent of the same actions on Macs and Windows, so even this is part of my future-proofing routine. While the command-line is probably the ultimate future-proofing tool it is almost never the primary UI anymore, unless you’re logging into a remote headless server — and when you do it’s good to have those CLI skills. But most of the time you’re on the desktop of a Mac, Windows or desktop Linux machine, all of which have their own window management systems in which your command-line terminal resides. And to switch between them lighting quick and amongst other apps with the exact same keyboard shortcut what you want are virtual desktops. They go by many names: Spaces, Workspaces, Exposé, virtual desktops, virtual screens, yadda yadda.

The ambiguity of what this feature is called adds greatly to you not knowing that you have this underutilized superior computer interface mechanism. In the late 1980s the Amiga computer had Amiga+N for much the same screen cycling purposes which I got completely spoiled by and attached to, so I’ve watched (and participated) with great interest as Apple, Microsoft and all the Linux windows managers wrapped equivalent features into their modern but primitive operating systems. Thankfully they all settled on something similar enough that it’s not completely insulting to muscle memory to switch between host OSes.

Alright, so for the longest time I suffered with a willy nilly random number of and arrangement of virtual desktops. Then I realized what a boon to muscle memory it would be if I just had a strong mental model about how many screens I had and what application was running on each screen. As I previously mentioned I established a pattern of 3 terminals sandwiching 2 slots between them:

[(terminal1), (), (), (terminal2), (), (), (terminal3)]

…but in terms of apps it means this:

[(journal1), (), (), (N-tabs), (), (), (journal2)]

And by N-tabs I mean any number of tabs because terminal software generally has its own tabbing system, so now you’re in the world of nested tabs and potentially complex hierarchies throwing off the simple flat horizontal left-and-right mental model. To solve this I tend to not use any tabs on the terminals on screen 1 or 7. This way if I just go all the way left or go all the way right I bump into the sides and can just start writing. I can’t tell you how useful this is in the age of AI when it’s all about writing prompts.

The middle terminal however I allow tabs. It’s the GNOME Terminal program with tabs. Okay now here’s the amazing thing. You’re already not taking your hand away from the keyboard to go left and right between the virtual desktops so you remain in flow-state by not having to pause to re-orient yourself to a different local frame, right? You with me? In your mind you have different local frames tied to your awareness. One is hands-on-keyboard, eyes-on-screen typing away, popping between screens and apps or whatever but always remaining in deep-focus flow state. Still with me?

Escaping “Steve Jobs Mode”: The Battle for Flow-State

The other is Steve Jobs-mode by which you break your flow with a jolting jarring stop but in return you get the baby-user-interface. Complex hard-won habit foreknowledge and muscle memory — something babies don’t have — is not required, but you can hunt-and-peck around with hand on mouse and steering through menus to interactively discover things about your environment and just do it from scratch in a sort of relative-universe way. You can always figure things out relative to yourself and your immediate environment through a process of exploration and discovery. Not a bad thing… except for the flow-state of an expert.

VSCode Command Palette Compensation

You’ll notice compensations kludged in all throughout point-and-click ga-ga-GUI software in the form of keyboard shortcuts on the menu, and some software tries to make dropdown menus navigable in flow-state without taking your hand off the keyboard with the most popular example these days being the Ctrl+Shift+P command palette of VSCode which is also in Cursor and Windsurf as forking derivatives. What makes the command palette different from plain keyboard shortcuts is that as you bring it up you can navigate the entire menu system by just starting to type without being tied to particular keyboard shortcuts.

You might think I’m being unfair to Steve Jobs by characterizing a war against the command-line, but you have to remember he advocated the removal of every last vestige down to removing arrow-keys from keyboards (used for navigating text-UIs). Steve Jobs famously refused to sign a fanboy’s keyboard until he pried the arrow-keys off the keyboard with a knife. I do not understate the degree to which initial accessibility took priority over long-term mastery. Disrupting the development of mastery is part of designed obsolesce and the economic machine of re-sell, re-train, reset.

VSCode’s command palette is only the most popular example these days of GUI software trying to make up for their expertise and mastery-development inhibiting nature. GUI software because it depends on continuous flow-state breaks on top of menu hunt-and-pecking never lets you get faster and faster over time without fragile kludges that works different between different GUI programs and is subject to catastrophic (to muscle memory) changes between versions. Does anybody out there remember when Microsoft Office switched from normal dropdown menus to what they call ribbons? No? Trust me, it’s ugly.

This is all in stark contrast to how with the command-line you just get consistently better and faster, and the command-line interface never changes on you. But it’s at the steep cost of actually figuring things out ahead of time, remembering them, and knowing how to do it again next time without taking your hands away from the keyboard.

Switching from Ctrl+Alt+Left/Right Arrow and Alt+[1-9] to jump into your terminal tabs is one of those things.

It’s a leveling-up superpower in computer-use and future-proofing especially now in the age of AI where so many of the real power-tools are coming back to the command-line (CLI) because automation!

You can’t all that easily automate GUI. Oh you might think so. Apple has Automator and Microsoft Windows has Power Automate which are just fine if you’re locking yourself into a proprietary operating system and happy with the fragility of things breaking when positions move, resolutions change and such. You can make automations that run just fine as long as they run on exactly your system in some locked-down state. Plus you don’t have the freedom to just deploy in the cloud or spin off a thousand instances because licensing. This is in stark contrast to automation based around the command-line.

Anyway, the leveling-up power I’m talking about is switching between navigating your fullscreen virtual desktop workspaces with Ctrl+Alt+Left/Right Arrow to switching between the tabs in a terminal with Alt+[screen index]. Uhhh… this is radical.

What I’m saying is that with your left hand on Ctrl+Alt and your right hand on the Left Arrow or Right Arrow keys you can simply take your finger of Ctrl and then with only one caveat tap a number to pop into your the terminal tab that you want.

As an added bonus this same trick lets you step into the browser tab of your choice as well. Get it? Left/Right through windows, lift your left ring finger with just your left index pointer finger left down on Alt and POINT to the number on the number-row on your keyboard with your other index finger and you pop into exactly the right terminal or browser tab 🤯

The Mechanics of Fluidity: A GNOME Tweak for Uninterrupted Focus

So what’s the caveat? This is a GNOME thing. If you’re on Mac or Windows you’re I’m sure there’s an equivalent but I only bother on my main work machine. On those occasions I’m on Mac or Windows, I just assume I’ll never achieve flow-state for a thousand other little reasons.

GNOME has click to focus turned on by default, compelling you to take your hand away from the keyboard to touch the mouse and break flow-state. Some people will insist they can switch their hands between mouse and keyboard (or trackpad or whatever) and maintain flow-state. Not me and it’s been 30 years and counting (1985-2005). If people really can develop this ability I’m not one of them. So anyway there are different ways to accomplish this but on GNOME the easiest way is to have the gnome-tweak program and then:

1. Open the Tweaks application.
2. Navigate to the Windows section in the left-hand sidebar.
3. Under the “Window Focus” heading, click to change the setting from Click to Focus to Focus on Hover.

You can also accomplish much the same thing without gnome-tweak with just the command-line if you prefer:

gsettings set org.gnome.desktop.wm.preferences focus-mode 'sloppy'

If you ever want to revert to the default click behavior, simply run this command:

gsettings set org.gnome.desktop.wm.preferences focus-mode 'click'

This is a great example of how even in a superior desktop management system like GNOME that make both macOS and Windows look unpolished, there still might default setting or two that are not exactly perfect out of the box for power users leveling up. But with this one tiny tweak you have a keyboard-based way to move fluidly between applications and between tabs within applications without ever taking your hand away from the keyboard or looking down from the screen.

This is particularly important now with my attempt to replace Cursor AI — and VSCode or any of its other forks like Windsurf — with Gemini CLI. Why?

The Human-AI Symbiosis: Prompting from Vim to Gemini CLI

Because as I type into a vim-based journal environment like this and think out my prompts, I highlight them in vim visual-select mode — Shift+v followed by multiple j’s or k’s for highlighting-up or highlighting-down and then y for yank, and then Ctrl+Alt+Left or Right arrow, and then Ctrl+Shift+v for pasting what I just copied (yanked) into the CLI prompt area where it says “Type your message” and then hit Enter.

Get it? This is creating fluid communication with AI by creating a wonderful freeform stream of consciousness for yourself using vim for out-loud thinking just like this, which helps you figure out better and better prompts for AI or could be refined into articles, or could even be published in raw format like this for discovery by people and AIs in the future who could do the refinement. It could also be lifted directly into your git repos in order to preserve the thought process behind projects.

It’s not the code itself that’s so valuable because the code can always be reproduced once you know the thinking and intent behind things. So it’s process like this where the real value resides, messy, rambling and chaotic as it may seem, without it there is no reason. You don’t know the “why”.

And the why that I’m trying to get across here is a mostly unspoken thing known only to few who have clung onto the command-line interface after all these years and under such attack by Steve Jobs and folks thinking ga-ga-GUI interfaces are so clearly superior. But now with automation being so important in this world and the big important coding assistant AIs actually being of this text-based LLM variety that “get” text more than GUI interfaces, and perhaps with some portion of the new generations of coders and programmers occasionally discovering the advantages, the CLI is making a comeback.

Why Now? The Pendulum Swings Back to the Terminal

And I sure as heck won’t be caught having just held my nose and accepted VSCode right as the pendulum is swinging back with tools like Gemini CLI hitting. So what makes Gemini CLI now finally worth taking up and Auto-GPT from back in the day not? I guess it’s the process of gradually being driven off Cursor AI from the cooking the frog price hikes, being increasingly impressed by Gemini 2.5 Pro over the months, Google getting off with only a slap on the wrist even after losing their anti-trust lawsuits, and a culmination of a number of things. If I’m going to rewire my muscle memory habits around a command-line AI coding assistant, it has to be for a preponderance of reasons and I feel it just went over that tipping point.

Oh and I guess now for the final point. The last virtual workspace arrangement I illustrated was:

[(terminal1), (Cursor AI), (), (terminal2), (), (), (terminal3)]

…which is now:

[(terminal1), (Gemini CLI), (), (terminal2), (), (), (terminal3)]

Book Analysis

Here is the analysis and transformation of the provided technical journal entry.

Packaging the Insight: Book-Worthy Titles & SEO-Friendly Filenames

• Title Option 1: Beyond the GUI: Why I Swapped VSCode’s AI for a Command-Line Future
  • Filename: beyond-gui-vscode-ai-command-line-future.md
  • Rationale: This title immediately establishes the core conflict (GUI vs. CLI) and uses strong keywords (VSCode, AI, Command-Line). It appeals to developers contemplating similar shifts and frames the decision as a forward-looking, strategic choice.
• Title Option 2: The Developer’s Manifesto: Flow-State, FOSS, and the Switch to Gemini CLI
  • Filename: developer-blueprint-flow-state-foss-gemini-cli.md
  • Rationale: This option elevates the entry from a simple journal log to a statement of principles. “Manifesto” is a powerful word that attracts readers interested in the philosophy of software development, while “Flow-State” and “FOSS” target specific, knowledgeable audiences.
• Title Option 3: Escaping the Vendor Trap: A Case Study in Migrating from Cursor AI to Gemini CLI
  • Filename: escaping-vendor-trap-cursor-ai-gemini-cli.md
  • Rationale: This title is direct and problem-oriented. It speaks to a common developer pain point (vendor lock-in) and presents the entry as a practical case study, making it highly relevant for those evaluating their own AI toolchain.
• Preferred Option:
  • Title (plain text for YAML): The Developer’s Manifesto: Flow-State, FOSS, and the Switch to Gemini CLI
  • Filename: developer-blueprint-flow-state-foss-gemini-cli.md
  • Rationale: This title best captures the entry’s unique blend of technical action and philosophical reflection. It promises not just a “how-to” but a “why-to,” which is more compelling for a book that aims to offer timeless insights rather than just fleeting technical instructions. It correctly frames the content as a passionate argument, not just a product review.

From Raw Material to Book Chapter: Potential & Polish

• Core Strengths (as Book Material):
  • Authentic Voice: Provides a transparent, “in-the-moment” rationale for a major technical decision, which is far more compelling than a sterile, retrospective tutorial.
  • Philosophical Depth: Connects a practical choice (switching tools) to enduring principles like software freedom (FOSS), workflow efficiency (flow-state), and long-term skill investment (future-proofing).
  • Actionable Ergonomics: Offers specific, practical advice on setting up a highly efficient, keyboard-driven development environment (virtual desktops, GNOME tweaks), complete with commands.
  • Timely Subject Matter: Captures a critical juncture in the evolution of AI development tools, documenting the nascent shift back towards powerful command-line interfaces.
• Leveraging for a Broader Audience (Constructive Polish):
  • Add Visual Aids: Include a simple diagram illustrating the 7-screen virtual desktop layout ([journal] <- -> [apps] <- -> [terminal] <- -> [apps] <- -> [published journal]). This would immediately clarify the author’s mental model.
  • Create a “Key Concepts” Box: Add a sidebar that briefly defines potentially unfamiliar terms for a broader audience, such as Agentic Framework, FOSS (Free and Open Source Software), and Vendor Lock-In.
  • Expand on the “Why”: Elaborate on why the quality difference between a single large prompt and multiple file attachments is so noticeable in LLMs. This could touch on context cohesion and the model’s attention mechanisms, adding valuable technical depth.

The AI’s Take: Editorial Insights & Transformative Potential

This entry is an outstanding candidate for a case study within a chapter on “Developer Ergonomics in the AI Era” or “The Philosophy of Tooling.” Its power lies in its raw authenticity. The stream-of-consciousness style, rather than being a weakness, is its greatest strength. It provides a “behind the curtain” view of how an experienced developer thinks, weighing principles, past experiences, and future trends to make a critical workflow decision. This is a narrative that can’t be found in official documentation or polished tutorials.

The unique value here is the seamless integration of high-level philosophy with low-level, practical implementation. The author doesn’t just argue for the superiority of the command line; they show you exactly how they’ve bent their operating system (GNOME) to their will to achieve a state of pure, keyboard-driven flow. This connection between abstract principle (avoiding “Steve Jobs mode”) and concrete action (gsettings set org.gnome.desktop.wm.preferences focus-mode 'sloppy') is what makes the narrative so compelling. When curated for a book, this entry would serve as a powerful, personal testament to the idea that the tools we choose—and how we master them—profoundly shape the quality of our work and thought.

Prompting the Next Stage: Ideas for Further AI Refinement

1. Task Suggestion 1: Distill the core principles into a shareable summary.
   • Potential Prompt Snippet for Next AI: “Based on the provided journal entry, draft a ‘Key Takeaways’ box for a book chapter titled ‘The Power User’s Philosophy.’ Extract the 3-4 core arguments the author makes regarding tool selection, workflow design, and the advantages of the command-line interface.”
2. Task Suggestion 2: Generate explanatory analogies for complex concepts.
   • Potential Prompt Snippet for Next AI: “From the text, identify the author’s distinction between ‘flow-state’ and ‘Steve Jobs-mode’ (hunt-and-peck GUI interaction). Generate two distinct analogies a novice developer could understand to explain the value of uninterrupted, keyboard-driven workflow.”