In general I hold the view that the terminal is usually the fastest, most efficient, and least stressful way to perform most tasks.

Even pre-LLM era I tried to move as much of my workflow to the terminal as possible, but now both the desire and ability to do that have increased even more. Primarily for two reasons:

  1. In the LLM era the volume of work and task management has dramatically increased, and so more efficient workflows have become even more relevant

  2. LLMs are great at dealing with local environment configuration and generating small tools, so our ability to customise our own workflows has become easy and cheap. Especially if your coding environment is terminal-based, which is highly configurable and extensible by nature.

I’ve loved coding in the terminal for a long time now, but there was always still a price you needed to pay in blood for it. Things didn’t “just work”, configuration could be a massive pain, and if you wanted to try updating those fifteen 3rd party neovim plugins your workflow depends on… well you might need to be willing to sacrifice the next 3 days of work to get everything working again.

But that’s all gone now. Getting everything you want configured and set up in the terminal for tmux, neovim, or whatever else really is as easy as just telling the LLM to go do it.

And so is modifying your workflow. Now rather than imagining some workflow improvement you want and either having to:

  1. Find an existing plugin that does what you want, or

  2. Spend the time building and maintaining the plugin yourself

An LLM can make it happen almost instantly. And the LLM approach is better in multiple important ways.

Obviously building it yourself takes time, and the knowledge to be able to do it, and so a lot of the time it’s hard to justify the effort especially if it’s a minor workflow improvement. Or maybe you just don’t have the desire to be building custom plugins at all.

But finding and using existing solutions, even good ones, has its downsides. A perfect example of this is why, for the PR workflow I am going to use as an example, I didn’t just use some existing 3rd party plugin like Octo.nvim which, on the surface, appears to be an obviously better and more complete solution to the problem I’m solving.

The main problems with 3rd party solutions to your problems are:

  1. Dependencies come at a cost. Specifically, we become dependent on them. We are dependent on them continuing to work in the way we want and to be maintained… and not be exploited in some way. Especially in the LLM age I think security is of even more concern, as there are many more tools being created and published much more quickly without the care and attention they perhaps once had (and even then security vulnerabilities were a frequent problem)

  2. Third party solutions need to be everything to everyone and tend towards bloat over time, as they need to not only cater to the workflow of the creator of the tool, but the workflows of everyone using the tool. A plugin that allows you to interface with GitHub features probably needs to support just about every GitHub feature, even if they are of no relevance to you.

  3. Partly because of point two, these tools have their own learning curves. Jargon to learn, keyboard shortcuts to learn, idioms and syntax, and so it becomes a time investment in having to learn how to use the tool itself before you can incorporate it into your workflow.

Let me give you the concrete example now. Since I’ve been using LLMs more and reviewing work by LLMs, the amount of time I’ve spent dealing with PRs on GitHub has increased dramatically.

As I mentioned, I like as much of my workflow to be in the terminal as possible. Everything is right there at my fingertips and I can quickly navigate around and do everything I need on the keyboard without ever having to reach for the mouse.

I know it sounds dramatic, but I think reaching for the mouse is a bigger deal than it might seem. It’s a more awkward and less precise input device, and at least for me it’s often the moment where I feel like I’m losing that flow state.

So, I use the mouse as little as possible. But PRs and GitHub were a bit of an exception to this. Especially for reviewing PRs, I would use GitHub’s interface for viewing changes across files.

And this was starting to annoy me, as I was constantly going into point and click with the mouse mode. I wanted to move this process to be directly in the terminal instead, where I could rely on just the keyboard. Specifically, the key feature I felt like I was missing in the terminal was the ability to easily compare changes across files in a PR, specifically in a way that looked nice and was readable.

So, I did what I’ve always been doing lately, I tell the LLM I want to be able to do X, Y, and Z and it goes and builds that into my workflow for me.

Now I have a little popup window I can launch in tmux that allows me to do all of the GitHub related tasks I do most commonly in my workflow (check out the video associated with this article if you want to see it in action).

I can easily see any PRs that are currently open on the project, I can take a look at them at a basic level, or I can automatically check the PR out into its own tmux session and worktree where I can review it in more depth.

I then have multiple ways to review changes across files in the PR, including in this side-by-side pane view that provides a similar experience to the GitHub GUI. I can also quickly browse through changes in files by using a quickfix list, and it is also easy to make modifications to the PR as I’m reviewing it.

Now I can do most of the things I need to do without going to GitHub in the browser at all with this simple tool the LLM created for me… but then why not just use Octo.nvim which is a pre-existing plugin that does all of this and more for neovim?

And the answer is… for the reasons I mentioned before. Using third party tools comes with its own costs: they are a dependency, they are often more bloated than what you actually need, they have their own learning curve. In this case, Octo would probably be a pretty safe bet for me to depend on, so for me the biggest downsides would be that it does all of the GitHub things when really I only need like 6 of the GitHub things, and because it is this big and complex tool it comes with its own learning curve and way of doing things that might not align with specifically what I want.

With my own simple custom tool I can focus on just the small set of specific things I want, and I can set them up to work in the exact way I want them to work, and there is no learning curve.

So, if we are able to create our own local tooling at a cost of almost nothing and a time investment of minutes, the downsides of relying on 3rd party tools becomes much greater by comparison, and at least in this setting of personal workflow tools I think it makes the most sense to make your default stance creating your own tools.

This is not always the case of course. For example, I’m not running my own custom built version of neovim itself: that’s a dependency that obviously makes sense to have. If I need syntax highlighting for some coding language it doesn’t make sense for me to have an LLM generate a treesitter grammar, when there are already plugins out there that do the job well.

My stance isn’t never use plugins or third party tools, it’s to prefer local tooling over third party solutions unless there is a strong benefit to adding the dependency.

You can use the handoff document I’ve shared below to implement a version of the GitHub tool I created on your own machine. What I have done will translate most naturally to a tmux and terminal-based environment, but you can also work with your coding agent to adapt this to other environments and setups too.