I built an app as an experiment with Codex's design capabilities.
The app is called NameSnap Picker. It helps teachers, streamers, coaches, parties, and other groups choose a name fairly without turning the process into a miniature administrative hearing.
You can paste a list of names, use a fast Quick Pick, spin a wheel, avoid repeats, and keep a visible history of winners. The current native build supports iPhone and iPad, and the winner moment can appear in 300 different celebration combinations.
I used GPT-5.6 Sol inside Codex to help establish the visual direction. It produced something that surprised me: a bold interface with strong ink-like outlines, offset shadows, vivid gradients, and a playful sense of motion that fit the people and moments the app serves.
You can try the current NameSnap beta in TestFlight.
The easy conclusion would be that AI has good taste now.
That is partly true. It is also incomplete.
A model can produce an attractive screen quickly. A product still needs a clear user, an honest job to do, a complete journey, stable behavior, and ruthless visual review. NameSnap taught me that AI-generated design works best when you give the model product truth instead of asking it to decorate an empty idea.
Here are five lessons I am carrying into every app I build next.
1. Describe the person before you describe the style
"Make it modern" is barely a design instruction.
Modern for whom? A bank, a preschool teacher, a music producer, and a competitive gamer can all use modern software without wanting the same interface.
NameSnap needed to work for people making a small decision in front of other people. A teacher may be choosing a student. A streamer may be picking a giveaway winner. A coach may be dividing a group. The action needs to feel quick, fair, visible, and just theatrical enough to be fun.
That context gave the visual direction a job.
The bold outlines make the controls easy to find. The bright colors create energy around the draw. The celebration system makes the result feel like an event. The interface does not look playful because I asked AI to sprinkle playfulness on top. It looks playful because the product moment benefits from anticipation and release.
Before you ask AI for a screen, write down:
- who is holding the device;
- who else may be watching;
- what decision is being made;
- how quickly it needs to happen;
- what could make the result feel unfair or confusing;
- and how the user should feel when the job is complete.
That is more useful than a bag of visual adjectives.
2. Design around the primary action, not the available features
A random picker can accumulate features surprisingly fast.
You can add themes, animations, sounds, saved lists, imports, exports, histories, settings, subscriptions, and half a dozen selection modes. If every feature fights for the first screen, the app becomes a control panel for a job that should take seconds.
The primary NameSnap journey is deliberately simple:
- add names;
- choose a picking mode;
- run the draw;
- see and trust the result;
- continue without accidentally repeating someone.
Everything important should support that path.
This is where AI needs product constraints. Without them, it may design a beautiful collection of features rather than a useful sequence of decisions. The difference matters. A screen can look expensive and still make the user hunt for the one button that delivers the value.
I now ask AI to identify the primary action on every screen before styling it. If two actions appear equally important, I make it explain why. If a supporting feature dominates the layout, I make it repair the hierarchy.
The goal is not fewer features for the sake of minimalism. The goal is an interface that makes the next useful action feel inevitable.
3. Rendered pixels are the proof
Code can be clean while the screen is wrong.
A component may have the right name, token, and constraint while its label is clipped, its shadow feels detached, or its button shifts at a mobile width. A layout can pass structural checks and still look like a collection of boxes assembled by someone who never saw the finished page.
That is why I do not approve an AI-designed interface from source code.
I render it at the real target size. I inspect the actual pixels. I look at both the whole screen and the individual components. I test the interface on iPhone and iPad instead of assuming one flexible layout magically understands both devices.
For NameSnap, that means checking questions such as:
- Does the main action remain obvious with realistic names in the list?
- Does the wheel still read clearly when labels vary in length?
- Does the winner celebration preserve the result instead of burying it?
- Are no-repeat and reset states understandable before the user makes a mistake?
- Does the iPad version use the extra space, or merely enlarge the phone layout?
- Do the screen captures look like the same product from one journey to the next?
AI can move quickly enough that visual inspection becomes more important, not less. Fast output lets you generate mistakes at industrial speed too.
4. One beautiful screen is not an app
Design demos tend to show the hero moment.
Real users also see the first launch, permissions, empty lists, loading, errors, confirmations, destructive actions, settings, history, and the awkward state created by pressing something twice.
NameSnap is small, but it still needs a complete screen and state system:
- adding names;
- pasting a list;
- choosing Quick Pick;
- using Spin Wheel;
- handling a completed draw;
- preventing repeats;
- showing winner history;
- resetting safely;
- explaining what will be deleted;
- and fitting those behaviors across iPhone and iPad.
The lesson scales to larger products. A social app is not a feed screen. It is onboarding, profiles, discovery, posting, comments, messaging, moderation, reporting, privacy, account recovery, loading, offline behavior, and dozens of transitions between them.
When you use AI for design, ask for an inventory before asking for final screens. Make the tool map the complete first-release journey and every meaningful state. Then inspect whether information and decisions persist between screens.
The most expensive missing screen is often the one you discover halfway through implementation.
5. Turn taste into a system without flattening it
The best AI output can feel like a lucky draw.
You need to preserve what worked without forcing every future product into the same costume.
For NameSnap, I can turn the chosen direction into reusable decisions:
- typography roles;
- color tokens and contrast rules;
- outline weight;
- shadow direction and depth;
- spacing rhythm;
- button states;
- animation boundaries;
- celebration behavior;
- and platform-specific layout rules.
That creates consistency inside NameSnap.
It should not become a house template that I paste onto a finance app, a medical tool, or a long-session music workstation. Those products serve different users, emotional contexts, and primary jobs.
A useful design system stores the logic of one product. A weak design system becomes a drawer full of fashionable parts that get reused whether they belong or not.
The human role is to keep asking two questions:
- Is this decision consistent with the product we already approved?
- Is that approved direction still the right one for this user and task?
Consistency should make the experience coherent. It should not make the product generic.
What AI did well, and what I still had to own
Sol gave NameSnap a stronger initial visual instinct than I would expect from a generic prompt-to-interface workflow. It found a coherent personality and translated the target user's moment into color, shape, and hierarchy.
That is real leverage.
It did not remove the need to decide what NameSnap should do. It did not remove implementation, platform behavior, accessibility, QA, App Store preparation, or the judgment required to reject a screen that looked exciting but weakened the workflow.
I think the useful division of labor is this:
- I define the user, problem, product boundaries, and proof.
- AI explores directions and accelerates execution.
- I inspect the rendered result and force the system to explain its choices.
- AI repairs the implementation against concrete findings.
- I test the complete journey on the actual platform.
That loop is much more powerful than either "AI did everything" or "AI is only autocomplete."
A practical starting prompt
If you want to try this on your own app, give your AI tool a prompt shaped like this:
I am building [product] for [specific user] who needs to [primary job]. They currently struggle with [problem]. The main journey is [steps]. The experience should make them feel [emotional outcome]. Propose three materially different visual directions that fit this audience and task. For each direction, explain the hierarchy, interaction model, density, color energy, and platform conventions. Do not produce final screens until we choose one direction and inventory every screen and state required for the first release.
That prompt will not finish the product for you.
It will give the work a much better beginning.
You can see the running result in the NameSnap Picker TestFlight beta. I am sharing it because the useful proof is not a screenshot of one impressive screen. It is whether the interface still makes sense when you use the product.
My AI App Builder Starter Prompts are free and help you define the user, problem, scope, stack, and first stable build before your project sprawls.
If you want the full path from idea through architecture, QA, deployment, and publishing, AI App Builder From Zero is my $19 build-along field manual.
AI can have taste.
Your job is to give that taste a product worth serving, then inspect whether the pixels keep their promise.
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Fiverr: https://www.fiverr.com/sellers/marcusykim
Contra: https://contra.com/marcusykim
Upwork: https://www.upwork.com/freelancers/marcusykim



Top comments (0)