The reference image should not set the date
Reading AesCode made me separate the appearance to borrow from a mockup and the content to preserve from the brief.
The brief said Saturday
Imagine making a poster for a small workshop. The brief says Saturday. The generated mockup looks good: a large heading, pleasing colors. Then you read the date at the bottom. It says Friday.
The picture has already moved the event forward a day.
If we use this mockup to produce HTML and CSS, what should we follow? I would like the heading size and spacing. Friday should stay behind.
This was the distinction that caught my attention in Microsoft’s AesCode introduction. A generated image supplies visual guidance, while the original prompt remains the authority for content. The output is described as editable HTML and CSS.
The project also points out that reference images can contain incorrect content. I have not run the model or compared its outputs. Reading the official materials prompted this hypothetical poster-editing task.
A good-looking mockup makes copying the whole thing tempting. Its words look like part of the design. Words also mean something.
Different information in the same box
Consider the date area. Putting it on the left or in the center, and choosing its distance from the heading, are layout decisions. The actual day should come from the event information.
In an image, those things sit together. While making the artifact, I would want to separate them for a moment.
I might supply the event name, date, and venue as content to preserve, and ask for the image’s colors, hierarchy, and spacing as references. An address or ticket price appearing only in the mockup should not be filled in as fact.
This is a workflow I am proposing after reading. I have not verified that writing those instructions makes the model obey every time. The resulting copy still needs comparison with the supplied information.
An ambiguous brief can fail earlier. “Next Saturday” is not a question the picture can settle. Someone still needs to establish the date to publish.
Something else happens when the real event name replaces a shorter one in the mockup: the line breaks may change. Only after correcting the content can we properly judge the design.
Suppose a short English heading fits comfortably, but the actual Korean event name takes two lines. Shrinking the text could make it fit again. Whether people can comfortably read it needs a look at the rendered screen.
I would therefore separate resemblance to the mockup from readability with the actual content. Those checks may not end in the same place.
After “editable”
Keeping HTML and CSS is appealing for this kind of work. We can find the date, change it, and render again, without first erasing letters painted into a picture.
Being able to edit does not establish that the layout survives the edit. After a word grows longer, we still need to see whether the venue line moves or elements overlap on a narrow screen.
If I inherited this poster, I would want to know where the authoritative brief, reference image, and editable code live. A later date change should not start with guessing which one supplies the facts.
Back at the original mockup, changing Friday to Saturday is a small task. Once it is correct, I can give the spacing and colors my attention.
Then someone might ask to add just one more word to the event name. Time to reopen the code and see how far the heading pushes the next line down.