Guide
UI code review tools
The build is green and the interface is broken. What each tool in the pipeline actually checks, and where the gap is.
Every check passed. ESLint found nothing, the tests are green, TypeScript compiled without complaint. The deploy goes out, and the new settings page has body text at 3.8:1 contrast, a modal you can't close with a keyboard, and buttons in three slightly different heights. Nothing in the pipeline was looking for any of it.
That's a scoping problem, not a tooling failure. Each tool in a frontend pipeline checks exactly what it was built to check, and the design quality of the interface is in none of their job descriptions.
What each tool actually covers
| Tool | What it checks | What it can't see |
|---|---|---|
| ESLint Rams vs ESLint → | JavaScript/TypeScript syntax, style, likely bugs. With jsx-a11y, a static slice of accessibility. | Anything visual: hierarchy, spacing, color, states. |
| axe Rams vs axe → | Accessibility violations on a rendered page, at runtime. | Everything outside accessibility, and any page you don’t point it at. |
| Lighthouse Rams vs Lighthouse → | Performance, SEO, and baseline accessibility on a rendered page. | Design quality. A page can score 100 and look wrong. |
| Visual regression (Chromatic, Percy) | Pixel diffs against an approved baseline screenshot. | Whether the baseline was good. It catches change, not quality. |
| General AI reviewers (CodeRabbit, Greptile) Rams vs CodeRabbit → | Broad code review: logic, security, style, architecture. | Design isn’t systematic — a11y and visual issues surface occasionally, not reliably. |
| Automated design review (Rams) | Design quality of UI source at PR time: accessibility, color, typography, spacing, components, UX, motion, craft. | Logic, security, performance. It reviews the interface, not the program. |
The uncovered slot: a design read of the diff
Line the tools up and one job stays unassigned: someone reading the changed UI code with design judgment, before it merges. Linters read the diff but don't judge design. axe and Lighthouse judge more, but only after render, on pages you remember to test. Visual regression flags that pixels changed, not whether the change was good.
Automated design review fills that slot. Rams does it as a GitHub App: it reads the UI files in each pull request and reviews them against 118 rules across 8 categories — accessibility, color, typography, spacing, components, UX, motion, and craft — then posts findings as inline comments with one-click fix suggestions. It runs in about a minute, with no CI config, and every review produces a 0–100 design score you can track.
The bar is stricter than green checks suggest. shadcn/ui scored 54/100 under this ruleset, and its checks were green too.
Choosing honestly
None of these tools replaces the others. Keep ESLint; it's the right tool for code correctness. Keep axe or Lighthouse in CI if you have runtime accessibility gates. Add a design reviewer if the failure you keep shipping is the one no green check ever catches: an interface that works and looks wrong.
Find out what your green checks are missing.
Free on public repos. One review, one score, no config.
Review my public repoFree