I was thinking about the acquisition of Bun by Anthropic and wondering what it really signals. On the surface, it’s an intriguing investment of an AI company in a faster JavaScript runtime. But what it really is, is a big bet on a specific future: one where Claude Code and similar terminal/text-based interfaces become the primary interface for coding, overtaking the GUI-based IDEs of today. It's Anthropic’s “Visual Studio Code" moment.
In a way, it’s not surprising. Many of the "hardcore" programmers of the world are either on Vim or Emacs, or were until very recently. Even if they use GUIs, their workflows are usually highly optimized with macros and keyboard shortcuts. I’ve personally worked with one such engineer years ago. He was so fast and comfortable with Vim that he’d be done with simple changes and be in and out of the file before I blinked.
It reminded me of Tally, India's largest accounting software and my first employer out of college. Tally was famous for its keyboard-based navigation. It supported a GUI, of course, but the interface was boxy, with complex forms and tabular layouts, and utilitarian. The magic was in the navigation: jumping from one box to another in a specific, almost unconscious way.
Filling a complex accounting form or adding tabular data could be accomplished at thought-speed. There was no typing, moving the mouse to a different place to point the cursor, and then typing again. You started at the beginning of the page and went either right or left, top or bottom, one character, one word, or one box/HTML element at a time. The “Tab” key was prominent, informing the user about where they were and where the next tab would take them. With enough muscle memory, a user could complete a complex invoice with their eyes closed(it’s not an exaggeration). That’s something you can simply never do with a mouse.
With AI-assisted coding, we’re seeing a return to this text-first reality. Even in modern GUI IDEs like Cursor, the workflow is largely keyboard-centric. You’re either typing prompts, choosing to “Accept” or “Ignore” changes, or typing “Tab, Tab, Tab.” You might use a mouse to go from the chat window to the editor, to the navigation bar, but the real action happens on the keyboard. Imagine if you could go from the chat window to the editor with one keypress, or from the editor to the navigation bar in two.
These are my merely observations and thoughts, so I was curious to know what Science has to say about all of this. Why does a keyboard-based layout feel not just faster, but easier on the brain? From doing a little bit of research, it turns out there are really interesting topics to be learned here that back up common, real-world observations.
Fitts’s Law, proposed in 1954, is a predictive model of human movement used in Human-Computer Interaction(HCI)(Source). It states that the time to move to a target is a trade-off between distance (how far you have to move) and size (how big the target is). Here’s the formula for reference, but we’ll soon walk through some examples to understand it better:
ID (Index of Difficulty) = log2(2D/W)Where D is the distance to the target, and W is the width of the target. Simply put, the farther the target, or the smaller the target, the more difficult a task is, i.e. the slower it is.
Let’s dig into this from a completely different, yet an everyday and relatable setting: driving a car. The brake pedal is designed to be significantly wider than the accelerator. The goal is to try and get you to brake more easily than accelerate, especially in high-stress situations or emergencies. The underlying assumption is that braking is a safer choice in a majority of cases than accelerating.
From a Fitts’s Law perspective, in an emergency, you need to hit the brakes immediately. Since the brake is significantly wider than the accelerator, W is larger. By increasing W, car designers lower the Index of Difficulty. This matters because, in a panic situation, your motor control degrades (i.e., your aim gets worse). A wider target compensates for the lack of precision, ensuring you can hit the brakes without looking.
Now, let’s consider two examples that are closer to what this article is about – digital devices and interfaces.
The "Infinite Width" Hack: This is a great counter-intuitive example attributed to Bruce Tognazzini at Apple. Imagine you want to click the “Start” button in Windows or the “Apple Menu” on a Mac in the corner of the screen. The Distance (D) is often far because you’re likely doing something near the center of the screen, and technically, the icon is small, meaning W is small. Per Fitts’s Law, the Index of Difficulty should be huge!
But, and here’s the counter-intuitive part, because your mouse cursor stops when it hits the edge of the screen, you cannot “overshoot” the corner. The edges of your screen essentially act as a safety net, making it harder for you to miss the target. You can essentially drag your mouse blindly to the top-left or bottom-left to get where you want to go. This makes the “effective width” of the screen corner Infinity! As W approaches infinity, the Index of Difficulty drops to near zero. This is why corners are the fastest places to click on a screen, second only to where your cursor already is.
One last example to internalize the point: The Right-Click. Say you want to copy text. You’ve highlighted the words you want to copy. You can move your mouse to the “Edit” menu at the top of the application, or you can right-click. When you right-click, the menu appears exactly where your cursor already is, making the distance (D) effectively zero. This is the mouse equivalent of a keyboard shortcut—bringing the interface to the user, rather than forcing the user to go to the interface.
Going back to the keyboard vs. the mouse observations: when you use a mouse, you’re constantly fighting Fitts’s Law. You are managing D (moving the mouse across the screen) and W (aiming for small targets). When you use a keyboard command (like Ctrl+C or Cmd+Shift+P), D is constant and low since your fingers are resting on the keys, and W is irrelevant since you don’t need to aim at the keys. Your muscle memory (the memory of the keyboard layout that your fingers retain) knows exactly where they are.
But Fitts's Law only explains part of the speed advantage. There’s another reason.. or a class of reasons, that stem from something called Modal Homogeneity, for why keyboard-only iterfaces feel faster.
This describes a state where the user does not have to shift their physical or cognitive “mode” to complete a task. There are a few different explanations for why operating in one mode is computationally faster for the brain than switching.
The “Homing” Time: In the 1980s, researchers at Xerox PARC found(as part of the GOMS model they developed) that the act of switching devices has a specific time penalty called Homing (H). Homing Cost is the time it takes for your hand to leave the keyboard, travel to the mouse, and settle into position. Research consistently shows this takes ~0.4s per switch. If you’re coding (keyboard) and need to click a file tab (mouse) and then go back to coding (keyboard), you pay the “homing cost” penalty twice: 0.4s to the mouse + 0.4s to the keyboard = 0.8s lost in travel. In a typical coding session, you might lose minutes of time every hour just moving your hands between the two devices!
Open-Loop vs. Closed-Loop Systems: These are terms used in engineering and neuroscience that come down to one key difference: Feedback. Open-loop systems are like the “fire-and-forget” model. They execute a command without checking or waiting to see if it worked. This model assumes the environment is predictable and the command is perfect. The sequence of steps is this: Input → Processing → Action.
In the context of the brain, this is extremely fast because it does not have to wait for feedback from your sensory inputs to return. For example, expert typists don’t have to look at the keyboard to lock in the key they want to type. They do it through muscle memory and move on immediately after pressing that key. The brain has moved on to the next key the instant the previous key is typed. It’s optimistic in nature. That is, your default assumption is that you’ve pressed the right key. You go back to course-correct only if you realize that you typed it wrong by looking at the screen. The difference is that you don’t wait for feedback. You only go back if and when you see you did something wrong.
A closed-loop system is constantly comparing what is happening to what is supposed to happen and making adjustments in real-time. The sequence of steps becomes more elaborate: Input → Processing → Action → Feedback → Processing → Corrective Action. The system is limited by the speed of the feedback loop. For example, when you’re using a mouse, since it’s purpose-built to help you navigate a “graphical” user interface, you are required to wait for the visual sensors to send feedback about where you are, and you constantly take corrective actions to get to where you want to be. Of course, all of this happens unconsciously, but it still takes significant brain cycles of processing and time.
Expert coders or typists are so fast because they have successfully moved complex tasks from the closed-loop bucket to the open-loop bucket. Learning a skill, any skill, is essentially the process of converting a closed-loop activity (where you have to constantly assess if you’re on point) into an open-loop activity (where you “think” and it happens).
I remember the first time I went skiing with a friend who was good at it. On a slope where I was repeatedly falling, he was trying to teach me how to take smooth turns. It’s funny, the advice he gave me. He said, “You need to lock your eyes on where you want to go, and you’ll automatically go there. It just happens.” That, for a first-time skier like me, turned out to be terrible advice. Now I understand that, for him, skiing had become an open-loop system.
Cognitive Load of Switching from Symbolic to Spatial Modes: Finally, what makes switching from keyboard to mouse and back harder, is that keyboard mode engages the symbolic and linguistic centers of the brain. Mouse mode engages the visual and spatial centers. You stop looking at the code and start looking for shapes, colors and positions on the screen. When you switch from one to the other, your brain has to “context switch” and reorient from “thinking about words” to “thinking about pictures,” which makes it harder to achieve Flow.
GUIs were invented to make digital devices less technical and more accessible to the population. They were invented to help beginners discover what was possible. But not only do developers represent a specialized segment of the population that are savvier than the average user in navigating digital interfaces, AI-assisted coding removes the need for discovery. If AI is not only coding but also using tools to make things happen on your computer(through tool use), you just have to describe the goal and rely on it to execute it perfectly. In other words, you inherently transition the act of coding from a closed-loop to an open-loop system!
The future of coding seems to be to remove the friction introduced by graphical user interfaces so we can build software at the speed of thought.