The first commit on a new project usually looks like a work in progress. Some types are missing. ESLint has a few warnings. Coverage is aspirational. That's normal — first commits are rough drafts that get cleaned up over time.

Not on this project. The first commit on a client engagement last quarter had zero lint errors, zero TypeScript type errors, and 92% test coverage. The developer had been working for 6 hours. This post explains the guardrail architecture that made that possible — and why it matters more than the headline numbers suggest.

The Guardrail Stack: Four Layers

The AI Code Factory guardrail architecture operates at four points in the development cycle. Each layer catches a different class of issue, and together they create a quality floor that holds regardless of who wrote the code — agent or developer.

The Pre-Commit Hook: The First Gate

The pre-commit hook runs ESLint with auto-fix and TypeScript's type checker on every commit attempt. If ESLint can fix an issue automatically, it does. If it can't, or if tsc finds a type error, the commit is blocked. The developer sees the error in the terminal and fixes it before the commit proceeds.

This sounds simple. It is simple. But most teams don't run it strictly because of the friction it introduces during early development — when code is intentionally rough. The AI Code Factory approach is to enforce it from the first commit, because the SKILL.md-driven generation produces code that passes these checks without effort. The guardrail enforces what the agent already did correctly. The cost is near zero; the guarantee is absolute.

.husky/pre-commit

#!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh"

ESLint with auto-fix on staged files

npx lint-staged

TypeScript type check — full project

npx tsc --noEmit

Exit 0 only if both pass

The TypeScript check deserves emphasis. Running tsc as a blocking pre-commit check is stricter than most teams operate. Many run it in CI but not locally, which means type errors can exist in the working tree for hours before anyone notices. Running it locally means the developer finds out immediately, while the context is fresh. Fix time drops from "interrupt during PR review" to "30 seconds at the terminal."

The Coverage Gate: Why 80% Is the Floor, Not the Target

The on-push hook runs the full Vitest suite and blocks if coverage drops below 80%. On this project, the first commit hit 92% because the testing.skill.md drove the agent to generate a test file alongside every route handler, with coverage built in by default.

80% is the floor because below that, gaps in coverage are large enough to hide production-breaking bugs. Above 80%, additional coverage provides diminishing returns relative to the cost of writing and maintaining tests. The target isn't 100% — it's "every meaningful path is tested, and every path that could fail in production is definitely tested." 92% on a well-structured codebase typically meets that standard.

"The 92% on the first commit wasn't because the developer was unusually diligent. It was because the testing skill file generates a test file as part of every code generation step. Quality became the default, not the exception." — Tom Bergström, COO & Co-Founder, Indpro AB

Advisory vs. Blocking: The Rollout Sequence That Works

The PR review agent is the only guardrail that starts in advisory mode. The reason: the first-party guardrails (ESLint, tsc, coverage) have near-zero false positive rates on well-configured codebases. The PR review agent has a calibration period — typically 2–3 weeks — before its false positive rate is low enough to justify blocking.

The sequence is: deploy in advisory mode, review every flag for 3 weeks, add exceptions for intentional deviations from the skill file patterns, then flip to blocking for critical and high severity findings. This produces a system the team trusts, which is more important than a system that's technically correct but creates daily frustration.

Frequently Asked Questions

Q: How do you enforce these guardrails without creating developer frustration?

Two things: the agent generates code that passes the checks, so developers rarely see guardrail blocks in normal workflow. And when blocks do happen, the error output is specific and actionable — not generic CI failure messages. The key is making the guardrail a fast feedback loop, not a slow one. Local hooks that block in 3 seconds are less frustrating than CI blocks that surface 20 minutes after the push.

Q: What TypeScript configuration do you recommend for maximum type safety?

We use strict mode enabled, with noUncheckedIndexedAccess, exactOptionalPropertyTypes, and noImplicitReturns. This is stricter than many teams start with, but the skill file generates code that satisfies these constraints from the beginning. The strictness catches an entire class of runtime bugs at compile time — particularly around nullable values and index access.

Q: How long does it take to set up the full guardrail stack?

For a new project: 2–4 hours including Husky setup, ESLint config, TypeScript strict mode, Vitest coverage config, and the GitHub Actions workflows for on-push and post-build hooks. For an existing codebase: 1–2 days, because you'll likely need to fix existing lint/type errors before the pre-commit hook can run cleanly. We cover the existing codebase migration approach in our AI Code Factory guide.