About

Most of what makes AI-assisted coding expensive and unpredictable isn't logic — it's UI. Layout, spacing, and composition decisions are exactly the kind of open-ended judgment call a model has to re-solve from scratch on every request, and the cost shows up twice: in tokens spent deciding, and in the variance between one run and the next. Rebar removes that decision from the job by shipping units that already encapsulate it — a full Kanban board, a signature pad, a combobox — so the model supplies content and props instead of re-deriving layout from scratch, whether it reaches for that unit as hand-authored JSX or through the placement layer's own construct wrapper. The measured result is a real, repeated (n=15) one: cheaper than hand-authored Ant Design outright, faster, and close to zero run-to-run variance, not just cheaper than hand-authoring the same thing without a design system at all.

Rebar is aimed at IT professionals and engineering teams who need to ship a real, working tool and don't want the UI layer to be where the project gets stuck. It's deliberately low-fidelity out of the box — genuinely usable and accessible, but visually plain by design — so token spend and attention go toward logic, data flow, and correctness first. Visual finish is a real, bounded step at the end (migrate once to a real design system), not an ongoing back-and-forth on an unfinished frame the whole way through.

Cheaper and faster is the headline, but it's not the point on its own. The interactive primitives (dialogs, menus, selects, tabs, tooltips, popovers and the like) wrap real Radix UI primitives underneath, and the components built on them inherit that, so keyboard operability, focus management, and ARIA semantics come from a maintained library rather than being bolted on. Visual values are driven by --rebar-* CSS custom properties rather than hardcoded pixels or colors — which is what makes the near-zero output variance possible in the first place: a pre-built component's own internal layout is fixed by its implementation, not re-derived per request, whether it's reached directly as JSX or composed through the placement layer — either way, the model isn't improvising layout from scratch.

A real, common failure mode inside larger organizations: many different teams — sometimes many different individual engineers — building internal tools in isolation, each with its own ad hoc styling, its own inconsistent patterns, no shared visual language at all. When every one of those tools is built the same way, through the same small block vocabulary and the same token set, they converge on the same look without anyone having to coordinate it by hand. That's a genuinely different scale of consistency than one team's design system — it's every team's internal tooling looking like it came from the same place, by construction, not by a style guide everyone's expected to remember.

A core use case for Rebar is decomposing an incumbent enterprise platform — a large, entrenched system (a CRM, an ERP, a legacy internal tool) that's expensive to replace wholesale but painful to keep extending. Reverse-engineering the pieces you actually need into a placement-layer document is cheap precisely because the composition step is free: describe what a screen needs to do, not how it should look, and rebuild it incrementally rather than committing to a single, all-or-nothing migration. Scenario 6 on /benchmarks works through this directly, with real numbers, not just the idea of it.

Rebar is MIT-licensed and the entire catalogue is available: every component, every block, the placement layer's Packer, the theme packages, and this docs site's own source. That's a deliberate design choice, not incidental openness — the whole point of shipping deliberately low-fidelity, token-only-styled components (see Built for engineers, not designers above) is that a team can fork the entire project, replace the visual layer with their own brand, and keep everything else — the tier structure, the component APIs, the Packer's schema — exactly as-is. A consumer isn't limited to installing rebar-ui as a dependency and working around its look; taking the whole repo and making it your own is a fully intended, first-class path in, the same as any other.

Maintaining a fork inside the default catalogue structure is what keeps that path cheap over time. Concretely: keep the tier taxonomy (Imitation/Synthetic/Opinion/Order/Genesis) and the file layout it implies (packages/core/src/components, one file per component; apps/docs/src/app/<tier>/<slug> for its reference page) intact rather than reorganizing around your own conventions — the classification rules in ref/TIERS.md, the build/test/typecheck discipline in add-constructs.md, and any tooling built against that structure (the props-table generator, the packer-coverage audit, an agent's own agent.md context) all assume it, and keep working on a fork for free as long as the shape doesn't drift. Re-skin through the existing theme mechanism — swap @rebar-ui/theme-clean/@rebar-ui/theme-sketch for your own theme package that redefines the same --rebar-* custom properties — rather than hand-editing component internals or hardcoding colors into component files; that's what keeps a fork mergeable with upstream changes instead of diverging into an unmergeable rewrite. Add your own project-specific constructs the same way add-constructs.md describes for this repo itself: classify by the same tests, build a reference page the same way, and they'll sit naturally alongside the shipped catalogue rather than as a bolted-on second system.

The broader thesis this project is betting on: making AI-assisted UI work genuinely more efficient puts real, positive price pressure on both development and AI services generally — not because Rebar itself is special, but because of what reaching for a pre-built, complete component instead of assembling one from primitives actually changes about the job. Two concrete mechanisms, not just a hope:

• Cheaper models close the gap with premium ones. The real, measured cross-model benchmarking on this project found the gap between rebar-ui and hand-authored Ant Design is bigger on a budget model (Qwen, Kimi) than on a frontier one (Claude) — because most of what a cheaper model struggles with is exactly the open-ended composition work a complete, pre-built component removes from the job. Reaching for the highest-tier existing unit is a lever that helps a cheaper model punch above its weight more than it helps an already-strong one.
• Less total compute, not just less cost per call. Composition and layout decisions currently get re-solved by a model on every single request, everywhere, by every developer independently. Moving that work into a shared, reusable component catalog — open source, one implementation per interaction pattern, used by the whole developer community instead of re-derived per project — is a real reduction in the amount of inference the industry collectively needs to do to get the same UI built.

This is the project's stated thesis, not a measured claim the way the token/time numbers on /benchmarks are — it's the reasoning behind why this exists, offered plainly as reasoning rather than dressed up as proof.