CodexWorkThe first generation is the easy part to admire. A page appears with confident type and a believable palette. A video arrives with pacing and a soundtrack. A game boots and something moves. The reaction is real delight, and it’s fair.
Then you try to change it. You want the buttons clearer, the third scene shorter, or the jump to feel less floaty. Something else breaks, or the thing you loved quietly disappears. Many people hit this wall and conclude they need a better prompt. Sometimes they do. They may also have run into a different problem: they have an output, and what they needed was something they could steer.
This piece is about that gap, and about the human work that happens inside it.
A complaint worth reading closely
On 15 October 2026, a user posted to the Codex community on Reddit asking why UI work still goes wrong. The post is here: October UI discussion
One post says nothing about how often this happens. The post does include three images, and they show more than the headline does. The author reports a poor first interface for a Hex board game, despite a repository guide. They also report that another agent produced a better design, and that they couldn’t get a later mock-up matched.
In the first image, the board is made of pale, low-contrast cells sitting in a large yellow rounded field. The second image, from the alternative agent, shows a contiguous honeycomb with clear colored goal edges and visible Undo and Resign controls. The third is a comparison against a separate tic-tac-toe mock crop.
That last comparison is the most instructive. The implementation keeps the layout, the piece positions and the broad palette. It loses the woodgrain, the chamfered volume, the contact shadows and the depth of the grooves. The visible comparison supports a loss of material qualities more clearly than a wholesale change of layout.
We can’t see the prompts, the models, the effort settings or the code. We also don’t know which other agent produced the better version. So this isn’t a verdict on anyone. It’s a useful specimen, because it holds three separate problems that usually get blurred together.
Three different failures
The three problems need different responses, so it helps to name them.
1. A wrong task model
The first Hex image reads as a legibility and composition failure. Cells you can barely tell apart, inside a field that dominates the board, suggest the tool understood “make a game board UI” as styling rather than as a place where a player must see the edges, the goals and the state.
A board game interface has an information order. What is the goal? Whose turn is it? Where can I undo? A screenshot can look pleasant and still get that order wrong. The fix here is a clearer task model: what the person must perceive, in what sequence. Prettier surfaces won’t fix it.
2. Loss of material and visual fidelity
The third image shows something else. Structure survived and substance didn’t. Woodgrain, bevels, soft shadows where a piece touches the board and the depth of a groove are all physical cues. A palette and a layout can be copied by describing them. A convincing wooden surface is much harder to rebuild from a description.
This is where a medium decision matters. A real texture may need a real raster asset, such as a photographed or painted surface, while the controls and text stay as code so they remain sharp, accessible and editable. Asking code alone to imitate wood can produce a flat approximation, and then the approximation gets blamed on taste.
3. An uninteresting underlying idea
Sometimes the layout is clear, the materials are faithful, and the thing is still dull. No amount of repair helps, because nothing is broken. A tidy, legible, well-textured board for a game nobody wants to play twice is a finished answer to a weak question.
This third failure is the easiest to miss, because the first two give you something concrete to fix. Weak ideas hide in plain sight. They look professional.
You can’t tell which of the three you have by looking at the output alone. You have to look at what changed between the intent and the result.
What others report, and why it stays anecdotal
A thread from 19 September 2026 reports on an image-first workflow for building UIs: September image-first discussion
Some commenters report strong success. Others report getting only outlines, effects that drift from the reference, expensive iteration, or failures across several providers. That spread is the useful part. It’s selected, first-hand anecdote, not a controlled experiment, so it can’t say which approach wins. It does suggest that a reference image helps some people with some tasks. Where it fails, it may fail for the same three reasons above.
Evaluation is fragile too. A post in the Claude Design community originally claimed a clear win for adding design guidance, then withdrew its headline result in a 29 July edit after rerunning all twelve cases: revised comparison account
We’re not repeating the original scores, because the author retracted them. The lesson is modest and useful. Small samples of subjective design work move around a lot. Be wary of any before-and-after story, including your own.
What design guidance actually offers
Several open repositories now publish design guidance for coding agents. We read them as methods, not as proof that they work.
Anthropic’s frontend-design skill, in its September revision, asks the agent to derive composition, material and typography from the subject, and to plan and challenge generic choices: frontend-design skill
The Impeccable project, in the October 4 snapshot inspected for this feature, separates product truth, visual world and page purpose. Its asset-producer guidance separates raster media from code-made media: Impeccable design guidance and asset-producer guidance
Emil Kowalski’s break-ui skill, at its October 2 revision, pushes in a different direction. It asks you to stress a design with missing, long, extreme and empty data, and with awkward widths: break-ui skill
Read together, these are a vocabulary for questions a person can ask. What is this subject made of? What is this page for? Which parts should be a photograph and which should be text? What happens when the name is forty characters long? They don’t show that any procedure fixes anything. You don’t need to adopt all of it, and a large pile of installed skills isn’t the answer. One sharp question you actually ask is worth more.
A fictional sequence: one thing, one problem, one edit
Here is an invented example, not a report of a test. Mara runs marketing for a small letterpress studio. She wants a one-page teaser for a printed calendar.
Intention
Before generating anything, Mara writes down three sentences. The calendar is a tactile object. The page should feel like paper under a lamp. A visitor should find the launch date and the pre-order button within three seconds.
First result
The agent returns something lovely. The headline has presence, the composition has a good asymmetry, and the warm palette is right. Mara is pleased for about a minute.
Then she notices a precise problem. The paper “texture” is a soft gradient and doesn’t read as paper. The launch date sits in small grey text beneath a decorative flourish. The pre-order button is the same tone as the background.
Her first instinct is to say “make it better.” She holds off, because she can name the problem. There are two separate faults: material fidelity (the paper) and information order (the date and button).
Consequential edit
She keeps what worked: the headline, the asymmetry and the palette. She asks for three specific changes.
- Replace the gradient with a real scanned paper image, used as a background asset, with text and controls remaining code.
- Move the launch date above the flourish at a legible size, and give the button a clearly different color.
- Leave everything else as it is.
The request names what must not change. That’s the human contribution here. The agent doesn’t know which part she loves unless she says so.
Usable final state
Now she inspects the whole page, not only the fixed spots. She narrows the window to phone width. She tries a longer launch note, an empty event list and a very long product name. She turns on a reduced-motion setting to check that the entrance animation stops. She zooms the text and looks at the contrast between the button and the paper.
Two things break at narrow width, and she asks for those to be fixed. A screenshot of the desktop view would never have shown either.
Reduced motion matters here as a design question and not only a rule. Purposeful motion helps explain state, and when it’s switched off the state should still be clear. A screenshot can’t verify every interaction, so she checks by using the page.
FOUR FRAMES / ONE REVISION
The second edit
Designed fictional sequence, not an observed trial.Intention
Three sentences before any generation: what it is, what a visitor notices first, what it should feel like. The calendar should feel like paper under a lamp.
First result
A handsome draft. The headline and composition work. The paper is a gradient, the launch date is small and grey, and the button blends into the background.
Consequential edit
Keep the headline, asymmetry and palette. Swap in a real paper scan, lift the date, and give the button its own color. One named problem, one named boundary.
Usable final state
Checked at phone width, with an empty list, a long name and reduced motion. The page works when it's used, not just when it's photographed.
The same shape in video
Video makes the preservation problem sharper. Manus announced a Video Editor on 1 October 2026: Manus Video Editor announcement
The vendor describes research-to-video, media that’s generated or made in code, separate timeline tracks, direct edits, and an agent that continues in the same project. It also describes a full desktop editor. We haven’t inspected a real project, and we’re not borrowing any speed or viewing claims.
The idea is still worth thinking about. Separate tracks mean a title, a voiceover and a clip can be treated as different things. That’s the video equivalent of keeping controls in code and texture in raster. The question to ask is practical. If you hand-trim a clip so a pause lands on a word, does that trim survive the next time the agent revises the video? An intentional edit is a piece of authorship. If a revision silently overwrites it, you’ve lost something the first generation never had.
The three failures show up again. A wrong task model might be a video structured like a slideshow when you wanted a story. A fidelity loss might be a brand typeface or a texture that changes on re-render. An uninteresting idea might be a perfectly cut video with nothing to say.
The same shape in games
Manus announced a Game Developer on 1 October 2026: Manus Game Dev announcement
It describes live parameter controls, replaceable assets and multiplayer help, and it admits rough edges. We haven’t tested a game or watched anyone replay one.
A game that runs is different from a game someone wants to play again. An automated playthrough can expose failures along the path it exercises. It cannot establish that a person enjoyed the game. Live parameters are interesting here because they invite a human to feel a change: gravity a little lower, enemies a little slower. Replaceable assets let you swap a flat sprite for one with real character, which is the fidelity question again.
The wrong task model in a game is a “game” that’s really a demo. The weak idea is a mechanic that works perfectly and goes nowhere.
The throughline
Across a page, a video and a game, the same human work appears after the first output.
- Intention. Say what the thing is for, and what a person should perceive or feel, before you generate.
- Medium. Decide what should be a real asset and what should be code, track or parameter.
- Preservation. Name what worked, so the next change doesn’t erase it.
- Inspection. Look at the whole thing under stress, not just the spot you fixed.
- Judgment. Ask whether it’s interesting. This is the one a tool is least able to answer for you.
None of this belongs to one provider, and none of it proves any provider can’t do it. It describes where your attention goes after a first draft exists.
An experiment you can run
This is a proposed experiment, not a report. We haven’t run it, and we can’t say what you’ll find.
Pick one small thing: a one-screen web page, a 20-second video, or a single game mechanic. Use any tool you like.
Step 1: Write the intention. Three sentences. What it is, what a person should notice first, and what material or mood it should have.
Step 2: Generate once. Save the result. Don’t touch it yet.
Step 3: Name one precise problem. Classify it honestly. Is it a wrong task model (the structure or information order is off), a loss of material fidelity (the look or feel is thinner than intended), or an uninteresting idea (nothing’s wrong, nothing’s compelling)?
Step 4: Make one consequential edit. Write down what must be preserved. Change only the named problem. For a page, that might be swapping one texture for a real image. For video, trimming one beat by hand. For a game, changing one parameter.
Step 5: Check whether the edit survived. Ask for one more unrelated revision. Did your edit stay? Write down what changed that you didn’t ask for.
Step 6: Inspect the whole.
- Page: narrow width, an empty state, a very long string, reduced motion.
- Video: sound off, then eyes closed.
- Game: hand it to someone and watch whether they choose to play again without being asked. Record only what you saw, and treat a small number of people as a hint, not a result.
What to record: your classification of the problem, whether the edit survived, and one sentence on whether the final thing is interesting. If it isn’t, that’s a finding.
Boundaries: one task, one tool, one session. Don’t compare providers from a single run, and don’t claim time saved unless you measured it. The point is to practise seeing, not to produce a ranking.
Evidence and scope
The community accounts are selected anecdotes inspected on 15 October 2026, not comparative tests. The studio sequence is fictional, including its revisions and checks. The design repositories describe methods; the Manus pages describe vendor capabilities, rechecked on 23 October. No actual video project, game play, user enjoyment or measured improvement was observed for this feature.