Warning: long post ahead. On the bright side, it's 100 percent human-written, typos and all. No AI slop was used to generate any of the following post. Bask in the warm glow of our increasingly rare shared humanity, gentle reader.

Just wanted to report my local model coding experience tonight. One of my board game hobby websites (static sites hosted on Github pages) had an annoying UI bug you can see in the "before" pic above: when the Tools nav button is clicked, the dropdown menu appears half offscreen on the left side of the viewport. So I fired up my local LLM coding rig to fix it.

Hardware: MacBook Pro M4 Max with 64Gb of RAM. Model backend: oMLX. Model: Gemma4-26B-A4B-it-oQ6. Agentic harness: Pi.

This Gemma4-26B MoE model runs pretty fast on my machine: 800 tokens/second prompt processing, 63 tokens/second token generation. Qwen3.6-35B is my usual daily driver, and I have only used Gemma4 for chat purposes to date. But tonight I decided to test it for coding.

I described the UI bug to Gemma4 verbally, and since it has Vision capabilities, I took a screenshot of the issue and uploaded it to the model for good measure. Things started out promising. Gemma4 analyzed the issue, figured it had the root cause, and started reading the site CSS file to insert a fix in the right spot. That's when things started to go off the rails. Gemma4 fell into a recursive doom loop of read, edit, fail, then read again. Several times I stopped the model, told it that was doom looping, asked how I could help. Gemma4 apologized, acknowledged that it was looping, even appeared to identify why it was looping, said that it would try a different approach, then just fall into another doom loop. After about 15 minutes wasting my time trying to redirect Gemma4, I said "screw this" and loaded up The Big Gun:

Qwen3.6-27B-UD-MLX-8bit.

That's right -- we're going full-on 27 billion dense parameters on your ass, CSS bug. None of this puny MoE nonsense. Time to roll up our (virtual) sleeves and get down to business.

Now I don't often use the dense model for coding, because it is significantly slower on my Mac. Prompt processing is 190 tokens/second, token generation a comparatively glacial 13.2 tokens/second. But what Qwen3.6-27B lacks in speed, it makes up for in reasoning ability and coding quality.

I started a /new Pi session with qwen3.6-27B loaded up. Described the UI bug verbally. Didn't even bother to upload a screenshot. That was enough for Qwen3.6-27B to understand the issue. Then it started THINKING. It chewed up about a quarter of my context window just figuring out the bug from all angles, paragraph upon paragraph of back and forth with itself. "I can see the issue...but wait...the problem is...actually...wait, that should be fine...oh wait, i see the issue...let me re-examine...unless...the cleanest fix is..."

And after all that thinking, Qwen3.6-27B fixed the bug in a single-shot. As you can see in the "after" pic above.

To me, this is a clear real-world illustration and confirmation of certain assumptions I have made in my few months of exploring local models.

1. MoE models are faster but more prone to mistakes and loops.

2. Dense models are slower but far more accurate and precise.

3. Gemma4 is not as useful for coding as Qwen3.6.

Qwen3.6-35B (MoE) will still remain my daily driver because it has a nice balance of blazing speed and acceptable accuracy. But when the shit hits the fan, it's nice to be able to bust out a dense model to get myself out of a jam.

TL; DR: Gemma4 MoE is fast but doom-loopy, while Qwen3.6 is slow but spot-on accurate.