Elegant

An executable guardrail beats a review comment every time

The Elegant team 6 min readai-and-frontend
An executable guardrail beats a review comment every time

A rule that lives in a senior engineer’s head is enforced only when that engineer happens to be reviewing, is paying attention, and remembers the rule that day. The same rule written as a check is enforced on every diff, forever, by something that never gets tired, never rushes a Friday review, and never lets a change through because it trusts the author. This is the whole argument for executable guardrails over review comments, and it stops being a nice-to-have the moment a meaningful share of your code is authored by an AI — because review does not scale to that volume and a check does.

A review comment catches some diffs; an executable guardrail catches all of them Top row: many diffs pass a human reviewer, some slip through unchecked. Bottom row: the same diffs all pass through a guardrail gate, none slip through. review (sometimes) 👁 one slipped through guardrail (always) gate every diff, same standard
Review is a probabilistic filter — attention-dependent and rushed under load. A guardrail is a deterministic gate that applies the same rule to every change.

Turn the review comment into a check

The move is mechanical: whenever you write the same review comment twice, promote it to a check. “Don’t hard-code colours, use a token” is a real, repeatable comment — and a two-line rule:

// eslint: no raw hex colours in components — use a design token
{
  files: ["src/**/*.{jsx,css}"],
  rules: {
    "no-restricted-syntax": ["error", {
      selector: "Literal[value=/#[0-9a-fA-F]{3,6}/]",
      message: "Use a design token (var(--…)), not a raw hex colour.",
    }],
  },
}

You will never type that comment again. The rule types it, on every diff, with a message that teaches the fix.

A guardrail gives the failure a name

The underrated benefit is specificity. A review comment is often vague — “this feels heavy,” “watch the bundle size.” A check states the exact threshold and the exact overage, which is both fairer to the author and impossible to argue with:

$ node harness/bundle-budget.js
  FAIL  entry chunk is 312kb, budget is 250kb (over by 62kb)
        largest additions: chart-vendor 48kb, moment 19kb

Now the conversation is not “is this too big?” but “here are 62kb to remove, and here is where they came from.” The disagreement disappears because the standard is written down and measured.

What review is still for

None of this abolishes review — it reallocates it. Offloading the mechanical, repeatable rules to guardrails frees human review for the things a check genuinely cannot judge: is this the right abstraction, does this API make sense, will this design age well. That is a better use of a senior engineer than counting hex codes, and it is the only division of labour that keeps up when a model is generating diffs faster than anyone can read them. The rule of thumb is simple: if you can state the rule precisely, make it a check; if judging it requires taste and context, keep it in review. The harness-link-checker and harness-atom-guardrail exercises are exactly this promotion in miniature — a comment you would have made by hand, turned into a gate that makes it for you, every time.