7 places I use AI agents in design work, and where I stop

I use AI in 7 kinds of work: research, design systems, plugins, apps, 3D assets and a game for a hackathon. Below is each one with what the agent did, what I did and how I checked the result.

1. Sorting support tickets

For the privacy settings project at FlippingBook I pulled customer support tickets from the last six months out of Jira and Zendesk, and used Claude to categorize them. Before that I wrote an interview script for the sales team about churned prospects. In the mobile app project I did the same with 100+ tickets and the App Store and Google Play reviews, clustering pain points by frequency and severity.

The agent did the sorting. The interview script and the questions were mine. The full research is in the Mobile App case.

2. Design systems in Figma

I build and grow design systems with Claude Code working in Figma. I write the rules: names, structure, how a component and its variants must behave. The agent creates variables, components and variants from them, and I review the result by hand. How this changes the time a design system takes is in the post “21 days to 14”.

3. Plugins and web tools: AxoLinter

When our design team grew, hardcoded colors, radiuses and spacings started to leak into the files. I built AxoLinter, a plugin that scans frames, checks layers against the design system and lists errors. The Fix All button maps hardcoded values to the right tokens.

I built it in the Antigravity IDE with Gemini and Mimo. I wrote the scanner logic in TypeScript and covered it with modular unit tests in Vitest, the interface is vanilla HTML and CSS, and esbuild bundles everything into a single ui.html. QA before development became 5x faster and 85% of hardcoded data was purged.

I make web tools and configurators the same way, for tasks where a plugin or a spreadsheet is not enough.

4. A full-stack app: Time Burner

I could not find a routine tracker that matched my own schedule and worked on every platform. I designed the front-end layout and generated the app logic with prompts in Google AI Studio. Firebase handles authentication and real-time sync, so a change on desktop appears on mobile instantly, and the site runs on GitHub Pages. It is a free open source project, available to everyone. More in the Time Burner project.

5. Native apps for iOS and Android

Drëmych is a baby sleep tracker for iOS and Android. I build it alone, from scratch, for both platforms at once. I have used the Android build myself for more than 2 months, the iOS build is about 60% done. The split is the same as everywhere in this post: the agent takes drafts and generated assets, and I take the product decisions and the final look. The gnome and the scenes on the home screen are one example, I decide how the day and the night look, and the agent helps with the variants.

6. A hackathon game and 3D assets: FigmaGotchi and EWA

At the Figma x Contra hackathon I wanted to stress-test Figma Make. The result, FigmaGotchi, is a playable digital pet game in a pseudo-3D console shell. The pet has age, hunger and energy. Figma Make generated the interface layouts, and AI agents made the 3D graphics. I went from the idea to a finished concept inside the hackathon deadline.

The EWA assignment was a library screen redesigned as a roadmap, with 2 days to deliver. I made 3 high-fidelity prototypes in Figma and generated the 3D islands and game elements with AI plugins.

7. This website

I wrote the brief for this site as a document before any code. Claude Code works through it in sessions, each with a clear definition of done, a commit and an entry in the progress log. The rules sit in a CLAUDE.md file in the repository. Orange only where it is allowed, no magic numbers in animation, numbers from a case only from its meta.yml, no invented content. The details are in the post “How this site is built”.

Four rules I follow

1. Write the brief before the prompt. A session with a clear goal and a definition of done costs less than three vague ones. My Claude Code plan has a small prompt limit per five-hour window, so short sessions are a necessity for me.
2. Give the agent a way to check itself. Unit tests in AxoLinter. For the site, check, build and tests must be green before a commit, and 267 functional Playwright tests run on every change.
3. Keep facts where the agent cannot invent them. Numbers live in one file per case. If there is no data, the agent writes a question to a log and leaves the gap empty.
4. Look at the result with my own eyes. After changing colors or sizes in a design system I take a screenshot of the set of variants, because numbers lie about how it looks. The same applies to code written by an agent.

Where I would use it next

In the retrospective of my design system case I wrote that AI tools could have dramatically accelerated the migration to tokens, which took more than six months. That is the first place I would put an agent today.