Qwen Code in practice: CSV, pagination and import

Qwen Code on local Qwen3.8-27B handled CSV export and a pagination fix well at medium effort. In a user-import task it passed 12 public tests but only four of five hidden checks because it accepted a blank name or role. That does not disqualify the tool. It explains why deployment decisions need checks the agent cannot see.

We evaluated four ordinary changes in clean copies of small projects. Prompts used natural language, normal tools were available and the sessions had no artificial completion ceiling.

Qwen Code medium results

These are observations from single runs. They do not mean 80% import reliability or promise a response time. They identify a candidate profile for further testing and a missing safeguard.

The requests the agent received

We did not write implementation recipes:

Export: Customers with several tags are showing up more than once in the CSV order export. Fix it under src, keep the existing columns and add a regression test.

Pagination: Filtering works on the first page, but after “load more” entries from other owners appear and matching entries are skipped. Track down the bug in src/activity-store.js and fix it with tests.

Import: Add CSV import for name, email and role. Blank lines are fine, but a bad row or duplicate email must reject the whole file without a partial import. Add tests and update README.

The follow-up changed the contract: an existing email should update name and role, including duplicates earlier in the same file; the operation must remain atomic and return created and updated counts.

These are issue-like prompts. The agent had to discover the CSV separator and cursor contract in the repository. It should have interpreted a blank name or role as a bad row in the data model, but did not. That is the value the hidden case added.

CSV export: medium effort changed the answer

The first task was a small export bug. Public tests did not cover the separator specified in the README. Qwen Code at low effort passed all three public tests but only one of three hidden checks. At medium, it found the written contract and passed every check in 38.24 seconds.

The lesson is not that medium always wins. Low effort can suit a mechanical change with cheap verification. Here, however, shorter reasoning saved 3.47 seconds and left the requested behaviour wrong.

Pagination: compatibility is part of correctness

Qwen Code medium, Codex medium and OpenCode medium all passed the pagination checks. Their scope differed.

• Qwen Code medium made the smallest repair that preserved the existing contract.
• Qwen Code low changed the cursor contract despite passing tests.
• Codex produced a broader, backward-incompatible rewrite.
• OpenCode made a minimal fix and then wandered into unnecessary .git inspection.

Hidden checks could not replace reviewing the diff. A change may be logically correct and still too broad to accept safely.

Import: green public tests hid missing validation

Qwen Code built a working import, documented it and passed the entire existing suite. A fifth hidden check supplied an empty name or role. The implementation accepted it.

Codex scored 5/5 hidden checks on the same task in 212 seconds. OpenCode also scored 5/5 in 89.04 seconds. Qwen Code was not the quality winner in this cell. An honest agent choice cannot come from one logo or an average across unlike tasks.

The Qwen Code follow-up implemented the requested upsert in the same session, but it did not revisit the earlier validation gap. The agent retained useful solution context and retained the debt. That resembles ordinary team work: the next ticket rarely repairs an acceptance criterion no one names.

How to read an agent's output

A reviewer should separate five questions:

1. Does it build, and do public tests pass?
2. Does it satisfy the contract in documentation?
3. Are difficult inputs validated?
4. Is the change the smallest scope that solves the problem?
5. Does the final report match what was actually verified?

An agent can answer four correctly and still produce a change that should not merge. Production use therefore needs deterministic checks and review proportional to impact.

The business metric is accepted work

A coding agent should shorten the path from request to an accepted change without increasing debt or incidents. The useful equation is:

cost per accepted change = agent time
  + infrastructure cost
  + human review time
  + expected rework cost

A slow local model may still pay when it handles bounded work overnight. A fast model can lose money when a senior engineer has to reconstruct every missed contract.

How Syntalith deploys this pattern

We begin with a sample of real tickets, build hidden acceptance criteria and run profiles in isolated repository copies. Then we set tool access, approval gates and escalation rules. The client receives the result even when the local model loses to its current API.

Teams can learn to build these evaluations in the AI-Native course, using their own repository. For an implementation decision, start with the free process scan.

The full protocol is in how to benchmark a local coding agent.