cs.AIOct 16, 2026
SaveWebCoder: Scaling General Frontend Development with Artifact-Grounded Agentic Reinforcement Learning
Organizations: Tsinghua University · Zhipu AI · Beihang University · University of Oslo
Abstract
Real-world frontend development requires agents to compose reproduction, generation, modification, and repair over an evolving application state. Learning a general policy for this process requires translating heterogeneous execution feedback into task-aligned rewards and effective credit assignment across long sequences of interdependent actions. We introduce WebCoder, a general frontend development agent trained with artifact-grounded agentic reinforcement learning. Our key idea is to assess diverse development activities through their effects on a shared executable artifact and its satisfaction of task requirements. We build Webdev-World, an executable environment that integrates code editing, application execution, browser inspection, and on-demand skills while preserving project state across interactions. An independent verifier evaluates the final application against task requirements to provide terminal rewards, while changes in intermediate artifact progress redistribute the resulting rollout advantage across development segments. Context compaction and message-tree sample construction support training on trajectories beyond a single context window while avoiding repeated loss computation on shared generated history. We further introduce Webdev-Bench to evaluate composed development requirements within a single project. On Webdev-Bench, WebCoder-27B raises requirement satisfaction from 64.8 for its Qwen3.8-27B base model to 72.8, exceeding Claude-Opus-4.8 (65.1) and GPT-5.4 (59.6); on Vision2Web, it improves the average visual and functional score from 41.1 to 62.4, on par with Claude-Opus-4.8. Ablation studies confirm the contributions of artifact-grounded credit assignment and long-horizon training.
Figures & tables
Figure 1: From isolated frontend tasks to general frontend development. (a) Existing work typically studies frontend reproduction, generation, and modification as separate task categories. (b) In real-world development, a single user request often requires multiple capabilities to be composed within a continuous, stateful, and iterative development process, followed by multi-turn and multimodal refinement over the evolving application state.
Figure 2: Overview of our artifact-grounded agentic reinforcement learning framework. WebCoder builds and refines a runnable project in Webdev-World through development tools and on-demand skills; an independent verifier scores the final application against the task checklist, artifact-based potentials redistribute the GRPO rollout advantage across trajectory segments, and an ownership mask assigns each generated token to one training sample.
| Model | Vision2Web | Webdev-Bench | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| VS | FS | Avg | DSR | RS | VS | FS | IS | Avg | DSR | |
| Proprietary Models | ||||||||||
| Claude-Opus-4.8 | 59.1 | 65.9 | 62.5 | 98.5% | 65.1 | 75.0 | 70.7 | 84.1 | 73.7 | 100.0% |
| GPT-5.4 | 51.3 | 64.4 | 57.9 | 97.0% | 59.6 | 72.7 | 70.0 | 81.0 | 70.8 | 100.0% |
| GPT-5 | 23.3 | 64.7 | 44.0 | 98.5% | 53.5 | 64.0 | 65.8 | 74.6 | 64.5 | 100.0% |
| Gemini-3-Pro | 13.3 | 14.6 | 14.0 | 65.2% | 48.0 | 65.8 | 58.5 | 68.5 | 60.2 | 100.0% |
Table 1: Main results on Vision2Web and Webdev-Bench. Vision2Web (L2-frontend, 66 titles) reports the visual score (VS), functional score (FS), their average (Avg), and the delivery success rate (DSR); Webdev-Bench (40 tasks) reports requirement satisfaction (RS) together with its visual (VS), functional (FS), and interaction (IS) components, their average (Avg), and DSR. Undelivered tasks count as in all score columns. Best in bold and second best underlined per column across all models.
Figure 3: Ablation studies of WebCoder on Vision2Web L2. Full model, the two ablated variants, and the base model on (a) VS, (b) FS, (c) Avg, and (d) DSR. Higher is better.
Figure 4: Training dynamics of WebCoder . (a) Evaluation scores on the fixed anchor set. (b) Per-step mean training rewards and centered five-step moving averages, computed separately within each stage. (c) Early and late reward distributions: steps 1–4 versus 11–14 in Stage 1, and steps 18–21 versus 26–29 in Stage 2. Blue and orange shading mark reward thresholds above which the late or the early window, respectively, has the larger fraction of rollouts.
Figure 5: WebCoder on Vision2Web (caplugs) and Webdev-Bench (c22). Left: the reference homepage of caplugs and WebCoder’s render. Right: c22 states after each round, each cropped to the region the requirement changes. R2 tightens the hero and removes the investor row; the first attempt at R3 keeps the five “Why SEDA” parts in the old staggered layout and is rejected by the gate, while the second attempt compacts them into two rows and passes; R4 adds a filterable newsroom below the hero.
Appendix figures & tables29 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 6: Construction (top) and multi-round evaluation (bottom) of Webdev-Bench. During construction, a specification drives a two-agent authoring loop that produces each task together with its hidden checklist. During evaluation, requirements are revealed round by round under a simulated-user gate, and an independent acceptance agent scores the complete application at the end.
Figure 7: Task composition and acceptance scale of Webdev-Bench. (a) Tasks per starting condition, 40 composite tasks in total; the nine repair tasks (green segment) are contained within the existing-project category. (b) Each point is one task, with the number of requirements on the horizontal axis and the number of checklist items on the vertical axis; small horizontal jitter reduces overlap. The benchmark contains 1,125 checklist items in total.
Figure 8: Anatomy of representative task c38, a screenshot-seeded composite task. (a) Initial material: the task’s own full-page reference screenshot of a real website. (b) The four requirements revealed round by round (abridged; later requirements are invisible to the agent when requirement is revealed). (c) Hidden-checklist excerpt with parent requirement, dimension, and weight tags; hidden from the agent throughout and used only at terminal acceptance. Texts are translated from the Chinese originals.
Figure 9: Anatomy of representative task c22, an existing-project task with defect repair. (a) Initial material: the above-the-fold view of the task’s own starting repository (the injected selector-drift defect disables the three PRIMER entries and is invisible in a static screenshot). (b) The five requirements revealed round by round (abridged). (c) Hidden-checklist excerpt, including the repair item, an explicitly regression-tagged item, and coverage items that check that the removed content does not resurface after later modifications. Texts are translated from the Chinese originals.
Figure 10: Context management and training sample selection. (a) Prompt length across interaction turns in an example rollout. Context reduction allows development to continue as the history grows; the dashed line marks the 64k training window. (b) Artifact potential over chronologically ordered candidate paths. Orange markers indicate the six candidates selected for training from 34 paths, retaining the initial and terminal candidates along with selected intermediate candidates.
Figure 11: Message-tree representation . Blue and orange paths show candidates before and after compaction. The dashed arrow denotes the context rewrite.
| Requirement type | Evidence | Verification | Weight |
| Reproduction tasks (reference screenshot) | |||
| Pixel-level fidelity | rendered page vs. reference | deterministic image comparison ( ) | 0.6 |
| Visual fidelity / layout | screenshot | judge, anchored scale | / |
| Content coverage / text match | screenshot | judge, anchored scale | / |
| Render health | screenshot | judge, anchored scale | |
| Generation tasks (textual requirements) | |||
Table 2: Evidence, verification method, and weight of each requirement type in the training reward. Weights of judge dimensions are given as the judge-leg weight times the within-leg dimension weight.
| Item | Configuration |
|---|---|
| Policy initialization | Qwen3.8-27B |
| Training algorithm | GRPO |
| Tasks per training step | 16 |
| Rollouts per task | 8 |
| Learning rate | (constant) |
| Training precision | BF16 |
Table 3: Model initialization and hyperparameter settings for long-horizon RL training.
Figure 12: Trajectory scale and inference token overhead. (a) Distribution of the trajectory-length proxy normalized by the 64k training window across 1,556 rollout sessions. The dashed line marks one window; 97.9% of sessions exceed it. (b) Cache-adjusted token count versus , with one point per session and colors indicating task families. The inset compares the median per-session ratios and before and after subtracting cached input tokens ( and , respectively).
Figure 13: Context compaction and prefix caching. Left: historical inputs are repeatedly prefilled without prefix reuse. Right: matching prefixes are cached, and compaction rebuilds a bounded context. Filled regions indicate input requiring prefill; dashed outlines indicate reused prefixes. The two panels illustrate mechanisms rather than a controlled timing comparison. Turns and bar heights are schematic, not measured; decoding and cache-access costs are not depicted.
Figure 14: Training-side case: renders of the highest- and lowest-reward rollouts of one reproduction task. Panels show the reference design, the rollout with reward , and the rollout with reward , each cropped to the same height from the top of the page and scaled at native aspect ratio.
| Rollout | Visual fidelity | Coverage | Layout | Text match | Render health | Pixel leg | Reward |
|---|---|---|---|---|---|---|---|
| Highest | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 0.920 | 0.952 |
| Lowest | 0.75 | 1.00 | 1.00 | 1.00 | 1.00 | 0.659 | 0.765 |
Table 4: Judge dimension scores and deterministic-leg score for the two rollouts in Figure 14 . Dimension scores are medians of three draws.
Figure 15: Agreement of the acceptance judge across three independent passes. Share of 999 checklist items whose three grades are identical, differ by one adjacent grade, or differ by two or more grades.
| Req. 1 dashboard | Req. 2 search and filters | Req. 3 watch list | Req. 4 sidebar and views | |
| Pass 1 | 5/5 | 6/6 | 5/6 | 5/5 |
| Pass 2 | 5/5 | 6/6 | 5/6 | 5/5 |
| Pass 3 | 5/5 | 6/6 | 5/6 | 5/5 |
Table 5: Evaluation-side consistency case: per-requirement outcome of three acceptance passes on the same artifact. Cells give the number of items graded over the number of items in the requirement.
Figure 16: Evaluation-side contrast case: final-state screenshots of the same task built by two model lines. Panels show the starting repository’s homepage, the WebCoder-27B artifact, and the Gemini-3-Pro artifact, each cropped to the top of the page at the same aspect ratio. WebCoder compacts the five “Why SEDA” parts into two rows of three and two; the Gemini-3-Pro artifact leaves the last two parts staggered below the first row, exceeding the height budget, with the numerals hidden behind the images.
| Model | Requirements 1–5 | RS | Items below grade 3 (grade) |
|---|---|---|---|
| WebCoder-27B | 1, 1, 1, 1, 1 | 1.0 | none |
| Gemini-3-Pro | 1, 1, 0, 0, 0 | 0.4 | five parts in two rows (1), numerals visible with their texts (1), block height within 1400 px (2); pager shown for single-page categories (2); statistics cell linked to the newsroom (1), button style consistency (2) |
Table 6: Per-requirement acceptance outcome and items below grade for the two artifacts in Figure 16 .
Figure 17: Tool-use patterns across training windows in replication tasks:redundant-operation rate, observed skill use, and observed webshot use. Early, Trough, and Recovery correspond to steps 1–4, 8–11, and 12–14, respectively.
Figure 18: (a) Training-policy entropy. (b–d) Frequent words in replication tasks during Early, Trough, and Recovery. Font sizes use a shared square-root mapping of word frequency across all three clouds; color does not encode a statistic.
| Word | Early | Trough | Recovery |
|---|---|---|---|
| look | 63.2 | 125.3 | 89.1 |
| reference | 148.5 | 219.3 | 183.3 |
| check | 60.1 | 85.3 | 84.3 |
| edit | 19.3 | 8.1 | 10.3 |
| run | 42.2 | 31.1 | 37.6 |
Table 7: Selected word frequencies per 10,000 retained words.
Figure 19: A terminal-style excerpt from a recorded rollout. Commands, paths, outputs, and image-omission notices are reproduced from the saved records; orange highlights repeated reads. Read is an agent tool, and the harness lines contain framework feedback. The figure is a typeset transcript, not an original terminal screenshot.
| Model | Webdev-Bench | Item grade-3 rate | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| RS | VS | FS | IS | Avg | DSR | Functional | Coverage | Interaction | Visual | |
| Proprietary Models | ||||||||||
| Claude-Opus-4.8 | 65.1 | 75.0 | 70.7 | 84.1 | 73.7 | 100.0% | 83.6 | 83.3 | 91.6 | 86.1 |
| GPT-5.4 | 59.6 | 72.7 | 70.0 | 81.0 | 70.8 | 100.0% | 83.1 | 85.2 | 91.3 | 84.8 |
| GPT-5 | 53.5 | 64.0 | 65.8 | 74.6 | 64.5 | 100.0% | 81.4 | 80.6 | 86.3 | 77.0 |
| Gemini-3-Pro | 48.0 | 65.8 | 58.5 | 68.5 | 60.2 | 100.0% | 75.2 | 75.9 | 80.3 | 77.7 |
Table 8: Full Webdev-Bench results. The left six columns follow the metrics and ordering of Table 1 ; the right four columns give the item-level grade-3 rate, i.e., the fraction of checklist items of each dimension graded at terminal acceptance (items of undelivered tasks count as grade ). Best in bold, second best underlined.
| Model | Brownfield ( =11) | Replication ( =9) | Text-to-project ( =20) | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RS | VS | FS | IS | RS | VS | FS | IS | RS | VS | FS | IS | |
| Proprietary Models | ||||||||||||
| Claude-Opus-4.8 | 79.5 | 90.9 | 90.0 | 90.9 | 58.9 | 61.1 | 78.3 | 77.8 | 60.0 | 72.5 | 56.7 | 83.2 |
| GPT-5.4 | 71.8 | 75.0 | 87.7 | 95.5 | 55.0 | 71.3 | 66.7 | 74.1 | 55.0 | 72.1 | 61.7 | 76.1 |
| GPT-5 | 59.5 | 65.9 | 86.8 | 74.2 | 37.2 | 50.9 | 46.7 | 61.1 | 57.5 | 68.8 | 62.9 | 80.8 |
| Gemini-3-Pro | 55.0 | 62.1 | 80.5 | 85.6 | 23.3 | 52.8 | 32.2 | 40.7 | 55.3 | 73.8 | 58.3 | 71.6 |
Table 9: Webdev-Bench results by task starting point. Tasks start from an existing repository (brownfield), a reference screenshot (replication), or a textual specification (text-to-project); each cell is the mean over the tasks of that type, with undelivered tasks counted as . Best in bold, second best underlined.
Figure 20: Pairwise human preference for WebCoder-27B against four opponents on the 40-task Webdev-Bench suite. Each row gives the share of the 40 items in which WebCoder wins, ties, or loses.
Figure 21: Vision2Web, caplugs: reference and final renders of seven model lines. Top row shows the homepage, bottom row the product-catalogue page, both cropped from the top. Scores below each column are VS, FS, and their average for the whole six-page title.
Figure 22: Webdev-Bench, c03: final applications of eight model lines and their per-requirement acceptance. Each column shows the full final page after the fifth requirement; the strip below marks each requirement as satisfied (green, all items grade ) or not (red).
Figure 23: Webdev-Bench, c22: every attempt of WebCoder. The first attempt at requirement three is rejected by the simulated-user gate (red frame); the second attempt passes (green frame) and the remaining rounds pass at the first attempt. The box gives the gate’s feedback after the rejected attempt, translated from the original.
Figure 24: Vision2Web, caplugs: all six pages of the WebCoder deliverable. Top row shows the reference screenshots, bottom row the judge-time renders of the served application, cropped from the top.
Figure 25: Webdev-Bench, c15: the WebCoder trajectory on a task graded RS . Panels show the reference design, the first passing state of requirement one (after two gate rejections), the state after requirement two, and the terminal state after requirement four, all cropped to the top region and shown at the same scale.
| Skill | Role |
|---|---|
| Screenshot replication | |
| Pipeline coordination | Coordinates planning, implementation, and validation. |
| Input analysis | Interprets reference inputs and identifies the task mode. |
| Long-image planning | Divides tall screenshots into semantic sections. |
| Flow planning | Models multiple reference views as application states and transitions. |
| Asset processing | Prepares visual assets and selects their representations. |
Table 10: Overview of the skills available to the training agent. Names are shortened for readability.
More in this topic
AI Coding Agents
AI coding agents use language models and software tools to plan, edit, test, and maintain code with varying levels of autonomy.
See all 326 papers