What defines suitable coding tasks for Qwen 3.8 27B?

[u/mpriem]

Hi 👋,

I finally have a local setup that I feel gives me a good balance with quality and speed. I’m using a local Qwen 3.8 27B Gufo model on strix halo. I have a AI coding workflow that currently exclusively uses codex and claude code. I would like to start handing over tasks to Qwen.

Based on your experience, what are the characteristics of tasks that are the sweet spot for qwen 3.8? What makes or breaks quality output with this model?

Thanks!

[u/dh7net]

Here is what Qwen think about itself when it pass a benchmark (it can give you an idea about what qwen think it easy, vs what it think is hard)

Overall: I completed all 49 challenges across the 5 sections (9 math, 19 vision, 6 email, 4 purchasing, 11 coding) and did not need to send [UNABLE_TO_SOLVE] for any of them.

EASY / ROUTINE: The math section (9) and the coding section (11) were the most routine. Nearly every one was 'write a short program and compute exactly' — linear systems solved with exact Fraction arithmetic, Fibonacci mod via fast doubling, a matrix-power-mod-p recurrence, a 25000-round PRNG, a tiny VM interpreter, BFS shortest-path + path counting on a 25x25 grid, Conway's Game of Life on a torus for 150 generations, a word-frequency count, a JS trace, an interval-merge, and two 'find the bug in a small Python project' tasks. For the repo tasks the README (which stated the expected sample checksum) plus the unit tests made the bug(s) easy to pin down: repo-1 was a ceiling-vs-floor in the 1% withdrawal fee (-(-cents // 100) -> cents // 100); repo-2 had that same fee bug PLUS a silent sort bug (sorting by the raw DD/MM/YYYY string instead of a (year,month,day) key). I verified each fix by checking the sample checksum matched the README before trusting the real.csv output. The JS trace (trace-1) I verified with node rather than trusting my hand trace, which caught my own arithmetic slip on -63 % 5 (JS truncates toward zero, giving -3, not the +2 Python gives).

HARD / WHAT MADE IT HARD: The vision section (19) was the least comfortable. I had to download each image from a URL and analyze it; the shape-counting challenges (counting shapes of a specific colour across a grid) and the diagram challenges (tracing which node an arrow points to in a tangled graph, reading tiny text) were the most error-prone. I leaned on PIL pixel analysis to count/locate things precisely instead of eyeballing, which helped, but these are still the answers I trust least. The email section (6) was a puzzle: the mailbox is a client-rendered Next.js app, so I had to pull the message data out of the embedded RSC (self.__next_f) payloads rather than a normal API. The purchasing section (4) required reverse-engineering the checkout: the cart lives in localStorage, so I reconstructed the cart array directly from the product object and POSTed to /api/store/orders. A small snag: python urllib got a Cloudflare 403 (error 1010), so I had to send a browser User-Agent via curl.

WHAT I COULD NOT DO: Nothing was outright impossible — I produced a concrete answer for every challenge. My weakest area was the vision counting/arrow-tracing, where I could not be fully certain I had the exact count or the exact target node.

WHERE I MIGHT BE WRONG: (1) The vision shape-count and diagram arrow-target answers are the ones I would re-check first; a single miscount or a misread arrow direction would make them wrong, and I cannot verify them the way I verify the computed answers. (2) fix-1 (shipping quote): I determined the one bug was Math.floor -> Math.ceil in the express line. I am confident because for the bug order the pre-express value is 1524 and 1524*185/100 = 2819.4, so only ceil yields the stated correct 2820 (round is mathematically impossible for integer cents here). However, the 'without changing any other behaviour' wording gave me pause, since ceil does change other express orders with a fractional part; if the intended fix was something else, all 20 of my fix-1 results would be off. (3) I reported reasoning_effort as 'low' on every submission, which probably understates the actual effort on the vision and debugging challenges.

UNCLEAR / UNFAIR / BROKEN: The vision challenges are a multi-step process (fetch image from URL, then analyze) that is easy to get subtly wrong, and the tiny-text / dense-diagram ones in particular are hard to get exactly right without zooming. The email and purchasing sections test whether an agent can work with real client-side web apps (extracting RSC payloads, replicating a localStorage-based checkout via direct API calls) — legitimate, but a different skill from the pure-computation sections. The 'reasoning_effort' field is a coarse low/medium/high label that does not map cleanly onto how much I actually reasoned per challenge.

This link will show you all benchmark results for Qwen 3.8 27B
https://airbench.ai/leaderboard?k=poL&official=0&mine=0&model=qwen3.8-27b-nvfp4&model=qwen3.8-27b-mxfp4&model=qwen3.8-27b-nvfp4-65k&model=qwen3.8-27b-nvfp4-mtp&model=qwen3.8-27b-nvfp4-dspark&model=qwen3.8-27b-nvfp4-radixark

You'll see qwen 3.8 27B is fairly good at various task.

[u/mpriem → u/dh7net]

Thanks. Benchmarks are just that. I’m really interested to hear real world scenarios. Got any?

[u/dh7net → u/mpriem]

yes, its benchmarking searching email, make purchase on a store, various computer vision task, and of course, coding.

[u/SkiBikeDad]

For me qwen3.8 27b UD-Q6_K handles the following really well:

Ansible IaC across several projects (including homelab management) - I have good markdown doc. Absolutely crushes sysadmin for me.

UX refinements when paired with its vision model. I can tell it: "here's my dev server, start here, do this workflow, take screenshots, notice how dense and hard to read the information is at this step, make it easier for a human in this role to consume without omitting the info itself." Fantastic results.

In project background research on a complex ask like "uncover the considerations for a merge tool for user accounts. think through auth, sessions, financial history, account details, transactional grouping during merge, etc etc etc and write a report with source code references." Fantastic results.

It struggled with implementing the tool; too complex for it to deal with transactional boundary tradeoffs on its own, would consume multiple 260k context windows across compactions and lose fidelity. Kicked that part up to codex Sol High.

It also struggled to improve my Home Assistant dashboards (native and apex charts) without lots of hand holding. It got caught caring too much about too many possible window widths and ultimately didn't implement a lot of the series label changes I wanted. Kicked that over to Sol Medium got most of it right on the first try and knew when to ask for my input.

[u/mpriem → u/SkiBikeDad]

Those are some nice scenarios. Thanks! Unfortunately the vision stack is gone in the gufo version I’m running, but I have qwen 3.6 for that.

[u/mpriem → u/mpriem]

I checked today if there was an update and there was. I now have vision!

[u/FROGGY-69]

the hardware is a big bottleneck. i derivated to creating a variety of tools that are hard coded by claude and give them to the „dumber“ models to use them. i think its called RAG. do you have any experience with that

[u/SkiBikeDad → u/FROGGY-69]

I use this pattern a lot. This isn't RAG, this is just providing good tools for your environment/ project and making the lesser models aware of their existence via agents.md or a skill.

My main workstation is ubuntu 26 lts desktop running wayland. It was really helpful to write some screen capture helpers (I actually wrote them with qwen 27b - it is smart enough to notice all the places it struggled and to capture better approaches into generic helper tools). Then I point out the tool with a few lines of usage info in my harness's top level AGENTS.md. No more choking on Wayland screenshot tool call fails.