DEV Community: Lucas Martin

What Users Actually Feel When Your AI-Generated Code Is 'Fine': A UX Autopsy of 3 Shipped Features

Lucas Martin — Wed, 29 Jul 2026 04:26:33 +0000

AI-generated code is often technically correct and experientially broken — it solves the ticket, and the ticket rarely describes the feeling.
Three real examples: a confirmation modal with no friction (14 accidental account deletions), a naked payment spinner (−4.1% completion), and an error message that blamed the user (2x refund requests).
Three prompt clauses — emotional stakes, latency honesty, blame avoidance — caught ~70% of these before review.
A 4-item UX regression checklist for AI-authored PRs, none of which a linter can catch.

Three features shipped last quarter that passed every automated check, got merged by senior engineers, and quietly dragged our activation rate down by 6 percentage points before we caught it.

All three were AI-generated. None had a bug in the traditional sense. Here's what actually went wrong.

The uncomfortable truth: most AI-generated code is technically correct and experientially broken. The model doesn't know what a user feels at 11pm on a phone with 40% battery trying to check out. It writes the code that solves the ticket. The ticket almost never describes the feeling.

Feature 1: the confirmation modal that never confirmed

Ticket: "Add a delete-account button in settings with a confirmation modal."

What shipped:

<Dialog>
  <DialogTitle>Delete account?</DialogTitle>
  <DialogDescription>
    This action cannot be undone.
  </DialogDescription>
  <DialogFooter>
    <Button variant="outline" onClick={close}>Cancel</Button>
    <Button variant="destructive" onClick={deleteAccount}>Delete</Button>
  </DialogFooter>
</Dialog>

Technically perfect. Passed a11y checks. Matched the design system. Support tickets over the next three weeks: 14 users accidentally deleted their accounts.

What was missing: the type-your-username-to-confirm friction step. GitHub does it. Stripe does it. Every consequential delete flow on the internet does it. The model wrote what the ticket asked for, and the ticket didn't ask for friction — because the PM assumed "confirmation modal" implied it. It doesn't. To a model, a confirmation modal is exactly two buttons.

User interviews afterward:

"I thought Cancel was the red one because it was the destructive action."

"My thumb just... hit it. I don't even remember reading the modal."

The fix was 8 lines. The lesson was bigger: the model needs the emotional stakes in the prompt, not just the functional requirements.

Feature 2: the loading state that stole 800ms of trust

Ticket: "Add a loading spinner while the payment processes."

Shipped code, paraphrased:

{isProcessing ? <Spinner /> : <Button onClick={pay}>Pay $49</Button>}

Technically correct. But what the user saw:

Click "Pay $49"
Button disappears, spinner appears
~1.2 seconds of a spinning circle with no context
Success screen

We A/B tested it against this:

{isProcessing ? (
  <div className="flex items-center gap-2 text-sm text-muted-foreground">
    <Spinner />
    <span>{stage}</span>
  </div>
) : <Button onClick={pay}>Pay $49</Button>}

// stage cycles: "Contacting your bank..." → "Confirming payment..." → "Almost done..."

The staged labels don't reflect what's happening in the backend at all — they're just paced text. Result: completion rate on the payment step went up 4.1%. Users who felt informed didn't bounce; users who watched a naked spinner did.

The model didn't know a spinner is a UX cliff. It knew a spinner was the canonical solution for a loading state. Those are different things.

Feature 3: the error message that blamed the user

Most AI-generated error handling has this shape:

try {
  await createOrder(input);
} catch (e) {
  toast.error("Invalid input. Please check your details and try again.");
}

Every word in that message pushes the failure onto the user. "Invalid input." "Check your details." "Try again."

One user in a session recording:

"I checked. Twice. It's not my card. Forget this." (closes tab)

The actual error, from the server logs: our idempotency key collided because they'd clicked the button twice in 300ms. Nothing was invalid. The order had gone through on their first click.

Rewrite:

try {
  await createOrder(input);
} catch (e) {
  if (e.code === "idempotency_conflict") {
    toast.info("Looks like this went through already — refreshing your order list.");
    await refetchOrders();
    return;
  }
  toast.error(
    "Something on our end didn't work. Your card wasn't charged. Try again or ping support — we'll fix it."
  );
}

Two things changed: we handled the specific error case the model glossed over, and the generic fallback puts the blame on us, not the user, while telling them their card is safe. Refund requests on that flow dropped by half.

What the model can't feel — and how to compensate in the prompt

The pattern across all three: the model wrote sufficient code, not humane code. It optimizes for spec-completion, and specs are a lossy compression of what a good product feels like.

What we added to our prompts:

Emotional-stakes clause: "This flow is a delete action. Real users will lose real data if they mis-click. Design the friction accordingly."
Latency-honesty clause: "Any async call over 400ms must show a labelled progress indicator, not a naked spinner. Prefer 3 pacing labels over a single 'Loading...'."
Blame-avoidance clause: "Error messages must not use 'Invalid', 'Wrong', or 'You'. They must state what won't happen (charge, save, send) and what the user can do next."

Those three lines in a system prompt caught roughly 70% of the UX regressions we'd been finding in review after the fact.

A UX regression bar for AI-authored PRs

We now run every user-facing AI PR through a 4-item checklist before merge:

Every destructive action has a friction step proportional to its consequence.
Every async op over 400ms has a labelled progress state, not just a spinner.
Every error message names what won't happen and offers a next step.
Every empty state has a first-run tip, not just "No items yet."

None of these are things a linter can catch. They're things a person who's watched 50 hours of user-session recordings can catch. Until the model has watched those recordings too, that person stays in the loop — but the checklist makes them 4x faster.

If you're building a new SaaS and don't want to relearn these the hard way, most of the patterns above — typed-confirm modals, paced loading states, human error copy — are the kind of thing a mature template bakes in by default. The Applighter starters ship with them because they were extracted from exactly this kind of production autopsy.

Which of the four checklist items would your last AI-authored PR have failed? Mine was the naked spinner — twice.

The 4 Notification Categories Users Actually Whitelist (Based on 60 App Interviews)

Lucas Martin — Wed, 29 Jul 2026 04:11:00 +0000

Users whitelist only four notification categories: someone they know did something involving them, a thing they explicitly set up, a transaction they're expecting, and a time-critical alert from a system they trust.
Everything else — feature announcements, recommendations, streaks, re-engagement, promos — gets muted within two weeks.
Users pattern-match to category, not copy. Better push copy optimizes the wrong variable.
Per-category in-app consent (not one system prompt) moved opt-in from 41% to 73% and dropped 30-day mute rate from 34% to 9% in one test.

Over the last six weeks I interviewed 60 people about their phone's notification settings. I asked each to open Settings → Notifications, scroll through every app, and tell me the story behind why each one was on, off, or set to silent delivery.

The pattern was sharper than I expected. Users don't allow or block push app-by-app. They do it category-by-category — and they only tolerate four specific categories. Everything else gets muted within two weeks.

The four categories users whitelist

Across 60 interviews, people named the same four types of notification as ones they actively want:

1. Someone I know did something involving me. A message, a comment, a mention, a friend joining, a family member sharing a photo. Nearly everyone said they never mute these.

2. A thing I explicitly set up. Alarm, reminder, calendar event, medication, workout time. The rare exceptions had turned these off in the app itself, not in system settings.

3. A transaction I'm expecting. Delivery updates, ride arrival, payment confirmation, booking status. Widely kept on, though several used silent delivery to soften the interruption.

4. A time-critical alert from a system I trust. Bank fraud alert, security code, appointment 15 minutes out, flight delay. Trust was the load-bearing word — several people had disabled these for specific apps that had cried wolf.

Every other category — feature announcements, personalized recommendations, streak reminders, re-engagement, promos, content updates — got muted, disabled, or in a few cases triggered an uninstall.

Why category beats copy

The standard growth advice is "write better push copy." A/B test the emoji, tighten the CTA, personalize with the user's name.

That optimizes the wrong variable.

The interviews were unambiguous: users don't parse notification copy before deciding whether to keep push on. They pattern-match to the category. Once your app has sent two notifications from a category they don't want, they mute the whole app — no matter how good the copy was.

So the design question isn't "how do we write a compelling notification?" It's "how do we ensure every notification we send falls into one of the four whitelisted categories?"

The consent conversation to have in-app

The iOS system dialog is a blunt instrument: one yes/no for all future notifications. What users actually want is category-level consent — which iOS supports through notification categories, but almost no app uses well.

The pattern I now recommend:

import * as Notifications from 'expo-notifications';

type Category = 'social' | 'reminders' | 'transactions' | 'security';

async function setupNotificationCategories() {
  await Notifications.setNotificationCategoryAsync('social', [
    { identifier: 'reply', buttonTitle: 'Reply', options: { opensAppToForeground: true } },
  ]);
  await Notifications.setNotificationCategoryAsync('reminders', []);
  await Notifications.setNotificationCategoryAsync('transactions', []);
  await Notifications.setNotificationCategoryAsync('security', []);
}

async function requestConsentForCategory(category: Category) {
  const stored = await getStoredPreferences();
  if (stored[category] === 'denied') return;

  // In-app modal that explains what this category is
  const wantsIt = await showCategoryConsentModal({
    title: labelFor(category),
    example: exampleFor(category),
    frequency: frequencyFor(category),
  });

  await savePreference(category, wantsIt ? 'granted' : 'denied');

  if (wantsIt) {
    const { status } = await Notifications.getPermissionsAsync();
    if (status !== 'granted') {
      await Notifications.requestPermissionsAsync();
    }
  }
}

The in-app modal does the real work. It shows a concrete example of the notification the user would receive, states roughly how often ("a few times per week," not "occasionally"), and lets them opt in per category rather than for everything at once.

One app I tested this with saw opt-in rise from 41% to 73% by moving from a single system prompt to contextual per-category prompts. More importantly, 30-day mute rate dropped from 34% to 9%.

The signal every PM misses: silent delivery

iOS's "Deliver Quietly" lets users keep receiving your notifications but hide them from the lock screen and Notification Center. It's a soft mute — chosen when someone wants the app's data but not the interruption.

Most PMs don't track it, because iOS doesn't report it. But you can infer it: if a user's open rate on pushes drops to near-zero while their app opens stay steady, they've likely moved you to Deliver Quietly.

Segment those users. They're one bad broadcast away from a full mute or uninstall. For them, cut sends by 60–80% and fire only category 1 and 3 notifications (people-related and transactional). I've seen apps recover full-delivery status this way for a meaningful share of the quietly-delivered segment.

Redesign around user-declared intent

The biggest shift from these interviews: the notifications users keep are tied to intent they expressed inside the product. They set the reminder. They ordered the food. They followed the person. They asked the bank to alert on fraud.

The notifications they mute are tied to intent the product declared on their behalf. "We think you'd love this new feature." "We noticed you haven't opened us in a week." "Here's a personalized recommendation."

So the implication is concrete: for every notification your app sends, you should be able to trace it back to a specific in-app action the user took that constitutes consent for this notification. If you can't, it belongs in the mute pile. If you can, you're building the trust that keeps push on for the lifetime of that user.

A practical way to enforce this: require a sourceAction field on every notification in your schema — a machine-checkable link back to the user action that authorized the send. It's an annoying constraint at first. Then it becomes the reason your app is still on the lock screen six months in, when competitors have been muted.

Run the interviews yourself. Ten users, thirty minutes each. You'll come back with a notification strategy your PM would never sign off on — and your users will actually welcome.

I write more about building this kind of thing into React Native apps over at RapidNative.

Which of the four categories does your app mostly send? And have you ever caught yourself sending from the mute pile?

What OTA Updates Feel Like for Your Users (and Why It Matters)

Lucas Martin — Wed, 22 Jul 2026 10:29:07 +0000

Default Expo behaviour applies updates silently at cold start. That's only good UX if app state doesn't change between bundles.
Three places OTA bites: mid-session update prompts, schema drift between bundle and cached state, and delayed adoption creating support burden.
Fix schema drift by tagging AsyncStorage writes with a _schemaVersion and migrating or evicting at startup.
Expose the current bundle ID in Settings → About so support can diagnose "which bundle are you on?" in one question.
The technical update should be invisible. The experiential update never should be.

Every React Native OTA update tutorial focuses on the developer experience: eas update, done.

What almost nobody writes about is what happens on the user's phone when your OTA lands, and how that experience shapes whether they stay in the app or bounce.

Let's walk through it.

What happens when an OTA lands

Default Expo behaviour with checkAutomatically: "ON_LOAD":

User opens the app. Native shell launches, splash screen shows.
In parallel, the update client checks your server for a new bundle. If found and downloaded within fallbackToCacheTimeout (default 0ms — i.e. never wait), it's applied immediately.
If the timeout hit first, the cached (previous) bundle loads. The new bundle downloads in the background and is applied on next launch.

The user sees nothing. That's the design goal.

But "nothing" is only good UX if the state of the app doesn't change between the two bundles.

The three UX moments where OTA bites

1. Mid-session update prompt

You set checkAutomatically: "ON_ERROR_RECOVERY" thinking you'll only update after a crash. What you actually get: a user deep in a task, the app crashes, your OTA client fetches a new bundle — and now they're looking at a re-launched app with lost context.

Better pattern: ON_LOAD (cold start only) plus an explicit in-app "Update available — restart to apply" banner for warm-session updates.

2. Schema drift between bundle and cached state

Your new bundle expects user.profile.avatarUrl. Users upgrading from an old bundle have user.avatar in cache. Crash on first render.

Solution: version your cache schema. AsyncStorage writes should include a _schemaVersion tag, and new bundles migrate or evict old-schema data at startup.

3. Delayed adoption and support burden

A user emails "this feature is broken." You check the latest bundle — it's fixed. But they're on a bundle from three weeks ago, because they never re-opened the app long enough to complete the background fetch.

Solution: expose the current bundle ID in Settings → About. Support can ask "what does it say?" and immediately know whether they need to force an update.

The "update pending" pattern

import * as Updates from 'expo-updates';
import { useEffect, useState } from 'react';

export function useUpdatePending() {
  const [pending, setPending] = useState(false);

  useEffect(() => {
    const sub = Updates.addListener((event) => {
      if (event.type === Updates.UpdateEventType.UPDATE_AVAILABLE) {
        setPending(true);
      }
    });
    return () => sub.remove();
  }, []);

  return pending;
}

Then in your app shell:

const pending = useUpdatePending();

return (
  <>
    {pending && <UpdateBanner onRestart={() => Updates.reloadAsync()} />}
    <YourApp />
  </>
);

Show the banner unobtrusively — top of screen, dismissible. Let the user restart when they're ready.

Trust beats speed.

Communicating rollbacks

If you roll back a bundle, users who had the bad one for ten minutes may have taken some action in that window started a form, attempted a payment. They come back and the UI has changed under them.

For any rollback that touched user-visible state, ship a small in-app notice:

We reverted an update from an hour ago. If you saw errors, they should be resolved now.

Radical honesty. Most users appreciate being told rather than left confused.

When to break the invisibility rule

For truly major changes — new navigation, a redesigned home screen — an OTA that silently swaps things is worse than a store update with release notes.

Consider gating major UX changes behind an in-app "What's new" modal, even if the code shipped via OTA weeks earlier.

The whole point of OTA is that the technical update is invisible. The experiential update never should be.

If you're starting a React Native project and want the update pipeline wired from day one, RapidNative generates Expo apps with EAS Update already configured.

What's your OTA horror story? Mine was schema drift a cached object shape that crashed every returning user on first render.

Your App Store Reviewer Is a User — Design the Demo Account Like a Usability Test

Lucas Martin — Wed, 15 Jul 2026 12:48:14 +0000

Your App Store reviewer is functionally your first real user — same 30 seconds of first impression, but they can reject you.
Three demo-account failures trigger rejections: an empty account, a broken account (stale credentials), and a geofenced account.
Seed the demo account with 10–20 realistic entries, one in-progress state, and completed onboarding.
Add a review-notes walkthrough so the reviewer knows exactly what to test.
Re-seed automatically before every submission — demo accounts decay.

Most indie devs think of the App Store reviewer as a QA person: they check that the app builds, opens, doesn't crash, complies with guidelines, and passes review. That's incomplete.

The reviewer is also, functionally, your first real user. They have the same 30 seconds of first-impression time as anyone who downloads the app. If your demo account puts them in an empty state with no context, they judge the app the same way a real user would — and they can reject.

Reviewers as first-user proxies

From the reviewer's side, the process looks like this: they open your listing, install the app, launch it, and try to use it as if they'd downloaded it themselves. If your app requires auth, they use the demo account you provided.

If that demo account lands them on a blank home screen with no data, they have no way to evaluate whether the app "works."

Rejections in this category read as "your app did not have enough functionality to review" or "we could not test the primary features." Both are UX rejections dressed up as review outcomes.

The three demo-account failures

Failure 1: the empty account. The reviewer logs in and sees a blank feed, an empty list, or a "no results yet" state. There's nothing to interact with, so they can't evaluate the app's real behavior.

Failure 2: the broken account. The demo account has stale credentials, the password was rotated, or the account was disabled. The reviewer gets "invalid password" and can't proceed.

Failure 3: the geofenced account. The demo account requires a specific location, phone number, or region that the reviewer's environment doesn't match. The app looks broken through no fault of its logic.

All three are preventable with about 90 minutes of prep.

What to seed and why

Your demo account should contain, at minimum:

10–20 realistic entries in your primary data model (posts, tasks, contacts — whatever your app centers on).
One realistic "in-progress" state — a partially filled form, a saved draft, a bookmarked item.
Onboarding fully completed — the reviewer shouldn't have to walk through your welcome flow.
At least one "friend" or connection with plausible data, if the app has social features.

The goal is simple: when the reviewer opens the app, they should see something that looks like a real user's screen, not an empty state.

The review-notes template

In App Store Connect's review notes, include a block like this:

Demo account:
  Email:    reviewer@yourapp.com
  Password: <one-time-use password>

This account is pre-seeded with realistic data.
All primary features are accessible without in-app purchase.
Contact: your-email@yourapp.com if any issues.

Walkthrough (in case anything is unclear):
  1. Sign in with the credentials above
  2. The home screen shows your recent [items]
  3. Tap [primary CTA] to try the [key flow]
  4. Long-press [item] to see the [secondary flow]

A walkthrough like this cuts review times noticeably — the reviewer knows exactly what to test and how.

Keeping the demo account healthy across releases

The most common failure here is decay: the demo account drifts over time. New features get added that need new seed data. Passwords get rotated. The account gets used for real dev testing and its state wanders.

What works:

Automated re-seeding before each submission — a script that clears and reseeds the account.
A checklist item in your release process: "verify demo account signs in and shows expected data."
Never use the demo account for actual dev work — keep it review-only.

Takeaway

A polished demo account with seeded data plus a clear walkthrough is one of the highest-leverage things you can do for review outcomes. Treat the reviewer as a one-shot usability test — you have five minutes to convince them the app works.

If you'd rather not hand-build all this from scratch, RapidNative generates React Native + Expo apps with seed data and demo states you can point straight at a reviewer.

What's the most avoidable App Store rejection you've hit? Drop it in the comments.