WebDesignIter: Co-Evolving Design Knowledge for Repository-Level Front-End Code Generation Zheng Pei
Mingwei Liu
Sun Yat-sen University Zhuhai Key Laboratory of Trusted Large Language Models Zhuhai, China [email protected]
School of Software Engineering, Sun Yat-sen University Zhuhai Key Laboratory of Trusted Large Language Models Zhuhai, China [email protected]
Zhenxi Chen
Zihao Wang
Sun Yat-sen University Zhuhai Key Laboratory of Trusted Large Language Models Zhuhai, China [email protected]
Sun Yat-sen University Zhuhai Key Laboratory of Trusted Large Language Models Zhuhai, China [email protected]
arXiv:2607.10621v1 [cs.SE] 12 Jul 2026
Yanlin Wang Sun Yat-sen University Zhuhai Key Laboratory of Trusted Large Language Models Zhuhai, China [email protected]
Abstract—Front-end development accumulates change after change at the repository level, weaving complex cross-file dependencies that current LLM coding agents tuned for single-shot tasks cannot reliably track across multiple iterations, leading to functional regressions and code that resists maintenance. We argue the missing piece is design knowledge: architectural principles, module responsibilities, and structural constraints that developers lean on to keep code readable, maintainable, and evolvable as a system scales. To operationalize this, we propose WebDesignIter, a framework built around a persistent knowledge graph (WebAppArchKG) that fuses repository structure with design knowledge and keeps both in sync across development cycles. WebDesignIter works in two stages: design-informed planning pulls historical context and architectural overviews from WebAppArchKG to produce an implementation plan with corresponding test scripts, and design-aware generation executes that plan through targeted diff-based patches, validated by sandbox execution and automatic syntax repair. On Web-Bench, WebDesignIter delivers an average Pass@2 gain of 9.55 percentage points across nine foundation models over existing baselines. More importantly, WebDesignIter outperforms every general-purpose coding agent Claude Code, OpenHands, SWE-Agent, Codex CLI on every model configuration, posting the highest Pass@1 and Pass@2 while consuming 2530 fewer input tokens. Ablation singles out design knowledge as the most impactful component: stripping it drops Pass@1 by 11.40 percentage points, a degradation far larger than removing codegraph retrieval, patch-based generation, or sandbox verification, confirming that design knowledge provides a fundamentally more efficient and reliable path to repository-level code generation. Index Terms—Code Generation, Front-end Repository-Level Code, Design Knowledge, Incremental Development
Front-end development is critical in modern software systems, as it directly impacts user interaction quality and overall usability. Compared to back-end development, it involves
a heterogeneous technology stack and strongly componentoriented structures [1], encompassing multiple file types (e.g., HTML, CSS, JavaScript/TypeScript, and configuration files) and complex cross-file and cross-component dependencies [2]. In practice, front-end development evolves incrementally at the repository level [3], where new features are added while preserving existing functionality. This tightly coupled, continuously evolving paradigm challenges repository-level code generation and maintenance, particularly regarding semantic understanding, contextual construction, and regression risk. Large language models (LLMs) have recently become primary assistive tools in front-end development and have demonstrated strong performance across a wide range of software engineering tasks, including code generation, completion, translation, security analysis, and automated repair [4]– [11]. Building on these advances, agent-based approaches [12] and the Vibe Coding paradigm [13] have gained popularity. However, these methods typically optimize for singletask completion and struggle in long-term, continuously evolving repositories, where they often induce functional degradation or regressions of previously implemented features. Most existing front-endoriented research further focuses on UI2Code paradigms [14]–[18], which translate visual interface designs into code. While effective for prototyping, such approaches often produce simplified implementations with limited interactivity and fail to capture the complexity of realworld front-end repositories that evolve incrementally over time [19]. As a result, one-shot UI-to-code generation remains insufficient for realistic front-end engineering workflows.
A key missing component in existing approaches is design knowledge—the structured understanding of a software system’s architecture, encompassing component responsibilities, module boundaries, dependency constraints, and the design rationale behind structural decisions. In real-world frontend development, such knowledge is essential for longterm readability, maintainability, and evolution [20]. Poor design practices easily lead to “spaghetti code”, such as mixing presentation, styling, and business logic within the same file, as illustrated in Figure 1. This significantly increases the cost of understanding and modifying code in subsequent iterations while reducing code readability and maintainability. Moreover, such low-quality designs introduce redundant and irrelevant information, inflating the contextual burden on LLMs and further degrading generation quality. Case 1 :Model output format
Case 2 :Modularized output format
blog.ts import { Component, Input } from '@angular/core'; @Component({
blog.ts import { Component, Input } from '@angular/core'; @Component({ selector: 'app-blog',
selector: 'app-blog',
standalone: true,
standalone: true,
templateUrl: './blog.html',
imports: [], template: `
<div> <h2 class="blog-title">{{ title }}</h2>
styleUrls: ['./blog.css'] }) export class BlogComponent { @Input() title!: string;
<p>{{ detail }}</p> </div> `,
@Input() detail!: string; }
styles: ` .blog-title {
width: fit-content;
<div>
<h2 class="blog-title">{{ title }}</h2>
font-size: 24px; } `,
<p>{{ detail }}</p> </div>
blog.css
}) export class BlogComponent { @Input() title = '';
.blog-title { width: fit-content;
@Input() detail = ''; }
(1) Poor readability and maintainability
blog.html
font-size: 24px; }
(2) Good readability and maintainability
Fig. 1: The impact of modularized output formats and model output formats on readability and maintainability
Recent benchmarks, such as Web-Bench [19], target incremental, multi-task, and repository-level front-end development settings and systematically expose the complexity and challenges of these scenarios by simulating realistic software development workflows. On this benchmark, Web-Agent [19] achieves only 42.40% Pass@2 and an even lower 26.40% Pass@1, indicating limited overall performance and suggesting that the majority of tasks remain difficult to complete successfully. These results further demonstrate that even state-ofthe-art agent-based approaches struggle in such environments, largely due to their limited ability to integrate design knowledge and reason about system-level dependencies, which often leads to loosely structured and poorly maintainable code. Addressing these challenges requires overcoming three fundamental obstacles: (1) design knowledge and repository information must be persistently maintained and co-evolved across iterations to preserve global consistency; (2) automated refactoring of poorly structured code is necessary to sustain long-term readability and reduce contextual noise; and (3)
precise cross-file and cross-component context construction is essential for effective repository-level generation in heterogeneous front-end systems. To this end, we propose WebDesignIter, a designknowledge-driven framework for incremental frontend repository-level code generation. WebDesignIter maintains a persistent repository-level knowledge graph (WebAppArchKG) that integrates code structure and design knowledge, supporting a two-stage generation pipeline: the Design-informed Planning stage generates an Implementation Plan driven by Design Knowledge, followed by the Designaware Generation stage, which produces precise code modifications. By explicitly embedding design knowledge into the generation process, applying code changes, fixing syntax errors, refactoring spaghetti-like files to enhance readability and maintainability, and validating correctness in a sandbox before finally updating WebAppArchKG, WebDesignIter enables incremental, maintainable, and verifiable front-end development. Experiments on Web-Bench [19] show that WebDesignIter achieves state-of-the-art performance, with an average improvement of 7.98% in Pass@1 and 9.55% in Pass@2 over existing baselines. WebDesignIter also outperforms generalpurpose coding agents—including Claude Code, OpenHands, SWE-Agent, and Codex CLI—across every model configuration, attaining the highest Pass@1 and Pass@2 while consuming 25–30× fewer input tokens. Ablation studies confirm the critical role of design knowledge, whose removal causes a 11.40% drop in Pass@1. Maintainability analysis further shows that WebDesignIter reduces average file length and repository complexity, enhancing code readability. In summary, our contributions are threefold: • Design Knowledge-Guided Front-End RepositoryLevel Code Generation: We integrate design knowledge into front-end repository-level code generation. HighLevel Design produces an abstract implementation plan, while Low-Level Design uses this plan to generate precise, functionally complete code diff patches. • Construction of WebAppArchKG: Our knowledge graph maintains design knowledge, historical design, and repository structure, supports update strategies and crossfile component associations, and automatically refactors poorly structured code to improve readability and maintainability. • Diff Patch and Syntax Check Mechanisms: We employ incremental diff patches to avoid regressions caused by full-file regeneration and integrate syntax checking, making the workflow compatible with incremental development rather than wholesale replacement. I. M ETHOD We propose a novel framework, referred to as WebDesignIter, as illustrated in Fig. 2. Our approach integrates a code knowledge graph with established software engineering design paradigms to emulate the cognitive processes of professional developers, enabling robust architectural-level reasoning and
iterative adaptation to evolving requirements. In addition, we incorporate a rule-based refactoring mechanism to systematically restructure spaghetti-like code files, thereby substantially improving the maintainability and readability of the codebase. Furthermore, we employ a sandboxed execution environment in conjunction with automated test scripts to verify the consistency between the generated code and user requirements. This design establishes a closed-loop feedback mechanism in which test outcomes continuously trigger updates to both the WebAppArchKG. As a result, the framework promotes long-term consistency, correctness, and maintainability of the generated codebase. As shown in Figure 2, the proposed framework consists of four sequential stages: 1) Architectural Knowledge Extraction and Evolution: The initial code repository is first transformed into a knowledge graph that captures cross-file structural and semantic relationships. In parallel, a design blueprint is initialized by integrating historical design knowledge, the repository structure, and high-level architectural overview information. Prior to updating WebAppArchKG, we apply rule-based refactoring to spaghettilike code files to ensure that the information maintained in WebAppArchKG is grounded in good maintainability and readability. 2) Design-informed Planning: Given the current user requirements, the framework retrieves relevant historical design information, repository structure, and architectural overview data from WebAppArchKG. If feedback from previous iterations is available in WebAppArchKG, these design and feedback signals are jointly provided to the LLM to generate an Implementation Plan and a corresponding set of Test Scripts. 3) Design-aware Generation: Guided by the Implementation Plan, the framework performs priority-aware execution by retrieving relevant contextual nodes from the code graph in WebAppArchKG. Code changes are generated in the form of diff-based patches, enabling precise and minimal modifications to the existing codebase. 4) Repo-Verification: The generated patches are applied incrementally. The framework first performs AST-based static analysis to detect potential syntax errors; if any are found, the LLM is invoked to repair the patch in isolation. If the static checks pass, the patch is validated in a sandboxed environment. Upon successful validation, rule-based refactoring is applied to any newly introduced spaghetti-like code, followed by an update to WebAppArchKG. If validation fails, a feedback mechanism is triggered to record the failure signals in WebAppArchKG, which are then used to regenerate the Implementation Plan. A. Architectural Knowledge Extraction and Evolution In this stage, we focus on systematically extracting and continuously evolving architectural knowledge from the initialized front-end repository. By analyzing the repository, we
construct the WebAppArchKG, which provides an explicit and machine-interpretable, repository-level representation of file-level and component-level dependencies. It captures the semantic information of the code and explicitly models the connections between design knowledge and the code repository, as illustrated in Figure 3. This representation forms the foundation of the architectural knowledge and is progressively refined throughout subsequent iterations. The extraction and evolution process consists of the following steps: Extract architectural primitives by parsing source files into abstract syntax trees and segmenting them into blocklevel units, as shown in Figure 4. • Infer and refine cross-file architectural relationships by analyzing inter-block references and dependency patterns across the repository. • Evolve the architectural representation by refactoring heterogeneous code structures, extracting embedded code written in different languages into separate files, and reconstructing dependencies using the same extraction pipeline. • Initialize the design knowledge in WebAppArchKG, which represents the current state of the codebase as well as its complete design information and architectural memory. •
Architectural Primitive Extraction. As illustrated in Figure 4, each source file is parsed using abstract syntax tree analysis. We employ Tree-sitter to extract descendant blocklevel nodes from the syntax tree and treat them as architectural primitives. These primitives constitute the fundamental units of architectural knowledge and enable fine-grained modeling of component structure and behavior in downstream stages. Architectural Relationship Inference. Building upon the extracted primitives, we infer architectural relationships at both coarse-grained and fine-grained levels. At the coarsegrained level, file-level dependencies are identified by detecting explicit inclusion and import signals, such as <script> tags in HTML files and import statements in JavaScript or TypeScript files. At the fine-grained level, we analyze inter-block references to identify selectors, identifiers, and referenced elements, and align them with symbols defined in related files. When a correspondence is established, a precise architectural linkage is recorded in the WebAppArchKG, progressively refining the architectural representation. This process links cross-file and interrelated code components within WebAppArchKG, constructing a componentcentric Code Graph that fully captures contextual information, thereby enabling precise understanding and reasoning over the code. Architectural Evolution via Refactoring. To enable the continuous evolution of extracted architectural knowledge, the system scans both during WebAppArchKG initialization and upon receiving modified code files to detect embedded heterogeneous code fragments, such as JavaScript within HTML
(1) Architectural Knowledge Extraction and Evolution
(2) Design-informed Planning
User Requirement
Web Code Repository WebProject-ArchKG src
Design Info
……
project
……
Code Graph
Rule-Based Refactoring
Design Info
Overview Design
Retrieve
Relevant Code Node
Code Graph Node
Implementation Plan File To Modify
File To Create
path: index.js reason: We Need to …… priority: 1 dependence: no
path: components/header/xx.js reason: We Need to …… priority: 4 dependence: 3
N
Design File Patch
……
……
Error Info Pass?
Repo Structure
Design Knowledge
Update
Rollback Regenerate
Y
Historical Design
Retrieve
path: index.html reason: We Need to …… priority: 2 dependence: 1
path: components/main/xx.js reason: We Need to …… priority: 3 dependence: no
Test
Sandbox (4) Repo-Verification
Apply
Syntax Check
Test Script
(3) Design-aware Generation
Fig. 2: Overview of WebDesignIter.
files or HTML snippets within TypeScript files. Using a rulebased extraction strategy, these fragments are separated into new files, while the original files are updated to maintain consistency. This refactoring step evolves the architectural representation by improving modular boundaries, reducing file complexity, and preserving consistency within the dependency structure encoded in the knowledge graph. Architectural Memory Initialization. Finally, the framework clears the Historical Design within the Design Knowledge in WebAppArchKG, while the Repository Structure is constructed as a tree representation derived from the initial directory layout. The Architectural Overview is initialized as empty, allowing it to be gradually populated and updated throughout successive design and implementation cycles. B. Design-informed Planning In this stage, we transform user requirements into a systemlevel high-level design plan that emulates a realistic software development workflow. The primary objective of this plan is to guide the LLM, acting as a developer, to reason over the repository structure, the architectural overview, and the historical design context, and to synthesize a structured modification strategy. This strategy explicitly specifies which files should be modified or created, the recommended order of execution, and the existing artifacts that should be referenced. By providing sufficient and accurate contextual grounding, the plan supports subsequent code generation and effectively mitigates the risk of hallucinated or inconsistent outputs. In parallel, the framework automatically derives a set of endto-end test scripts aligned with the intended functionality of the design plan. These tests serve as an executable specification
of functional correctness and provide a verification mechanism for the generated implementation. Specifically, the process can be divided into the following two steps: Design Knowledge-Guided Implementation Plan Generation. In this step, WebDesignIter automatically retrieves the corresponding Design Info from WebAppArchKG based on the user requirements and current state. Specifically, the system queries the latest state of WebAppArchKG and retrieves the stored records of the most recent Historical Design. It then scans the directory structure in WebAppArchKG, organizing it into a tree representation presented as the Repo Structure. Finally, the system extracts the file-level Overview Design from each file node, organizes it in an ordered manner, and returns it as complete Design Info to guide the LLM in generating the Implementation Plan. Design Knowledge-Guided Test Script Generation. The generation of test script is performed synchronously within the aforementioned workflow. A sample is provided here to illustrate the required output format. The reason for not generating them separately is that doing so may prevent the model from accurately understanding its most recent actions, potentially resulting in test scripts that do not align with the task requirements. C. Design-aware Generation In the design-aware generation phase, the framework follows the Implementation Plan produced in the previous stage and executes code generation in a priority-aware manner. For each planned operation, the framework references the contextual information of dependent files and retrieves preestablished dependencies from the WebAppArchKG. Neighboring nodes related to the target files are automatically
Metadata content: document.addEventListener( 'DOMContentLoaded', () => {const addressSelect = document.querySelector('.ad dress’) ……
extension: .js node_type: expression_statement path: index.js@0_952
CLASS statement
…… Import Tag
HTML File
……
JavaScript File
Metadata
History design: Task-1:Add topbar element (class 'topbar') and page iframe (class 'content', name 'content') in the browser element. topbar and content together fill the entire space of the browser element. No other elements in browser element. Task-2: ……
DOM Tag
HTML File
DOCS
HTML File
ROOT
Rule Block
HTML File
content: Complete code Path: XX/XX.html Summary: XXXXX.
Metadata
Import statement
Design Knowledge CSS File
Historical Design
HAS_ELEMENT
Rule Block
TypeScirpt File
Repo Structure
Rule Block Function statement
Rule Block
Fig. 3: Schema of WebAppArchKG.
Code Content import { Component } from '@angular/core' import { HeaderComponent } from './components/header/header.component'; import { MainComponent } from './components/main/main.component'; @Component({ selector: 'app-root', imports: [HeaderComponent, MainComponent], template: `……`, styles: `……`, }) export class AppComponent { title = 'angular' }
import_statement import { Component } from '@angular/core' import { HeaderComponent } from './components/header/header.component'; import { MainComponent } from './components/main/main.component';
export_statement @Component({ selector: 'app-root', imports: [HeaderComponent, MainComponent], template: `……`, styles: `……`,})
class_statement export class AppComponent {title = 'angular'}
Fig. 4: An Example of Code Content Segmentation into Blocks.
included in the prompt to construct a well-founded contextual representation, preventing the model from generating fabricated outputs due to incomplete knowledge of repository-level dependencies. Based on this enriched contextual grounding, the system generates a corresponding set of Design File Patches for each high-level design action, ensuring that the implementation remains aligned with the intended architectural and functional objectives. Context Construction Based on the WebAppArchKG. In our approach, the WebAppArchKG is constructed in advance and serves as a structured source of contextual information during code generation. When generating code, the system automatically retrieves nodes connected by relevant edges in the graph and aggregates their associated information as contextual input. As illustrated in Figure 5, the retrieval of semantically and structurally related code context enables
the model to reason about which existing artifacts should be referenced, rather than fabricating nonexistent functions or interfaces, thereby substantially reducing the risk of hallucinated outputs. Unified Patch-Based Output Format. We adopt a patchbased output representation rather than generating complete source files. To the best of our knowledge, most existing studies [21], [22] focus on full-file code generation, which significantly increases token consumption and introduces the risk of inadvertently overwriting correct code or hallucinating the removal of valid implementations. To address these issues, the system uses a unified diff format to represent code modifications in a minimal and localized manner. Furthermore, since LLMs often struggle to accurately track line numbers and boundaries, a rule-based mechanism is employed to automatically correct erroneous diff outputs, including incorrect start and end line indices. This mechanism ensures that the generated patches can be reliably and consistently applied to the target repository. D. Repo-Verification At this stage, the system directly applies the diff-based patch generated in the previous stage to the target codebase. It then performs an abstract syntax tree analysis to detect potential syntax errors. If no errors are found, execution proceeds; if errors are detected, the LLM is invoked to repair the individually modified files. If repairs fail more than twice, the LLM generates the complete current code guided by the patch to ensure that the intended changes can be correctly applied. After successful repair, the updated codebase is deployed in a Docker-based sandbox environment for verification, where
Fine-grained Modification Design （No Retrieval Code Block） Code File
Wrong Code
Design Reason
import { Component } from '@angular/core’; …… @Component({ …… imports: [BlogComponent, BlogListComponent], template: ` <main class="main"> <app-blog-list [blogs]="blogs"></app-blog-list> <app-blog [title]="blogs[0].title" [detail]="blogs[0].detail"></app-blog> </main> `, styles: `……` }) export class MainComponent { blogs = [……];}
1)Introduce a selection state and bind a click event to update app-blog content dynamically. 2) Initialize the selection state to the first item of the blogs array. 3) Add visual styles like background color to enhance aesthetics without altering layout dimensions.
I don't understand BlogComponent and BlogListComponent.
Fine-grained Modification Design （With Retrieval Code Block） Code File
Design Reason
import { Component } from '@angular/core’; …… @Component({ …… imports: [BlogComponent, BlogListComponent], template: ` <main class="main"> <app-blog-list [blogs]="blogs"></app-blog-list> <app-blog [title]="blogs[0].title" [detail]="blogs[0].detail"></app-blog> </main> `, styles: `……` }) export class MainComponent { blogs = [……];}
1)Introduce a selection state and bind a click event to update app-blog content dynamically. 2) Initialize the selection state to the first item of the blogs array. 3) Add visual styles like background color to enhance aesthetics without altering layout dimensions.
…… @Component({ imports: [BlogComponent, BlogListComponent], template: ` <main class="main"> <app-blog-list [items]="blogs" [active]="currentIndex" (onClickItem)="changeBlog($event)" ></app-blog-list> <app-blog [data]="currentData"></app-blog> </main>`, styles: `……`}) …… currentIndex = 0; currentData = null; changeBlog(index: number) {this.currentIndex = index;}}
Right Code
Relevant Context ../blog/blog.component @Component({……}) export class BlogComponent { @Input() title = ''; @Input() detail = ‘’;} ../blog-list/blog-list.component @Component({……}) export class BlogListComponent { @Input() blogs: { title: string; detail: string; }[] = []; @Input() selectedBlog: { title: string; detail: string; } | null = null; @Output() blogSelected = new EventEmitter<{ title: string; detail: string; }>(); selectBlog(blog: { title: string; detail: string; }) { this.blogSelected.emit(blog);}}
I understand BlogComponent and BlogListComponent.
…… @Component({ …… imports: [BlogComponent, BlogListComponent], template: ` <main class="main-content"> <div class="blog-list-container"> <app-blog-list [blogs]="blogs" [selectedBlog]="selectedBlog" (blogSelected)="onBlogSelected($event)"> </app-blog-list></div> <div class="blog-detail-container"> <app-blog [title]="selectedBlog.title" [detail]="selectedBlog.detail"></app-blog> </div></main>`, styles: `……`,}) …… selectedBlog = this.blogs[0]; onBlogSelected(blog: { title: string; detail: string; }) { this.selectedBlog = blog;}}
Fig. 5: Impact of WebAppArchKG–Based Retrieval on Generated Code Correctness.
the test scripts produced during the high-level system design phase are executed to ensure that the generated implementation meets user requirements. Upon successful validation, the system performs a refactoring scan of the applied code, and both the refactored and unrefactored files are fed into WebAppArchKG for node expansion and dependency construction. Meanwhile, a LLM summarizes the newly implemented functionalities from this deployment, which are incorporated into the Overview Design within the Design Knowledge. The historical requirements are recorded and added to the Historical Design, updating WebAppArchKG and the Repository Structure accordingly.
II. E VALUATION To evaluate the effectiveness of WebDesignIter, we conduct extensive experiments addressing the following research questions: RQ1 (Effectiveness): How does WebDesignIter perform in terms of task completion and reliability for incremental front-end repository-level code generation, compared to the Web-Agent baseline? • RQ2 (Ablation Study): How do the individual components of the framework contribute to its overall effectiveness? • RQ3 (Robustness and Maintainability): How do the design paradigm and refactoring strategies in WebDesignIter affect failure modes and code maintainability? • RQ4 (Cost Efficiency): How do representative generalpurpose coding agents compare in task completion, token consumption, and cost-effectiveness? •
A. Experimental Setup Benchmark. We adopt Web-Bench [19], the first benchmark specifically designed for natural-language-to-repositorylevel frontend code generation. The benchmark comprises 50 projects, each with 20 sequential tasks that introduce new requirements depending on the repository state produced by prior tasks—closely reflecting real-world incremental frontend development. Projects span modern frameworks including Vue, Angular, and Tailwind. Baseline. We adopt Web-Agent [19] as our primary baseline— the only publicly evaluated agent designed for repositorylevel front-end code generation, leveraging file manipulation tools and a RAG system. In addition, we compare against four widely adopted general-purpose coding agents—Codex CLI, Claude Code, OpenHands, and SWE-Agent—to assess how representative tools perform on front-end tasks without design knowledge. While these agents have demonstrated strong results on general software engineering benchmarks such as SWE-bench, they were not designed for the incremental, heterogeneous, multi-framework nature of front-end development. Most existing studies [22]–[25] target non-frontend tasks, while front-end approaches remain limited to singlecomponent UI generation or design-to-UI conversion [16], [17], [26], operating at shallow abstraction levels that fail to capture real-world repository-level workflows. Evaluated Models. For RQ1–RQ3, we follow the original Web-Bench study [19] and evaluate the same nine foundation models spanning the Gemini, Claude, Qwen, OpenAI, and DeepSeek series: Gemini 2.5 Pro, Claude 4 Sonnet, GPT4.1, GPT-4o, O4-Mini, Qwen-Max, Qwen-Plus, DeepSeek-V3, and DeepSeek-R1. For RQ4, we extend the evaluation to two additional model families—DeepSeek V4 (Pro and Flash) and
Qwen 3.5 (Plus and Flash)—paired with general-purpose coding agents and WebDesignIter under identical benchmark conditions. All models are evaluated on the same set of projects for fair comparison. This setup provides a stronger stress test: the RQ4 models and general-purpose agents represent more recent and capable configurations, making WebDesignIter’s consistent outperformance across all of them a particularly stringent validation of its design-knowledge-driven approach. B. RQ1: Effectiveness Design. We compare WebDesignIter against Web-Agent across the same nine foundation models originally evaluated in the Web-Bench study [19] on the full benchmark. For each configuration, we report Pass@1 (fraction of tasks completed on the first attempt), Pass@2 (fraction completed within two attempts). All metrics are computed across the complete set of 50 projects. To complement the aggregate metrics, Figure 6 visualizes the per-project task completion distribution via boxplots, revealing variability and outlier behavior across projects.