| |

Gemma 4 12B aced the short jobs, but its code review still needed a red pen

Engine/model: Ollama, gemma4:12b-it-q4_K_M

Gemma’s 12B run is the first result in this campaign that made the short-workflow panel look almost suspiciously clean. Under scorer v2 it passed all six cases: literal evidence extraction, three structured portfolio decisions, and both short community replies. The code-review lane was much less tidy. Four recommendations were useful, five needed a warning label, and four were simply wrong.

Two-panel qualification chart for Ollama Gemma 4 12B showing six of six scorer-v2 workflow passes, an original scorer-v1 total of four of six, and review findings split into four useful, five qualified, and four false or materially wrong.
Gemma 4 12B went 6/6 under scorer v2, up from 4/6 under v1. Independent source review kept four of 13 code-review findings as useful.

Two scorer fixes, both earned

The original score was 4/6. Scorer v2 raised it to 6/6 for two specific reasons. One community prompt asked for a casual fan voice but never required literal team or city names; the old scorer quietly did. One portfolio answer returned HOLD in uppercase, even though the action enum was supposed to be case-insensitive. Version 2 removed the hidden wording test and casefolded the action before checking it. Nothing in the historical receipt was rewritten.

That leaves a clean v2 split: hotel 1/1, paper league 3/3, and crowd control 2/2. The six calls took 42.4 seconds in total, with a 2.5-second median. This is exactly the kind of bounded, validator-backed work that a mid-sized local model ought to win.

The review lane found real work and invented some too

Two of four repository reviews passed the deterministic format and quotation checks. Across all four, the model proposed 13 findings. Source inspection kept four as useful: an unfinished time-edit control, conflicting framework configuration files, a client-only persistence gap, and an upstream error path that discarded diagnostic detail.

Five more were plausible only after qualification. They included ordinary refactors presented as larger architectural problems and a security warning whose severity outran its actual input boundary. Those are usable leads for a human reviewer, but not tickets I would file unchanged.

The other four failed source adjudication. A duplicate check was called redundant even though removing it would expose a different uniqueness failure. Necessary URL validation was described as waste. A simple startup migration was labeled a race without evidence, and an intentional relative asset path was treated as a portability bug. Quote-shaped evidence did not make those conclusions true.

The full ten-call run processed 100,408 provider-reported tokens in 313.8 seconds. The four large review packets dominate both numbers, so this is not a fair raw-speed comparison with the short cases.

Provisional verdict: likely keep

At 7.04 GiB, this Ollama tag has earned a place in the next round. It was contract-safe on every corrected workflow case and found enough real review work to be useful. I would route it to extraction, classification, structured decisions, and review triage behind validators. I would not let it approve security or migration findings without source-aware adjudication.

The verdict is likely_keep, not permanent protection. The matching family on the other engine still needs its own report, and no model is deleted without separate authorization.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *