Guardrails Instead of a Green Checkmark

"We take code quality seriously" is a sentence that carries almost no information — every engineering team says it, and it's unfalsifiable from the outside. What's actually worth explaining to a technical evaluator isn't the sentiment, it's the mechanism: what specifically stops bad code from shipping, and when does it run.

For Piskes, the answer isn't a single CI pipeline with a pass/fail badge. It's a registered, enforced, and steadily growing set of guardrail checks that run locally, before code is even committed — not after a PR is opened and waiting on a pipeline.

What a guardrail actually is here

Each guardrail is a small, specific script that checks one thing: does a new by-id API route include a tenancy check, so one customer's request can't reach another customer's record by ID. Does a new delete route call the audit logger before removing data. Does a Worker import something from a Node-only API that will silently fail under the actual Workers runtime. Does a fetch call carry a timeout, so a hung upstream request can't hang the whole handler. Each of these is a real, specific failure mode this platform has hit before — the checks aren't hypothetical hardening, they're responses to actual bugs, converted into a rule that now runs automatically instead of relying on a reviewer to remember to look for it every time.

Where it runs, and why that placement matters

Two commands cover it: a fast pass that runs on every commit, and a fuller pass — guardrails plus test suites — that runs before every push. Both are wired through git hooks, so they're not something a developer has to remember to run manually; they fire automatically at the point where they can still stop something from landing, not after the fact in a pipeline that only reports a failure once the code is already merged and someone has to go clean it up.

That placement is a deliberate choice, not an artifact of tooling limitations. A check that runs in CI after a merge tells you something went wrong. A check that runs before a commit is even created stops it from going wrong in the first place, in the exact session where the context for fixing it is still in the developer's head.

The set only grows, and that's measured, not asserted

Here's the part that matters most for trusting this as a real practice rather than a marketing description of one: the platform explicitly declines to quote a fixed number of checks anywhere in its own internal documentation, because the number is stale by the time anyone writes it down — it has moved measurably even across single days of active development, as new checks get added faster than anyone can keep a static count current. The only trustworthy count is the one the check runner itself prints when it runs, not a number copied into a document.

And there's a second-order guardrail on the guardrails themselves: a dedicated check fails the build if a new check script exists in the codebase but nothing actually invokes it — closing the specific failure mode where someone writes a rule, believes it's protecting the codebase, and it silently isn't wired into anything that runs. A rule that exists but never executes is worse than no rule at all, because it creates false confidence. This platform has a standing check specifically against that outcome.

Why "show, don't tell" is the right frame here

A technical buyer evaluating a vendor's engineering discipline has learned, reasonably, to discount "we care about quality" as a sentence with no content. What's harder to fake is a described mechanism specific enough to be wrong if it isn't true: checks registered by name, run automatically at commit and push time via git hooks, with a self-check that catches an unregistered rule, and a stated refusal to quote a number precisely because the real number moves too fast to write down accurately. That level of specificity is the actual evidence — not a badge, not a sentence, a described system a skeptical reader could go verify.