Trending Terminal & Shell

I used to ship whatever I built first. The vibe coded version would go straight to production, and then I'd spend weeks untangling it because the code was optimized for speed, not clarity. Claude and I would just keep patching things, and eventually I couldn't even remember why certain decisions got made. Then I started treating prototypes like actual disposable prototypes instead of secret first drafts. I build the thing fast with Claude, get it working, understand what I actually need, then I start completely over with a real spec. The second version gets written deliberately with the person who'll maintain it in mind. It's weird but it works. When I start the rewrite I always run `vercel env pull` first to make sure I have the actual production config, then I'm building from a fresh Next.js template and a spec that's just a few sentences about what this needs to do and why. The prototype taught me what the thing should be, and now the real code gets to be what it should look like. The caveat is that this only works if the prototype is actually fast to build. If it takes you two weeks to prototype something, rewriting it from scratch is going to feel ridiculous. This technique is for the stuff where you can throw together a real working version in a day or two, learn what you need to learn, and then do it right. 

Keeping shell, editor and tool configuration in a version-controlled repository, so a new machine is one clone away from feeling like the old one.

Before I started doing this, I'd either have a pile of detached sessions scattered across my machine with no memory of what was running in each one, or I'd try to cram multiple projects into a single session and lose track of which window belonged to where. Terminal scrollback would evaporate whenever my laptop slept, and context switching meant either killing running processes or leaving them orphaned and resource-hungry in the background. What changed is that I now create each project's session with a predictable structure. Editor window, server window, tests window. Always in that order. When I come back to a project after days away, I run `tmux attach-session -t projectname` and everything is exactly where I left it. The scrollback persists because the processes aren't dying. I can actually see what broke three hours ago because I still have the terminal history. The concrete implementation is a small shell function that creates a session with `tmux new-session -d -s $projectname -x 120 -y 40`, then splits windows with `tmux new-window -t $projectname` and names them with `tmux rename-window -t $projectname:0 editor`. Zsh and Neovim run in window zero, the dev server or build process lives in window one, and automated tests run in window two. One keybinding to cycle between them. The honest limitation is that this breaks down if a project genuinely needs more than three persistent processes, or if you're debugging something that requires seeing multiple logs simultaneously. For those cases I sometimes add a fourth window, but I've found that creeping complexity usually means I should split the workflow differently. It works best when your development process is actually that simple.