I used three local coding models for a week of real work, and the smallest one won

Local AI has advanced enough to almost feel like a life hack. You can brainstorm, analyze complex documents, generate and run complex code on your machine and derive insights that aid important decision-making, and none of it costs a dime if you’ve got the compute and the storage for it. It’s no surprise that the local AI landscape is advancing fast, and we’re almost spoilt for choice on capable open-weight models these days.

That abundance, though, is what put me in a dilemma between three of the most sought-after coding models right now. Between Qwen3-Coder, Devstral-Small-2 and GPT-OSS, it’s hard to pick one that’s better than the other based on just a few hours or days of use. So, after putting them through an entire week of work, I’ve finally decided which one earns a permanent spot in my local AI stack.

Three of the best open-weight models put to test

But how do I compare them reasonably?

It seems as though every week, a new open model claims to be the coding model to settle on, and Qwen3-Coder, Devstral Small-2, and GPT-OSS were all making that case rather loudly on AI subreddits and tech forums.

The plan to pick the best out of the three was to see how each model handles a week of coding. Over this week, I gave the three models the same prompt by asking them to build a Pygame application from scratch, scoring them on how well it ran as well as on the basis of whether the models implemented behavior that I didn’t explicitly ask for.

One of the most inevitable aspects of using generative AI for code generation, is, of course, running into bugs, and dealing with them efficiently. Over the course of this time, I asked Claude Fable 5 to sneakily plant three separate logic bugs into each model’s own generated script, and then handed each model back its own file reporting nothing more except for the mere fact that “there’s a bug, and it needs fixing.”

And then finally, I put every single model through a refactoring test. The subject was a 120-line Python script simulating a small online store’s order pipeline that checked a queue of customer orders against an inventory, rejected ones with unknown products or insufficient stock, applied category-based discounts, added sliding-scale shipping fees and printed a revenue and stock report at the end. It was written in a way a total beginner would hastily write, making it a realistic candidate for a clean-up.

Qwen3-Coder 30B was the fastest, but…

The least trustworthy of the three

Qwen made the strongest first impression by being the snappiest of the three. The program, which was a simple Snake game built using Pygame, was the largest and the best looking of the lot. Qwen produced an 800×600 board with a drawn grid with distinct stylistic elements, and every response arrived faster than either competitor. If I’d adjudicated based on presentation and speed alone, I would’ve had a winner at this point.

As it stands, however, the model warranted further “scrutiny”, for the lack of a better word. Its arena let the snake teleport through walls, which, as anyone would know, is a failing condition. In the subsequent debugging round, its generated code did fix all the logic bugs that Claude planted in the original code, but its written diagnosis was largely inconsistent with the faults that it described. The most likely explanation for it is that Qwen didn’t find the bugs at all, and it simply rewrote the suspected sections from its memory of how the Snake logic should look and that made it land on the right code.

The refactoring test was the real disappointment. Its restructured Python script crashed on the very first line with a scoping error. A model that answers quickly, looks polished and can’t explain its own fixes is a risky addition to the stack.

Devstral Small 2 shipped the most broken fixes

Genuinely impossible to recommend

Devstral has a reputation that’s built on agentic use-cases, so I went in expecting it to shine when handed its own buggy file. It found exactly one of the three planted bugs, then reversed the direction check, and diagnosed it well, explaining the 180-degree turn mechanism that Claude’s intended bug would cause. Thereafter, it confidently declared the code fixed while the other two sat untouched in the very script it handed back, one of them reproduced verbatim. This was rather hilarious, since broken code labeled as repaired is the single worst outcome a debugging assistant can produce.

Now, I would’ve dismissed it as a one-off, but the refactoring round repeated the pattern again. Its plain-English description of the 120-line script was accurate in its own right, but the restructured code crashed at the summary stage over a parameter it forgot to pass.

GPT-OSS 20B was the smallest model, and yet…

It swept every single round, perfectly

GPT-OSS was the one model that had me dumbfounded. It won the generation round, because it was based on sound judgment. The Snake Pygame was the only one amongst the others where the walls actually killed you, the only one with a proper opposite-direction map blocking instant reversals, and the only one that checked food spawns against the snake’s entire body through a dedicated helper. As in all the tests, this behavior was not specified, and no hand-holding was involved.

The debugging round was also a clean sweep. All three planted bugs were identified with precise root causes, verified against my diff, and fixed without touching a single line that wasn’t broken. There’s literally zero room for complaints here.

The refactor sealed it running byte-for-byte identical to the original, while its plain-English explanation was the only one to note details like the script never persisting data. All of this came from the smallest download of the three, fitting my 16GB RTX 4070 Ti Super with room to spare. This model proved that there was simply no contest.

A result that nothing could’ve prepared me for

If you’ve been following my coverage, you’ll know that I have run a fair share of LLM benchmark assessments so far. Every test I’ve run has ended in revealing some trade-offs when it comes to some models, with usually one running on capability with the other clawing back points on efficiency. This is the first time a benchmark run has handed me a whitewash. GPT-OSS is the undisputed victor in all three rounds, but I do believe further testing is warranted. One week of testing and one pair of hands running it all is definitely a signal or an indicator, but it could be far from a universal verdict if the testing methodology is changed. There’s only one way to know.