I generated 847 lines of production code in 12 minutes.
Not pseudocode. Not a prototype. Real, working Python with tests, error handling, API integration, and it works well. I described what I wanted to an AI agent, went to grab coffee, came back, and it was done.
It felt incredible. Like unlocking god mode. Why would I ever go back to writing code line by line?
The Promise & The Reality
This is the promise of AI-centric development tools like Zencoder, vibe-kanban, and even parts of Cursor. Steve Yegge calls it “vibe coding”: stop micromanaging, trust the AI, let it scaffold entire features while you focus on the big picture. And when you see it work, it’s intoxicating.
But here’s what happened next.
I had to review those 847 lines. Every function. Every edge case. Every assumption the AI made about my requirements. Did it handle validation correctly? Is this maintainable? Did it miss something subtle about the business logic?
The review took longer than writing it would have.
And I still wasn’t confident. So I asked a different AI to review the first AI’s code. It found some issues. I fixed them. But now I’m reviewing AI-generated fixes to AI-generated code, and I’m three layers deep in a review process that feels more like managing a team of junior developers than writing software.
Then comes the PR. Do I ask my teammates to review 847 lines of AI code? They’ll either spend hours on it (and resent me) or run it through AI themselves (and we’re all just trusting machines at that point).
The Identity Question
So I have to ask: what does this make us as developers?
If AI writes the code and AI reviews the code, and we’re just approving diffs we don’t fully understand… are we developers anymore? Or are we product managers for code we didn’t write?
Maybe that’s fine. Maybe AI is good enough now that we should embrace it.
But I don’t think it is. Not yet. I find issues constantly: bugs the AI missed, patterns it didn’t understand, edge cases it overlooked. And the “big bang” feature implementations don’t feel right to me. I still value ensuring the AI is building the right thing according to my understanding of the problem. And the only way to do that is to review in detail, stay close to the code, and actually understand what’s being built.
My Journey Through the Landscape
I’ve been a Vim user for years. Not the “I use Vim btw” meme kind. The “my fingers know hjkl better than WASD” kind. The muscle memory runs deep. So when AI coding assistants exploded onto the scene, I had a choice: migrate to VS Code like everyone else, or figure out how to make AI work in my world.
Let’s be clear: I didn’t stick with Vim out of stubbornness. I explored the alternatives. I keep exploring them.
Cursor: Too Distant
I’ve tried Cursor. It’s impressive: genuinely AI-first, with inline suggestions and chat that feels magical. But here’s the problem: it makes you too distant from the code. You’re directing an AI that’s directing the editor. There’s a layer of abstraction I don’t trust yet. I want my hands closer to the metal.
Zed: Doesn’t Fit My Workflow
I tried Zed. Better balance. It’s code-centric with AI tools bolted on the side: you choose when to invoke them. I liked that. But Zed expects you to work on one project at a time. That breaks my workflow immediately. I live in tmux with 3-4 projects open, constantly switching contexts, piping output from one terminal to another. Zed doesn’t fit that reality.
Zencoder & vibe-kanban: Even More Distant
Then I went to the other extreme: full AI-centric tools like vibe-kanban and Zencoder. I was motivated to try this route after reading Steve Yegge’s writings on vibe coding. The idea is compelling: stop micromanaging the AI, trust the vibes, let it scaffold entire features while you focus on the big picture. So I gave it an honest shot.
These tools are wild. You describe what you want, and they scaffold entire features, write tests, integrate APIs. It feels like having a senior dev in a box. Zencoder especially caught my attention. You feel powerful. You ship fast.
But here’s the catch: you’re absurdly distant from the code.
AI writes it. AI organizes it. You review diffs like a manager reviewing PRs. And I don’t trust AI that much yet. Every line it writes, I have to re-review. Does it meet standards? Is it maintainable? Did it miss an edge case? The review overhead is real.
What I realized: I still need to review code in detail and ensure features are going in the right direction. The “trust the vibes” approach sounds liberating, but in practice, I’m doing more cognitive work reviewing after the fact than I would have supervising during development.
The Solution: Bite-Sized Pair Programming
So I found a middle ground: bite-sized pair programming with AI. The AI does most of the coding. I supervise and keep it on track. I course-correct in real time instead of reviewing a massive diff later. And the best way I’ve found to do that is still Neovim + tmux: AI in one pane, code in another, constant back-and-forth.
I don’t write code the same way I used to. I used to open a file, think through the problem, and type. Now? I spin up a worktree, open an AI in a terminal pane, and direct the solution instead of typing it character by character. But I stay close. I supervise. I course-correct in real time.
The AI does the heavy lifting. I do the thinking. It’s not full vibe coding. It’s not solo coding either. It’s collaborative, with me staying close enough to catch problems early. The tools are different. The medium is the same: the terminal.
AI in the Terminal: Multiple Tools, One Workflow
The real shift wasn’t about finding one perfect plugin. It was about building a workflow that lets me use whatever AI tool fits the task without leaving the terminal.
For a while, I experimented with different approaches: Claude Code in a split buffer, Codex in a tmux pane, jumping between terminal windows to manage different tools manually. I wasn’t married to any particular setup.
More recently, I’ve found somewhat of a sweet spot: I use sidekick.nvim as my interface layer. It gives me the flexibility to switch between different AI agents when I want to. But in practice? I mostly default to Claude Code. Its rules and configuration are pretty robust right now, plus my company pays for it, so why not use it?
That’s the real advantage of the terminal workflow: the flexibility is there when you need it. Want to test a new model? Swap it in. Want a second opinion on code? Switch agents mid-task. But you’re not forced to constantly context-switch. You can settle into what works and only switch when it makes sense.
And here’s a workflow trick I’ve been using: implement a feature with one AI tool, then review or test it with a different one. You get a less biased second opinion. If Model A wrote the code and Model B flags the same issues you’re concerned about, you know it’s real. If Model B says “looks good,” you have more confidence. It’s like pair programming, but the second programmer is a completely different intelligence.
The “best” AI model changes constantly. Claude Code dominates today, but that changes by the hour. Being locked into one tool means you’re always playing catch-up. In the terminal, switching is trivial.
Why the Terminal Wins
Neovim scored 83% in StackOverflow’s 2024 Developer Survey as the most admired IDE, even though VS Code is the most used at 59%. That gap tells you something. People who use Vim don’t just tolerate it. They love it. And it’s not Stockholm syndrome.
Here’s what keeps me here.
Hands on the Keyboard
When my hands never leave the keyboard, I stay in flow. Every time I reach for the mouse, there’s a micro-decision: where’s the cursor? What am I clicking? Did I miss? Those interruptions compound. Not just in seconds, but in mental overhead.
Want to find a file? <leader>sf brings up Telescope. Search across everything? <leader>sg for live grep. Navigate between Vim splits, tmux panes, or even tmux windows? Ctrl+h/j/k/l handles it all seamlessly. Start a new task with a worktree and AI ready? <leader>at. Toggle a floating terminal? <leader>;.
No mouse. No sidebars. No menu hunting. Just muscle memory.
The AI tools I use (Claude Code, Codex, OpenCode) fit into this. I don’t context-switch to a browser or separate app. I invoke them in a split pane with a keybind. Everything stays in one place.
Speed isn’t about typing fast. It’s about never stopping.
The Terminal is a Toolkit
The terminal isn’t one tool. It’s composable. Want to process JSON from an API? Pipe it to jq. Transform file paths? sed or awk. Run a command on 50 files? find | xargs. Monitor logs while coding? tmux split with tail -f.
When you add AI to this composability, things get wild.
I can prompt Claude Code in one pane, watch it write code in another, pipe the output through a test runner, grep the results, and feed errors back into the AI. All without leaving the terminal. All scriptable. All reproducible.
Cursor can’t do that. You can’t pipe Cursor’s output through grep. You can’t script it to run in a loop. It’s a black box. The terminal is Lego blocks, and AI is just another piece.
Performance You Actually Feel
VS Code and Cursor are Electron apps. They’re running a full Chromium browser under the hood. Neovim is written in C. It opens instantly, uses around 50MB of RAM, and never lags.
When I spin up 10 tmux tabs with Neovim and AI tools, my system barely blinks. Try opening 10 VS Code windows and listen to your fan scream.
I juggle 5 to 10 worktrees at any given time. Each one is a separate environment. If each took 500MB of RAM and 3 seconds to load, my workflow would fall apart. Neovim and tmux? Instant, lightweight, snappy.
My Setup is Code
My entire development environment is 600 lines of dotfiles in a git repo. New machine? Clone it, run a script, and I’m back up in two minutes. Same keybinds, same plugins, same aliases, same AI integrations.
GUI tools let you sync settings, but you’re at the mercy of their config systems. With terminal tools, the setup is code. You can version it, diff it, review it, share it. I can recreate my entire workflow on a fresh VM faster than VS Code can install.
These Tools Have Staying Power
Vim came out in 1991. Neovim in 2014. tmux in 2007. They’ve outlived programming languages, frameworks, companies. They’ll outlive Cursor. They’ll outlive Zed. They might outlive JavaScript.
The muscle memory I’m building, the keybinds, the workflow patterns: they’ll be relevant in 10 years. Will Cursor? Maybe. Probably not. Learning Vim is an investment that compounds. GUI tools are a bet on a company staying solvent.
The Control Gradient
Here’s how I think about the spectrum:
Full Control (Traditional Vim)
You write every character. You think through every problem. Slow, but you know exactly what’s happening.
AI-Assisted (My Current Setup)
You direct the solution. AI accelerates execution. You stay close to the code. You review as it’s built, not after. You can do manual trivial actions where pertinent instead of asking everything to the agent.
AI-First (Cursor, Zed)
AI suggests, you accept/reject. Fast, but you’re reacting more than creating.
AI-Centric (Zencoder, vibe-kanban)
AI builds, you review diffs. Fastest, but you’re a product manager for code you didn’t write.
Right now, AI-assisted is the sweet spot. I get speed without losing control. I stay in my flow. I trust the output because I was there while it was written.
But I’ll be honest: this might not last.
AI is getting scary good at both writing and reviewing code. It’s catching bugs I miss. It’s flagging patterns I overlook. If AI review becomes as reliable as human review, the argument for staying hands-on gets weaker.
We might be transitioning to AI-centric whether we like it or not. The question is: how long do I have before “staying close to the code” becomes nostalgia instead of pragmatism?
For now, I’m staying in the terminal. But I’m watching.
The Honest Uncertainty
This workflow makes me feel in control. I know where my code is, how it got there, and what’s happening at every step. I’m not watching an AI build something in the background and hoping it got it right. I’m directing it, reviewing as it goes, staying close to the work.
That control matters. For now.
But I’d be lying if I said I’m confident this is the future. AI is getting better at an absurd pace. It’s already catching bugs I miss. It’s writing code that would take me hours in minutes. It’s reviewing my work and finding patterns I overlooked.
At some point, the argument for staying hands-on stops being pragmatic and starts being nostalgic. Maybe we’re already there and I just don’t want to admit it.
I keep testing the AI-first tools. Zencoder, vibe-kanban, Cursor. Not because I think they’re worse, but because I want to know when the terminal workflow stops being the smart choice and starts being stubbornness.
Maybe that happens next week. Maybe it already happened and I’m just slow to see it. AI-centric development might not be a distant future. It might be now, and I’m still clinging to a workflow that makes me comfortable.
For today, I’m staying in the terminal. It’s faster for me. It fits how I think. It keeps me close to the code in a way that feels right.
But tomorrow? Who knows.
The terminal-centric workflow wins for me right now. But I’m watching the gap close. And when it does, I’ll probably switch. Not because I want to, but because it’ll be the obvious move.
Until then, I’ll keep hitting <leader>at and letting the AI do the heavy lifting while I stay at the wheel.
