Qwen 3.6 35B was wonderfully fast, right up until code review
ollama / qwen3.6:35b made a terrific first impression on the M5 Max. It passed every corrected workflow case, and its six short jobs finished in 13.56 seconds altogether. The median call took 0.79 seconds. For a 35B-class model, that feels almost indecently quick.
Then I gave it four unfamiliar codebases.
That half of the test was less flattering. The model found six useful issues, but it also produced thirteen recommendations that were false or materially wrong. Speed did not disappear. Judgment did.
The scorer changed, not the answers
The original receipts recorded four passes out of six. Scorer v2 gives the run 6/6.
Two corrections explain the difference. The paper-trading scorer now treats HOLD and hold as the same action, rather than failing an otherwise valid decision on capitalization. The casual fan test no longer demands two hidden team-name keywords that the prompt never required. The stricter Lions case still keeps its literal-name requirement because that prompt asked for those words.
Nothing in the old receipts was rewritten. The v1 total remains 4/6; the current workflow result is 6/6 under scorer v2.
The six cases covered literal evidence extraction, three structured portfolio decisions, and two short sports replies. This model handled the evidence, arithmetic, schema, tone, and factual constraints correctly once the benchmark stopped penalizing answers for rules it had not stated.
Code review was a coin toss with good manners
The repository stage produced 26 recommendations across four frozen source snapshots. Two of the four review documents passed the mechanical validator. That only proves the quotations and JSON shape were acceptable, so I checked every recommendation against the surrounding source.
Six were useful. Seven had a real idea buried inside an exaggerated severity or an unproven threat model. Thirteen were false or materially wrong.
The good findings were practical. The model noticed a deployment job uploading the repository root instead of the generated site, a scraper call that could abort all remaining search terms, missing automated tests, an ephemeral session key that would log users out after restarts, and a routine that loads a full table before grouping records.
Its misses were just as concrete. It declared static export incompatible with client components, but the pinned application built and exported successfully. It mistook a truncated review packet for a truncated source file several times. It warned that static assets might bypass authentication while overlooking the explicit middleware gate and the comment explaining execution order. It said a maintenance job would skip cleanup after a scrape failure, although cleanup runs before the deliberate nonzero exit. One finding was titled as a timezone problem while its quoted line configured SQLite thread handling.
A perfect quote can still support a bad reading. Half of this model’s recommendations landed in that category.
Fast enough to keep, not safe enough to trust
The four repository reviews used 96,198 tokens and took 110.74 seconds. Their median latency was 29.49 seconds. Across all ten calls, the campaign recorded 98,068 tokens and 124.30 seconds of model time.
That is the interesting result. Ollama’s qwen3.6:35b was both the fastest part of this campaign tick and one of the clearest demonstrations that throughput is not judgment. It can tear through a bounded task, obey a schema, and return a useful first-pass lead. Give it a broad codebase and it starts promoting possibilities into findings.
My provisional verdict is likely keep. I would use it for evidence extraction, structured decisions, quick classification, and tightly scoped review prompts backed by deterministic checks. I would not let it assign security severity or approve code without an independent source-aware reviewer.
No model is being deleted from this result. Retention remains provisional until the direct engine and family comparisons are complete.
