What’s the best artificial intelligence to use for professional software work, for building products?
I’m making this video in reply to a short by Francesco Ciulla (@Devmy), whom I salute and recommend you follow, he does great interviews. Francesco asks: “I want to equip my team of developers with AI to write code. It’s not exactly easy to choose between Copilot, Claude, this one, that one.” There’s a ton of confusion, and he’s right. I want to answer him, and more generally talk about how you handle a choice like this.
Think of intelligence as a resource, not a subscription
I start by defining this artificial intelligence as a resource. Try to think of it that way. Don’t think of it as a subscription. Think of AI as a pipe. Out of this pipe comes raw intelligence, the same way electricity reaches your house, the same way water reaches your house. Intelligence arrives, and you decide how to route it.
This dynamic breaks away from the classic software as a service model, the ten euros a month, a hundred a month, whatever it is. That model is the wet dream of American big tech, but it’s already clear it applies very badly to AI. Why? Because software as a service scales incredibly well, and AI doesn’t scale the same way. Every time you fire off a prompt you’re switching on four microwave ovens somewhere in the Arab Emirates. Every time you use it, that stuff burns energy.
The other reason the subscription creaks with AI: paying a subscription per person per month assumes the user is a person. But if this raw intelligence ends up inside agentic software, it isn’t even necessarily a person using that resource. So what do you pay for, per agent per month? The whole thing creaks and barely works.
Start anywhere, then focus on standards
My advice here is, first of all, to start somewhere, anywhere. If you find yourself overthinking it, “do I go here, do I go there, what’s best for me,” it’s because you’ve fallen into the big tech marketing trap, where they hand you the single best service and start reeling you in, tangling you in their capitalist claws. Joking aside, it’s actually far better to just start somewhere. Copilot, Claude Code, OpenCode, pay as you go. Start wherever you like and focus on the standards and the working practices around this stuff.
That way, once you’ve identified the standards and the ways of working, you can switch vendor, and you can move from subscription to pay-as-you-go or the other way round whenever you want, and you’re independent from these people.
Here’s an example. I’m starting out, I want something quick, I want to use the most talked-about technology, so I get the twenty-euro-a-month Claude Code subscription and start tinkering. I get smart and try to monitor my usage: how often I use it, how many tokens I burn, when I hit the limits. As I start to understand these things, I also study the standards that live inside that technology, but that also apply across this whole sector. How skills work, and I start building my own skills. How MCP servers work, and eventually I start building my own MCP servers. How to structure spec-driven development, how to do agentic engineering. You can do all of this independently from the vendor.
Independence from the model, too
That mostly depends on how big the model is. The smaller the model, the harder it is to make it do interesting things. For instance, I take OpenCode, I hook up OpenRouter as a pay-as-you-go vendor, and I use the latest Qwen at 400B. I use Kimi, I use GLM, I use them at different sizes. I sit down and compare, say, how Opus does against the Qwen beast, how Sonnet does against the open 30B models.
You have to find working setups that are independent from the specific vendor, and even independent from the specific model, and concentrate on the standards and the practices.
It could be that, for certain working habits, the twenty-euro subscription suits you, though I doubt it, that one’s more for hobbyists. Maybe the hundred-euro one suits you. In other cases, based on your usage patterns, paying per usage is absolutely better, especially if you find yourself paying per-seat subscriptions. If you’re paying five hundred-euro-a-month subscriptions to Anthropic, that’s five hundred euros a month, and you’d burn through a lot of the big Chinese models pay-as-you-go before hitting five hundred. So it really depends on measuring how much use you make of it, and on how well you’ve understood how this stuff works at the level of standards. Starting as early as possible matters more than making the definitive choice.
This is where I disagree with Francesco’s framing, because it was as if he had to choose and then stay there. You don’t have to choose, and above all you don’t have to stay. Big tech would love it if, once you chose, you stayed put for five, six, ten years. But no. You change AI vendor with the same ease you change your mobile carrier or your home provider.
A note on local setups
The other point is about local setups. A local setup makes sense, but it really has to be worth it. So don’t get fixated on “we want the machines in-house, the GPUs, the local models.” That’s something that can be worth doing for environments where it’s genuinely critical that information stays confidential and in-house. It’s very hard to have local setups that match the level of the AI you can get from some data center, pay-as-you-go or by subscription.
So it really has to be worth it. In ninety percent of cases it absolutely is not. You’re signing up for a valley of tears where the end result might not even match what you’d get by simply paying a subscription or paying per usage from some vendor. So watch out, it’s very demanding, it has to be worth it.
To recap
Start as early as possible. Make sure you focus on standards, not vendors. Make usage estimates. And set yourself up so you can switch whenever you want.
