Qwen3-Coder-Next vs Devstral Small 2: local coding

Qwen3-Coder-Next vs Devstral Small 2 should be assessed by the work an agent completes in the repository, not just its chat response. Giallo has not run a comparative test of these checkpoints: we do not claim that either is superior for the quality of your code.

The initial difference concerns sizing. Qwen3-Coder-Next is an MoE with 80B total parameters and 3B active; Devstral Small 2 24B Instruct is a 24B model designed for software engineering, with visual support. These figures, checked against the official cards on 27 October 2026, help prepare a test rather than automatically predict which patch will be correct.

Why is a coding chat insufficient for choosing?

Writing an isolated function differs from fixing a project defect. The agent must find the right files, understand dependencies and conventions, devise a change, run checks and interpret their outcomes. An apparently impressive answer may fail when it encounters an unexpected test command or a library with a changed API.

The first test document should therefore describe the work: short fixes, integration maintenance, component changes or navigation of a large archive. Choosing AI models for programming starts with these tasks. If the team mainly uses AI to explain code, a simple configuration may suffice. If it expects autonomous changes, it must also assess tool use, error recovery and respect for assigned boundaries.

What do 80B total and 3B active parameters mean?

In an MoE, only some experts participate in each step, but this does not make the complete checkpoint disappear from memory. Qwen3-Coder-Next should not be presented as a tiny model based on its active parameter count. Distinguishing total size from per-token computation is essential when deciding where to run it.

An independent weights-only calculation, ideally assuming four bits for each of the 80 billion parameters, gives about 40 decimal GB. This is a theoretical order of magnitude, before metadata and operating memory. Conversions and offloading may change the actual pipeline, which must be documented. The Hugging Face quantization overview helps distinguish precision, hardware and method; it does not replace measurement of the chosen file and runtime.

How should Devstral's hardware guidance be interpreted?

Mistral's Devstral Small 2 card indicates deployment on an RTX 4090 or a Mac with 32 GB. Attribute this reference to the vendor: it does not demonstrate that every configuration works well on a company's repository, with a long context and other programs open.

Before buying hardware, specify weights format, runtime, context length and request count. A developer's computer may simultaneously host an editor, browser, local services and builds. Nominal memory capacity is not the space left for inference. For Mac, the guide to LLMs with 16, 24 or 32 GB explains how to test the workload; on PC, distinguish between RAM and VRAM on Windows.

Which differences should be recorded before testing?

The specifications come from the two official model cards cited. They do not judge Italian-language quality or your own stack. Even a difference in modality may not affect the work: a screenshot helps describe a visual defect, but a verifiable reproduction and test may still be necessary. Image access does not automatically solve browser diagnosis.

Model and agent: which components must stay the same?

To isolate the model's effect, the comparison should keep repository, issue description, available tools and success criteria unchanged. The operating budget must also be explicit: number of attempts, maximum duration and permission to install dependencies. A candidate allowed to work for a long time is not directly comparable with one stopped after its first patch.

Some integrations, however, require different tool-call formats. Document that difference rather than pretend the variable is perfectly isolated. The outcome concerns the complete configuration the team can use. Choosing between Ollama and LM Studio is another decision of this kind: compatibility and observability may matter as much as initial interface convenience.

How can SWE-bench be read without creating a false ranking?

SWE-bench evaluates repository changes based on software issues and provides a reproducible evaluation environment. Dataset variants and execution conditions must be distinguished. A result published for a particular agent does not describe every editor connected to the same weights.

For business comparisons, report benchmarks as context and specify exactly what they measure. Do not add percentages from different datasets or attribute an original version's result to a quantization without testing. The final decision needs an internal sample: defects representative of the stack, with solutions and checks defined in advance. The benchmarking method for local LLMs describes how to keep quality, failures and timings separate.

A scenario: fixing an import in business software

Imagine a team maintaining business software that needs to handle an import file with missing fields. This is a hypothetical example. The agent's brief contains a fictional file, expected behaviour and verification commands. Both candidates work on equivalent project copies, without credentials or production data.

Success means more than accepting the faulty file. The patch must distinguish missing from invalid data, return a clear error and preserve behaviour for cases that already work. Check whether the agent edits unrelated files, hides the error or removes useful validation. A shorter solution may be preferable if it addresses the issue without introducing an entirely new import system. Keep failed attempts too, because they represent real work and risk.

A scenario: understanding a defect shown in a screenshot

A second illustrative case concerns an administration page where a button becomes unreadable. The input includes a screenshot, page path and reproduction conditions. Devstral's visual support can become a requirement to test; with a text-only candidate, some evidence must be converted into a description or another component added.

The evaluation must state this difference. It would be unfair to describe the defect accurately to one model while giving the other an ambiguous image without context. After the change, open the page and check the state that caused the error, including screen size and theme. A correct screenshot does not establish that every interaction works. The agent must produce evidence linked to the requirement, while the reviewer distinguishes the fixed defect from introduced regressions.

Which permissions should the first experiment have?

1. Prepare a repository copy with fictional data and known dependencies.
2. Allow reading and editing only in the necessary folders.
3. Define verification commands and observe every request for additional access.
4. Review the patch before connecting it to real systems or publishing it.

These are proposed design boundaries for the test, not features automatically attributed to either model. The selected environment must be able to enforce them. A prompt instruction can state a rule, but does not create technical isolation on its own.

Tool network access must be checked separately. A model running on the computer can invoke extensions or services that communicate elsewhere. This concerns the entire offline local AI workflow, including installation, diagnostics and documentation searches. A development configuration must make these operations visible and controllable.

What should be measured beyond passing tests?

Tests can pass while a patch remains fragile or disproportionate. An agent might bypass the problematic condition, change the test's expectation or introduce an unnecessary dependency. The record therefore includes a diff review and an explanation linking the change to the defect. The operator must be able to understand why the fix addresses the case.

Separate categories are useful: correct solution, incomplete solution, out-of-scope change, execution error and failure to understand the project. Record review time too. If a patch needs lengthy checking of unrequested changes, its cost is not represented by generation seconds alone. Decorative percentages are unnecessary: stable definitions and traceable cases suffice. The comparison becomes repeatable and can be updated when the stack or requirements change.

How should repository context and information be managed?

Providing the entire project without selection can add noise, consume memory and make it hard to identify which instructions mattered. Start with the issue description, essential structure and file-search access. The model should find references and connect them to behaviour, rather than receive an indiscriminate collection of content.

Project rules must distinguish conventions, verified commands and change constraints. If the repository includes third-party documents or examples containing instructions, the environment must treat them as material to analyse, not authorization. Also measure behaviour when a file is missing or a command fails: stopping with an accurate explanation may be better than inventing an outcome. An agent's quality includes recognizing what it could not verify.

Mistakes that make a fragile project look inexpensive

Considering only active parameters underestimates sizing. Considering only generated tokens ignores review work. Considering only the public benchmark overlooks the actual repository. These mistakes can combine to make a configuration look convincing even though it cannot support everyday work.

Another shortcut is updating the model, editor integration and project libraries simultaneously. If a regression appears, attribution becomes difficult. Record approved versions and change them against a reference test. The goal is not an agent that appears autonomous in a demonstration, but a tool that helps the team within understandable, repeatable boundaries, with recovery when the work fails.

What should accompany the approved configuration?

Users must be able to reproduce the workflow without depending on the person who demonstrated it. Handover includes a component list, required settings, verification sample and an example of a rejected outcome. The latter clarifies when the team should stop the attempt and proceed with normal development.

Persistent sessions also need a rule: which conversations are kept, when to start with a clean context and how to exclude outdated information. An agent remembering an old project structure may suggest a change consistent with the past but wrong today. The team must know how to recognize and correct this without compensating through ever-longer instructions.

Finally, keep the evaluation accessible after adoption. When a colleague finds a regression, they should be able to add the case to the sample and check whether it affects only that version or the entire workflow. Maintaining the test takes work, but prevents every problem becoming a subjective debate about model capability.

From a local trial to a team tool

The final choice may favour the configuration easiest to maintain, even if another looks more ambitious on paper. What matters is completing the required kind of change with sufficient quality and sustainable review. The record must specify permitted tasks, exclusions, hardware, versions and checks required before accepting a patch.

Start with a bounded set of representative defects, without giving the agent deployment responsibilities or production access. If the comparison is to become part of your development process, Giallo Studio builds custom software and can establish the environment, evaluation and operating rules around the actual repository. That workflow turns a downloaded model into practical help for those who write and maintain code.