There is no best AI coding model

I’ve spent an unreasonable amount of time swapping AI models in and out of my development workflow over the last year. One week I’ll be using Kimi heavily for implementation. Another model will turn up that’s much better at planning. Something cheap will surprise me at repository exploration, then completely fall on its face when I ask it to coordinate a few tools reliably.

I’ve stopped thinking about any of them as the best coding model, because I don’t think there is one. Software development isn’t one job, so I’m not sure why we’ve decided one model should be best at all of it.

I don’t want the biggest model doing everything

There’s a fairly obvious trend where people buy the biggest Claude, GPT or equivalent subscription they can get and then throw basically everything through the most capable model available. I understand how we got there. If you’ve paid for a massive allowance, using anything else can feel like deliberately choosing the worse option.

Except it isn’t always the better option. Sometimes it’s just more expensive, sometimes it’s slower, and occasionally it makes the actual software worse.

I’ve had straightforward changes where giving a powerful reasoning model too much room to think ends with it convincing itself the problem is considerably more interesting than it is. A change that should have been:

find the problem
      ↓
fix the problem
      ↓
test it

can become:

find the problem
      ↓
question the architecture
      ↓
invent future problems
      ↓
add abstractions and configuration
      ↓
change unrelated code
      ↓
eventually fix the bug

The result can still be technically correct, which is almost the worst part. The tests pass, the application works and the agent gives you a convincing explanation. You’ve just gained another interface, two unnecessary classes and some configuration nobody asked for.

More reasoning is not automatically better engineering. Sometimes the best thing a coding model can do is understand the problem, make the smallest sensible change and stop.

Software development is a load of different jobs

A lot of this clicked before I built SpecOps, when I started spending more time with spec-driven development workflows in AI coding harnesses such as OpenCode. Gentle AI was a big influence. It showed me how useful specialist roles could be, but I wanted something much leaner and more constrained for the way I work.

That eventually led me through OpenSpec and into building SpecOps around the bits I actually wanted. The thing that stuck was simple: exploring, planning, designing, implementing and reviewing are different jobs, and the same model does not need to do all of them.

An explorer mostly needs to find where behaviour lives and work out which parts of the codebase matter. Planning and design need more judgement. The implementer needs to be good at actually working in the repository, which is not always the same thing as being the strongest reasoning model available. Some extremely intelligent models are surprisingly irritating implementers. They’ll produce a fantastic analysis and then need encouraging to actually get on with the fucking thing.

I also normally want a different model reviewing the result because different model families seem to have different blind spots. Frontier models make no mistakes, obviously, but I keep the reviewer anyway.

This is what I’m using today

At the moment one of my SpecOps configurations uses models from MiniMax, Qwen, Z.ai, Kimi, OpenAI and DeepSeek. Right now it looks like this:

Model Routing

Coordinator    MiniMax M3
Explorer       Qwen3.7 Plus
Planner        GLM-5.3
Designer       Kimi K3
Implementer    GPT-5.6 Luna
Reviewer       DeepSeek V4 Pro
Frontier       GPT-5.6 Sol

That list changes all the time. Kimi K3 happens to be in the designer role, but there are design jobs I’d rather give to something else. Kimi 2.7 Code is still one of the models I use most often for implementation, while I’ve been testing Luna more recently because it’s very cheap for the quality of work I’m getting from it.

The assignments aren’t particularly important. The useful bit is that the roles aren’t tied to them. If something better appears tomorrow I can swap it in without redesigning the workflow.

A simple job can still need a decent model

There is a limit to this. “Use cheaper models” can quickly become another stupid blanket rule, and the SpecOps coordinator is a good example.

Its job is deliberately boring. It is heavily constrained, has limited permissions and mostly inspects OpenSpec state and hands work to specialists through a small set of custom SpecOps tools. It isn’t free to wander around the repository and improvise. On paper it is rigid enough that it shouldn’t need anything particularly clever.

In practice, a better model still gives you a noticeably better experience. It spots work that can be dispatched in parallel, keeps useful to-do lists, gives clearer progress feedback and moves the workflow along without needing nudges. A weaker model can understand the same narrow job and still make the whole thing feel worse because the agentic behaviour around it is less reliable.

MiniMax M3 works very well for me there, and some of DeepSeek’s cheaper models have also been good at that sort of tool-heavy orchestration. Models I wouldn’t trust as coordinator can still be great explorers when the job is tightly bounded.

The goal isn’t to find the weakest model you can get away with. It’s to find a model that’s comfortably good enough for the job you’re giving it.

Sometimes the expensive model really is the right answer

None of this is an argument against frontier models. There are problems where I absolutely want the strongest model I can get: difficult architecture, ugly concurrency, security-sensitive changes, unfamiliar systems, or situations where several other agents have looked at something and I’m still not convinced we’ve got the right answer.

That’s what the frontier role in SpecOps is for. If an explorer can gather the same context for a fraction of the cost, let it. If an implementation model can make a well-defined change reliably, let it. If they hit something genuinely difficult, escalate.

A frontier model should be available because you need it, not used because the dropdown happens to let you select it.

I’m part of the waste problem too

I’m not pretending I’m outside the compute problem. I run coding agents that are somewhat autonomous and they are not as efficient as they could be. I use them because they’re useful, but I also try to make the workflow earn the compute it burns. If something isn’t worth automating, I don’t automate it. Plenty of things are still simpler, cheaper or more enjoyable to do myself. I still like writing the code, after all.

A fixed-price subscription makes this easy to ignore because another frontier-model run can feel free. The compute obviously isn’t. There are GPUs, electricity, cooling and a lot of infrastructure behind it.

I can’t tell you the exact environmental cost of one coding-agent run, and I’m wary of neat comparisons that pretend otherwise. What we can measure is the direction of travel. The IEA’s 2026 analysis of energy and AI puts global data-centre electricity use at around 485 TWh in 2025 and projects roughly 950 TWh by 2030. It expects electricity use from AI-focused data centres to triple over the same period.

Inference is getting dramatically more efficient while we’re finding ways to do vastly more of it. Agentic coding makes that particularly easy. Use the amount of compute the problem actually needs.

The bit that worries me is when nobody reads the code

The overthinking problem matters more when generated changes aren’t read carefully. It’s very easy to look at a summary, see green tests and accept a change that appears to work.

Tests can tell you whether the behaviour you’ve tested still works. They don’t tell you whether another abstraction was a good idea, whether the model solved an imaginary requirement, or whether a six-file change should have been six lines. Somebody still has to apply engineering judgement.

AI made producing a 600-line diff almost frictionless. Understanding a 600-line diff did not become frictionless.

I’ve rejected plenty of AI-generated code that worked because another implementation would leave the system in a better state. That’s why I like review as a separate part of the workflow, although another model isn’t a replacement for understanding the change yourself. If I’m responsible for the software, I still want to know what the fuck has gone into it.

Benchmarks only get you so far

I look at benchmarks when a new model appears, but a coding score doesn’t tell me whether it will be a good SpecOps coordinator, whether it will over-engineer a tiny bug, whether it reliably uses tools, or whether another model costing a tenth as much will do the job just as well.

The only way I’ve really found those things out is by using the models. Some I’ve expected very little from have ended up with a permanent place in my workflow. I’ve moved expensive models out of roles because something cheaper simply behaves better there.

Model selection is an engineering trade-off. The leaderboard is just one input.

Prompting is part of this too

The same model can behave completely differently depending on the prompt, context, tools, permissions and constraints around it. I’ve spent far too much time discovering that while building agent workflows.

That’s a different article. Choosing the right model doesn’t magically solve everything, but throwing the most capable model available at a badly defined job doesn’t either.

I expect the models to keep changing

I don’t know what my SpecOps routing will look like six months from now. I barely know what it’ll look like next month, and that’s fine. I don’t want the workflow designed around MiniMax, Kimi, DeepSeek, GPT or anything else. I want it designed around the work.

Explore the code, understand the change and plan it properly. Design the bits that need designing, implement it, review what changed, then escalate when the problem genuinely needs more capability. The models underneath those jobs can come and go.

There is no best AI coding model. There are just models that are better suited to particular problems. Working out where each one is useful has become a much more interesting problem than trying to pick a winner.