ai-research-survey

scan.json (32405B)

---

 {
   "paper": {
     "title": "DesignBench: A Comprehensive Benchmark for MLLM-based Front-end Code Generation",
     "authors": [
       "Jingyu Xiao",
       "Man Ho Lam",
       "Ming Wang",
       "Yuxuan Wan",
       "Junliang Liu",
       "Yintong Huo",
       "Michael R. Lyu"
     ],
     "year": 2026,
     "venue": "Conference '26 (ACM)",
     "arxiv_id": "2506.06251",
     "doi": "10.48550/arXiv.2506.06251"
   },
   "scan_version": 3,
   "active_modules": ["experimental_rigor", "data_leakage"],
   "methodology_tags": ["benchmark-eval"],
   "key_findings": "DesignBench evaluates 9 MLLMs across 3 front-end frameworks (React, Vue, Angular) and vanilla HTML/CSS on generation, edit, and repair tasks using 900 webpage samples. Claude-3.7, GPT-4o, Gemini-2.0, and Pixtral-124B are the top performers, but all models struggle significantly with framework-specific syntax (especially Angular) and show very low adoption of component-based design patterns (0.24% for React). Code-only input consistently outperforms image-only and even multimodal input for edit and repair tasks, suggesting MLLMs underutilize visual information. UI issue detection accuracy averages only 27.1% across all models and frameworks.",
   "checklist": {
     "artifacts": {
       "code_released": {
         "applies": true,
         "answer": true,
         "justification": "The paper states 'Our code and data are available at https://github.com/WebPAI/DesignBench' in the abstract and references [43]."
       },
       "data_released": {
         "applies": true,
         "answer": true,
         "justification": "The benchmark data (900 webpage samples) is released at the same GitHub repository. The paper states 'Our code and data are available at https://github.com/WebPAI/DesignBench.'"
       },
       "environment_specified": {
         "applies": true,
         "answer": false,
         "justification": "The paper specifies temperature=0 and max tokens but does not provide a requirements.txt, Dockerfile, or detailed environment setup section listing library versions needed to reproduce the evaluation pipeline."
       },
       "reproduction_instructions": {
         "applies": true,
         "answer": false,
         "justification": "The paper references the GitHub repo but does not include step-by-step reproduction instructions in the paper itself. No 'Reproducing Results' section or specific commands are provided."
       }
     },
     "statistical_methodology": {
       "confidence_intervals_or_error_bars": {
         "applies": true,
         "answer": false,
         "justification": "All results in Tables 5-10 are reported as point estimates (e.g., CLIP scores, MLLM scores) with no confidence intervals or error bars."
       },
       "significance_tests": {
         "applies": true,
         "answer": false,
         "justification": "The paper makes numerous comparative claims (e.g., 'Claude-3.7 achieves the highest performance', 'code-only input consistently outperforms image-only') based solely on comparing raw numbers without any statistical significance tests."
       },
       "effect_sizes_reported": {
         "applies": true,
         "answer": false,
         "justification": "Raw metric values are reported in tables but no formal effect sizes (Cohen's d, relative improvement with baseline context, etc.) are computed. Differences between models or conditions are described qualitatively without quantifying effect magnitudes."
       },
       "sample_size_justified": {
         "applies": true,
         "answer": false,
         "justification": "The benchmark contains 900 samples (430 generation, 359 edit, 111 repair) but no justification is given for why these sizes are adequate. No power analysis is discussed."
       },
       "variance_reported": {
         "applies": true,
         "answer": false,
         "justification": "Results are from single runs with temperature=0. No variance, standard deviation, or spread measures across multiple experimental runs are reported."
       }
     },
     "evaluation_design": {
       "baselines_included": {
         "applies": true,
         "answer": true,
         "justification": "Nine MLLMs are compared against each other across all tasks and frameworks. Table 1 also compares DesignBench against prior benchmarks (Pix2code, WebSight, Web2Code, WebCode2M, Design2Code)."
       },
       "baselines_contemporary": {
         "applies": true,
         "answer": true,
         "justification": "The evaluated models include state-of-the-art MLLMs: Claude-3.7-sonnet (Feb 2025), GPT-4o (Nov 2024), Gemini-2.0-Flash, Qwen2.5-VL, and Llama-3.2-Vision, all contemporary at the time of evaluation."
       },
       "ablation_study": {
         "applies": true,
         "answer": true,
         "justification": "RQ4 (Section 6.4, Table 7) conducts an input context ablation study comparing code-only, image-only, and combined inputs for Design Edit and Repair tasks, systematically varying input modalities while keeping everything else constant."
       },
       "multiple_metrics": {
         "applies": true,
         "answer": true,
         "justification": "Six metrics are used: CLIP (semantic similarity), SSIM (structural similarity), CSR (compilation success rate), CMLS (code modification location similarity), CMCS (code modification content similarity), and MLLM-as-Judge scores."
       },
       "human_evaluation": {
         "applies": true,
         "answer": true,
         "justification": "Five PhD students conducted human validation of the MLLM-as-Judge metric by evaluating model outputs. Inter-annotator agreement was high (Kappa 0.8648 and 0.8428) and MLLM judge accuracy was 95.54% for edit and 91.89% for repair compared to human majority votes."
       },
       "held_out_test_set": {
         "applies": true,
         "answer": true,
         "justification": "The benchmark is used as a zero-shot test set. Models are not trained or tuned on any portion of DesignBench data; all 900 samples serve as evaluation-only data."
       },
       "per_category_breakdown": {
         "applies": true,
         "answer": true,
         "justification": "Extensive breakdowns are provided: by framework (React/Vue/Angular/Vanilla), by task (generation/edit/repair), by difficulty level (easy/medium/hard in Table 6), by input context (Table 7), by edit type, by issue type, and by failure category (Figure 9)."
       },
       "failure_cases_discussed": {
         "applies": true,
         "answer": true,
         "justification": "RQ6 (Section 6.6) provides systematic failure analysis with 22 failure types across the three tasks. Figure 9 shows detailed failure type distributions for each model, including compile errors, layout disorder, wrong objects, partial edits, and no-repair attempts."
       },
       "negative_results_reported": {
         "applies": true,
         "answer": true,
         "justification": "Multiple negative findings are reported: very low component-based design adoption (0.24% for React, Table 9), poor UI issue detection accuracy (27.14% average, Table 10), severe Angular compilation challenges, and multimodal input providing minimal benefit over code-only."
       }
     },
     "claims_and_evidence": {
       "abstract_claims_supported": {
         "applies": true,
         "answer": true,
         "justification": "The abstract claims about framework-specific limitations (supported by RQ2, Table 5, Fig. 6), task-related bottlenecks (supported by RQ1), and performance variations (supported by RQ3-RQ4) are all substantiated by corresponding experimental results in Sections 6.1-6.6."
       },
       "causal_claims_justified": {
         "applies": true,
         "answer": true,
         "justification": "The main causal-ish claims come from the input context ablation (RQ4), where code-only vs image-only vs both are compared in a controlled manipulation. The claim 'code representations convey more precise semantic information' is hedged with 'suggesting' and supported by the controlled experiment varying only the input type."
       },
       "generalization_bounded": {
         "applies": true,
         "answer": true,
         "justification": "The title specifies 'MLLM-based Front-end Code Generation' and findings are generally scoped to the tested frameworks and models. The external validity section (Section 7) explicitly acknowledges the limitation to React, Vue, and Angular frameworks."
       },
       "alternative_explanations_discussed": {
         "applies": true,
         "answer": false,
         "justification": "The paper does not discuss alternative explanations for its findings. For example, code-only outperforming image-only could be due to token budget differences, prompt design effects, or the specific way images are encoded, but none of these alternatives are considered."
       },
       "proxy_outcome_distinction": {
         "applies": true,
         "answer": true,
         "justification": "The paper clearly defines what each metric measures (CLIP for semantic visual similarity, SSIM for structural similarity, CSR for compilation, CMLS/CMCS for code modification quality) and validates the MLLM-as-Judge proxy against human evaluation (95.54% and 91.89% accuracy). Claims match the granularity of measurements."
       }
     },
     "setup_transparency": {
       "model_versions_specified": {
         "applies": true,
         "answer": true,
         "justification": "Table 4 lists specific model versions for 7 of 9 models: GPT-4o-2024-11-20, Claude-3-7-sonnet-20250219, Pixtral-12B-2409, Qwen2.5-VL-7B/72B-Instruct, Llama-3.2-11B/90B-Vision-Instruct. Two exceptions lack snapshot dates: Gemini-2.0-Flash and Pixtral-large-latest (a floating tag)."
       },
       "prompts_provided": {
         "applies": true,
         "answer": false,
         "justification": "Figure 5 shows only simplified prompt templates with placeholders like '<framework>', '<instruction>', '{code}', and '<image>'. The paper states 'detailed prompts available in our code [43]' but does not include the actual prompt text used in experiments."
       },
       "hyperparameters_reported": {
         "applies": true,
         "answer": true,
         "justification": "Section 5.2 states: 'we set the temperature to 0 and the maximum number of tokens output as the upper limit of MLLMs' maximum output token. All other parameters are kept at their default settings.'"
       },
       "scaffolding_described": {
         "applies": false,
         "answer": false,
         "justification": "No agentic scaffolding is used. Models are prompted once and generate code output directly without tool use, retry logic, or multi-turn feedback loops."
       },
       "data_preprocessing_documented": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.2 documents the full data collection and processing pipeline for each task: GitHub/top 500 collection, single-file tool for saving, image placeholder replacement, Selenium screenshots, V0/Vue0 crawling with filtering criteria, annotator quality assessment with majority voting, and GPT-4o translation for Angular/Vanilla edit samples."
       }
     },
     "limitations_and_scope": {
       "limitations_section_present": {
         "applies": true,
         "answer": true,
         "justification": "Section 7 'Threats to Validity' provides substantive discussion of internal and external validity threats."
       },
       "threats_to_validity_specific": {
         "applies": true,
         "answer": true,
         "justification": "Section 7 discusses specific threats: MLLM-as-judge reliability (mitigated by human validation with 95.54% accuracy), data leakage from closed applications and manually-written ground truth, and limitation to three specific frameworks. These are specific to this study."
       },
       "scope_boundaries_stated": {
         "applies": true,
         "answer": true,
         "justification": "External validity explicitly states: 'We only include limited frameworks of React, Vue, and Angular' and explains the rationale. Section 3.2 also notes that interactive and multi-page applications (Interaction2Code, MRWeb) are 'out of our scope.'"
       }
     },
     "data_integrity": {
       "raw_data_available": {
         "applies": true,
         "answer": true,
         "justification": "The benchmark data is released at https://github.com/WebPAI/DesignBench, including webpage samples, annotations, and evaluation code, enabling independent verification."
       },
       "data_collection_described": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.2 provides detailed data collection procedures: GitHub projects (152 popular projects with deployed links, 4055 avg stars), Moz top 500 websites (158 framework-based webpages), V0 platform (541 React projects), Vue0 (1,349 Vue projects), and 120 webcode2m samples."
       },
       "recruitment_methods_described": {
         "applies": true,
         "answer": true,
         "justification": "Sample recruitment is well-described: GitHub search for framework-specific projects with star count filtering, Moz top 500 ranking for popular websites, V0/Vue0 platforms for edit task data with compilation filtering. Annotators are described as 'five PhD students with three years of front-end development experience.'"
       },
       "data_pipeline_documented": {
         "applies": true,
         "answer": true,
         "justification": "The full pipeline is documented in Section 4.2 with counts at each stage: Design Edit goes from 541+1,349 crawled projects → filtered for compilation + 2+ iterations → annotator quality assessment (3 clarity levels × 3 quality levels) → majority voting → 359 high-quality samples → 146 translated to Angular/Vanilla → verified by annotators."
       }
     },
     "conflicts_of_interest": {
       "funding_disclosed": {
         "applies": true,
         "answer": false,
         "justification": "No funding sources or acknowledgments section is present in the paper. University-affiliated researchers typically have grant funding but none is disclosed."
       },
       "affiliations_disclosed": {
         "applies": true,
         "answer": true,
         "justification": "Author affiliations are clearly listed: six authors from The Chinese University of Hong Kong and one from Singapore Management University. They are not affiliated with any of the evaluated model providers."
       },
       "funder_independent_of_outcome": {
         "applies": true,
         "answer": false,
         "justification": "No funding source is disclosed, so independence cannot be assessed. Without a funding disclosure statement, this criterion is not satisfied."
       },
       "financial_interests_declared": {
         "applies": true,
         "answer": false,
         "justification": "No competing interests or financial interests statement is present in the paper."
       }
     },
     "contamination": {
       "training_cutoff_stated": {
         "applies": true,
         "answer": false,
         "justification": "Section 5.3 reviews the training datasets of open-source models but does not state the training data cutoff dates for any of the 9 evaluated models."
       },
       "train_test_overlap_discussed": {
         "applies": true,
         "answer": true,
         "justification": "Section 5.3 discusses potential overlap: reviews training datasets of Qwen, Pixtral, and Llama (finding they don't include web HTML code), notes that design edit/repair data is unlikely contaminated due to proprietary instruction-code-image triples, and computes BLEU scores between generated and original code."
       },
       "benchmark_contamination_addressed": {
         "applies": true,
         "answer": true,
         "justification": "Section 5.3 addresses contamination through multiple arguments: half the webpages come from closed applications (top 500 websites), repair ground truth is manually written by developers, and Table 3 shows low BLEU scores (0.05-0.15) between generated and original code, indicating models are not memorizing."
       }
     },
     "human_studies": {
       "pre_registered": {
         "applies": false,
         "answer": false,
         "justification": "No human subjects are studied. The five PhD students serve as benchmark annotators and metric validators, not as research participants."
       },
       "irb_or_ethics_approval": {
         "applies": false,
         "answer": false,
         "justification": "No human subjects study is conducted. Annotators are creating/validating the benchmark, not being studied."
       },
       "demographics_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human subjects study. Annotators are described only as 'five PhD students with three years of front-end development experience.'"
       },
       "inclusion_exclusion_criteria": {
         "applies": false,
         "answer": false,
         "justification": "No human subjects study is conducted."
       },
       "randomization_described": {
         "applies": false,
         "answer": false,
         "justification": "No human subjects study is conducted."
       },
       "blinding_described": {
         "applies": false,
         "answer": false,
         "justification": "No human subjects study is conducted."
       },
       "attrition_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human subjects study is conducted."
       }
     },
     "cost_and_practicality": {
       "inference_cost_reported": {
         "applies": true,
         "answer": true,
         "justification": "Section 5.2 reports: 'The entire benchmark evaluation incurs an average API cost of $52 per model on average. The average processing times per sample with a single thread, are 49 seconds for generation, 29 seconds for editing, and 25 seconds for repair.'"
       },
       "compute_budget_stated": {
         "applies": true,
         "answer": true,
         "justification": "Total API cost ($52 per model average) and per-sample processing times are reported in Section 5.2, providing a clear picture of the computational budget."
       }
     },
     "experimental_rigor": {
       "seed_sensitivity_reported": {
         "applies": true,
         "answer": false,
         "justification": "Results are from single runs with temperature=0. No seed sensitivity analysis is reported. While temperature=0 makes outputs nominally deterministic, API non-determinism is not tested or acknowledged."
       },
       "number_of_runs_stated": {
         "applies": true,
         "answer": false,
         "justification": "The number of experimental runs is not explicitly stated. Temperature is set to 0, implying single runs, but this is not confirmed and the implications for result stability are not discussed."
       },
       "hyperparameter_search_budget": {
         "applies": true,
         "answer": false,
         "justification": "No hyperparameter search is reported. The prompt design process is not described — it is unclear how the prompts in Figure 5 were developed or whether alternatives were tested."
       },
       "best_config_selection_justified": {
         "applies": true,
         "answer": true,
         "justification": "A single, standard configuration is used across all models (temperature=0, max tokens at model limit, default other parameters). No configuration selection or tuning is performed, eliminating cherry-picking concerns."
       },
       "multiple_comparison_correction": {
         "applies": true,
         "answer": false,
         "justification": "The paper makes many implicit comparisons across 9 models × 4 frameworks × 3 tasks without any statistical testing, let alone multiple comparison correction."
       },
       "self_comparison_bias_addressed": {
         "applies": true,
         "answer": false,
         "justification": "The authors design the benchmark, prompts, and evaluation metrics, then evaluate third-party models. No discussion of potential biases from their own design choices affecting results (e.g., prompt design favoring certain models)."
       },
       "compute_budget_vs_performance": {
         "applies": true,
         "answer": false,
         "justification": "While API costs and model sizes are mentioned, no analysis relates performance to compute budget. Comparing a 7B model to a 124B model without discussing the compute-performance tradeoff leaves an incomplete picture."
       },
       "benchmark_construct_validity": {
         "applies": true,
         "answer": false,
         "justification": "The paper validates MLLM-as-Judge against human evaluation but does not discuss whether CLIP and SSIM scores are valid proxies for UI quality, or whether the benchmark tasks comprehensively capture 'front-end engineering capability.' No comparison with alternative evaluation approaches."
       },
       "scaffold_confound_addressed": {
         "applies": false,
         "answer": false,
         "justification": "No scaffolding is involved. Models are prompted directly without agentic frameworks, tool use, or multi-turn interactions."
       }
     },
     "data_leakage": {
       "temporal_leakage_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No temporal analysis is provided. The paper does not discuss when the benchmark webpages were created relative to model training cutoffs. GitHub projects and top 500 websites may have been in training data for models trained after their publication."
       },
       "feature_leakage_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of whether the evaluation setup leaks information. For example, in design edit/repair tasks, providing the original code could contain structural hints not available in real-world scenarios."
       },
       "non_independence_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of whether test examples share structural similarities. Multiple webpages from the same GitHub projects or similar website categories could introduce non-independence, but this is not addressed."
       },
       "leakage_detection_method": {
         "applies": true,
         "answer": true,
         "justification": "Table 3 computes BLEU scores between generated and original webpage code for all 9 models. Low scores (0.05-0.15) provide concrete evidence that models are not memorizing and reproducing original code."
       }
     }
   },
   "claims": [
     {
       "claim": "Claude-3.7, GPT-4o, Gemini-2.0, and Pixtral-124B are the top-performing MLLMs across three front-end tasks.",
       "evidence": "Table 5 shows these models consistently achieve the highest CLIP scores (0.60-0.83), MLLM scores (8.01-9.15 for edit, 5.28-7.32 for repair), and compilation rates across frameworks. Section 6.1, Finding 1.",
       "supported": "strong"
     },
     {
       "claim": "Larger models consistently outperform smaller variants within the same family.",
       "evidence": "Table 5 shows systematic improvements: Llama-90B vs 11B, Pixtral-124B vs 12B, Qwen-72B vs 7B across all metrics and tasks. Section 6.1, Finding 2.",
       "supported": "strong"
     },
     {
       "claim": "MLLMs demonstrate strongest performance with vanilla HTML/CSS and significant challenges with Angular implementations.",
       "evidence": "Figure 6 shows vanilla HTML achieves highest CLIP scores (>0.72) and perfect compilation rates, while Angular has lowest compilation (0.6-0.7) and CLIP (0.45-0.55). Section 6.2, Finding 4.",
       "supported": "strong"
     },
     {
       "claim": "Code-only input consistently outperforms image-only input for Design Edit and Design Repair tasks.",
       "evidence": "Table 7 shows code-only MLLM scores (8.40-8.57 for edit) exceed image-only (7.37-7.68) across all models. Multimodal combinations provide minimal additional improvement. Section 6.4, Finding 6.",
       "supported": "strong"
     },
     {
       "claim": "MLLMs show critical deficiencies in component-based implementation, with very low adoption rates.",
       "evidence": "Table 9 shows component-based design adoption rates of 0.24% (React), 5% (Vue), and 19% (Angular) on average across models. Case study in Figure 8 and Listing 1 demonstrates hardcoded repetitive structures instead of v-for directives. Section 6.5.2, Finding 8.",
       "supported": "strong"
     },
     {
       "claim": "MLLMs struggle with identifying UI design issues, with an overall average accuracy of only 27.14%.",
       "evidence": "Table 10 shows UI issue identification accuracy ranging from 0.0149 (Llama-11B) to 0.3951 (GPT-4o), with framework-specific averages of 29.72% (React), 22.05% (Vue), 22.75% (Angular), and 34.03% (Vanilla). Section 6.5.3, Finding 9.",
       "supported": "strong"
     },
     {
       "claim": "MLLM performance degrades significantly under harder task conditions.",
       "evidence": "Table 6 shows degradation across all tasks: generation CLIP drops from 0.79-0.86 (easy) to 0.43-0.53 (hard), edit MLLM scores drop from 8.64-9.05 to 7.51-8.19, and repair MLLM scores drop from 6.93-7.21 to 4.19-6.93. Section 6.3, Finding 5.",
       "supported": "strong"
     }
   ],
   "red_flags": [
     {
       "flag": "No statistical significance tests",
       "detail": "All comparative claims across 9 models, 4 frameworks, and 3 tasks are based on comparing raw numbers without any statistical tests, confidence intervals, or error bars. Given single-run results, it is impossible to determine whether observed differences are meaningful or within noise."
     },
     {
       "flag": "GPT-4o used as both subject and judge",
       "detail": "GPT-4o is evaluated as one of the 9 benchmark subjects while simultaneously serving as the MLLM-as-Judge for Design Edit and Design Repair scoring. This creates a potential self-evaluation bias where GPT-4o may rate its own outputs more favorably."
     },
     {
       "flag": "GPT-4o used to create benchmark data it is then evaluated on",
       "detail": "Section 4.2 states that 146 edit samples were translated from React/Vue to Angular and vanilla HTML/CSS 'using GPT-4o.' GPT-4o is then evaluated on these same samples in Table 5, potentially giving it an advantage on data it generated."
     },
     {
       "flag": "Single-run results with no variance reporting",
       "detail": "All results are from single experimental runs (temperature=0). Even with deterministic settings, API non-determinism can affect results. No spread measures are reported, making it impossible to assess result stability."
     },
     {
       "flag": "No funding disclosure",
       "detail": "No funding sources or competing interests are declared despite the research being conducted at two major universities. The absence of disclosure is not the same as absence of conflicts."
     }
   ],
   "cited_papers": [
     {
       "title": "Design2Code: How Far Are We From Automating Front-End Engineering?",
       "authors": ["Chenglei Si", "Yanzhe Zhang", "Zhengyuan Yang", "Ruibo Liu", "Diyi Yang"],
       "year": 2024,
       "arxiv_id": "2403.03163",
       "relevance": "Directly competing benchmark for design-to-code evaluation using real-world webpages from Common Crawl."
     },
     {
       "title": "Webcode2m: A real-world dataset for code generation from webpage designs",
       "authors": ["Yi Gui", "Zhen Li", "Yao Wan"],
       "year": 2025,
       "relevance": "Large-scale real-world webpage-to-code benchmark providing training data and test sets for MLLM evaluation."
     },
     {
       "title": "Automatically Generating UI Code from Screenshot: A Divide-and-Conquer-Based Approach",
       "authors": ["Yuxuan Wan", "Chaozheng Wang", "Yi Dong"],
       "year": 2025,
       "relevance": "MLLM-based approach for UI code generation using divide-and-conquer strategy, directly evaluated by DesignBench-type tasks."
     },
     {
       "title": "Interaction2Code: How far are we from automatic interactive webpage generation?",
       "authors": ["Jingyu Xiao", "Yuxuan Wan", "Yintong Huo"],
       "year": 2024,
       "arxiv_id": "2411.03292",
       "relevance": "Related benchmark focusing on interactive webpage generation, a complementary evaluation dimension to DesignBench."
     },
     {
       "title": "Livecodebench: Holistic and contamination free evaluation of large language models for code",
       "authors": ["Naman Jain", "King Han", "Alex Gu"],
       "year": 2024,
       "arxiv_id": "2403.07974",
       "relevance": "Contamination-free code evaluation benchmark, relevant to data leakage and benchmark design methodology."
     },
     {
       "title": "BigCodeBench: Benchmarking code generation with diverse function calls and complex instructions",
       "authors": ["Terry Yue Zhuo"],
       "year": 2024,
       "arxiv_id": "2406.15877",
       "relevance": "Code generation benchmark with diverse task types, relevant to evaluation methodology for LLM code capabilities."
     },
     {
       "title": "SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains?",
       "authors": ["John Yang", "Carlos E Jimenez", "Alex L Zhang"],
       "year": 2025,
       "relevance": "Multimodal software engineering benchmark evaluating whether AI systems generalize to visual domains, closely related to DesignBench's scope."
     },
     {
       "title": "MLLM-as-a-Judge: Assessing multimodal LLM-as-a-judge with vision-language benchmark",
       "authors": ["Dongping Chen"],
       "year": 2024,
       "relevance": "Establishes methodology for using MLLMs as evaluation judges, directly adopted as a key evaluation metric in DesignBench."
     },
     {
       "title": "MMCode: Benchmarking Multimodal Large Language Models for Code Generation with Visually Rich Programming Problems",
       "authors": ["Kaixin Li", "Yuchen Tian", "Qisheng Hu"],
       "year": 2024,
       "relevance": "Multimodal code generation benchmark using visual programming problems, relevant to evaluating MLLMs on code from visual inputs."
     },
     {
       "title": "ComUICoder: Component-based Reusable UI Code Generation for Complex Websites via Semantic Segmentation and Element-wise Feedback",
       "authors": ["Jingyu Xiao"],
       "year": 2026,
       "arxiv_id": "2602.19276",
       "relevance": "MLLM approach for reusable UI component generation, directly addresses the component-based design limitations identified in DesignBench."
     },
     {
       "title": "Web2Code: A Large-scale Webpage-to-Code Dataset and Evaluation Framework for Multimodal LLMs",
       "authors": ["Sukmin Yun"],
       "year": 2024,
       "arxiv_id": "2406.20098",
       "relevance": "Webpage-to-code evaluation framework for MLLMs using synthetic data, a direct predecessor benchmark to DesignBench."
     },
     {
       "title": "CruxEval: A benchmark for code reasoning, understanding and execution",
       "authors": ["Alex Gu", "Baptiste Rozière", "Hugh Leather"],
       "year": 2024,
       "arxiv_id": "2401.03065",
       "relevance": "Code reasoning benchmark for LLMs, relevant to evaluating code understanding capabilities."
     }
   ],
   "engagement_factors": {
     "practical_relevance": {
       "score": 2,
       "justification": "Front-end developers can use the benchmark results to choose which MLLM works best for their framework, and the findings about code-only vs multimodal input inform practical workflow decisions."
     },
     "surprise_contrarian": {
       "score": 1,
       "justification": "The finding that multimodal input doesn't improve over code-only is somewhat surprising, but most findings (bigger models better, vanilla easier than frameworks) confirm expectations."
     },
     "fear_safety": {
       "score": 0,
       "justification": "No AI safety, security, or risk concerns are raised."
     },
     "drama_conflict": {
       "score": 0,
       "justification": "No controversy or conflict with prior work; the paper positions itself as filling gaps in existing benchmarks."
     },
     "demo_ability": {
       "score": 2,
       "justification": "Code and data are released on GitHub, enabling researchers to reproduce evaluations, though there is no live demo or pip-installable tool."
     },
     "brand_recognition": {
       "score": 1,
       "justification": "Authors are from CUHK, a well-regarded but not headline-grabbing lab. The paper evaluates well-known models (GPT-4o, Claude, Gemini) which adds some recognition."
     }
   }
 }