You Are Chasing Tools. The Skill Is Underneath.

Most days I write code with two different models, and I switch between them without much ceremony. One is fast, and I reach for it when the work is mechanical and I want the loop to feel like an extension of my own hands. The other is slower and reaches further, and I bring it in when the problem actually needs reasoning. Here is the part that took me a while to admit. The switch changes almost nothing about the work. The specification I write is the same. The way I break the problem down is the same. The review at the end is the same. I change the engine and keep everything I built around it.

The question is a poll

The question I get, and the one I see everywhere, is which tool is best. Which model, which agent, which editor. It sounds technical. It is really a poll. Best at what, for whom, under what constraints, on which codebase? Take those out and there is no answer left, only taste, and taste is not knowledge. And whatever answer you did land on would be stale by the next release. You would have spent real effort producing a fact with a shelf life of weeks.

You are optimizing the part of the system that changes the most and matters the least. There are three layers in play. The model, which is what the arguments are about, and which you can swap in a day. The harness around it, the product you actually buy: how it holds context, whether it can read your codebase, run your tests, and recover when it breaks. And the loop you run through it, the specs and the review, which is yours and goes with you everywhere. For everyday work the frontier models are close enough that choosing among them is a coin flip; what remains is fast versus deep, and that is a choice you make per task, not a ranking. The tool question obsesses over the first layer and barely mentions the other two, and the other two decide the result.

Same tool, two hands

Hand the same tool to two developers and you get two different outcomes. One specifies the problem, reads the output, catches the place it went wrong, and fixes it. The other accepts whatever comes out. Hold the tool constant and the results diverge. Hold the person constant, I do it every time I switch models, and almost nothing moves. That asymmetry tells you where to put your attention.

There is also a cost to tool-hopping, and it is paid in exactly that attention. Every switch resets something. You relearn the quirks and rewrite your instructions, and the gain is small and does not last. Meanwhile the thing that compounds sits untouched, because you were busy shopping. The developer who picks a good-enough tool and goes deep on the loop passes the one who is always migrating.

Where the tool does matter

None of this means the tool is nothing, and the lazy version of this argument pretends it is. The category matters a lot. An autocomplete that finishes your line, a terminal agent that edits across a repo and opens a pull request, and a runner you point at a task and leave are different instruments, and treating them as substitutes is how people end up disappointed.

On the hardest problems, the ones that do not fit neatly in a benchmark, the difference between a strong setup and a weak one is whether you ship at all, and most of that difference is the harness and the loop, not the name on the model. If your work lives on one platform, the tool native to it can win on integration alone. Even the speed I mentioned is a real difference, not a taste; part of the skill is knowing when a task needs the fast model and when it needs the slow one.

"Just learn the fundamentals" is its own empty answer when it means ignore the tools. Tools amplify fundamentals. That is why the fundamentals pay off, and it is not permission to ignore what you are amplifying with.

And then there is the bill

The place the tool matters most has nothing to do with which model is smartest. It is the pricing. For a long time I lived on a tool that charged one flat price, and I leaned on it hard, all day, every day, and the bill never moved. I knew exactly what a month cost. Then the pricing changed underneath me, from flat to metered, and the same work I had always done started adding up to more than a thousand euros in a single week. Nothing about my skill or my loop had changed, only the meter.

A price change is a real reason to switch, and it is the opposite of chasing novelty. I moved to a tool with a predictable cap, running the same models I already preferred, and my bill went back to a number I could plan around. I hit a limit now and then. I do not miss the thousand-euro weeks. The tools I left still charge a premium for exactly the models I want, which is a fine business for them and a poor deal for me.

Anyone who has run things in the cloud has seen both halves of this before. The bill that turns metered and then surprises you. The capacity you cannot fully count on: the instance that will not come up in your region, the limit you hit at exactly the wrong hour. The cloud spent a decade teaching engineers to watch the meter, cap what they can, and never wire themselves so tightly to one provider that leaving means a rewrite. The AI tools are early in the same story, and the lesson carries straight over.

So when someone tells you the tool does not matter, this is the part they are leaving out. The intelligence converges and the harness matters, but the terms of the deal can matter more than either. Not only the price and the capacity, but the license that changes under you, and the privacy policy that starts reading your code into the next model's training set. These are levers a vendor can pull overnight without touching a line of yours, and every one of them has been pulled on somebody in the last few years. That is the real argument for keeping your loop portable. Not so you can chase a leaderboard, but so that the day the deal changes, you can walk.

The good version of the question

The good version of the tool question is answerable, because it names its constraints. Best for large refactors that have to fit in one context. Best under a fixed monthly budget. Best for code that cannot leave our own machines. Best in the language we actually work in. Those have answers. "What is the best AI coding tool" does not, because it never says best at what. So decompose it, and switch on purpose rather than on impulse: when you have named a capability you are missing and run a fair comparison. Keep a little time for scouting too, watching what people you trust actually adopt, because the one switch that matters most is sometimes into a category you did not know existed.

I picked my setup this way and then mostly stopped thinking about it. The project instructions, the specs, and the review habits all carry over; only the model underneath changes with the task. The tools I have built lean the same way: a pipeline that turns a sentence into a plan and opens its own pull requests, a control plane that governs fleets of agents. None of them care which model sits behind them. They are scaffolding around the same loop.

And it goes further than my own tooling, because most of what looks like a new AI product is built on frontier models anyone can rent. I have helped build products that do serious work in law, in health, in scientific research, and in auditing, and none of them runs on a secret engine. Inside there is a pipeline: several steps with their own dependencies, often different models at different steps for different reasons, a fast one where latency is the constraint, a deep one where the reasoning is, the same split I make at my own desk. But every model in the chain comes off the same short menu the competitors order from. What makes these products worth paying for is everything around the models: the retrieval over sources that actually matter, the grounding that keeps an answer pinned to those sources, the workflow shaped to how the profession really works. The models are nobody's moat. The value collects around them, not inside them, and that is the same lesson at a different altitude.

What you actually keep

So chase a tool for a week if you want, and then get good. The model you use will be replaced by a genuinely better one on a schedule you do not control, and it will still not save the developer who never learned to specify or to read. The way you think a problem through and the eye that catches the wrong line stay yours across every switch. One of those is worth building. The other deserves a week of your attention, and a way out you keep open.