Learning the Loop, Not Just the Page: Execution-Grounded Loop Learning for Web Generation

# Learning the Loop, Not Just the Page: Execution-Grounded Loop Learning for Web Generation
Source: [https://arxiv.org/html/2610.11543](https://arxiv.org/html/2610.11543)
###### Abstract

Functional Web generation is increasingly optimized with executable rewards, yet existing methods largely focus on the quality of the final page and leave the process of diagnosing and repairing imperfect implementations underexplored\. We identify a central challenge in this setting: the Generator and Refiner produce executable artifacts with direct environment rewards, whereas the intermediate Critic influences downstream behavior without a directly executable outcome\. We introduceWebLoop, an execution\-grounded framework that jointly learns generation, critique, and refinement within a shared policy\. WebLoop trains an execution\-free Critic with complementary signals for requirement\-level discriminability and downstream helpfulness, first establishing reliable diagnosis and then introducing consequence\-aware credit, while all three roles are jointly optimized with group\-relative policy learning\. With Qwen3\.5\-9B, WebLoop reaches 41\.5 Overall on WebRise and 38\.9% accuracy on WebGen\-Bench, improving the base model by 11\.3 and 15\.4 points, respectively\. The gains transfer to first\-pass generation, persist at 27B scale, and generalize from text\-only training to multimodal inputs\. Controlled analyses further show that the improvement cannot be explained by an additional refinement pass alone, highlighting the importance of learning the Critic and the loop itself\.

00footnotetext:∗Equal contribution\.
†Corresponding authors\.
Under Review\.## 1Introduction

Large language models are rapidly moving Web generation from page\-level code synthesis toward*functional Web generation*, where models must not only produce complete HTML/CSS/JavaScript but also satisfy natural\-language requirements through correct interactions, state transitions, and persistent behaviors\([Lu et al\., 2025b](https://arxiv.org/html/2610.11543#bib.bib1);[Meng et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib2)\)\. Unlike conventional code or text generation, generated Web pages are directly executable, allowing functional correctness to be verified through browser interactions and further optimized with reinforcement learning\([Jiang et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib3);[Chen et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib4)\)\. However, existing execution\-based learning remains largely outcome\-centric: it optimizes what the model ultimately generates, while paying considerably less attention to how the model should diagnose and repair an already imperfect implementation\. In practical Web development, first\-pass generation is rarely the end of the process, and*reliable diagnosis and revision are equally critical to producing a functional page*\.

A natural direction is self\-critique and refinement, where models inspect their own outputs and use the resulting feedback to guide subsequent revisions\([Madaan et al\., 2023](https://arxiv.org/html/2610.11543#bib.bib5);[Shinn et al\., 2023](https://arxiv.org/html/2610.11543#bib.bib6);[Gou et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib7);[Chen et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib8)\), with related paradigms increasingly adopted in Web generation\([Lu et al\., 2025a](https://arxiv.org/html/2610.11543#bib.bib9);[Li et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib10)\)\. As shown in[Fig\.1](https://arxiv.org/html/2610.11543#S1.F1), execution supervision is typically used either to directly optimize generated Web pages, as in generation\-only RL \([Fig\.1](https://arxiv.org/html/2610.11543#S1.F1)\(a\)\), or as external feedback for iterative editing \([Fig\.1](https://arxiv.org/html/2610.11543#S1.F1)\(b\)\)\. Neither formulation directly addresses how to optimize an intermediate Critic that guides subsequent refinement\. From a reinforcement learning perspective, this introduces an*intermediate credit\-assignment problem*: the Generator and Refiner produce executable artifacts and receive direct environment rewards, whereas the Critic influences downstream behavior without a directly executable outcome\. An effective Critic must therefore learn both*discriminability*, which identifies satisfied and violated requirements, and*helpfulness*, which reflects whether its feedback improves subsequent refinement\. Since accurate diagnosis does not necessarily lead to effective repair, the central challenge is how to assign reliable RL credit to the Critic from verifiable execution outcomes\.

![Refer to caption](https://arxiv.org/html/2610.11543v1/teaser_v34.png)Figure 1:Conceptual comparison of execution\-based learning paradigms for functional Web generation\.\(a\) Generation\-only RL optimizes executable outputs directly\. \(b\) Execution\-guided RL feeds external feedback back into the code policy\. \(c\) WebLoop jointly learns Generator, Critic, and Refiner, assigning execution\-derived credit to the intermediate Critic\.To address this challenge, we introduceWebLoop, an execution\-grounded loop learning framework shown in[Fig\.1](https://arxiv.org/html/2610.11543#S1.F1)\(c\)\. WebLoop jointly optimizes Generator, Critic, and Refiner as interdependent roles of a shared policy\. The Generator first produces a candidate page and receives functional rewards from browser execution\. The Critic then evaluates the task requirements and candidate source code without access to test results or execution traces\. Conditioned on this critique, the Refiner revises the implementation and is evaluated in the same browser environment\. WebLoop trains the Critic with two complementary signals: requirement\-level execution labels supervise its discriminability, while the execution improvement induced by subsequent refinements measures its helpfulness\. We first establish reliable diagnostic behavior and then introduce downstream improvement for consequence\-aware optimization, while all three roles form separate comparison groups for group\-relative advantage estimation and are jointly optimized through GRPO\. The Critic therefore remains*execution\-free*during inference while receiving execution\-derived retrospective credit during training, turning a fixed self\-refinement pipeline into a learnable RL loop\.

We evaluate WebLoop on functional Web generation benchmarks across model scales and input modalities\. With Qwen3\.5\-9B, WebLoop reaches 41\.5 Overall on WebRise and 38\.9% accuracy on WebGen\-Bench, improving the corresponding base model by 11\.3 and 15\.4 points, respectively\. The gains transfer to first\-pass generation, persist at the 27B scale, and generalize from text\-only training to Markdown, Sketch, Image, and Video inputs\. Controlled ablations further show that the improvement cannot be attributed to an additional refinement pass alone: joint loop optimization consistently outperforms staged alternatives, while the Critic benefits from complementary discriminability and downstream helpfulness signals with staged credit assignment\.

Our contributions are threefold\. \(1\) We formulate functional Web self\-refinement as a structured reinforcement learning problem and identify intermediate Critic credit assignment as a central challenge under asymmetric reward observability\. \(2\) We propose WebLoop, which learns an execution\-free Critic through complementary discriminability and helpfulness signals and jointly optimizes the Generator, Critic, and Refiner through group\-relative policy learning\. \(3\) We conduct controlled evaluations across Web benchmarks, model scales, and input modalities, demonstrating consistent gains over generation\-only and refinement\-only alternatives and validating the role of Critic learning and loop\-level optimization\.

## 2Related Work

Functional Web Generation and Execution\-Based Learning\.Web generation has evolved from reconstructing interfaces from screenshots or visual specifications toward generating complete and interactive Web applications\. Early and concurrent work studies large\-scale screenshot\-to\-code learning and front\-end reconstruction through datasets and benchmarks such as WebSight, Design2Code, and Web2Code\([Laurençon et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib12);[Si et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib13);[Yun et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib14)\), while FrontendBench further emphasizes executable evaluation for realistic front\-end development\([Zhu et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib15)\)\. More recent benchmarks shift the focus from visual fidelity toward functional correctness, using interaction traces, state transitions, and requirement\-level tests to evaluate generated websites\([Lu et al\., 2025b](https://arxiv.org/html/2610.11543#bib.bib1);[Meng et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib2)\)\. This verifiability has also enabled reinforcement learning for Web generation\. WebGen\-R1 and WebGrader optimize Web policies with executable rewards or programmatic graders\([Jiang et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib3);[Chen et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib4)\), while WebGen\-Agent incorporate iterative interaction or rendering feedback into step\-wise Web optimization\([Lu et al\., 2025a](https://arxiv.org/html/2610.11543#bib.bib9)\)\. These methods establish execution as an effective signal for optimizing Web artifacts\. In contrast, WebLoop further uses executable outcomes to assign learning credit to the intermediate critique that determines how an imperfect artifact is subsequently revised\.

Critique\-Guided Refinement and Self\-Improvement\.A broad line of work improves model outputs through self\-generated feedback, reflection, verification, or tool\-assisted correction\([Madaan et al\., 2023](https://arxiv.org/html/2610.11543#bib.bib5);[Shinn et al\., 2023](https://arxiv.org/html/2610.11543#bib.bib6);[Gou et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib7);[Chen et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib8)\)\. Since intrinsic self\-correction is often unreliable, later work explicitly trains correction, evaluation, or critic behavior with supervised or reinforcement signals\([Huang et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib16);[Kumar et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib17);[McAleese et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib18);[Wang et al\., 2024](https://arxiv.org/html/2610.11543#bib.bib19)\)\. More recent methods optimize critiques according to the quality of their induced revisions, with RCO\([Yu et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib20)\)and Critique\-RL\([Xi et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib11)\)directly connecting critic learning to downstream refinement and staged critic optimization\. Similar ideas have entered Web generation, where WebGen\-Agent\([Lu et al\., 2025a](https://arxiv.org/html/2610.11543#bib.bib9)\)and ReLook\([Li et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib10)\)use external or multimodal feedback to support iterative revision\. WebLoop instead learns an execution\-free Critic from requirement\-level diagnosis and downstream execution gains, while jointly optimizing Generator, Critic, and Refiner within a shared policy\.

## 3WebLoop: Learning the Generation–Critique–Refinement Loop

As shown in[Fig\.2](https://arxiv.org/html/2610.11543#S3.F2), WebLoop organizes generation, critique, and refinement into a sequential loop implemented by a shared policy\. Executable outputs are directly grounded by browser evaluation, while the intermediate critique conditions subsequent refinement\.

![Refer to caption](https://arxiv.org/html/2610.11543v1/pipeline_v3.png)Figure 2:Overview of our WebLoop framework\.A shared policy sequentially acts as Generator, Critic, and Refiner\. The Generator and Refiner produce executable Web pages evaluated in the same browser environment, while the execution\-free Critic guides subsequent refinement and receives training credit from its diagnosis and downstream effects\.### 3\.1Loop Formulation and Execution Rewards

Generator–Critic–Refiner loop\.Letx=\(d,ℛx\)x=\(d,\\mathcal\{R\}\_\{x\}\)denote a Web generation task, whereddis the natural\-language description andℛx=\{rq\}q=1Qx\\mathcal\{R\}\_\{x\}=\\\{r\_\{q\}\\\}\_\{q=1\}^\{Q\_\{x\}\}contains its functional requirements\. WebLoop uses a shared policyπθ\\pi\_\{\\theta\}to instantiate three roles under different conditioning contexts\. The Generator maps the task to a complete initial HTML implementationThe Critic inspects an imperfect implementation against the task requirements and produces requirement\-level judgments and repair guidance\. The Refiner conditions on the task, the current implementation, and the critique to generate a complete revised HTML implementation\.

Letpgenp\_\{\\mathrm\{gen\}\},pcritp\_\{\\mathrm\{crit\}\}, andprefp\_\{\\mathrm\{ref\}\}denote the corresponding prompt construction functions, and letπθold\\pi\_\{\\theta\_\{\\mathrm\{old\}\}\}denote the rollout policy\. For each task, WebLoop samples the three stages as

yi\(1\)\\displaystyle y\_\{i\}^\{\(1\)\}∼πθold\(⋅∣pgen\(x\)\),\\displaystyle\\sim\\pi\_\{\\theta\_\{\\mathrm\{old\}\}\}\\big\(\\cdot\\mid p\_\{\\mathrm\{gen\}\}\(x\)\\big\),i=1,…,ng,\\displaystyle i=1,\\ldots,n\_\{g\},\(1\)cj\\displaystyle c\_\{j\}∼πθold\(⋅∣pcrit\(x,yb\)\),\\displaystyle\\sim\\pi\_\{\\theta\_\{\\mathrm\{old\}\}\}\\big\(\\cdot\\mid p\_\{\\mathrm\{crit\}\}\(x,y\_\{b\}\)\\big\),j=1,…,nc,\\displaystyle j=1,\\ldots,n\_\{c\},yj,k\(2\)\\displaystyle y\_\{j,k\}^\{\(2\)\}∼πθold\(⋅∣pref\(x,yb,cj\)\),\\displaystyle\\sim\\pi\_\{\\theta\_\{\\mathrm\{old\}\}\}\\big\(\\cdot\\mid p\_\{\\mathrm\{ref\}\}\(x,y\_\{b\},c\_\{j\}\)\\big\),k=1,…,nr,\\displaystyle k=1,\\ldots,n\_\{r\},whereyby\_\{b\}denotes the imperfect base implementation selected from the initial generations\. The Generator and Refiner therefore produce executable artifacts, whereas the Critic produces an intermediate feedback decision that changes the conditional distribution of subsequent refinements\.

Execution reward\.Both initial and refined implementations are evaluated by the same browser environment\. Following WebRISE\([Meng et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib2)\), each task is associated with an Interaction Contract Graph𝒢x\\mathcal\{G\}\_\{x\}that specifies browser interactions and functional assertions\. Executing a pageyyreturns

ℰ⁡\(y,𝒢x\)=\(T⁡\(y\),Re​\(y\),Ri​\(y\),𝐳⁡\(y\)\),\\mathcal\{E\}\(y;\\mathcal\{G\}\_\{x\}\)=\\big\(T\(y\),R\_\{\\mathrm\{e\}\}\(y\),R\_\{\\mathrm\{i\}\}\(y\),\\mathbf\{z\}\(y\)\\big\),\(2\)whereT⁡\(y\)T\(y\)denotes transition validity,Re​\(y\)R\_\{\\mathrm\{e\}\}\(y\)andRi​\(y\)R\_\{\\mathrm\{i\}\}\(y\)denote explicit and implicit requirement coverage, and𝐳⁡\(y\)∈\{0,1\}Qx\\mathbf\{z\}\(y\)\\in\\\{0,1\\\}^\{Q\_\{x\}\}contains requirement\-level execution labels\. We define the page\-level execution reward as

rweb​\(y\)=0\.50​T​\(y\)\+0\.25​Re​\(y\)\+0\.25​Ri​\(y\)\.r\_\{\\mathrm\{web\}\}\(y\)=0\.50T\(y\)\+0\.25R\_\{\\mathrm\{e\}\}\(y\)\+0\.25R\_\{\\mathrm\{i\}\}\(y\)\.\(3\)Both Generator and Refiner outputs are optimized withrwebr\_\{\\mathrm\{web\}\}, placing the two executable endpoints in the same reward space\. This shared objective allows the behavioral change before and after critique to be measured directly\.

Critique\-conditioned branching\.After evaluating the initial generations, we select the median\-reward candidate among valid but imperfect implementations as the shared base draftyby\_\{b\}\. All critiques are sampled from the same\(x,yb\)\(x,y\_\{b\}\)context, which removes variation caused by different starting implementations\. Importantly, the Critic observes only the task requirements and the source code ofyby\_\{b\}, without access to browser results or execution traces\. Each critiquecjc\_\{j\}then conditionsnrn\_\{r\}independent refinements, and every refined page is evaluated under the same execution objective\. Multiple refinements under the same critique provide a more robust estimate of how effectively the current Refiner can act on that feedback\. If no valid imperfect draft exists, the task contributes only its initial\-generation samples\. Further details are provided in[Sec\.A\.2](https://arxiv.org/html/2610.11543#A1.SS2)\.

This construction gives direct environment rewards to the Generator and Refiner, while the intermediate Critic has no directly executable outcome\. We next assign Critic credit using requirement\-level diagnosis and downstream refinement effects\.

### 3\.2Credit Assignment for the Critic

Unlike the executable Generator and Refiner outputs, a critique has no direct browser outcome from which to obtain an environment reward\. Following the critic decomposition in Critique\-RL\([Xi et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib11)\), we distinguish two complementary properties of a critique:*discriminability*, which measures whether it correctly diagnoses the current implementation, and*helpfulness*, which measures whether acting on it improves downstream execution\. WebLoop grounds these two properties with requirement\-level browser labels and executable refinement outcomes, respectively\.

Execution\-free critique\.For the selected base draftyby\_\{b\}, the Critic receives only the task requirements and source code throughpcrit​\(x,yb\)p\_\{\\mathrm\{crit\}\}\(x,y\_\{b\}\)\. It predicts whether each explicit requirement is satisfied and provides corresponding repair guidance\. Importantly, browser results, requirement labels, and execution traces are never exposed to the Critic as input\. Execution is instead used only to construct training signals, requiring the Critic to infer functional failures directly from the specification and implementation\.

Diagnostic discriminability\.Letzq∈\{0,1\}z\_\{q\}\\in\\\{0,1\\\}denote the execution\-grounded label for requirementrqr\_\{q\}, wherezq=1z\_\{q\}=1only if all corresponding assertions are satisfied\. For critiquecjc\_\{j\}, letz^j,q\\hat\{z\}\_\{j,q\}denote its predicted requirement status\. We define the failed and satisfied requirement sets as

ℱ=\{q:zq=0\},𝒫=\{q:zq=1\}\.\\mathcal\{F\}=\\\{q:z\_\{q\}=0\\\},\\qquad\\mathcal\{P\}=\\\{q:z\_\{q\}=1\\\}\.\(4\)To avoid bias toward the majority class, we measure diagnostic discriminability using balanced class\-wise accuracy,

D⁡\(cj\)=afail​\(cj\)\+apass​\(cj\)−1,D\(c\_\{j\}\)=a\_\{\\mathrm\{fail\}\}\(c\_\{j\}\)\+a\_\{\\mathrm\{pass\}\}\(c\_\{j\}\)\-1,\(5\)whereafaila\_\{\\mathrm\{fail\}\}andapassa\_\{\\mathrm\{pass\}\}denote the prediction accuracies overℱ\\mathcal\{F\}and𝒫\\mathcal\{P\}, respectively\. When only one class is present, we linearly rescale its accuracy to the same\[−1,1\]\[\-1,1\]range\. Thus,D⁡\(cj\)D\(c\_\{j\}\)measures whether the Critic correctly distinguishes satisfied from violated requirements independently of downstream refinement\.

Retrospective helpfulness\.Diagnostic correctness alone does not indicate whether a critique can actually guide an effective repair\. For each critiquecjc\_\{j\}, we therefore estimate its downstream utility from thenrn\_\{r\}refinements conditioned on it:

H⁡\(cj\)=1nr​∑k=1nrrweb​\(yj,k\(2\)\)−rweb​\(yb\)\.H\(c\_\{j\}\)=\\frac\{1\}\{n\_\{r\}\}\\sum\_\{k=1\}^\{n\_\{r\}\}r\_\{\\mathrm\{web\}\}\\big\(y\_\{j,k\}^\{\(2\)\}\\big\)\-r\_\{\\mathrm\{web\}\}\(y\_\{b\}\)\.\(6\)A positiveH⁡\(cj\)H\(c\_\{j\}\)indicates that refinements conditioned on the critique outperform the original implementation on average\. Using multiple refinements reduces sensitivity to a single stochastic regeneration and measures the practical utility of the critique under the current Refiner\. WhileD⁡\(cj\)D\(c\_\{j\}\)captures what the Critic understands,H⁡\(cj\)H\(c\_\{j\}\)captures what happens when its feedback is acted upon\.

Staged critic credit\.Inspired by the two\-stage optimization principle of Critique\-RL\([Xi et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib11)\), we first establish reliable discriminability before introducing downstream helpfulness\. This separation is particularly important in WebLoop because helpfulness is a delayed signal that depends jointly on the critique and the current Refiner, whereas discriminability can be directly grounded by requirement\-level execution labels\. At update stepmm, we define the Critic reward as

rcrit\(m\)​\(cj\)=\{D⁡\(cj\),m≤15,H⁡\(cj\)\+λ​D​\(cj\),m\>15,r\_\{\\mathrm\{crit\}\}^\{\(m\)\}\(c\_\{j\}\)=\\begin\{cases\}D\(c\_\{j\}\),&m\\leq 15,\\\\ H\(c\_\{j\}\)\+\\lambda D\(c\_\{j\}\),&m\>15,\\end\{cases\}\(7\)whereλ\\lambdacontrols the contribution of diagnostic discriminability in the second stage\. RetainingD⁡\(cj\)D\(c\_\{j\}\)prevents downstream improvement from serving as a substitute for correct diagnosis, whileH⁡\(cj\)H\(c\_\{j\}\)encourages feedback that can be effectively acted upon by the Refiner\. This schedule prevents downstream improvement from serving as a substitute for correct diagnosis while gradually introducing consequence\-aware credit\. The resulting scalar reward allows critique samples to participate in policy optimization while preserving their distinct reward semantics from executable Web outputs\. Complete reward definitions are provided in[Sec\.A\.2](https://arxiv.org/html/2610.11543#A1.SS2)\.

### 3\.3Joint Group\-Relative Optimization

WebLoop produces three types of policy outputs with different conditioning contexts and reward semantics\. We therefore construct role specific comparison groups for advantage estimation, and then jointly optimize all outputs under the shared policy\.

Role specific comparison groups\.For each task, Generator outputs are compared under the same task, Critic outputs under the same base draft, and Refiner outputs under the same critique\. Specifically, we define

Ggen​\(x\)=\{yi\(1\)\}i=1ng,Gcrit​\(x,yb\)=\{cj\}j=1nc,Gref,j​\(x,yb,cj\)=\{yj,k\(2\)\}k=1nr\.G\_\{\\mathrm\{gen\}\}\(x\)=\\\{y\_\{i\}^\{\(1\)\}\\\}\_\{i=1\}^\{n\_\{g\}\},\\quad G\_\{\\mathrm\{crit\}\}\(x,y\_\{b\}\)=\\\{c\_\{j\}\\\}\_\{j=1\}^\{n\_\{c\}\},\\quad G\_\{\\mathrm\{ref\},j\}\(x,y\_\{b\},c\_\{j\}\)=\\\{y\_\{j,k\}^\{\(2\)\}\\\}\_\{k=1\}^\{n\_\{r\}\}\.\(8\)The corresponding rewards arerwebr\_\{\\mathrm\{web\}\}for Generator and Refiner outputs andrcritr\_\{\\mathrm\{crit\}\}for Critic outputs\. For any outputoowith comparison groupg⁡\(o\)g\(o\), we compute the group relative advantage as

Ao=r⁡\(o\)−μg⁡\(o\)σg⁡\(o\)\+ϵnorm,A\_\{o\}=\\frac\{r\(o\)\-\\mu\_\{g\(o\)\}\}\{\\sigma\_\{g\(o\)\}\+\\epsilon\_\{\\mathrm\{norm\}\}\},\(9\)whereμg⁡\(o\)\\mu\_\{g\(o\)\}andσg⁡\(o\)\\sigma\_\{g\(o\)\}are the reward mean and standard deviation within its group\. This grouping keeps each comparison local to outputs generated under the same decision context, while preserving the distinct credit semantics of the three roles\.

Joint policy update\.After advantage estimation, Generator, Critic, and Refiner samples are merged into a single optimization batch𝒪\\mathcal\{O\}\. For an outputoowith conditioning contextuou\_\{o\}, the token level probability ratio is

ρo,t​\(θ\)=πθ​\(ot∣uo,o<t\)πθold​\(ot∣uo,o<t\)\.\\rho\_\{o,t\}\(\\theta\)=\\frac\{\\pi\_\{\\theta\}\(o\_\{t\}\\mid u\_\{o\},o\_\{<t\}\)\}\{\\pi\_\{\\theta\_\{\\mathrm\{old\}\}\}\(o\_\{t\}\\mid u\_\{o\},o\_\{<t\}\)\}\.\(10\)We optimize the shared policy with the clipped GRPO objective

ℒGRPO\(θ\)=−1Ntok∑o∈𝒪∑t=1\|o\|min\(ρo,t\(θ\)Ao,clip\(ρo,t\(θ\),1−ϵclip,1\+ϵclip\)Ao\),\\mathcal\{L\}\_\{\\mathrm\{GRPO\}\}\(\\theta\)=\-\\frac\{1\}\{N\_\{\\mathrm\{tok\}\}\}\\sum\_\{o\\in\\mathcal\{O\}\}\\sum\_\{t=1\}^\{\|o\|\}\\min\\Big\(\\rho\_\{o,t\}\(\\theta\)A\_\{o\},\\operatorname\{clip\}\\big\(\\rho\_\{o,t\}\(\\theta\),1\-\\epsilon\_\{\\mathrm\{clip\}\},1\+\\epsilon\_\{\\mathrm\{clip\}\}\\big\)A\_\{o\}\\Big\),\(11\)whereNtokN\_\{\\mathrm\{tok\}\}is the number of valid output tokens in the batch\. Therefore, group structure assigns role\-specific relative credit, while all three roles jointly update the shared policy\. WebLoop is therefore sequential in rollout, role\-specific in credit assignment, and joint in optimization\.

### 3\.4Executable Training Data Construction

We construct executable Web generation tasks that pair natural\-language specifications with browser\-based functional supervision for WebLoop training\.

Task scope\.The corpus covers diverse Web applications, including e\-commerce, office productivity, education, developer tools, and data analytics\. Across these domains, we instantiate functional scenarios involving core operations, management functions, user settings, data presentation, and multi\-step workflows\.

Construction pipeline\.For each scenario, we construct explicit requirements that specify functions and interaction entry points, together with implicit requirements covering behavioral constraints such as state consistency, operation ordering, boundary handling, and reset behavior\. Motivated by WebRISE, we convert these requirements into an initial\-state contract and an executable Interaction Contract Graph \(ICG\) containing browser interactions and functional assertions\. We then generate a reference implementation, execute the associated tests in a real browser, and retain tasks with transition validityT≥0\.60T\\geq 0\.60\. Further construction details are provided in[AppendixB](https://arxiv.org/html/2610.11543#A2)\.

Dataset statistics\.The resulting corpus contains 2,880 tasks across 21 domains and 1,442 scenarios, with 11\.87 requirements per task on average: 5\.47 explicit and 6\.39 implicit, with implicit requirements accounting for 53\.9%\. The ICGs average 10\.64 states, 11\.40 transitions, and 28\.15 executable assertions, enabling fine\-grained functional supervision\.

## 4Experiments

### 4\.1Experimental Setup

Benchmarks and metrics\.We evaluate functional correctness on WebRise\([Meng et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib2)\)and WebGen\-Bench\([Lu et al\., 2025b](https://arxiv.org/html/2610.11543#bib.bib1)\)\. WebRise contains 442 tasks and reports transition validityTT, explicit requirement coverageReR\_\{\\mathrm\{e\}\}, implicit requirement coverageRiR\_\{\\mathrm\{i\}\}, and their average Overall score\. For consistent comparison, all controlled training uses Text\-conditioned tasks, and the main WebRise results are evaluated under the Text modality\. WebGen\-Bench contains 101 website tasks with 647 functional test items, and we use the Bolt\.diy framework with automatic starter\-template selection disabled to generate websites from an empty workspace\. Following the official protocol, we report Yes, Partial, No, Start\-Fail, and Accuracy\. “N/A” indicates that model outputs could not be parsed by the harness due to incompatible output formatting\.

Baselines\.We compare against representative general\-purpose models, including Qwen3\.5\-122B\-A10B and Qwen3\.5\-397B\-A17B\([Qwen Team, 2026](https://arxiv.org/html/2610.11543#bib.bib21)\), Kimi\-K2\.6\([Moonshot AI, 2026](https://arxiv.org/html/2610.11543#bib.bib22)\), GLM\-5\.3\([GLM\-5 Team, 2026](https://arxiv.org/html/2610.11543#bib.bib23)\), Claude Opus 4\.7\([Anthropic, 2026](https://arxiv.org/html/2610.11543#bib.bib24)\), Gemini 3\.1 Pro\([Google DeepMind, 2026](https://arxiv.org/html/2610.11543#bib.bib25)\), and GPT\-6 Astra\([OpenAI, 2026](https://arxiv.org/html/2610.11543#bib.bib26)\)\. We also include Web\-generation specialized models, including WebGen\-LM\([Lu et al\., 2025b](https://arxiv.org/html/2610.11543#bib.bib1)\), WebGen\-Agent\([Lu et al\., 2025a](https://arxiv.org/html/2610.11543#bib.bib9)\), and UIGEN\-T2\([tesslate, 2024](https://arxiv.org/html/2610.11543#bib.bib28)\)\. For controlled same\-backbone comparisons, we evaluate the original Qwen3\.5 model, Generate–Critique–Refine without RL, and alternative critique\-learning methods Critique\-GRPO\([Zhang et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib27)\)and Critique\-RL\([Xi et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib11)\)\. Throughout the paper, “Gen” denotes the first\-pass code produced by the Generator of the trained checkpoint, while “Refine” denotes the revised code after one complete Generator–Critic–Refiner loop from the same checkpoint\.

Models and training\.We instantiate WebLoop with Qwen3\.5\-9B and Qwen3\.5\-27B, with all controlled ablations conducted on the 9B model\. Training uses 3K text\-conditioned Web generation tasks with a task batch size of 64\. For each task, we sample three initial generations, three critiques for the selected imperfect draft, and three refinements per critique, yielding 12 executable Web candidates per rollout\. The Critic is trained with discriminability alone for the first 15 updates and then with the combined discriminability and helpfulness reward usingλ=0\.2\\lambda=0\.2\. Unless otherwise stated, Generator, Critic, and Refiner samples are jointly optimized with GRPO\. Further training, rollout, and optimization details are provided in[AppendixA](https://arxiv.org/html/2610.11543#A1)\.

### 4\.2Main Results

Table 1:Main results on WebRise and WebGen\-Bench\.General\-purpose and Web\-generation specialized models are included as capability references, while the Qwen3\.5 block provides controlled comparisons\.Bolddenotes the best result within each reference group or controlled backbone size according to the metric direction\.†denotes proprietary models\.Model / MethodWebRiseWebGen\-BenchTT↑\\uparrowReR\_\{e\}↑\\uparrowRiR\_\{i\}↑\\uparrowOverall↑\\uparrowYes \(%\)↑\\uparrowPartial \(%\)↑\\uparrowNo \(%\)↓\\downarrowStart\-Fail \(%\)↓\\downarrowAcc\.↑\\uparrowGeneral\-Purpose Models \(Open\-Source & Proprietary\)Qwen3\.5\-122B\-A10B38\.048\.935\.240\.79\.96\.278\.15\.913\.0Kimi\-K2\.644\.654\.241\.846\.925\.711\.155\.37\.931\.2Qwen3\.5\-397B\-A17B45\.757\.242\.848\.616\.19\.170\.04\.820\.6GLM\-5\.359\.577\.154\.963\.820\.611\.967\.50\.026\.5Claude Opus 4\.7†48\.857\.645\.850\.747\.415\.835\.51\.255\.3Gemini 3\.1 Pro†50\.761\.147\.553\.140\.212\.547\.00\.346\.4GPT\-6 Astra†62\.578\.957\.766\.437\.211\.949\.51\.443\.2Web\-Generation Specialized ModelsWebGen\-LM\-7B5\.517\.76\.19\.82\.82\.094\.11\.13\.8WebGen\-Agent\-7B \(Step\-GRPO\)5\.823\.76\.912\.11\.97\.190\.60\.55\.4WebGen\-LM\-32B6\.013\.45\.48\.32\.61\.495\.80\.23\.3UIGEN\-T2\-7B12\.133\.011\.118\.7N/AN/AN/AN/AN/AWebGen\-LM\-14B15\.335\.514\.521\.82\.91\.194\.31\.73\.5Controlled Comparisons: Qwen3\.5Base \(Qwen3\.5\-9B\)23\.245\.322\.130\.218\.410\.267\.14\.323\.5Generate–Critique–Refine \(w/o RL\)25\.847\.924\.632\.826\.39\.659\.24\.931\.1Critique\-GRPO27\.650\.026\.234\.613\.48\.376\.71\.517\.6Critique\-RL26\.948\.825\.633\.824\.18\.862\.05\.128\.5WebLoop\(Gen\)31\.755\.430\.039\.128\.710\.856\.93\.634\.2WebLoop\(Refine\)34\.657\.932\.041\.531\.714\.448\.45\.638\.9Base \(Qwen3\.5\-27B\)36\.347\.334\.339\.324\.311\.062\.12\.629\.8Generate–Critique–Refine \(w/o RL\)40\.563\.137\.647\.132\.611\.053\.82\.638\.1WebLoop\(Gen\)43\.866\.640\.150\.226\.013\.060\.90\.232\.5WebLoop\(Refine\)46\.168\.042\.752\.236\.013\.650\.20\.242\.8

Functional Web generation\.[Table1](https://arxiv.org/html/2610.11543#S4.T1)shows that WebLoop consistently improves functional correctness across both backbone sizes and benchmarks\. With Qwen3\.5\-9B, WebLoop \(Refine\) reaches 41\.5 Overall on WebRise and 38\.9% accuracy on WebGen\-Bench, improving the base model by 11\.3 and 15\.4 points and surpassing Qwen3\.5\-122B\-A10B on both benchmarks\. At 27B, WebLoop further reaches 52\.2 and 42\.8%, outperforming Qwen3\.5\-397B\-A17B and the 1T\-parameter Kimi\-K2\.6 despite a substantially smaller total parameter footprint\. It also approaches proprietary frontier models, trailing Gemini 3\.1 Pro by only 0\.9 points on WebRise and 3\.6 points on WebGen\-Bench, and GPT\-6 Astra by 0\.4 points on WebGen\-Bench\.

First\-pass generation and model scaling\.As shown in[Table1](https://arxiv.org/html/2610.11543#S4.T1), WebLoop improves both first\-pass generation and final refinement\. WebLoop \(Gen\) raises Qwen3\.5\-9B from 30\.2 to 39\.1 on WebRise and from 23\.5% to 34\.2% on WebGen\-Bench\. These gains indicate that loop\-level training strengthens the underlying generation policy itself, rather than benefiting only critique\-conditioned revision\. At 27B, the corresponding gains are 39\.3 to 50\.2 and 29\.8% to 32\.5%, respectively\. The complete loop further reaches 52\.2 and 42\.8%, showing that the benefits persist with model scaling and continue to compound through refinement\.

Table 2:Cross\-modal generalization on WebRise\.WebLoop is trained only on Text\-conditioned tasks and evaluated on all five input modalities using the same checkpoint\.Avg\.averages the modality\-level\(T\+Re\+Ri\)/3\(T\+R\_\{e\}\+R\_\{i\}\)/3scores\.Generalization across input modalities\.[Table2](https://arxiv.org/html/2610.11543#S4.T2)evaluates whether Text\-only WebLoop training transfers to other input modalities\. The average WebRise score improves from 31\.9 for the base model to 37\.5 for WebLoop \(Gen\) and 40\.1 after the complete loop, with consistent gains across Text, Markdown, Sketch, Image, and Video\. The improvements also span all three functional metrics, demonstrating that the learned generation and refinement capabilities generalize beyond the text\-conditioned training distribution\.

## 5Analysis and Discussion

Table 3:Where does the gain come from?Controlled comparison of training schemes on WebRise and WebGen\-Bench\. All variants use the same Qwen3\.5\-9B backbone, training data, and rollout budget, and differ only in which roles are optimized and whether they are trained jointly or sequentially\.Bolddenotes the best result according to the metric direction\.Training Scheme / OutputOptimized RolesWebRiseWebGen\-BenchTT↑\\uparrowReR\_\{e\}↑\\uparrowRiR\_\{i\}↑\\uparrowOverall↑\\uparrowYes \(%\)↑\\uparrowPartial \(%\)↑\\uparrowNo \(%\)↓\\downarrowStart\-Fail \(%\)↓\\downarrowAcc\.↑\\uparrowBase–23\.245\.322\.130\.218\.410\.267\.14\.323\.5Generation Only \(Gen\)Gen29\.554\.127\.336\.917\.810\.567\.93\.923\.0Refine w/o Critique \(Gen\)Gen \+ Refine28\.253\.325\.235\.616\.711\.970\.50\.922\.6Refine w/o Critique \(Refine\)32\.957\.329\.740\.021\.610\.068\.30\.026\.7Staged Training \(Gen\)Gen→\\rightarrowCritic \+ Refine27\.652\.025\.935\.220\.711\.166\.02\.226\.3Staged Training \(Refine\)32\.956\.430\.940\.129\.812\.555\.52\.236\.1WebLoop \(Gen\)Gen \+ Critic \+ Refine31\.755\.430\.039\.128\.710\.856\.93\.634\.2WebLoop \(Refine\)34\.657\.932\.041\.531\.714\.448\.45\.638\.9

### 5\.1Where Does the Gain Come From?

Beyond additional refinement\.[Table3](https://arxiv.org/html/2610.11543#S5.T3)shows that WebLoop’s gains cannot be explained by an extra refinement pass alone\. Generation Only reaches 36\.9 on WebRise and 23\.0% on WebGen\-Bench, while Refine w/o Critique improves the final output to 40\.0 and 26\.7%, respectively\. WebLoop further reaches 41\.5 and 38\.9%, indicating that learned critique provides additional value beyond second\-pass generation\. Joint optimization is also important: Staged Training reaches 40\.1 and 36\.1% after refinement, while WebLoop achieves 41\.5 and 38\.9%, with a larger gap already visible in first\-pass generation\. These results show that WebLoop benefits from jointly learning generation, critique, and refinement rather than treating refinement or Critic learning as isolated stages\.

Table 4:Critic reward ablation\.All variants use the same Qwen3\.5\-9B backbone, training data, and rollout structure and differ only in the Critic reward\.DDdenotes discriminability andHHdenotes downstream helpfulness\.Bolddenotes the best result according to the metric direction\.Critic Training / Output𝐑crit\\mathbf\{R\_\{\\mathrm\{crit\}\}\}WebRiseWebGen\-BenchTT↑\\uparrowReR\_\{e\}↑\\uparrowRiR\_\{i\}↑\\uparrowOverall↑\\uparrowYes \(%\)↑\\uparrowPartial \(%\)↑\\uparrowNo \(%\)↓\\downarrowStart\-Fail \(%\)↓\\downarrowAcc\.↑\\uparrowBase–23\.245\.322\.130\.218\.410\.267\.14\.323\.5Discriminability Only \(Gen\)DD30\.053\.627\.236\.922\.38\.765\.83\.226\.6Discriminability Only \(Refine\)33\.457\.330\.740\.527\.810\.759\.42\.233\.2Helpfulness Only \(Gen\)HH27\.650\.724\.734\.318\.29\.068\.24\.622\.7Helpfulness Only \(Refine\)31\.354\.128\.738\.028\.113\.056\.32\.634\.6Mixed from Start \(Gen\)H\+λ​DH\+\\lambda D30\.254\.027\.837\.324\.49\.362\.93\.429\.1Mixed from Start \(Refine\)32\.756\.529\.439\.528\.010\.558\.33\.233\.2WebLoop\(Gen\)D→H\+λ​DD\\rightarrow H\+\\lambda D31\.755\.430\.039\.128\.710\.856\.93\.634\.2WebLoop\(Refine\)34\.657\.932\.041\.531\.714\.448\.45\.638\.9

Figure 3:Critic learning dynamics\.\(a\) DiscriminabilityDD\. \(b\) Downstream helpfulnessHH\. \(c\) Generator and Refiner execution rewards\. Thin and thick curves denote per\-step values and moving averages; the dashed line marks the reward switch after 15 updates \(around 1K samples\)\.
### 5\.2What Makes a Useful Critique?

Complementary critic signals and staged learning\.[Table4](https://arxiv.org/html/2610.11543#S5.T4)shows that discriminability and helpfulness capture complementary aspects of critique quality\. Optimizing either signal alone underperforms WebLoop, and their relative ranking differs across benchmarks: discriminability performs better on WebRise, while helpfulness is stronger on WebGen\-Bench\. Moreover, mixing the two signals from the beginning still falls short of the staged objective, indicating that both the reward composition and its scheduling matter\. WebLoop reaches 41\.5 on WebRise and 38\.9% on WebGen\-Bench, supporting a curriculum that first establishes reliable diagnosis and then introduces downstream utility\. This allows the Critic to learn feedback that is both correct and actionable\.

Critic learning dynamics\.[Fig\.3](https://arxiv.org/html/2610.11543#S5.F3)tracks discriminabilityDD, downstream helpfulnessHH, and executable reward throughout training\. We use the first 15 updates as a diagnostic warm\-up, optimizing onlyDDso that the Critic first learns reliable requirement\-level judgments from direct execution labels\. We then switch toH\+λ​DH\+\\lambda D, introducing the delayed downstream signal while retaining diagnostic supervision\. This staged schedule avoids relying on refinement\-dependent utility before the Critic has learned a stable notion of correctness\. Refined outputs remain consistently stronger than first\-pass generations, indicating that improved Critic behavior translates into executable gains\. Additional training\-dynamics and co\-adaptation analyses are provided in[Sec\.C\.1](https://arxiv.org/html/2610.11543#A3.SS1)\.

## 6Conclusion

We presentedWebLoop, an execution\-grounded framework that jointly learns generation, critique, and refinement for functional Web generation\. WebLoop treats critique as a learnable intermediate decision, assigning execution\-derived credit through complementary discriminability and downstream helpfulness signals while jointly optimizing all three roles within a shared policy\. Across WebRise and WebGen\-Bench, WebLoop improves both first\-pass generation and final refinement, with gains that persist across model scales and transfer from text\-only training to multimodal inputs\. Controlled ablations show that these gains cannot be explained by an additional refinement pass alone, suggesting that executable supervision can be used not only to optimize final artifacts, but also to learn how they should be diagnosed and improved\.

### AI Use Statement

Generative AI tools, including ChatGPT and AI coding assistants such as Codex, were used during the preparation of this work\. They assisted with language editing, improving clarity and organization, and the implementation, debugging, and refinement of selected code components\. AI models were also used to assist the generation and refinement of portions of the executable training data under predefined data\-construction protocols\. AI\-assisted training data were subsequently filtered and validated through the authors’ specified quality\-control and browser\-execution procedures\. The authors made and verified the final decisions regarding the research questions, methodological design, experimental protocol, analysis, and conclusions\. Generative AI was not used to fabricate, alter, or post hoc select reported experimental results; all reported metrics were computed from actual model outputs using the stated evaluation pipelines\. The authors reviewed all AI\-assisted content and take full responsibility for the final manuscript, implementation, data, and reported findings\.

### Reproducibility Statement

We provide the formulation, training procedure, data construction pipeline, and evaluation protocol required to reproduce WebLoop\. The main paper describes the Generator–Critic–Refiner loop, execution\-grounded Critic credit assignment, joint group\-relative optimization, and experimental protocol\.[AppendixA](https://arxiv.org/html/2610.11543#A1)provides training and rollout configurations, complete objective definitions, browser evaluation details, and controlled\-baseline adaptations, while[AppendixB](https://arxiv.org/html/2610.11543#A2)details executable task construction and filtering\. The complete role\-specific prompts are provided in[AppendixD](https://arxiv.org/html/2610.11543#A4)\. Unless otherwise stated, controlled comparisons use the same backbone initialization, training\-task distribution, browser evaluation infrastructure, and metric computation\. The core code is provided in the supplementary material accompanying this paper\. Source code, configurations, and data\-construction assets will be publicly released upon acceptance to facilitate reproducibility and future research\.

## References

- Anthropic \(2026\)AnthropicClaude Opus 4\.7 System Card\.Technical reportAnthropic\.External Links:[Link](https://www.anthropic.com/claude-opus-4-7-system-card)Cited by:[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Chenet al\.\(2026\)B\. Chen, H\. Liu, and S\. ZhangWebGrader: training llms for web development with self\-evolving programmatic grader\.CoRRabs/2608\.06474\.Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p1.1),[§2](https://arxiv.org/html/2610.11543#S2.p1.1)\.
- Chenet al\.\(2024\)X\. Chen, M\. Lin, N\. Schärli, and D\. ZhouTeaching large language models to self\-debug\.InICLR,Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p2.1),[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- GLM\-5 Team \(2026\)GLM\-5 TeamGLM\-5: from vibe coding to agentic engineering\.External Links:2602\.15763,[Link](https://arxiv.org/abs/2602.15763)Cited by:[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Google DeepMind \(2026\)Google DeepMindGemini 3\.1 Pro Model Card\.Technical reportGoogle DeepMind\.External Links:[Link](https://storage.googleapis.com/deepmind-media/Model-Cards/Gemini-3-1-Pro-Model-Card.pdf)Cited by:[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Gouet al\.\(2024\)Z\. Gou, Z\. Shao, Y\. Gong, Y\. Shen, Y\. Yang, N\. Duan, and W\. ChenCRITIC: large language models can self\-correct with tool\-interactive critiquing\.InICLR,Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p2.1),[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Huanget al\.\(2024\)J\. Huang, X\. Chen, S\. Mishra, H\. S\. Zheng, A\. W\. Yu, X\. Song, and D\. ZhouLarge language models cannot self\-correct reasoning yet\.InICLR,Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Jianget al\.\(2026\)J\. Jiang, C\. Cai, C\. Park, J\. Shen, S\. H\. Kim, J\. Li, and Y\. WangWebGen\-r1: incentivizing large language models to generate functional and aesthetic websites with reinforcement learning\.CoRRabs/2604\.20398\.Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p1.1),[§2](https://arxiv.org/html/2610.11543#S2.p1.1)\.
- Kumaret al\.\(2025\)A\. Kumar, V\. Zhuang, R\. Agarwal, Y\. Su, J\. D\. Co\-Reyes, A\. Singh, K\. Baumli, S\. Iqbal, C\. Bishop, R\. Roelofs, L\. M\. Zhang, K\. McKinney, D\. Shrivastava, C\. Paduraru, G\. Tucker, D\. Precup, F\. M\. P\. Behbahani, and A\. FaustTraining language models to self\-correct via reinforcement learning\.InICLR,Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Laurençonet al\.\(2024\)H\. Laurençon, L\. Tronchon, and V\. SanhUnlocking the conversion of web screenshots into HTML code with the websight dataset\.CoRRabs/2403\.09029\.Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p1.1)\.
- Liet al\.\(2026\)Y\. Li, C\. Zhang, R\. Lv, A\. Liu, K\. Deng, Y\. Zhang, J\. Liu, and B\. ZhouReLook: vision\-grounded RL with a multimodal LLM critic for agentic web coding\.InACL \(1\),pp\. 25471–25485\.Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p2.1),[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Luet al\.\(2025a\)Z\. Lu, H\. Ren, Y\. Yang, K\. Wang, Z\. Zong, J\. Pan, M\. Zhan, and H\. LiWebGen\-agent: enhancing interactive website generation with multi\-level feedback and step\-level reinforcement learning\.CoRRabs/2509\.22644\.Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p2.1),[§2](https://arxiv.org/html/2610.11543#S2.p1.1),[§2](https://arxiv.org/html/2610.11543#S2.p2.1),[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Luet al\.\(2025b\)Z\. Lu, Y\. Yang, H\. Ren, H\. Hou, H\. Xiao, K\. Wang, W\. Shi, A\. Zhou, M\. Zhan, and H\. LiWebGen\-bench: evaluating llms on generating interactive and functional websites from scratch\.InNeurIPS,Cited by:[§A\.3](https://arxiv.org/html/2610.11543#A1.SS3.p1.1),[§1](https://arxiv.org/html/2610.11543#S1.p1.1),[§2](https://arxiv.org/html/2610.11543#S2.p1.1),[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p1.1),[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Madaanet al\.\(2023\)A\. Madaan, N\. Tandon, P\. Gupta, S\. Hallinan, L\. Gao, S\. Wiegreffe, U\. Alon, N\. Dziri, S\. Prabhumoye, Y\. Yang, S\. Gupta, B\. P\. Majumder, K\. Hermann, S\. Welleck, A\. Yazdanbakhsh, and P\. ClarkSelf\-refine: iterative refinement with self\-feedback\.InNeurIPS,Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p2.1),[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- McAleeseet al\.\(2024\)N\. McAleese, R\. M\. Pokorny, J\. F\. C\. Uribe, E\. Nitishinskaya, M\. Trebacz, and J\. LeikeLLM critics help catch LLM bugs\.CoRRabs/2407\.00215\.Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Menget al\.\(2026\)Y\. Meng, Y\. Suo, J\. Wang, Y\. Sun, Y\. Yu, R\. Zhang, R\. Hu, Y\. Wang, S\. Ruan, B\. Wang, Y\. Zhang, and Y\. YangWebRISE: requirement\-induced state evaluation for mllm\-generated web artifacts\.CoRRabs/2606\.03220\.Cited by:[§A\.3](https://arxiv.org/html/2610.11543#A1.SS3.p1.1),[§B\.2](https://arxiv.org/html/2610.11543#A2.SS2.p1.1),[§1](https://arxiv.org/html/2610.11543#S1.p1.1),[§2](https://arxiv.org/html/2610.11543#S2.p1.1),[§3\.1](https://arxiv.org/html/2610.11543#S3.SS1.p3.1),[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p1.1)\.
- Moonshot AI \(2026\)Moonshot AIKimi K2\.6\.Note:Model CardExternal Links:[Link](https://huggingface.co/moonshotai/Kimi-K2.6)Cited by:[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- OpenAI \(2026\)OpenAIGPT\-6 Astra System Card\.Technical reportOpenAI\.External Links:[Link](https://deploymentsafety.openai.com/gpt-6-astra)Cited by:[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Qwen Team \(2026\)Qwen TeamQwen3\.5: towards native multimodal agents\.External Links:[Link](https://qwen.ai/blog?id=qwen3.5)Cited by:[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Shinnet al\.\(2023\)N\. Shinn, F\. Cassano, A\. Gopinath, K\. Narasimhan, and S\. YaoReflexion: language agents with verbal reinforcement learning\.InNeurIPS,Cited by:[§1](https://arxiv.org/html/2610.11543#S1.p2.1),[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Siet al\.\(2025\)C\. Si, Y\. Zhang, R\. Li, Z\. Yang, R\. Liu, and D\. YangDesign2Code: benchmarking multimodal code generation for automated front\-end engineering\.InNAACL \(Long Papers\),pp\. 3956–3974\.Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p1.1)\.
- tesslate \(2024\)tesslateUIGEN\-t2: scaling ui generation with reasoning on qwen2\.5\-coder\-7b\.Hugging Face\.External Links:[Link](https://huggingface.co/tesslate/UIGEN-T2)Cited by:[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Wanget al\.\(2024\)T\. Wang, I\. Kulikov, O\. Golovneva, P\. Yu, W\. Yuan, J\. Dwivedi\-Yu, R\. Y\. Pang, M\. Fazel\-Zarandi, J\. Weston, and X\. LiSelf\-taught evaluators\.CoRRabs/2408\.02666\.Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Xiet al\.\(2025\)Z\. Xi, J\. Huang, X\. Guo, B\. Hong, D\. Yang, X\. Fan, S\. Li, Z\. Chen, J\. Ye, S\. Yuan, Z\. Du, X\. Yao, Y\. Xu, J\. Chen, R\. Zheng, T\. Gui, Q\. Zhang, and X\. HuangCritique\-RL: training language models for critiquing through two\-stage reinforcement learning\.CoRRabs/2510\.24320\.Cited by:[§A\.3](https://arxiv.org/html/2610.11543#A1.SS3.p3.1),[§2](https://arxiv.org/html/2610.11543#S2.p2.1),[§3\.2](https://arxiv.org/html/2610.11543#S3.SS2.p1.1),[§3\.2](https://arxiv.org/html/2610.11543#S3.SS2.p5.1),[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Yuet al\.\(2025\)T\. Yu, C\. Xiang, M\. Yang, P\. Ke, B\. Wen, C\. Wang, J\. Cheng, L\. Zhang, X\. Mu, C\. Sun, and M\. HuangTraining language model to critique for better refinement\.InACL \(Findings\),Findings of ACL, Vol\.ACL 2025,pp\. 26760–26804\.Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p2.1)\.
- Yunet al\.\(2024\)S\. Yun, H\. Lin, R\. Thushara, M\. Q\. Bhat, Y\. Wang, Z\. Jiang, M\. Deng, J\. Wang, T\. Tao, J\. Li, H\. Li, P\. Nakov, T\. Baldwin, Z\. Liu, E\. P\. Xing, X\. Liang, and Z\. ShenWeb2Code: A large\-scale webpage\-to\-code dataset and evaluation framework for multimodal llms\.InNeurIPS,Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p1.1)\.
- Zhanget al\.\(2025\)X\. Zhang, H\. Sun, Y\. Zhang, K\. Feng, C\. Lu, C\. Yang, and H\. MengCritique\-grpo: advancing LLM reasoning with natural language and numerical feedback\.CoRRabs/2506\.03106\.Cited by:[§A\.3](https://arxiv.org/html/2610.11543#A1.SS3.p3.1),[§4\.1](https://arxiv.org/html/2610.11543#S4.SS1.p2.1)\.
- Zhuet al\.\(2025\)H\. Zhu, Y\. Zhang, B\. Zhao, J\. Ding, S\. Liu, T\. Liu, D\. Wang, Y\. Liu, and Z\. LiFrontendBench: A benchmark for evaluating llms on front\-end development via automatic evaluation\.CoRRabs/2506\.13832\.Cited by:[§2](https://arxiv.org/html/2610.11543#S2.p1.1)\.

## Appendix

## Appendix AImplementation and Training Details

We provide additional implementation details for WebLoop training, complete definitions of the objectives simplified in the main text, and the evaluation protocols used for controlled comparisons\.

### A\.1Training and Rollout Configuration

Optimization setup\.We instantiate WebLoop with Qwen3\.5\-9B and Qwen3\.5\-27B, and conduct all controlled ablations with Qwen3\.5\-9B\. Training uses the 2,880 executable tasks described in[Sec\.3\.4](https://arxiv.org/html/2610.11543#S3.SS4), referred to as approximately 3K tasks in the main text, with a task batch size of 64\. We optimize the shared policy with GRPO using a learning rate of1×10−61\\times 10^\{\-6\}and no explicit KL penalty\. Rollouts use a temperature of0\.70\.7and top\-ppof1\.01\.0, with maximum prompt and response lengths of 16,384 tokens\.

Rollout structure\.For each task, the Generator samplesng=3n\_\{g\}=3initial implementations\. After selecting one valid imperfect draft, the Critic samplesnc=3n\_\{c\}=3critiques, each of which conditionsnr=3n\_\{r\}=3independent refinements\. A complete rollout therefore contains 3 Generator outputs, 3 Critic outputs, and 9 Refiner outputs, including 12 executable Web pages\. If no valid imperfect draft exists, the task contributes only its Generator samples\. The three roles are sampled sequentially and jointly optimized in one GRPO update as described in[Sec\.3\.3](https://arxiv.org/html/2610.11543#S3.SS3)\.

Critic schedule\.For the first 15 policy updates, the Critic is optimized only with diagnostic discriminabilityD⁡\(c\)D\(c\)\. Subsequent updates useH⁡\(c\)\+λ​D​\(c\)H\(c\)\+\\lambda D\(c\)withλ=0\.2\\lambda=0\.2, thereby introducing retrospective helpfulness while retaining requirement\-level diagnostic supervision\. Generator, Critic, and Refiner share all model parameters throughout training\.

System implementation\.Our implementation is built onverlwith an FSDP2 actor and asynchronous vLLM rollout workers\. Policy weights are synchronized to the rollout workers after each update to maintain on\-policy sampling\. Browser execution is parallelized independently from model rollout, with up to 72 concurrent evaluations and a per\-example hard timeout of 2,400 seconds\.

### A\.2Additional Objective Details

Candidate selection\.Let𝒴x\(1\)=\{yi\(1\)\}i=1ng\\mathcal\{Y\}\_\{x\}^\{\(1\)\}=\\\{y\_\{i\}^\{\(1\)\}\\\}\_\{i=1\}^\{n\_\{g\}\}denote the initial implementations sampled for taskxx\. We retain candidates that receive a valid browser evaluation but do not fully solve the task:

𝒴x−=\{yi\(1\)∈𝒴x\(1\)∣yi\(1\)is valid,rweb\(yi\(1\)\)<1\}\.\\mathcal\{Y\}\_\{x\}^\{\-\}=\\left\\\{y\_\{i\}^\{\(1\)\}\\in\\mathcal\{Y\}\_\{x\}^\{\(1\)\}\\mid y\_\{i\}^\{\(1\)\}\\text\{ is valid\},\\;r\_\{\\mathrm\{web\}\}\\big\(y\_\{i\}^\{\(1\)\}\\big\)<1\\right\\\}\.\(12\)The shared base draft is the median\-reward candidate in this set,

yb=Medianrweb⁡\(𝒴x−\)\.y\_\{b\}=\\operatorname\{Median\}\_\{r\_\{\\mathrm\{web\}\}\}\\left\(\\mathcal\{Y\}\_\{x\}^\{\-\}\\right\)\.\(13\)This choice keeps all critiques anchored to the same implementation while avoiding both solved examples and unusually poor failures\. If𝒴x−\\mathcal\{Y\}\_\{x\}^\{\-\}is empty, no Critic or Refiner branch is expanded for that task\.

Complete discriminability definition\.For the selected draftyby\_\{b\}, letzq∈\{0,1\}z\_\{q\}\\in\\\{0,1\\\}denote the execution\-grounded status of requirementrqr\_\{q\}, and letz^j,q\\hat\{z\}\_\{j,q\}be the corresponding prediction from critiquecjc\_\{j\}\. We define

ℱ=\{q:zq=0\},𝒫=\{q:zq=1\},\\mathcal\{F\}=\\\{q:z\_\{q\}=0\\\},\\qquad\\mathcal\{P\}=\\\{q:z\_\{q\}=1\\\},\(14\)and the class\-wise accuracies

afail\(cj\)=1\|ℱ\|∑q∈ℱ𝕀\[z^j,q=0\],apass\(cj\)=1\|𝒫\|∑q∈𝒫𝕀\[z^j,q=1\],a\_\{\\mathrm\{fail\}\}\(c\_\{j\}\)=\\frac\{1\}\{\|\\mathcal\{F\}\|\}\\sum\_\{q\\in\\mathcal\{F\}\}\\mathbb\{I\}\[\\hat\{z\}\_\{j,q\}=0\],\\qquad a\_\{\\mathrm\{pass\}\}\(c\_\{j\}\)=\\frac\{1\}\{\|\\mathcal\{P\}\|\}\\sum\_\{q\\in\\mathcal\{P\}\}\\mathbb\{I\}\[\\hat\{z\}\_\{j,q\}=1\],\(15\)whenever the corresponding set is non\-empty\. The full discriminability score is

D⁡\(cj\)=\{afail​\(cj\)\+apass​\(cj\)−1,\|ℱ\|\>0,\|𝒫\|\>0,2​afail​\(cj\)−1,\|ℱ\|\>0,\|𝒫\|=0,2​apass​\(cj\)−1,\|ℱ\|=0,\|𝒫\|\>0,0,Qx=0\.D\(c\_\{j\}\)=\\begin\{cases\}a\_\{\\mathrm\{fail\}\}\(c\_\{j\}\)\+a\_\{\\mathrm\{pass\}\}\(c\_\{j\}\)\-1,&\|\\mathcal\{F\}\|\>0,\\ \|\\mathcal\{P\}\|\>0,\\\\ 2a\_\{\\mathrm\{fail\}\}\(c\_\{j\}\)\-1,&\|\\mathcal\{F\}\|\>0,\\ \|\\mathcal\{P\}\|=0,\\\\ 2a\_\{\\mathrm\{pass\}\}\(c\_\{j\}\)\-1,&\|\\mathcal\{F\}\|=0,\\ \|\\mathcal\{P\}\|\>0,\\\\ 0,&Q\_\{x\}=0\.\\end\{cases\}\(16\)When both classes are present, this reduces to Youden’sJJand assigns equal importance to satisfied and violated requirements\. The single\-class cases preserve the same\[−1,1\]\[\-1,1\]range\.

Expected refinement utility\.The helpfulness of a critique is defined through the quality of refinements generated under that critique\. For a fixed\(x,yb,cj\)\(x,y\_\{b\},c\_\{j\}\), the conditional refinement utility is

U\(cj∣x,yb\)=𝔼y∼πθold\(⋅∣pref\(x,yb,cj\)\)\[rweb\(y\)\]\.U\(c\_\{j\}\\mid x,y\_\{b\}\)=\\mathbb\{E\}\_\{y\\sim\\pi\_\{\\theta\_\{\\mathrm\{old\}\}\}\(\\cdot\\mid p\_\{\\mathrm\{ref\}\}\(x,y\_\{b\},c\_\{j\}\)\)\}\\left\[r\_\{\\mathrm\{web\}\}\(y\)\\right\]\.\(17\)We estimate this expectation using thenrn\_\{r\}sampled refinements,

U^​\(cj\)=1nr​∑k=1nrrweb​\(yj,k\(2\)\),\\widehat\{U\}\(c\_\{j\}\)=\\frac\{1\}\{n\_\{r\}\}\\sum\_\{k=1\}^\{n\_\{r\}\}r\_\{\\mathrm\{web\}\}\\big\(y\_\{j,k\}^\{\(2\)\}\\big\),\(18\)and define retrospective helpfulness as

H⁡\(cj\)=U^​\(cj\)−rweb​\(yb\)\.H\(c\_\{j\}\)=\\widehat\{U\}\(c\_\{j\}\)\-r\_\{\\mathrm\{web\}\}\(y\_\{b\}\)\.\(19\)Thus,H⁡\(cj\)H\(c\_\{j\}\)measures the expected execution gain obtained when the current Refiner acts on the critique rather than the linguistic form of the critique itself\.

Role\-specific rewards\.For completeness, the scalar reward assigned to any policy outputoois

r⁡\(o\)=\{rweb​\(yi\(1\)\),o=yi\(1\),rcrit​\(cj\),o=cj,rweb​\(yj,k\(2\)\),o=yj,k\(2\)\.r\(o\)=\\begin\{cases\}r\_\{\\mathrm\{web\}\}\\big\(y\_\{i\}^\{\(1\)\}\\big\),&o=y\_\{i\}^\{\(1\)\},\\\\ r\_\{\\mathrm\{crit\}\}\(c\_\{j\}\),&o=c\_\{j\},\\\\ r\_\{\\mathrm\{web\}\}\\big\(y\_\{j,k\}^\{\(2\)\}\\big\),&o=y\_\{j,k\}^\{\(2\)\}\.\\end\{cases\}\(20\)These heterogeneous rewards are normalized only within the role\-specific comparison groups defined in[Sec\.3\.3](https://arxiv.org/html/2610.11543#S3.SS3)\. Critiques that cannot be parsed into the required requirement\-level judgments receive the minimum Critic reward and do not instantiate downstream refinement branches\.

### A\.3Browser Evaluation and Baseline Adaptation

Browser evaluation\.For WebRise\([Meng et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib2)\), all generated pages are evaluated with the same Interaction Contract Graph and browser executor used to construct the execution rewards in[Sec\.3\.1](https://arxiv.org/html/2610.11543#S3.SS1)\. The evaluator executes the prescribed interactions and assertions and returns transition validity, explicit and implicit requirement coverage, and requirement\-level execution labels\. For WebGen\-Bench\([Lu et al\., 2025b](https://arxiv.org/html/2610.11543#bib.bib1)\), we use the benchmark\-provided evaluation harness and disable automatic starter\-template selection \(autoSelectTemplate=false\), requiring each model to construct the website from an empty workspace\. Pages that fail to launch are reported as Start\-Fail separately from functional failures after initialization\.

Same\-backbone controls\.The*refine \(w/o RL\)*baseline uses the original Qwen3\.5 checkpoint for Generator, Critic, and Refiner and performs one generate–critique–refine cycle without parameter updates\. Generation Only optimizes only the initial generation branch\. Refine without Critique trains generation and a second\-pass refinement without learned critique guidance\. Staged Training first optimizes generation and subsequently trains critique and refinement, allowing direct comparison with WebLoop’s joint optimization\.

Critique\-learning baselines\.We additionally adapt Critique\-GRPO\([Zhang et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib27)\)and Critique\-RL\([Xi et al\., 2025](https://arxiv.org/html/2610.11543#bib.bib11)\)to functional Web generation\. For Critique\-GRPO, a fixed teacher receives requirement\-level execution information during training and provides feedback for policy optimization\. For Critique\-RL, the Generator and Refiner actor is kept fixed while only the Critic is optimized, following its actor–critic separation\. At evaluation time, the learned Critic provides feedback that conditions refinement by the same underlying actor\. All controlled variants use the same task distribution and browser evaluator as WebLoop wherever applicable\.

Evaluation consistency\.All same\-backbone methods are initialized from the same Qwen3\.5 checkpoints and evaluated on identical benchmark instances with the same browser infrastructure and metric computation\. For WebLoop, “gen” denotes the first\-pass output of the trained shared policy, while “refine” denotes the output after one critique\-conditioned refinement cycle\. External open\-source, proprietary, and Web\-specialized models use the same benchmark\-specific execution harness while retaining the inference interfaces supported by their released implementations\.

## Appendix BExecutable Training Data Construction Details

We provide additional details on the construction of the executable Web training corpus introduced in[Sec\.3\.4](https://arxiv.org/html/2610.11543#S3.SS4)\. The objective is to pair natural\-language task specifications with browser\-executable supervision that captures both whether a requested function is present and whether its behavior remains correct across interactions\. This construction provides page\-level execution signals for the Generator and Refiner and requirement\-level supervision for Critic learning\.

### B\.1Task and Requirement Construction

Domain and scenario coverage\.We construct the corpus around functional Web applications rather than isolated visual layouts\. The task space spans 21 domains, including e\-commerce, office productivity, education, developer tools, and data analytics\. Within each domain, we instantiate concrete scenarios covering core operations, management functions, user settings, data presentation, and multi\-step workflows\. The resulting corpus contains 1,442 scenarios, which are further instantiated into 2,880 executable Web generation tasks\.

Functional task instantiation\.Each task specifies a target Web application through a natural\-language description together with a set of functional requirements\. Following the notation in the main text, we write a task as

x=\(d,ℛx\),x=\(d,\\mathcal\{R\}\_\{x\}\),\(21\)wheredddenotes the task description andℛx\\mathcal\{R\}\_\{x\}contains the requirements that define the expected behavior\. Unlike page\-generation data centered primarily on appearance or static content, these requirements describe interactive functionality that can subsequently be tested through browser execution\. This makes each task suitable for evaluating both the initial implementation and its later refinement under the same functional specification\.

Explicit and implicit requirements\.We decompose the requirement set into explicit and implicit components,

ℛx=ℛxexp∪ℛximp\.\\mathcal\{R\}\_\{x\}=\\mathcal\{R\}\_\{x\}^\{\\mathrm\{exp\}\}\\cup\\mathcal\{R\}\_\{x\}^\{\\mathrm\{imp\}\}\.\(22\)Explicit requirements describe functions and interaction entry points directly requested by the task specification\. They capture what operations the generated page should expose and provide the primary requirement\-level targets inspected by the Critic\. Implicit requirements instead describe behavioral constraints needed for these functions to operate consistently, including state consistency, operation ordering, boundary handling, and reset behavior\. They therefore extend supervision beyond the presence of an interface element to the correctness of the behavior induced by interacting with it\.

The final corpus contains an average of 11\.87 requirements per task, including 5\.47 explicit and 6\.39 implicit requirements\. Implicit requirements account for 53\.9% of all requirements, reflecting the importance of interaction semantics that are not fully characterized by explicit function descriptions alone\. This decomposition also supports the separate explicit\- and implicit\-requirement coverage terms used by the execution evaluator\.

### B\.2Interaction Contract Construction and Executability Filtering

From requirements to executable contracts\.Following the executable evaluation formulation of WebRISE\([Meng et al\., 2026](https://arxiv.org/html/2610.11543#bib.bib2)\), we convert each task specification into an initial\-state contract and an Interaction Contract Graph \(ICG\)\. The initial\-state contract defines the starting condition under which the subsequent browser interactions are executed\. The ICG then operationalizes the functional requirements as executable interaction trajectories and corresponding assertions\. In this way, natural\-language requirements are transformed into programmatically verifiable behaviors rather than evaluated only through textual or visual similarity\.

Interaction Contract Graph\.For a taskxx, its ICGGxG\_\{x\}organizes browser execution through states, transitions, and functional assertions\. Transitions describe the interactions used to move between Web states, while assertions verify whether the resulting behavior satisfies the corresponding functional constraints\. A single task can therefore contain multiple interaction transitions and multiple assertions, enabling evaluation of multi\-step functionality rather than only isolated final states\. Across the corpus, each ICG contains 10\.64 states, 11\.40 transitions, and 28\.15 executable assertions on average\.

Executing a generated implementationyyagainstGxG\_\{x\}produces the execution signals used throughout WebLoop,

E⁡\(y,Gx\)=\(T⁡\(y\),Re​\(y\),Ri​\(y\),𝐳⁡\(y\)\),E\(y;G\_\{x\}\)=\\left\(T\(y\),R\_\{e\}\(y\),R\_\{i\}\(y\),\\mathbf\{z\}\(y\)\\right\),\(23\)whereTTmeasures transition validity,ReR\_\{e\}andRiR\_\{i\}measure explicit\- and implicit\-requirement coverage, and𝐳\\mathbf\{z\}provides requirement\-level execution labels\. The first three quantities form the page\-level reward used for Generator and Refiner optimization, while the requirement\-level labels provide execution\-grounded supervision for Critic discriminability\. Thus, the same executable contract supports both outcome\-level optimization and intermediate Critic credit assignment\.

Reference implementation and browser validation\.To verify executability and reduce dependence on any single generator, we independently construct reference HTML implementations using Kimi\-K2\.6, Claude Opus 5, and GPT\-5, and execute each against the associated ICG in a real browser\. We retain a task only if all three implementations achieve transition validity of at least0\.600\.60:

Tm≥0\.60,∀m∈\{1,2,3\},T\_\{m\}\\geq 0\.60,\\qquad\\forall m\\in\\\{1,2,3\\\},\(24\)whereTmT\_\{m\}denotes the transition validity of the implementation generated by themm\-th model\. This cross\-model criterion filters tasks with insufficiently reliable interaction contracts before training\.

Human review and filtering\.Browser\-executable contracts may still be semantically misaligned with the intended requirements, for example by omitting necessary prerequisites or using assertions that execute successfully but do not faithfully test the target behavior\. We therefore conduct a manual audit of sampled candidate tasks with two reviewers\. For each audited task, the reviewers examine five aspects: \(1\)*requirement alignment*, whether each tested behavior is supported by an explicit requirement or a justified implicit constraint; \(2\)*interaction coherence*, whether the action sequence includes the necessary preconditions and follows a valid progression toward the target state; \(3\)*assertion validity*, whether the expected outcomes correctly reflect the intended functional semantics; \(4\)*structural consistency*, whether states, transitions, and requirement references are internally consistent with the ICG specification; and \(5\)*functional discriminability*, whether the checks distinguish actual functional completion from superficial interface presence\. Audited tasks containing invalid or misaligned interaction contracts are excluded before corpus finalization\.

Final corpus\.After executable validation and manual filtering,, the training corpus contains 2,880 tasks across 21 domains and 1,442 scenarios\. Together, their explicit and implicit requirements and associated ICGs provide fine\-grained supervision over both functional outcomes and intermediate interaction behavior\. This construction turns each natural\-language Web task into an executable training unit that can evaluate initial generation, diagnose requirement\-level failures, and measure the downstream effect of critique\-conditioned refinement\.

Table 5:Human validation of functional evaluation\.Agreement between the automatic evaluator and two independent human reviewers on the same 300 sampled interaction cases\. Human–human agreement is included as a reference\.
### B\.3Human Consistency Validation

Annotation setup\.

We further assess the reliability of the automatic functional evaluator through human consistency analysis on 300 sampled interaction cases\. For each case, two reviewers independently judge whether the expected behavior is satisfied based on the task requirements, tested interaction, and corresponding execution evidence\.

Metrics\.

We report accuracy, mean absolute error \(MAE\), Spearman correlation, Pearson correlation, and Cohen’sκ\\kappa\. Accuracy and Cohen’sκ\\kappameasure agreement on binary pass/fail judgments\. MAE and the correlation coefficients are computed over paired human and automatic graded scores normalized to\[0,1\]\[0,1\]\. As shown in[Table5](https://arxiv.org/html/2610.11543#A2.T5), the evaluator shows strong consistency with both reviewers across accuracy, MAE, rank and linear correlation, and Cohen’sκ\\kappa, while human–human agreement provides an upper\-reference level\. These results indicate that the automatic evaluator closely tracks human judgments and provides a reliable execution\-based supervision signal for WebLoop training and evaluation\.

## Appendix CAdditional Experimental Results and Analysis

![Refer to caption](https://arxiv.org/html/2610.11543v1/fig_growth_xgrid.png)Figure 4:Refinement learning and Generator–Critic checkpoint interaction\.\(a\) Refined\-page quality over training, reported as improvement from the initial training point, with refinement without learned critique as a control\. The dashed line marks the Critic reward switch\. \(b\) WebRise Overall under cross\-pairing Generator and Critic checkpoints from steps 20, 30, and 45\. The Refiner uses the same checkpoint as the Generator in each pairing\.### C\.1Training Dynamics and Loop Co\-Adaptation

Refinement gains over training\.[Fig\.4](https://arxiv.org/html/2610.11543#A3.F4)\(a\) compares WebLoop with generation and refinement trained without a learned Critic\. Both improve with training, but critique\-guided refinement develops a larger advantage, particularly after downstream helpfulness is introduced\. This trend suggests that WebLoop increasingly exploits learned intermediate feedback rather than benefiting only from an additional generation pass\.

Generator–Critic checkpoint interaction\.[Fig\.4](https://arxiv.org/html/2610.11543#A3.F4)\(b\) cross\-pairs Generator and Critic checkpoints to separate their contributions over training\. For every fixed Generator, later Critic checkpoints improve refinement quality; likewise, later Generators improve performance under every fixed Critic\. The score rises from 38\.4 for the step\-20 pair to 41\.5 for the step\-45 pair, with the best result obtained when both use the latest checkpoint\. These results indicate that both roles improve progressively and contribute jointly to the final refinement gain\.

### C\.2Fine\-Grained Functional Evaluation

WebGen\-Bench category breakdown\.[Table6](https://arxiv.org/html/2610.11543#A3.T6)decomposes WebGen\-Bench along two independent taxonomies provided by the benchmark\. Website categories group checks into Content Presentation, User Interaction, and Data Management, while check categories distinguish Functional Testing, Data Display Testing, and Design Validation\. Each taxonomy covers all 647 checks, so the two groups provide complementary views of performance rather than six mutually exclusive categories\. We use the same template\-free evaluation protocol and scoring rule as in the main results\.

Table 6:Fine\-grained WebGen\-Bench results\.Accuracy under the same template\-free setting as[Table1](https://arxiv.org/html/2610.11543#S4.T1)\. The 647 interaction checks are independently grouped by website category and check category; each grouping covers the full benchmark, so the six columns are not additive\.†denotes proprietary models\.Where does refinement help?As shown in[Table6](https://arxiv.org/html/2610.11543#A3.T6), WebLoop improves functional behavior across a broad range of categories rather than only interface\-level compliance\. For Qwen3\.5\-9B, the final Refine output improves over the base model by 11\.8 points on Functional Testing and 22\.0 points on Data Display Testing, while also increasing all three website\-category scores\. The 27B model shows the same pattern, including gains of 12\.4 points on Functional Testing and 11\.8 points on Data Display Testing\. Compared with first\-pass WebLoop generation, refinement is more heterogeneous at 9B: it substantially improves Content Presentation, Data Management, Functional Testing, and Data Display Testing, while User Interaction and Design Validation decrease slightly by 1\.0 and 0\.8 points\. At 27B, refinement improves all six categories, suggesting that larger models exploit critique\-conditioned revision more consistently\.

![Refer to caption](https://arxiv.org/html/2610.11543v1/critlen_vs_refinescore.png)Figure 5:Critique length versus refinement quality\.Each cell reports the mean WebRise Overall of refined pages within a critique\-length bucket for a given Critic objective\. WebLoop exhibits a stronger positive association, while alternative objectives show weaker or non\-monotonic trends\.
### C\.3Critique Diagnostics and Repair Analysis

Critique length and refinement quality\.[Fig\.5](https://arxiv.org/html/2610.11543#A3.F5)examines the association between critique length and downstream refinement quality under different Critic objectives\. For WebLoop, refined WebRise Overall increases from 38\.5 in the shortest bucket to 54\.0 in the longest, whereas the alternative objectives show weaker or non\-monotonic patterns\. This contrast suggests that critique utility depends on how additional feedback is structured and used, rather than on verbosity alone\. Because critique length is neither controlled nor independently randomized, we treat this analysis as descriptive rather than causal\.

![Refer to caption](https://arxiv.org/html/2610.11543v1/WebLoop_cases_combined_1.png)Figure 6:Successful critique\-guided repair on Poll Vote \(WebRise\)\.The Critic localizes premature disclosure of voting results and a missing post identifier that blocks vote updates\. The Refiner applies the corresponding fixes, changing both affected transition checks from FAIL to PASS\.
### C\.4Qualitative Analysis of the Improvement Loop

We utilize qualitative examples to examine where the improvement loop succeeds or breaks down between requirement diagnosis and executable repair\. We organize the analysis around successful repair and three distinct sources of failure: incorrect Critic judgments, insufficient repair guidance, and failures in Refiner implementation\.

Successful diagnosis and repair\.[Fig\.6](https://arxiv.org/html/2610.11543#A3.F6)illustrates how an execution\-free Critic can support targeted functional repair\. For W03, the Critic identifies that voting results are exposed before a vote is cast and localizes the missing state\-dependent guard\. For W04, it traces the failed post\-vote update to a missingdata\-post\-idattribute\. Conditioned on these diagnoses, the Refiner applies targeted code changes that turn both associated browser checks from FAIL to PASS\. This example demonstrates how requirement\-level diagnosis can yield actionable guidance and executable improvement\.

The file\-filter example in[Fig\.7](https://arxiv.org/html/2610.11543#A3.F7)provides a complementary boundary\-condition case\. Although clearing the controls already works, empty size inputs are parsed asNaN, causing all files to be excluded\. The Critic localizes this defect, and the Refiner adds guards that restore all 12 files while preserving the correct control\-reset behavior\. Across both examples, the diagnosed defect, implemented change, and browser\-verified improvement are well aligned\.

Critic judgment errors\.The Critic may incorrectly classify already functional behavior as violating a requirement\. In[Fig\.8](https://arxiv.org/html/2610.11543#A3.F8), it attributes broken message selection to a stale hidden\-checkbox property\. However, a CSS class controls the visible selection marker and a message\-ID set controls the preview, and both behaviors already pass in the draft\. The Refiner synchronizes the hidden checkbox while preserving these mechanisms, so the relevant predicates remain PASS\. This case therefore reflects a false\-positive Critic judgment rather than a failed Refiner implementation: preserving correct behavior after revision does not validate the preceding negative verdict\.

Limitations of Critic repair guidance\.Even when the requirement verdict is correct, the proposed repair may fail to address the defect responsible for the unmet behavior\. In[Fig\.9](https://arxiv.org/html/2610.11543#A3.F9), the Critic identifies a genuine type\-matching issue but does not address the required per\-tab counts\. The Refiner applies the suggested edit, yet the counts remain absent\. The failure therefore reflects insufficient repair guidance rather than failure to follow the recommendation\.

The paired critiques in[Fig\.10](https://arxiv.org/html/2610.11543#A3.F10)further isolate this distinction\. They share the same draft, requirement verdicts, and discriminability score \(D=0\.75D=0\.75\), but differ in fault localization\. Only Critique A identifies the conflation of petition\-opening and signing states\. Its corresponding refinement restores the disabled signing behavior, whereas Critique B’s modal\-close edit is implemented without removing the blocker\. Thus, verdict\-level correctness alone is insufficient to establish the correctness of the proposed repair direction\.

Repair guidance may also be valid but incomplete\. In[Fig\.11](https://arxiv.org/html/2610.11543#A3.F11), the Critic identifies a missing listener and the Refiner adds it, but an unaddressed selector error leaves the header checkbox unchecked\. The prescribed edit is implemented correctly, yet the target behavior remains unsatisfied because the guidance does not cover all contributing defects\.

Refiner implementation failures\.Failure can instead arise when the Refiner does not faithfully realize an appropriate recommendation\. In[Fig\.12](https://arxiv.org/html/2610.11543#A3.F12), both critiques correctly identify the missing event binding and explicitly recommend adding it, but one displayed refinement leaves the binding absent and fails\. Another refinement conditioned on the same critique adds the binding and passes\. Unlike the incomplete\-guidance cases above, the required repair is already specified here; the failure lies in executing that guidance\.

The Refiner may also introduce regressions while addressing genuine defects\. In[Fig\.13](https://arxiv.org/html/2610.11543#A3.F13), the Critic correctly identifies missing liked\-state feedback, but the revision conflates the user’s like state with the aggregate like count, causing the count predicate to regress from PASS to FAIL\. Thus, unsuccessful refinement may result either from failing to follow valid guidance or from introducing new implementation errors\.

Together, these cases distinguish whether the Critic judges the requirement correctly, whether its guidance is sufficient, and whether the Refiner implements that guidance successfully\. Discriminability evaluates the first, whereas helpfulness captures downstream outcomes jointly determined by feedback and implementation\. A failed refinement therefore does not by itself identify the source of failure; the intermediate diagnosis and resulting code changes are required to localize where the improvement loop breaks down\.

![Refer to caption](https://arxiv.org/html/2610.11543v1/WebLoop_cases_combined_2.png)Figure 7:Boundary\-condition repair on File Search with Filters \(WebRise\)\.The Critic traces the empty result set to size bounds parsed asNaNafter clearing filters\. The Refiner adds guards for empty bounds, restoring all 12 files while preserving the already\-correct control reset\.![Refer to caption](https://arxiv.org/html/2610.11543v1/WebLoop_cases_combined_3.png)Figure 8:False\-positive Critic judgment on Share Chat Link Interface \(WebRise\)\.The Critic attributes message\-selection failure to an unsynchronized hidden checkbox, although the visible selection and preview are already controlled correctly\. The Refiner synchronizes the checkbox without affecting either passing behavior\.![Refer to caption](https://arxiv.org/html/2610.11543v1/WebLoop_cases_combined_4.png)Figure 9:Correct verdict but mislocalized repair guidance on Search Result Tabs \(WebRise\)\.The Critic correctly marks the per\-category count requirement as unmet but targets a type\-matching issue rather than the missing count labels\. The Refiner applies the proposed edit, while the target predicate remains FAIL\.Figure 10:Divergent fault localization on Petition Progress Dashboard \(WebRise\)\.Both critiques correctly identify signing as broken, but only one localizes the state error that disables signing when the dialog opens\. Although both suggested edits are implemented, only the correctly localized repair changes the transition from FAIL to PASS\.![Refer to caption](https://arxiv.org/html/2610.11543v1/WebLoop_cases_combined_5.png)Figure 11:Incomplete repair guidance on Bulk Content Operations \(WebRise\)\.The Refiner adds the missing listener as recommended, but an unaddressed selector error still clears the header\-checkbox state\. The prescribed edit is implemented, yet the target requirement remains unsatisfied\.Figure 12:Divergent Refiner outcomes under equivalent diagnoses on Audit Timeline \(WebRise\)\.Both critiques identify the same missing event binding, but only one refinement implements the recommended listener and passes the transition check\. The contrast isolates implementation fidelity from Critic diagnosis\.![Refer to caption](https://arxiv.org/html/2610.11543v1/WebLoop_cases_combined_6.png)Figure 13:Refiner\-induced regression on Topic Trending \(WebRise\)\.While addressing missing liked\-state feedback, the Refiner conflates the user’s like state with the aggregate like count, causing the count\-update predicate to regress from PASS to FAIL\.

## Appendix DPrompt Templates

WebLoop utilizes role\-specific prompts to instantiate the Generator, Critic, and Refiner within the shared policy\.

Generator\.The Generator prompt in[Fig\.14](https://arxiv.org/html/2610.11543#A4.F14)directly maps the task specification to a complete self\-contained HTML implementation, restricting the output to executable code without auxiliary explanation\.

Critic\.The Critic prompt in[Fig\.15](https://arxiv.org/html/2610.11543#A4.F15)adopts an execution\-free red\-team perspective, requiring requirement\-level judgments from the specification and source code alone and structured repair guidance for detected failures\.

Refiner\.The Refiner prompt in[Fig\.16](https://arxiv.org/html/2610.11543#A4.F16)places diagnosed defects before the prior implementation, encouraging targeted rewrites while preserving unflagged behavior\.

GeneratorYou are an expert frontend developer\. Given a task description and a set of functional requirements, produce a single, complete, self\-contained HTML file that fulfills all requirements\.Rules:1\.Output only the HTML code, starting with<\!DOCTYPE html\>and ending with</html\>\.2\.Do not include any explanation, markdown fences, or commentary\.3\.Inline all CSS and JavaScript; no external files\.4\.The page must be fully functional on first load, with realistic placeholder data\.5\.Implement every explicit requirement completely\.Input:the task statement\{input\_text\}, which already carries the prose requirements and the test data contract, so the generator builds against exactly the statement the evaluation is derived from\.Output:the complete HTML page, with no surrounding prose\.

Figure 14:Generator prompt for first\-pass Web generation\.CriticYou are a red\-team QA engineer\. Your explicit goal is to break this self\-contained HTML page\. You are given the task it was built for, its explicit requirements \(each with an id\), and the page\. You have no automated test results — find breakage by reading the JavaScript\. Assume every requirement is broken until the code proves otherwise; a polished\-looking UI is not proof\.Where the attacks come from:the strongest attacks come from the*implicit constraints*each explicit requirement entails — the sub\-behaviours a careful spec author derives from it: validation of invalid inputs \(negative, zero, empty, non\-numeric, out\-of\-range\); persistence across save, re\-selection, and re\-render; consistency while a filter or sort is active or after the data changes; reversibility \(add↔\\leftrightarrowdelete, enable↔\\leftrightarrowclear\); and robust DOM handling under repeated or out\-of\-order use\.Procedure, for each explicit requirement:1\.Derive the implicit constraints it entails\.2\.Find the input or action sequence most likely to violate one, and confirm the failure in the code\.3\.Marksatisfiedtrue only if you could not break the explicit behaviour or any entailed constraint\.Output rules:1\.Keep any internal reasoning extremely brief \(at most a few sentences per requirement\)\. Do not re\-list task data, never re\-enumerate every element of an input array, never quote every field, and never repeat a check already made\.2\.Do not loop on the same doubt; after one brief re\-check, commit to a verdict and move on\.3\.Respond with a single JSON object and nothing after it: no reasoning after the JSON, no markdown fences around it\.4\.Emit exactly one entry per requirement id given, in the same order, each with a booleansatisfied\.5\.Includefixonly wheresatisfiedis false\. It must state the breaking case, the entailed constraint it violates, the code defect, and the concrete change — describing behaviour and code without mentioning any requirement id\.6\.Insidefixstrings use plain prose; do not quote code with backticks or backslashes, which break JSON parsing\.Output:Return exactly one JSON object:\{"requirements": \[ \{"id": "<requirement id\>", "satisfied": true\}, \{"id": "<requirement id\>", "satisfied": false, "fix": "\.\.\."\} \]\}

Figure 15:Critic prompt for requirement\-level diagnosis and repair guidance\.RefinerYou are an expert frontend developer fixing a web page that failed automated testing\. A reviewer has flagged specific broken features, each with the defect and the fix\.Treat the existing code for every flagged feature as broken — do not trust or copy it\. For each flagged defect, delete the current implementation of that feature and rewrite it from scratch so the described interaction works correctly: correct input validation, state updates, persistence, and DOM handling\. Keep the code only for features the reviewer did*not*flag\.Rules:1\.For every flagged defect, rewrite that feature’s JavaScript and DOM logic fresh; do not merely tweak the old code\.2\.Preserve unflagged, working features as\-is\.3\.Output only the corrected HTML, from<\!DOCTYPE html\>to</html\>\. No commentary, no markdown fences\. Inline all CSS and JavaScript\.Input layout:the prompt presents, in this order, the defect list to apply \(\{critique\}\), what the page must do \(\{input\_text\}\), and the current page to repair \(\{prev\_html\}\)\. Foregrounding the defects before the previous page is deliberate: the refiner otherwise inherits a strong prior to copy its own earlier output and ignore the critique\.Output:the corrected, complete HTML page, with every flagged feature rewritten\.

Figure 16:Refiner prompt for critique\-conditioned Web repair\.