This article records some pitfalls I encountered recently when using AI to replicate pages. Later, I built a workflow to address these issues and organized the entire process for reference.
You've probably experienced this too.
Sometimes you throw a screenshot at an AI and ask it to build a page based on it. The first version looks roughly right, but upon closer inspection, something feels off: cards are slightly wider, fonts are smaller, shadows are wrong—just minor issues.
Then you have to verbally describe what needs adjustment and how. Iterating through rounds takes quite a bit of time.
So I thought about chaining rendering, screenshots, comparison, and modification into a workflow, letting the model check and fix itself. This approach seemed sound.
But in practice, things didn't go as planned. Sometimes after fixing round two, round three reverted changes; results fluctuated, and the page could even get worse with each iteration.
Let's get straight to the point.
How to Make It Self-Correct
The process isn't complex:
1Target Screenshot ──▶ Model writes HTML ──▶ Browser renders 1:1 screenshot ──▶ Pixel-by-pixel diff generation2 │3Keep Best History ◀── Re-render ◀── Model diagnoses then edits code ◀── Original + Rendered + Diff
The Diff doesn't fix the page for the model. It just turns "it doesn't look quite right" into a visual map of specific deviations, which is then fed back to the model to decide next steps.
To prevent the model from guessing blindly based on the Diff, before each modification, I require it to answer three questions:
- Where is the biggest problem?
- Which element or CSS property likely caused it?
- How does it plan to fix it?
Only after answering do we touch the code.
For this test, I used Ling-3.0-flash-VL and selected two cards for a simple demo: one yellow card with a bright background, thick black border, and hard shadow; the other a dark SaaS pricing card with gradient buttons, tags, and feature lists.
I think cards are perfect. Not too many elements, but width, whitespace, button direction, and shadows—if any one is off, it's immediately noticeable.
First Run
Let's start with the yellow card.
After the first version, the overall result was actually quite good.
The structure, color scheme, copy, and button positions were mostly replicated. Without comparing side-by-side with the original, you might think it's close enough.
But placed together, subtle differences emerge: the card is slightly larger, font weights differ, and whitespace/button sizes aren't perfectly aligned.
I then fed the original image, first-round result, and Diff back to Ling, asking it to identify these detail issues.
From the diagnosis, it doesn't just say "not similar enough." It pinpoints problems like card size, fonts, and buttons, then modifies corresponding CSS.
Three-round comparison of the yellow card: Round 2 improved, Round 3 regressed, so we kept Round 2 as the historical best.
However, a good first round doesn't guarantee continuous improvement.
This video captures the issue: Round 2 was closer to the original, but Round 3 slipped back slightly. Fortunately, the workflow didn't default to the last round as the answer but preserved the historical best from Round 2.
So feeding the Diff back doesn't mean the model suddenly gets smarter. It can spot many detail issues and map judgments to specific CSS, but it still gets confused sometimes.
For details on how the workflow runs, watch the screen recording below.
Full demo of the dark pricing card: selecting assets, initial generation, slider comparison, then running two self-healing rounds.
Changes here weren't dramatic because the first round was already close. Subsequent rounds continued improving, focusing on card size, rounded corners, buttons, and gradients.
Comparing both recordings shows different trends:
The yellow card improved by Round 2 but regressed in Round 3; the dark card showed steady small improvements across all three rounds. While two recordings don't prove statistical rules, they show that the same workflow doesn't always yield better results each round.
Obvious issues are usually fixed in the first one or two rounds. Later iterations involve fine-tuning font sizes, rounded corners, and shadow offsets, where fixing one thing often breaks another. Therefore, I save the historical best rather than assuming the last round is the answer.
What Can It Actually Do?
From these results, the first version is standard Screenshot-to-Code. What's interesting is that after seeing the rendered output, it can pinpoint issues to specific elements and CSS properties instead of just saying "make it more similar."
Even without auto-fixing, this diagnostic step serves as a useful checklist.
Many visual issues don't trigger errors. If the model can see the browser's actual rendered page, it has a chance to continue fixing itself.
Another practical point: this workflow requires repeated model calls, so speed matters. My recorded single full-page HTML generation took about 7 seconds. Public data shows Ling-3.0-flash-VL has 124B total parameters, activating 5.5B per inference, with added visual understanding and Visual Agent capabilities.
The 7-second figure is based on my specific interface and settings. I haven't done horizontal comparisons nor will I derive speed/cost solely from active parameters.
Where Are the Pitfalls?
The real time sink wasn't connecting the model but getting feedback accurate. Initially, I thought fluctuations meant model instability. After checking Diffs one by one, I realized part of the problem lay in my feedback loop.
1. First pitfall: Size
If the target image was scaled and the browser screenshotted at a different size, the images never aligned from the start. Even with the correct answer, the Diff showed large discrepancies.
For pixel diffs, being off by a few pixels globally creates massive error zones.
2. Second pitfall: Animation
Once, the model added fade-in effects to feature lists. Screenshots captured mid-animation left content transparent.
After removing animations, the page looked normal visually, but automated comparison scores worsened.
Reason: Transparent content revealed the background, making pixel algorithms think it "looked more similar."
3. Third pitfall: Versioning
If a round broke the design, continuing to patch on top of bad code stacks errors. Like building on a crooked foundation—the harder you try, the messier it gets.
In short, Diff is a tool, not a judge.
If feedback is wrong, the model won't catch it. It will diligently fix the wrong direction based on flawed input.
Conclusion
I distilled the rules into three points:
- Use identical dimensions for original and browser screenshots; no secondary scaling.
- Fix viewport, fonts, animation states, and screenshot timing.
- Continue from the historical best version each round; don't patch degraded code.
Working code is just the first step. Issues that don't error out but look wrong can indeed be checked by visual models. However, seeing deviations doesn't guarantee correct fixes every time.
So I no longer assume more rounds equal better results. Fix obvious issues first, stop when improvements plateau—that's sufficient for me.
The model is open-source and free for 2 weeks. To run it yourself, use these links 👇🏻:
- Huggingface : https://huggingface.co/inclusionAI/Ling-3.0-flash-VL
- Ling studio：https://chat.ant-ling.com/chat
- Ant Digital MaaS (China): https://maas.antdigital.com/models/modelservice-1788265478122001738
- Openrouter：https://openrouter.ai/inclusionai/ling-3.0-flash-vl:free
Ps: This article was dictated and polished by AI, so it has soul ✌🏻
