React UI Components for AI-Built Websites

Key answer: React UI components are the reusable interface parts — dashboards, forms, navigation, and page sections — that an AI coding tool assembles into a website, and AI tools like Claude Code and Cursor build faster and more reliably when they install real React UI components from a curated source instead of regenerating them from scratch each time. Production-ready means accessible, typed, themable, framework-native source you actually own. AETumi ships exactly this: React and Next.js components you can install, edit, and keep, discoverable by your agent through MCP, sitting alongside cinematic 3D scenes.

Table of contents

• What you'll learn
• What React UI components are here
• Why AI workflows need a component source
• Architecture: discovery, install, adapt
• What makes a component production-ready
• The components that matter most
• How the MCP discovery layer works
• Real product evidence
• Performance
• Accessibility
• Production trade-offs
• When to use a component source
• When not to
• Decision matrix
• Expert notes
• How AETumi provides React and Next.js components
• GitHub and technical proof
• FAQ
• Related AETumi resources
• Conclusion

What you'll learn

• What "React UI components" means in an AI-assisted build, and why a curated source beats regeneration.
• The four properties that make a component production-ready: accessible, typed, themable, owned.
• The component types that repeat on almost every site, and why owning them pays off.
• How an MCP discovery layer lets an agent list and install components directly.
• The performance, accessibility, and maintenance trade-offs, and where AI still needs human review.
• How an owned source supplies editable React and Next.js components alongside cinematic 3D.

What React UI components are here

React UI components are self-contained, reusable pieces of interface built as React (and, in the App Router, Next.js) source: a Button, a Card, a DataTable, a NavBar, a PricingSection. Each one owns its markup, its styling contract, and its behavior, and exposes a typed props interface so it can be dropped into any page. In an AI-assisted build, they are the parts an assistant composes into pages — as opposed to prose, the freeform markup an assistant synthesizes when no parts exist.

An AI assistant can write a login form or a data table on demand. The question is whether it should. Regenerating the same navigation bar, the same settings panel, the same pricing grid on every project wastes tokens, invites subtle accessibility bugs, and produces code no two pieces of which match. A real component library flips that: the agent reaches for a known-good part and spends its effort on your product instead of reinventing a dropdown.

Why AI workflows need a component source

When you ask Claude Code or Cursor to "add a dashboard," the model has two options. It can synthesize markup and styles from its training, or it can pull a real component that a human already reviewed. The first path is convenient but lossy — the agent guesses at focus states, keyboard handling, and responsive breakpoints, and each guess is a place a bug hides.

The second path treats components as parts, not prose. The agent discovers what exists, installs it, and adapts it to your data. That is a better division of labor: the library carries the hard, repeatable engineering (accessibility, theming, types), and the agent carries the context only it knows — your routes, your API shape, your copy. This is the pattern a curated component source is built around, and it is what keeps an AI-built site consistent instead of drifting screen to screen.

Architecture: discovery, install, adapt

The workflow has three stages, and a good component source supports all three. Discovery: the agent needs to know what components exist without you pasting a catalog into the prompt. Install: the chosen component arrives as source in your repository — real files you can read — not as a runtime import behind a version number. Adapt: the agent wires the component to your data, routes, and copy, and edits the source where your case diverges.

The stage that most tools skip is discovery. Without it, you become the index — copying snippets from a documentation site into your editor. A discovery layer, exposed through an MCP server, lets the agent list available components and install one directly. The component lands in your repo as source, wired into your project, and from there the agent adapts it. This is the difference between a component website you browse and a component source your agent operates.

What makes a component production-ready

"Production-ready" is easy to claim and specific to verify. Four properties separate a component you can ship from a snippet you have to babysit:

• Accessible. Semantic elements, real focus management, keyboard operability, and ARIA only where the native element cannot carry the role. A modal traps focus and restores it on close; a menu is reachable with arrow keys.
• Typed. TypeScript props with clear names and sensible defaults, so the agent — and you — get autocomplete and compile-time errors instead of runtime surprises.
• Themable. Styling driven by design tokens or CSS variables, not hardcoded hex values, so one component matches your brand without a rewrite.
• Framework-native source you own. Real React and Next.js files in your repository, not a runtime black box behind an import. You can read them, edit them, and keep them.

A minimal typed, themable component looks like this — note the token-driven color and the explicit prop contract:

type CardProps = {
  title: string;
  children: React.ReactNode;
  tone?: "default" | "accent";
};

export function Card({ title, children, tone = "default" }: CardProps) {
  return (
    <section
      className="card"
      data-tone={tone}
      style={{ background: "var(--surface)", color: "var(--text)" }}
    >
      <h3 className="card__title">{title}</h3>
      {children}
    </section>
  );
}

The component reads its colors from CSS variables, so theming happens at the token layer, and the tone prop is a closed union, so an agent cannot pass an invalid value without a type error. Expected behavior: the same Card matches light and dark themes with no edits. The trade-off is that this only holds if every component in the source honors the same token names — one hardcoded hex and the theming guarantee breaks, which is a thing to check when you edit or extend.

A slightly richer example shows the accessibility property — a disclosure that is keyboard-operable and announces its state:

"use client";
import { useState, useId } from "react";

export function Disclosure({ label, children }: { label: string; children: React.ReactNode }) {
  const [open, setOpen] = useState(false);
  const id = useId();
  return (
    <div>
      <button aria-expanded={open} aria-controls={id} onClick={() => setOpen(!open)}>
        {label}
      </button>
      <div id={id} hidden={!open}>{children}</div>
    </div>
  );
}

The disclosure uses a real <button>, aria-expanded to announce state, and aria-controls to associate the trigger with its panel. Expected behavior: screen readers announce "expanded"/"collapsed," and the panel toggles with Enter or Space for free because it is a button. The trade-off is that this is the minimum bar — a production menu also needs arrow-key navigation and focus management, which is exactly the reviewed engineering a component source carries so the agent doesn't re-derive it.

The components that matter most

Most AI-built sites and apps repeat the same handful of surfaces. A component source earns its place by covering them well:

• Dashboards. Stat tiles, tables, filters, and layout shells — the parts that carry data and are tedious to get right.
• Forms. Inputs, validation states, selects, and multi-step flows, where accessibility and error handling are most often skipped.
• Navigation. Headers, sidebars, tabs, and menus that must stay keyboard-operable and responsive.
• Sections. Hero, features, pricing, testimonials, and calls to action — the marketing surfaces of a landing page.

When these exist as reviewed parts, the agent assembles a page from known-good pieces and reserves its creativity for what is genuinely custom. Forms are the clearest example of why this matters — accessibility and error handling are exactly what an agent skips:

export function FormField({ id, label, error, ...input }: {
  id: string; label: string; error?: string;
} & React.InputHTMLAttributes<HTMLInputElement>) {
  const errId = `${id}-error`;
  return (
    <p className="field">
      <label htmlFor={id}>{label}</label>
      <input id={id} aria-invalid={!!error}
             aria-describedby={error ? errId : undefined} {...input} />
      {error && <span id={errId} role="alert" className="field-error">{error}</span>}
    </p>
  );
}

The field ties its <label> to the input, flags aria-invalid on error, and associates the message with aria-describedby so screen readers announce it. Expected behavior: the error is read out when it appears, and focus moving to the input announces the description. The trade-off is that this correctness is easy to specify and easy to forget — which is the whole argument for a reviewed source: the field is right once, and the agent reuses it instead of re-deriving a div-based input that drops the label association.

How the MCP discovery layer works

The Model Context Protocol (MCP) is an open standard that lets an AI assistant call external tools. A component source exposed as an MCP server gives the agent two capabilities: list what components exist, and install one into the project. Wiring it into an agent like Claude Code or Cursor is a small config change.

{
  "mcpServers": {
    "aetumi": {
      "command": "npx",
      "args": ["-y", "@aetumi/mcp"]
    }
  }
}

After this config, the assistant can list and install components on its own — no browser round-trip, no copy-paste. Expected behavior: you ask for "a pricing section," the agent queries the MCP server, installs the matching component as source, and adapts it to your copy. The trade-off is that MCP shifts install power to the agent, so you review what it added the same way you review any code it writes; discovery does not remove the human review step, it just removes the manual indexing. For the boundary decisions this creates in Next.js specifically, see Next.js UI components with an AI coding assistant.

Real product evidence

The demo below shows an agent installing a React UI component through the MCP server and adapting it to project data — the discover, install, adapt loop in one pass. What it proves is that the component arrives as editable source in the repo, not as an opaque runtime dependency: after install, the agent opens the same files a human would and wires them to real routes. The deeper point is what these UI parts sit beside. The same source that supplies a clean settings form also supplies a production Three.js scene in the same design language, so one project carries both conventional UI and standout 3D moments.

Performance

Owned components help performance in two ways. First, they are written once and optimized once, so an agent assembling them doesn't re-introduce a heavy re-render or a layout thrash on every regeneration. Second, real source lets you see and fix the cost — you can code-split a heavy component, lazy-load a below-the-fold section, or memoize a list, because you own the file. A runtime black-box component gives you none of that visibility. The caveat: owning the source also means owning the performance work. The component source gives you a good starting point, but you still profile with real data, and you still decide what to defer. An AI assistant will not do that profiling unprompted.

Accessibility

Accessibility is the property AI most reliably approximates and least reliably nails. A component that compiles is not automatically accessible: the assistant produces divs with click handlers, omits focus return on dialog close, and forgets aria-current on active links. A reviewed component source front-loads this work — the modal already traps focus, the menu already handles arrow keys — so the agent inherits it instead of guessing. Even so, review the assembled result in your context: check tab order, focus visibility, labels, and contrast with a keyboard-only pass. Owned source makes the fixes possible; the review makes them happen.

Production trade-offs

A component source is not a silver bullet. It is another dependency to keep current, and owning the source means owning its maintenance — updates are yours to merge. The MCP discovery layer adds a moving part to your toolchain that has to be configured and trusted. And the central honesty of this whole approach: AI needs direction and review. A source makes the agent faster and more consistent, not autonomous — you still decide the architecture and check the output. Be honest about scope, too: for a single static page with no repeating UI, pulling in a component source and an MCP server is more machinery than the job needs; plain markup is fine. Reach for owned components when the site has surfaces that repeat and a lifespan that rewards consistency.

When to use a component source

When not to

Decision matrix

Expert notes

Expert Note — Point the agent at the source, or it will invent one. The most common failure is not a bad component library; it is forgetting to tell the agent to use it. Left unprompted, Claude Code or Cursor will happily synthesize a fresh dropdown every session. Put the instruction in your project rules or system prompt: "use the installed component source; do not regenerate UI." Consistency is a prompting discipline as much as a tooling one.

Expert Note — "Compiles" is not "accessible." Treat every agent-installed or agent-edited component as a draft on accessibility until you have done a keyboard pass. The value of a reviewed source is that the hard parts — focus trap, arrow-key menus, aria-expanded state — are already correct, so your review is a quick verification rather than a rebuild. Never ship an interactive component you have not operated with the keyboard.

Expert Note — Own the files, or you can't fix them under deadline. A runtime component you cannot open is fine until the day it renders wrong in your exact layout and you have no way to patch it. Framework-native source you own turns that emergency into a one-line edit. This is the single most practical reason to prefer editable source over a black-box import for anything you'll run in production.

Expert Note — Don't force 3D where static wins. Cinematic Three.js scenes are a real differentiator for a hero or a product moment, but a form, a table, or a settings panel is better plain. Use the visual weapons where they earn attention, and keep the everyday UI fast and quiet. A component source that carries both lets you make that choice per surface instead of committing the whole site to one register.

How AETumi provides React and Next.js components

AETumi is an AI-native 3D web platform, and its React component library is a first-class part of it. The components are real React and Next.js source: accessible, typed, and themable, built to be installed into your project and edited. On the Full Stack plan ($129, buy once and own for life), you get the full editable source plus the MCP server, which lets your AI assistant discover and install components directly through MCP rather than through copy-paste. AETumi does not sell "unlimited" anything — you buy the source once at a fixed price and keep it for life.

The differentiator is what these components sit next to. Those UI parts share a codebase with cinematic 3D — AETumi Three.js and WebGL scenes, scroll-driven heroes, R3F components. So the same project that gives your agent a clean settings form also gives it a production 3D scene, in the same design language. You get the conventional UI surfaces and the standout visual moments from one source. For a broader view of how AI changes the design process end to end, see AI website design; for the states a data UI must handle, see building a React dashboard UI with AI.

GitHub and technical proof

For the 3D side, the open react-three-fiber-examples repository shows minimal, correct scenes you can learn from — how to mount an R3F canvas, drive it from React state, and keep it accessible and performant inside a normal React app. The examples are deliberately small so each concept is legible; the limitation is that they teach the embedding pattern rather than shipping a full component catalog, which the AETumi source provides. Performance-wise they isolate the 3D render loop from the surrounding UI so a scene doesn't re-render on unrelated state changes — the discipline any site mixing 3D with conventional components needs. Read the repo to internalize the pattern, then compose it with the owned UI components for the non-3D surfaces.

FAQ

Can't the AI just write the React UI components itself? It can, but it will re-derive the same parts repeatedly, with inconsistent accessibility and styling, and no two instances will match. A curated source gives it reviewed pieces so it spends effort on your product — your routes, data, and copy — not on reinventing a table. The library carries the hard, repeatable engineering; the agent carries the context only it has. That division is what keeps an AI-built site consistent instead of drifting screen to screen.

Do I own the component source? Full editable source ownership comes with the Full Stack plan ($129, buy once and own for life). That plan also includes the MCP server for discovery and install. Owning the source means the files live in your repository — you can read them, edit them, and keep them, with no runtime black box and no per-seat subscription. AETumi does not offer "unlimited" tiers; the model is buy once, own for life.

Are these components accessible out of the box? They are built with semantic markup, focus management, and keyboard support — a modal traps and restores focus, a menu is reachable with arrow keys. As with any code, review the result in your context: AI-assisted work still needs a human check, and your specific layout can introduce issues the component alone can't foresee. The value of reviewed source is that the hard accessibility work is already done, so your check is a verification, not a rebuild.

How does the agent install a component? Through the AETumi MCP, an assistant like Claude Code or Cursor can list available components and install one into your project as source, then adapt it to your data and routes. You add a small mcpServers entry to the agent's config, and from then on the agent discovers and installs directly instead of you copy-pasting from a browser. You still review what it adds, exactly as you would review any code the agent writes.

Related AETumi resources

• React component library — the owned, editable source.
• MCP workflows — the discovery and install layer.
• Three.js at AETumi — the cinematic 3D that shares the codebase.
• Next.js UI components with an AI coding assistant — server/client boundaries in depth.
• Building a React dashboard UI with AI — the four states people forget.

Conclusion

AI writes code quickly, but it builds better sites when it assembles from real, reviewed parts. Production-ready React UI components — accessible, typed, themable, and owned — turn your agent from a code generator into an integrator, and an MCP discovery layer lets it find and install them without you becoming the index. Keep a human on accessibility, performance, and architecture; the source makes those fixes possible and the review makes them real. AETumi supplies those components as editable source alongside cinematic 3D, discoverable through MCP, so the same project carries both your everyday UI and your standout moments — buy once, own for life. Explore the React component library and the plans at aetumi.app/pricing when you want your AI workflow to stop reinventing the dropdown.