Redesign Your App With AI Without Breaking the Code
How do you let AI redesign your app without touching the logic? A rules file for the agent, five fixes asked one at a time, and a browser check after each.
You can let an AI agent redesign your app without letting it touch the logic. You need a rules file a few lines long and a browser open after every step. In our test, five fixes to a real screen took about nine minutes of agent time.
What It Is
A rules file is a short text the agent reads before it works. It says what it may change (styles and layout) and what it may not (logic, data and copy). Claude Code, the agent used here, reads a file called CLAUDE.md at the start of every session, so that's where the rules go.
Why It Matters
Working Surface summarised Xinran Ma's interview with Ayon, a designer at the AI start-up Eve. Engineers usually built 75 to 80 percent of a design, and notes listing the differences weren't enough. Now Ayon ships small layout, spacing, color and typography changes straight to production code with AI, inside guardrails agreed with the engineers.
Without guardrails, an agent "tidying up the design" can also touch what makes the app work.
How To Do It
- Split the files. In the demo, index.html (structure) and style.css (looks) are fair game; app.js (logic) and data.js (data) are not.
- Write the rules file with the prompt below.
- Limit the agent. In the test it could only read and edit files; commands were blocked.
- One fix per instruction, written the way a designer talks to a developer.
- After every step, save a snapshot (a git commit), open the page in a browser and compare the text.
We added the last two rules after the test. Swap in your own file names:
Rules for redesigning this app. You may change style.css freely: colors, spacing, sizes, corners, shadows, focus styles, animations. You may change index.html (tags, classes, layout), but every existing id stays on an element of the same kind, and the page must still work with app.js as it is. Do not touch app.js or data.js: that is logic and data, owned by the engineers. Do not change visible text unless the request gives you the exact new words. If you think the copy should change, put the suggestion in your final message. No new JavaScript, no libraries, no external fonts or images. Do not create new files. If a request needs logic, stop and tell me. If you can't check something, tell me what to check.
The test screen is a demo made up for the article: the Projects page of an app called Larkspur, like many first-run screens built quickly with AI.
The before: nothing broken, but nobody had looked at it twice.
1. An Empty State That Shows the Next Action
What it is. What a new user sees before they have anything. Here: a rocket, "No projects yet" and "Get Started".
Why it matters. "No projects yet" says what's missing, not what to do next.
How. In 46 seconds the agent removed the rocket and added a faded preview of three rows, made of plain CSS. The main button kept its id, so app.js still finds it.
Redo the empty state of the [page name] page. Remove the illustration. Show a faded preview of three rows like the ones that will appear here, drawn in CSS only and hidden from screen readers. Heading: "[your heading]". Below it: "[one line on what will live here]". One main button "[main action]" that keeps its current id, and a quieter button "[secondary action]".
An empty state answers three questions: what will live here, why it matters, what to do now.
2. One Corner System, One Shadow System
What it is. A few corner and shadow sizes, written as CSS variables: named values you set once and reuse everywhere.
Why it matters. Six corner sizes and a purple glow under the buttons made the page look stitched together from different kits.
How. In 77 seconds the agent replaced every corner and shadow. Then a problem showed up: the 18 pixel squares with 8 pixel corners looked like circles. Once we pointed it out, the agent added a 4 pixel radius for the smallest shapes.
Tidy up corners and shadows with CSS variables. 8px radius for small things (buttons, nav items, chips), 12px for cards, fully round only for real circles, 4px for elements smaller than about 24px. Three light grey shadow levels, no colored glows. Replace every corner and shadow in the file with these variables.
Rule of thumb: keep the corner at about a quarter of the element's short side, or less.
3. Shorter Lines, Easier Reading
What it is. Capping how many characters fit on one line. The welcome paragraph had about 107.
Why it matters. Long lines are tiring: your eye travels far, then has to find the next line. Most typography guides suggest 45 to 75 characters.
How. The request was 60 to 70 characters, using the CSS ch unit. The agent set 66ch in 39 seconds. Counted in Chrome, though, the lines were 85 characters. The reason: 1ch is the width of the "0" character, and most letters in that font are narrower. Given the real count, the agent switched to 50ch, and the lines came out at 66, 69 and 62 characters.
The [name] paragraph should run 60 to 70 characters per line. Set a max width in ch, then tell me how to count the characters of a real line in the browser: the ch value doesn't match real characters. I'll send you the count and you adjust it.
4. A Skeleton Instead of a Spinner
What it is. A skeleton is a grey placeholder in the same shape as what's coming.
Why it matters. A spinner only says "wait", and when the content arrived the card grew 94 pixels taller: the page jumped.
How. This was the longest step, 4 minutes 33 seconds. In Chrome both cards matched: 520 by 280 pixels in a 1,200 pixel window, 350 by 360 at phone size. Zero jump. A white gradient slides across it in about a second and a half, turned off for people who ask for reduced motion. The agent kept "Loading..." for screen readers and asked before deleting it.
Replace the loading spinner with a skeleton exactly the size of the card that will load: reuse the real card's style rule. Add a soft shimmer that turns off with prefers-reduced-motion. Don't touch the loading logic. Hide the loading text visually but keep it for screen readers.
5. A Focus Ring You Can Actually See
What it is. The outline that shows where you are when you move with the Tab key.
Why it matters. Many people use apps with the keyboard. Here, tabbing through the 9 focusable elements, none showed where you were.
How. In 59 seconds the agent removed the rule that killed the outline and used the :focus-visible selector, which shows the ring for the keyboard but not for mouse clicks. Afterwards all 10 elements had the ring. The agent picked a darker purple, #6d28d9, and said it reaches 7.1:1 contrast on white. We checked: it does.
Remove the rule that turns off the focus outline. Add one ring used everywhere: 2px in the app's main color, with a 2px gap, for keyboard focus only using :focus-visible. Tell me the color you chose and its contrast on white.
Never delete the focus outline without putting something better in its place.
Small Test
Take one screen of your app, add the rules file and ask only for fix 5, the focus ring. Then press Tab from the top to the bottom of the page and check with git that the logic files didn't change.
It worked if every element shows the ring on Tab but not on a mouse click, and the logic didn't change.
Watch Out For
In all six runs app.js and data.js didn't change by a single line (checked with git), and copy changed only where the exact words were given. But some things slipped:
- It wrote a file against the rules. The settings blocked eight of its attempts to run commands to measure heights, so it created a test page with JavaScript inside the project. It said so and asked for it to be deleted.
- It reported something false. Later it said that folder was gone. It wasn't: the snapshot included the file and git no longer listed it as new. Alek removed it by hand.
- It trusted a wrong number (66ch, off by about 30%) and gave tiny shapes corners that were too big.
- It left a dead button. "Start from a template" is visual only: wiring it needed logic. For users it's still a bug, one for the engineers' list.
None of this broke the app, but every problem came from opening the page and files, not from the agent's summary. And guardrails should be agreed with the engineers: the agreement matters more than the file.
Pick the fix your app is missing most and try just that one today. More ideas in five fixes that make a generic app look premium.
Source: Alek's piece on Medium. Thanks to Working Surface, Xinran Ma and Ayon for the interview.
In short: The rules file keeps the agent in its lane; the browser, opened after every step, tells you whether it really stayed there.
Newsletter
AI that actually works, in your inbox.
New pills, the tools we use and what we learn on real projects. Few emails, only when there is something useful.
