I’m an experimentalist by nature. I’m the guy who downloads the new thing the day it drops, reads every release post, and has opinions about tools most people haven’t heard of yet. But after working professionally for sometime now, I’ve landed on a concept I keep coming back to: push comes to shove tools.
These are the tools you’ve invested so much time into that they’ve become extensions of how you think. You’ve honed your skill in them, and you’ve honed the tools themselves—tweaked configs, built workflows, internalized shortcuts. And here’s the thing people don’t like admitting: a honed tool outperforms a “better” tool you barely know. A Neovim user will never be as fast in VS Code, and a VS Code user will never be as fast in Neovim. That’s just the reality.
Now, I don’t want to fall into the trap of only using what’s comfortable. If I’d dismissed LLMs when they first showed up, I’d be behind right now—and that’s not a good place to be in 2026. But even LLMs prove the point. It took us years to figure out how to use them well. In 2023, we were treating them like glorified Stack Overflow—asking questions and hoping the hallucinated answers were close enough. Now we’re architects. We drive the model; we don’t just query it. And the people who thrived? The ones who always cared more about solving the problem than writing the code.
So gather your push comes to shove tools. Because when you’re debugging something at 2 AM, you’re not reaching for the shiny new thing you installed yesterday. You’re reaching for what you know.
That said, there is a path to adopting new tools: pick one up, use it relentlessly on personal projects, get as good with it as you are with your current stack, and then phase the old one out. That’s the only honest way to do it.
_Written by transcribing, paraphrased in my style of writing by an LLM_