In the software industry, we’ve always had debates about tools. In my early years, it was Visual Basic vs. FoxPro vs. Delphi. Then, it was the endless cycle of JavaScript libraries and frameworks: Angular, React, Vue, Svelte, and so on (not to mention AngularJS, Ember, Knockout before that). A new library or framework is popping up all the time. It became a running joke: you kick a tree, half a dozen JavaScript frameworks fall out. At least those frameworks were free.
Today, the same energy has shifted to AI-assisted development tools. GitHub Copilot, Cursor, Windsurf, Claude Code; the list grows fast every week. Some focus on vibe coding, others lean into specification-driven development, which echoes practices we’ve been following for decades (BDD and specification by example, anyone?). The practices aren’t new. What’s new is the tools that wrap around them.
Recently, I saw a LinkedIn post claiming that Claude Code is “10x better” than Cursor. The author listed five tips, including practices like:
- Start with a project goals file (CLAUDE.MD).
- Ask the tool to explore before coding.
- Use
/clearto reduce hallucinations. - Automate repetitive tasks with custom commands.
- Paste screenshots for richer context.
The tips are solid. The issue is the framing. 10x better at what? For whom? Faster? More accurate? More aligned with a specific workflow? The post didn’t clarify.
The truth is, all of those “Claude features” were things I’d already been doing with Cursor, long before they became formal features. And Cursor, for example, already auto-summarizes chats when context fills up, eliminating the need for a manual /clear command. So is one really “10x better,” or does it simply fit that person’s way of working better?
This is why I keep coming back to practices over tools. Tools are just hammers. What matters is how you swing them. No. It’s what you use them for. And why.
For example:
- I follow BDD almost all the time, because it forces me to think in terms of human behavior and value.
- I follow TDD often, but not always. I have a practice of asking whether TDD makes sense for the problem at hand.
- I’ve carried practices like pair programming across languages, frameworks, and now, AI tools. Pairing with a human or an AI both require skill. Are you truly pairing (collaborating, questioning, and learning together) or just dictating instructions?
Practices endure. Tools change. My BDD and TDD habits have followed me across .NET, JavaScript, Ruby, testing frameworks, and now into AI-assisted environments. The practices make me effective. The tools enable them.
So when someone claims a tool is “10x better,” I always want to ask: Better for what? Better for who? Compared to what? Without data or context, it’s just a perception. And perception without context often leads us astray.
The real takeaway: focus less on the hype of tools and more on the practices and skills that make you effective. Tools will come and go. Your practices will carry you forward.
Leave a Reply