Frontend After AI: What Still Matters When Agents Write the UI

Nolan Lawson’s The asteroid currently hitting frontend web development is back on Hacker News, and for good reason. He is not hyping “10x shipping.” He is naming the awkward part: educators dialing back or pivoting to AI, agents that already give expert CSS Style Calculation advice, and teams rewriting Solid or Lit to React because agents know React better than humans know Solid.

I am Muhammad Tayyab, a full stack and mobile developer in Lahore. I ship Talk Motion, WorkConnect, Black Seal, and this site on Next.js + Sanity. I already use agents hard — I wrote about that in AI-first development. This post is the other half: what still matters when agents write the UI.

Frontend after AI is not “stop caring”

Lawson’s point that hits hardest for me is risk asymmetry. Chuck a bad DB migration into production and you get an incident. Yolo a React component and the blast radius is usually smaller — though he is careful: accessibility failures and infinite loops are still real.

That matches how I work day to day. I will let an agent draft a settings screen. I will not let it decide whether WorkConnect’s authenticated shell should be an SPA-shaped App Router tree while my portfolio blog stays content-first and mostly static. Those are architecture calls. Typing the JSX is not.

He also notes Cursor and Viget moving toward React for agent experience over DX. I feel that pull. My stack already leans React/Next because I ship web and mobile adjacent work and agents are fluent there. Homogenization is real. The answer is not mourning conferences — it is keeping judgment where the model is weak.

What I refuse to outsource when agents write the UI

Accessibility gates stay human

Agents will happily ship a pretty card with no focus ring, a modal that traps keyboard users wrong, or icon buttons missing names. Lawson flags a11y as a real residual risk, and I treat it as a merge blocker, not a nice-to-have.

On my apps I keep a short checklist before anything client-facing ships:

• Keyboard path for primary flows (no mouse assumed)
• Labels, names, and live regions for dynamic UI
• Contrast that survives dark mode and real device brightness
• Focus order after route and dialog changes

Agents can draft the markup. I still run the gate. Users with assistive tech do not care that Claude wrote the component.

Performance budget and Lighthouse taste

Lawson asked Claude about high Style Calculation cost with low Layout cost and got a strong answer — selector invalidation, inherited props, custom properties at the root, the usual traps. He says he would chuck a Chrome trace at Claude Code. Same. Agents are useful for diagnosis.

They are weaker at taste: which 50ms matters on a Pakistani 4G link, when a Lighthouse green is lying, when Instant Navigations still feel slow because the wrong chunks shipped. I have written about fixing Lighthouse on this portfolio and Turbopack chunking in Next.js 16.3. The knobs exist. Choosing the budget is still on me.

My rule: agents propose patches; I own the budget. If LCP regresses on the blog or WorkConnect’s first paint balloons, that is a human veto — not “ask the agent to make it fast again” forever.

MPA vs SPA is still an architecture decision

Agents love SPAs. Lawson’s positive path is educating them on MPA vs SPA: Astro or Eleventy for marketing, less code, fewer back-button and focus bugs. I agree in practice even when the framework is Next.

My portfolio and blog are content sites. They want SSR/SSG, structured data, fast HTML, boring routes. WorkConnect is an authenticated product app — richer client state, sessions, realtime-ish surfaces. Same Next.js family, different shape. If I let an agent “just build the site” without that constraint, I burn tokens fixing history, focus, and payload weight.

Agent-friendly sites, as Lawson notes, ironically look like good fundamentals: server-rendered content, accessibility, page speed. That is not nostalgia. That is how you stop paying twice — once to generate a SPA, again to un-SPA it.

Visual and interaction taste

In the comments on his post, Lawson agrees design and taste stay resistant: agents lack eyes and customer judgment. That tracks. I can get a competent first layout from an agent. I still notice when spacing is “almost,” when motion feels cheap, when a CTA is the wrong weight for a Pakistani indie product vs a US SaaS template.

Talk Motion and Black Seal live or die on how the UI feels in a thumb’s first ten seconds. I will not outsource that final pass. Eyes and product context still beat a screenshot prompt.

Concrete example: an agent will give me a onboarding carousel that looks like every other AI landing page — soft purple blobs, three feature cards, a “Get started” button with perfect border radius. Users bounce. What actually converts for me is quieter hierarchy, one clear next step, and copy that sounds like a person in Lahore shipping software, not a Series A pitch deck. That judgment is product work wearing a frontend hat.

SEO and structured data judgment

Agents will invent meta descriptions, duplicate titles, or skip JSON-LD because the page “looks fine.” Search and social previews are product surfaces for indie work. I decide canonical strategy, Open Graph honesty, and whether a page earns an Article schema. The agent drafts; I approve.

• First-pass pages when the IA and constraints are already written down
• Refactors that stay inside a reviewed pattern library

That is where agents crush it for indie shipping. I am one person across web and mobile. Drafting twenty Button variants by hand is a bad use of a week in Lahore.

On WorkConnect I will point an agent at the design tokens and say “build the empty states and loading skeletons for these three list views.” It is faster than me, and the risk is low if the tokens and a11y defaults already encode my taste. On this blog I will let it draft Portable Text-friendly layouts and FAQ blocks — then I rewrite voice so it sounds like me, not a press release.

The split is simple: generation inside a fence I built. Outside the fence — new product surfaces, new navigation models, anything that changes how users think about the app — I slow down and decide first.

Stay architect: constraints before generation

What I happily let agents draft

I am not anti-agent. I am anti-abdication.

I happily outsource:

• Boilerplate components against an existing design system
• Styling variants (sizes, densities, dark/light) once tokens exist
• Tests for happy paths and obvious regressions

The pattern that works for me:

1. Tokens and component library first — colors, type, spacing, a11y defaults in code the agent must reuse
2. Written constraints — “content site, MPA-ish, no client bundle for marketing routes” or “authenticated shell, keep session logic out of presentational components”
3. Review checklist — a11y, perf budget, SEO, visual QA on real devices
4. Then generate

If I skip step 1–3, I get vibe sludge: duplicated spacing scales, three modal patterns, a marketing homepage that hydrates half the app for a contact form. If I do them, the agent looks “smarter” because the rails are tight.

Lawson’s consulting angle for vibe-coded sites is the same idea from the outside: when money is on the line and the builder only knows “websites are apps on the internet,” expertise still matters. From the inside of shipping Talk Motion and WorkConnect, that expertise looks like constraints before generation — not mourning the asteroid.

Agent experience is winning over DX in some rewrites. Fine. I still choose architecture so the agent’s fluency does not pick a SPA for a blog or skip the focus trap because React was easier to autocomplete. When I do lean on React/Next for agent fluency, I pay that debt back with stricter reviews on the parts agents paper over — not by pretending the rewrite was free.

Indie shipping, not funeral for frontend

I am not here to eulogize conference tracks. I am here to ship. Frontend after AI, for me, means:

• Agents write a lot of the UI
• I keep the gates that users feel: a11y, speed, architecture, taste, SEO
• Fundamentals got rebranded as “agent-friendly,” and that is fine if it gets teams to care again

The asteroid metaphor is useful. Ignoring the crater is denial. Sitting in the crater and refusing to build is also a choice. My bet as an indie developer is boring and durable: use agents for volume, keep human ownership on the surfaces users actually touch, and treat architecture like a product decision — because it is.

If you are building with agents and want another set of eyes on a Next.js app that has to work for real users — not just look generated — get in touch.

FAQ

Does frontend still matter if agents write most of the UI?

Yes. The ephemeral parts get cheaper. The judgment parts — accessibility, performance budgets, MPA vs SPA, taste, SEO — still decide whether users stay. Agents draft; you still own the product surface.

Should I rewrite everything to React because agents know React?

Not blindly. Lawson cites teams moving Solid/Lit → React for agent experience. If you already ship React/Next and agents are productive there, lean in. If you have a working Vue or Solid product, measure agent quality before a rewrite. Homogenization is a force, not a law.

What is the fastest way to keep quality when agents generate UI?

Constraints before generation: design tokens, a small component library, an a11y/perf checklist, and a clear MPA vs SPA call for each surface. Then let the agent fill in the blanks.

How do I use agents without rehashing “ship 10x” advice?

Separate drafting from deciding. Let agents produce components, variants, and tests. Keep architecture, budgets, and taste reviews human. That is the practical middle between denial and vibe-only shipping.

Muhammad Tayyab is a full stack and mobile developer in Lahore, Pakistan. He builds Talk Motion, WorkConnect, and Black Seal — available for React/Next.js, Node.js, and SwiftUI projects. Get in touch · GitHub · LinkedIn · X.