Qwen 3.8 27B vs Gemini 3.7 Flash (High) for real coding: open-source 27B model did a much better job

TL;DR: In this real-world C++/OrcaSlicer debugging project, Qwen 3.8 27B impressed me more than Gemini 3.7 Flash High. Gemini was faster and productive, but repeatedly declared success before the tests fully justified it. Qwen was better at falsifying its own hypotheses, separating unrelated bugs, finding concurrency/memory issues, and ultimately keeping the feature disabled when one correctness question remained unresolved. I wouldn’t claim Qwen is universally smarter, but for long-running repo-level debugging, I trusted its engineering judgment more. I’ve been doing a pretty interesting real-world comparison between Gemini 3.7 Flash – High and the open-source Qwen 3.8 27B on a fairly complicated C++ project. This wasn’t a “write me a function” benchmark. Both models were acting as coding agents with access to a large existing codebase: a heavily modified OrcaSlicer fork for the Snapmaker U1. The feature being worked on is particularly nasty because it touches: multithreaded C++ / TBB slicing geometry Local-Z sublayers multi-tool scheduling G-code generation prime tower generation physical filament/tool assignment deterministic geometry comparisons real print-time estimation regression tests stochastic/non-deterministic slicing behavior I had been using Gemini 3.7 Flash High for most of the work. Then I switched the same ongoing investigation to Qwen 3.8 27B, running locally/remotely through my own setup: Native context: 262,144 Quantization: FP8 KV cache: FP8 E4M3 GPU memory util: 0.91 Max batched tokens: 8,192 Max sequences: 4 Default reasoning_effort (xhigh) I expected Gemini to be better because it’s a new closed-source frontier-ish model. That was not what happened. The biggest difference wasn't raw code generation. It was engineering judgment. Gemini did a lot of useful work and built much of the validation infrastructure, but I noticed a recurring pattern: It declared victory too early. For example, Gemini eventually gave me a report saying the new scheduler had passed all integrity gates and was safe to enable by default. The report looked excellent: exact parity all gates passed 32% fewer tool changes ~22% faster print default enabled But when I independently audited the actual test code, several of those gates were much weaker than the report implied. One “exact emitted parity” gate actually allowed things like: up to 300 physical-tool mismatches up to 100 Z mismatches up to 100 extrusion mismatches while the printed report described it as essentially zero-error parity. Another supposedly empirical geometry gate used: <= 300 mm² < 1.5% even though the observed natural nondeterminism was only around single-digit mm² in the controlled fixture. There were several rounds like this where Gemini improved the tests after I pointed things out, but kept tending toward: “Looks good now. Enable it.” Then I switched to Qwen 3.8 27B. And Qwen behaved very differently. Instead of trying to finish the task as quickly as possible, it started finding reasons not to enable the feature yet. It found or isolated several things that made its own job harder. Qwen discovered a real TBB deadlock A test was hanging indefinitely. We sampled the process and found it here: Print::process() -> name_tbb_thread_pool_threads_set_locale() -> tbb::parallel_for -> condition_variable::wait() The old code effectively created a barrier inside a TBB parallel_for, assuming all N tasks would run simultaneously. They aren't guaranteed to. If some workers enter the barrier before the remaining tasks get scheduled, the running workers can block the workers needed to run the remaining tasks. Classic scheduler-starvation deadlock. Qwen replaced it with a tbb::task_scheduler_observer rather than trying to patch around the symptom. It also found a completely separate giant-coordinate corruption bug At one point a test generated XY coordinates around: ~1e13 mm which naturally caused estimated print times around: ~1e13 seconds Qwen initially investigated one suspicious PrintInstance.shift value. Then it proved that hypothesis was wrong. Its response was basically: "That was a red herring. The value is deterministic and identical in clean and corrupted runs.". That sounds minor, but I value this a lot in an agent. It didn't try to preserve its previous explanation. It discarded it. It also demonstrated that the G-code time simulator was innocent: if you hand it a 10-trillion-mm travel, of course it produces an absurd travel time. The corruption occurred upstream. It discovered another pre-existing stochastic Local-Z bug Some Local-Z tests intermittently threw: Coordinate outside allowed range Qwen tested scheduler ON vs OFF: scheduler ON: 3/8 failures scheduler OFF: 4/8 failures It then traced the execution path and showed that the scheduler wasn't even active in those tests. So instead of blaming its new scheduler work, it concluded: "pre-existing bug, probably unrelated" Again: good engineering behavior. Most importantly, Qwen refused to enable its own feature After all the work, its final result was: texture_dependency_scheduler default = false Why? Because one exact parity test still failed: ~364–372 start/seam mismatches So its conclusion was essentially: "Performance is excellent. Geometry/tool/Z/extrusion parity is excellent. But one visible-output invariant still isn't satisfied, so default enablement remains blocked." That is the opposite of optimizing for “task completed.” I then independently audited Qwen's result too. Interestingly, I think Qwen may actually be overly conservative on the remaining blocker. The current test calls those ~372 differences “seam mismatches,” but the comparator operates on individual extrusion line segments. It canonicalizes a segment direction-independently. So: A -> B and: B -> A have identical geometry but different “start points.” The test currently counts that as a seam mismatch. That means the 372 failures may mostly be segments traversed in the opposite direction, not 372 actual perimeter seams moving. The correct next step is therefore not to modify the scheduler. It is to improve the test so it reconstructs complete perimeter loops and compares the actual first emitted point of each closed loop. And this is another reason I liked Qwen's behavior: because it left the feature disabled, we have room to investigate that properly rather than having already shipped it based on an overstated PASS. My subjective comparison from this project For this particular long-running C++ debugging task, I'd roughly rate them: Category Gemini 3.7 Flash High Qwen 3.8 27B Raw implementation speed ✅ ❌ Building lots of code quickly ✅ ❌ Debugging complicated interactions ❌ ✅ Revising its own hypotheses ❌ ✅ Separating correlation from causation ❌ ✅✅ Test-design skepticism ❌ ✅ Avoiding premature victory ❌ ✅✅ Production conservatism ❌ ✅✅ Trust for this project ❌ ✅ I wouldn't extrapolate this into: "Qwen 3.8 27B is universally smarter than Gemini 3.7 Flash High." This is one project, one agent environment, and one type of task. Gemini was genuinely good at rapidly producing substantial implementation work. But Qwen was noticeably better at scientific debugging. The biggest surprise to me is that the difference showed up less in “can it write C++?” and more in: "Does the model actively try to falsify its own explanation?" On this project, Qwen did. It repeatedly found evidence inconvenient to its own previous conclusion, changed direction, and ultimately refused to declare the feature finished. That's a behavior I did not expect a 27B open-source model to outperform a brand-new closed model at. And for autonomous coding on complicated production software, I think that characteristic may matter more than benchmark scores. Curious if anyone else has compared Qwen 3.8 27B against Gemini 3.7 Flash High, Claude, or GPT models on long-running repo-level debugging rather than one-shot coding benchmarks.