After a decade living in VScode, LLMs have brought me back to my first love: Vim. Most of this is nostalgia, but there is a real reason the terminal suddenly makes sense again.
The glory days
In July 2011 I destroyed my Windows partition by installing Ubuntu 11.04 from a CD I received in Linux Format. This allowed(forced) me to explore Linux, and discover that computers weren’t black boxes that magically rendered Runescape. They were highly logical systems that tickled my brain in just the right way. I vividly remember falling far into the enchantment of servers, software and networking.
As a newly minted terminal enthusiast it did not take long for me to discover the Vim vs Emacs holy war. While I was both young and dumb I did realise that what I wanted was a text editor and not an OS, so I correctly chose Vim. It allowed me to navigate code quickly and configuring it with syntax highlighting, basic debugging, and git was fairly straightforward. For me at the time it was perfect, it was efficient at what it does; editing, reviewing and comparing code. It didn’t get in the way but it also did not do all that much to help me.
Once my projects grew a bit in size and complexity the benefits of proper IDEs like PyCharm or Code::Blocks were hard to disregard. I still strongly preferred staying in the terminal with tmux and Vim so my vimrc became ever increasing in size to try to achieve the same. At a certain point it started becoming quite cumbersome to keep up with, and when VScode rolled around with its extension ecosystem I capitulated for most tasks.
Back to the future
Like everyone else and their dog I have been adopting LLM assisted coding practices and experimented with tooling. I have tested: Cursor, Windsurf, Google Antigravity, VScode + CLI agent extensions. None of these have really solved for what I want them to. My experience with all of these is that they are very much “batteries included” and mostly lend themselves to “Vibe” heavy workflows. I don’t want LLMs to develop with me, I want to develop with LLMs.
What I have found to work best is to mimic the workflow I have when working with junior engineers. When I give them a task I offer some general guidance concerning scope and approach, and I assume that they will get it 70% right. Once they return with a piece of work, whether that be a configured network or a piece of code, they present their work and I review it. At that point I will either give them feedback for them to improve it, or I will finish it myself with them observing if necessary. This works really well both for the junior engineer and myself. They get guidance and experience, and I get a result that is of quality.
Glorified autocorrect writes syntactic code but lacks most of the intelligence & capabilities of a junior engineer. Working this way however does give me a good way to ensure I get output that is of a quality I deem acceptable. I send it off solving some issue in the same kind of manner, and I instruct it to present its work in a format that makes output tokens easier to consume for my feeble human brain. The best way I have found to do this is by having it work in a separate worktree and generate a single HTML or md file that documents the work. This gives me a quick way to understand and give feedback. Once it looks approximately right I hack at it until it is just right.
Some models seem to be more prone to being maximalist than others, presumably a result of optimising for “agentic” work.
Claude for example tends to want to run away with whatever task I give it unless I am very deliberate about limiting scope.
By playing a bit with the harness and AGENTS.md I am mostly able to make the models behave.
I have had most success with the Pi coding agent.
Like Vim, it does what it does really well, but not much else out of the box.
The system prompt is only 1100 tokens by default. For comparison, Claude Code ships with a whopping 14,500 token system prompt.
Less baked in behavior means less for me to fight against when I want it to work my way.
The beautiful thing about this is that for many tasks my job mainly becomes to review, approve and refine code and config. For most other tasks I am able to write the complex or important parts myself, and have the LLM assist in smoothing out rough edges. Most of the syntactic gymnastics I once leaned on an IDE for is easily handled by the LLM, and a language server gives me everything I need to effectively do the rest. Vim is unironically the single best tool for the job.
Configuring Vim, tmux, Pi etc. is also a breeze with LLMs. The nightmarish vimrc maintenance is a thing of the past, and VScode package management and ease of config is no longer the boon it used to be. Given this new reality I have deliberately left this post void of any configs or snippets. I highly suggest working out your own AGENTS.md, init.vim/vimrc that suits your work & workflow.
See Also
- Moving to Forgejo on Hetzner
- Gleaning DNS resolver behavior
- Tuning Vibe CLI for Network Engineering
- Building your own Containerlab node kinds
- Containerlab Cisco images simplified
Got feedback or a question?
Feel free to contact me at hello@torbjorn.dev