Anti-Pattern Budgets & Ratcheting — Find the Bug¶

Category: Anti-Patterns at Scale → Anti-Pattern Budgets & Ratcheting — spot the ratchet that looks like it works but doesn't. Covers (collectively): Baseline-and-ratchet · "No new violations" gates · Per-area debt budgets · Ratchet tooling · Failing the build on regression

These are broken ratchets. Each one looks fine — it runs, it's green on the happy path, it gets merged — but it silently fails to do its one job: stop the metric from getting worse. For each: read the snippet, answer the question yourself, then reveal the fix.

The theme: a broken ratchet is more dangerous than no ratchet, because everyone believes the codebase is protected while it quietly rots. The bugs below are the ones that actually ship — usually because the gate stays green, so nobody notices it stopped gating. Refer to professional.md for the failure-mode catalog.

Table of Contents¶

Bug 1 — The self-updating baseline¶

#!/usr/bin/env bash
# ratchet.sh
set -euo pipefail

baseline=$(cat .baseline)
current=$(violations | grep -c '^')

if [ "$current" -gt "$baseline" ]; then
  echo "regression detected"
  exit 1
fi

echo "$current" > .baseline          # keep the baseline up to date
git commit -am "update baseline" && git push

The question. This passes every test, the build is always green, and yet the violation count keeps climbing in production. Why does this ratchet never catch a regression?

if [ "$current" -gt "$baseline" ]; then
  echo "❌ regression: $current > $baseline"; exit 1
fi
if [ "$current" -lt "$baseline" ]; then
  echo "$current" > .baseline                    # tighten ONLY on improvement
  git commit -am "ratchet: tighten → $current"
fi
# equal: do nothing — the baseline holds.

Bug 2 — The off-by-one creep¶

def check(current: int, baseline: int) -> int:
    if current > baseline + 1:        # allow a little slack so we're not too strict
        print(f"❌ regression: {current}")
        return 1
    return 0

The question. The author added + 1 "to avoid being annoyingly strict." Why does this quietly let the violation count grow without bound?

def check(current: int, baseline: int) -> int:
    if current > baseline:            # strict: not one more than today
        print(f"❌ regression: {current} > {baseline}")
        return 1
    return 0

Bug 3 — Counting lines, not violations¶

#!/usr/bin/env bash
# "code quality ratchet"
baseline=$(cat .loc-baseline)
current=$(find src -name '*.go' | xargs wc -l | tail -1 | awk '{print $1}')

if [ "$current" -gt "$baseline" ]; then
  echo "❌ codebase grew — quality regression"; exit 1
fi
echo "$current" > .loc-baseline

The question. This ratchets total lines of code as a quality metric. Beyond the self-updating-baseline bug, what makes the metric itself worthless and trivially gamed?

baseline=$(cat .lint-baseline)
current=$(golangci-lint run ./... 2>/dev/null | grep -c ':')   # count warnings, not lines
if [ "$current" -gt "$baseline" ]; then
  echo "❌ lint warnings increased: $current > $baseline"; exit 1
fi
# (and tighten only on a decrease)

Bug 4 — The baseline that resets on merge¶

# .github/workflows/ratchet.yml
on:
  push:
    branches: [main]          # run after every merge to main
jobs:
  ratchet:
    steps:
      - uses: actions/checkout@v4
      - run: |
          current=$(violations | grep -c '^')
          echo "$current" > .baseline      # "refresh" the baseline on main
          git commit -am "baseline: $current" && git push

The question. This recomputes and commits the baseline on every push to main. The PR-time gate compares against this committed baseline. Why does this combination mean a PR can add violations and they become permanent with no red build?

current=$(violations | grep -c '^')
baseline=$(cat .baseline)
if [ "$current" -lt "$baseline" ]; then    # tighten only; NEVER overwrite upward
  echo "$current" > .baseline
  git commit -am "ratchet: tighten → $current [skip ci]" && git push
fi
# if current >= baseline: leave the baseline untouched.

Bug 5 — Comparing against main's tip¶

#!/usr/bin/env bash
# PR-time ratchet
baseline=$(git show origin/main:.baseline)   # the baseline on main right now
current=$(violations | grep -c '^')

if [ "$current" -gt "$baseline" ]; then
  echo "❌ you increased violations: $current > $baseline"; exit 1
fi

The question. Developers complain the ratchet randomly blames them for violations they never wrote. The script reads the baseline from the tip of origin/main. Why does that produce false failures?

base_commit=$(git merge-base origin/main HEAD)
baseline=$(git show "$base_commit":.baseline)   # the floor THIS branch started from
current=$(violations | grep -c '^')
if [ "$current" -gt "$baseline" ]; then
  echo "❌ this branch increased violations vs its merge-base: $current > $baseline"; exit 1
fi

Bug 6 — betterer in write mode¶

# ci.yml
- name: Quality ratchet
  run: npx betterer            # run betterer to enforce our quality budgets

The question. The team adopted betterer to gate @ts-ignore. CI runs npx betterer. The snapshot file .betterer.results keeps changing in CI and the build is always green even as @ts-ignores pile up. What's wrong with the invocation?

- name: Quality ratchet
  run: npx betterer ci          # READ-ONLY: fails on regression, never writes the snapshot

Bug 7 — The swap that a bare count misses¶

# ratchet on a bare count
baseline = 214                       # number of @ts-ignore last time
current = count_ts_ignore("src/")    # → 214

assert current <= baseline, "regression!"   # passes: 214 <= 214 ✓

The question. A PR removed a @ts-ignore from a well-tested file and added one to a critical untested file. The total is still 214, so this passes. Why is "passes" the wrong outcome, and what kind of baseline catches it?

// .betterer.ts — records EACH @ts-ignore by location+context, not just the count.
import { regexp } from '@betterer/regexp';
export default {
  'no new @ts-ignore': () => regexp(/@ts-ignore/).include('./src/**/*.ts'),
};
// betterer ci sees the removed one AND the added one as distinct changes:
// the added one is NOT in the snapshot → regression → fail.

Summary¶

• A broken ratchet's signature is a permanently green build that gates nothing — far more dangerous than no ratchet, because it certifies safety while the codebase rots.
• The recurring bugs: (1) writing the baseline unconditionally so it self-updates and never detects a regression; (2) slack (+1, -ge) that leaks one violation per PR; (3) counting a worthless proxy (LOC) instead of the actual violation; (4) a post-merge job that resets the baseline upward on every merge; (5) comparing against main's tip instead of the merge-base, blaming a branch for others' work; (6) running a tool in write/record mode in CI instead of read-only gate mode; (7) a bare count that's blind to swaps.
• The unifying rules: the baseline only ever moves down; CI is read-only (only one controlled writer tightens); compare against the merge-base; count the real violation, not a proxy; and when swaps matter, track which violations exist, not just how many.
• Each bug stays green, which is exactly why it survives review — a ratchet's correctness is invisible until you deliberately try to make it go red. Test your ratchet by adding a violation on purpose and confirming the build fails.

Related Topics¶

• tasks.md — build correct versions of every gate broken here.
• optimize.md — the performance failure mode (whole-repo recompute).
• professional.md — the full failure-mode catalog these bugs are drawn from.
• junior.md — why the baseline must only move down.
• interview.md — Q&A, including several of these bugs as discussion prompts.
• Architecture Fitness Functions — the sibling topic; a broken fitness function fails the same way.