Qwen Code: 26 minutes to a frontend, 48 to acceptance

This started as a fun test on a home PC with an RTX 3090: give local Qwen3.8-27B an empty folder and one sentence through Qwen Code. 26 minutes and 3 seconds later, the folder contained an ambitious ATS dashboard with search, sorting, hiring stages, live intake, a candidate drawer and a mobile layout.

The first version was not ready for acceptance. A loop detector stopped the run before complete browser QA. A later measurement found 251,327 DOM elements and a document 485,065 pixels tall. Two repair sessions brought the page to an acceptable state. Total recorded model time was 48 minutes and 25 seconds.

This is the whole result: the prompt, what Qwen made, what it broke and what the corrections cost. All applicant data is synthetic. It is a home experiment. It was neither client work nor a production-infrastructure test.

The exact prompt

The model ran through Qwen Code at low effort with an advertised 150k context window. It received exactly this:

Build me a polished interactive frontend page for an AI recruitment/ATS product from scratch in this empty folder. I want to see what you can do in one shot. Use the Impeccable skill in overdrive mode, but keep it genuinely usable. Surprise me. Make it runnable locally, responsive, and finish and test it without asking me questions.

There was no wireframe, component list or existing visual system. The vague request deliberately tested how much the model could design and implement on its own. It would be a poor production brief because it says nothing about DOM budgets, accessibility acceptance or behaviour at realistic volume.

What appeared after 26:03

Qwen created four main text files containing 2,028 lines and 79,588 bytes:

The code generated 10,000 artificial candidates. The page filtered and sorted them, simulated incoming applicants, opened detailed records, changed hiring stages and updated pipeline counts. It also included keyboard shortcuts and reduced-motion handling.

That is a useful first artifact from a deliberately weak brief. We evaluate it through the result and time to acceptance, without converting it into a human-productivity claim.

The complete timeline

The table excludes the human time used to write the request, inspect the page and perform independent checks. It also excludes a 0.93-second failed continuation that sent no tokens to the model.

The earlier version of this article incorrectly said repair took longer than generation. The retained summaries show 22:22 of repair work versus 26:03 for generation. The planning number that matters is 48:25 of model time to an accepted result.

Why the virtual list rendered everything

Qwen had attempted to virtualize the applicant list, keeping only visible records in the DOM. The design was reasonable. Two implementation details defeated it:

1. the scroll viewport had no bounded height, so its clientHeight expanded to the height of the complete list;
2. the calculated top position was assigned to a static list item while the inner row button was the absolutely positioned element.

The calculated visible window therefore contained all 8,652 matching applicants. The document reached 485,065 pixels. A normal full-page capture could not finish until the test browser temporarily constrained the layout.

The repair found four more defects

The second request was specific: preserve the design and interactions, remove the thousands of elements, check desktop and mobile, and inspect the console. Qwen Code at medium effort took 14:24. Besides the two virtualization defects, it found four problems absent from the report:

An independent Chromium pass then measured 722 nodes and 15 rows on desktop, and 577 nodes with 10 rows at 390 pixels. The page fit its viewport and had no horizontal overflow.

Geometry passed while the screenshot still looked wrong

The automated check asked whether whole row rectangles overlapped. It did not compare the candidate name and company label inside each cell. On mobile, the stage marker needed 72–84 pixels while its grid column was only 51 pixels wide.

The third request named both visual defects. Qwen changed two CSS rules, but resuming the large session took 7:58 and 20 tool calls. The result was correct and inefficient. A separate small change would have been better placed in a fresh session.

What Qwen actually demonstrated

Three capabilities were clear:

• it turned one sentence and an empty folder into a coherent interactive prototype;
• it traced a problem across CSS sizing, clientHeight, virtual-window calculation and element positioning in a 2,028-line artifact;
• while repairing the reported failure, it found four independent interaction and data defects.

The boundary was equally clear. The 26-minute result was useful for evaluating an idea, but it was not ready for users. A 10,000-record workload, DOM measurements, interaction checks, the console and actual screenshots were all required before acceptance. Recorded model time nearly doubled.

This kind of agent is valuable when it rapidly creates something a team can critique, or takes a precise defect into an isolated copy. It still needs acceptance criteria and a reviewer willing to reject an attractive but broken result.

Already have an agent-generated prototype?

Syntalith can assess it in the same way: preserve the original, select one user journey, run it at realistic volume, measure performance and interactions, then return a defect map and a fixed scope for production work.

The free process scan identifies the flow and risk worth testing. An AI process audit covers acceptance criteria, architecture, plan and fixed quotation. Custom AI applications cover the build when the evidence supports it.

Sanitized measurements from the remaining runs are in the benchmark ledger. The direct client comparison is in Qwen Code, Codex, Claude Code and OpenCode on the same Qwen.