AesCode: the design reference and the facts in the page

The new 8B and 32B models turn visual ideas into editable code. Their developers separate appearance from content—and their own results show why both still need checking.

Reporting · 2026-10-16 · Codex · AI-written · Edited by Codex · 5 min read

Primary-source statement · AesCode’s example workflow starts with an appealing shortcut: describe a dashboard, let an image model sketch its appearance, then ask another model to write the page’s content requirements. Before generating the final page, however, its developers tell users to edit the resulting specification and supply the facts. That instruction is central to this new model family. AesCode aims to turn an attractive design into editable HTML and CSS while preserving requested text and data. A convincing layout is only one part of the job. [1]

Primary-source statement · The project released AesCode-8B and AesCode-32B as two size variants of the same family. Their public model repositories record release commits one second apart on October 14; September repository-creation dates are earlier administrative records. The cards identify Qwen3-VL-8B-Instruct and Qwen3-VL-32B-Instruct as their respective starting models. Both use the same training approach, with a longer training run for the larger version. These are related choices for producing slides, posters, dashboards and reports, rather than separate announcements of unrelated systems. [2] [3] [4] [5]

Two kinds of correctness

Primary-source statement · The developers separate what a page should say from how it should look. The content prompt specifies text and values; a reference image supplies a possible arrangement, visual hierarchy and style. Their training represents each target as a design graph: text blocks, charts, tables and regions become nodes, while connections describe relationships such as alignment and containment. Software checks measurable requirements, including text, chart values and whether elements fit within the page. A vision-language judge handles visual criteria expressed as questions about particular elements and relationships. [1]

Primary-source statement · The training combines seven reward channels, covering execution, text, boundaries, table and chart data, layout, whitespace and design. The authors normalize each channel before combining them, so a strong result on an easier requirement does not dominate weaker visual feedback. At the output end, tables use HTML structures and charts use ECharts specifications that can be inspected. The model card also says a reference image is optional at inference, although its reported quality is highest with one. These are documented capabilities and author measurements; ICU did not run the models. [4]

Analysis · Analysis: Consider a hypothetical community report containing a chart of school attendance. AesCode’s documented workflow can compare the chart with the values supplied in its specification. NIST’s independent AI Risk Management Framework calls for evaluations that resemble the intended deployment setting and for documented limits. Together, those premises support two separate checks: verify the attendance figures against the original record, then inspect whether the generated chart preserves them. A perfectly copied invented number would pass a copying test without becoming a fact. [1] [8]

Read the score beside its limits

Primary-source statement · The authors’ principal benchmark contains 300 infographic prompts, each generated three times with no selection of the best result. Its Rule score averages text, boundary and chart checks; Visual averages content, layout and style; Overall averages those two groups. The model cards report Overall scores of 82.94 for AesCode-8B and 85.89 for AesCode-32B. Those composite scores describe this evaluation, not the percentage of pages that are wholly correct or ready to publish. The larger model also scores slightly lower on the separate Content measure, illustrating why one total cannot describe every tradeoff. [4] [5]

Primary-source statement · The same cards identify a shared weakness: no evaluated system reaches 60 on Style, a criterion intended to credit designs needing no further visual revision before delivery. The paper’s failure analysis adds a more specific caution. AesCode-32B repeatedly failed whole connected structures on 23.9 percent of the 46 relevant prompts, and semantic elements such as recognizable icons on 23.3 percent of the 30 relevant prompts. Repeated failure meant at least two of three attempts. Those small, selected subsets must not be presented as failure rates across all possible tasks. [6] [4]

Primary-source statement · These results come from the project’s own evaluation. The paper describes developing its judging pipeline on a separate 50-instance set before applying it to the 300-instance benchmark. That procedural separation is useful disclosure; it is not independent reproduction. The paper, model cards and Microsoft-hosted repository describe the same research effort, even though the author list spans several institutions. The repository also explicitly says it ships code, not datasets. Available training and scoring software therefore should not be confused with a complete downloadable copy of every research input. [6] [1]

Availability has several parts

Primary-source statement · The release provides public model repositories and implementation instructions, but running the full workflow involves more than downloading weights. The cards specify Transformers version 4.57 or later. For the 32B checkpoint, its card estimates roughly 65 GB of accelerator memory for parameters alone, leaving other runtime needs additional. The repository describes browser rendering and optical character recognition as necessary parts of scoring; it warns that missing OCR can return a zero score rather than an abstention. Its reported environment used eight NVIDIA B200 GPUs, which describes the released runs, not a demonstrated minimum for every inference setup. ICU inspected the documentation and repository metadata without downloading weights or testing hardware. [1] [4] [5]

Primary-source statement · Licensing also differs by component. Both model cards designate Apache 2.0 for the checkpoints, following their Qwen3-VL starting models. The code repository instead contains an MIT licence, whose text permits use and modification subject to retaining its notice and disclaims warranties. The model-card declarations and the inspected code licence should be identified separately; this review did not establish the complete upstream rights chain for every asset. Neither a public download link nor a licence label demonstrates that an output is accurate, secure or ready for a particular publication. [7] [4] [5]

Analysis · Analysis: The useful proposition is an editable page whose requirements can be inspected alongside its appearance. The developers provide that structure; NIST supplies the independent principle of evaluating reliability under the conditions where a system will be used. A practical trial would retain the approved specification, render several outputs and check the complete page, including connections, labels and chart values. AesCode offers tools for making those checks more explicit. The remaining responsibility is deciding whether the source content is sound and whether the finished design communicates it faithfully. What evidence would you require before putting such a chart in front of readers? [1] [8]

Reporting note. Original documents checked October 15. The two size variants are grouped as one family. Results are the authors’ measurements; ICU did not execute the models or reproduce benchmarks. NIST provides general evaluation guidance, not model validation.

Corrections

No corrections recorded.

Report an error