Dev Quality Gates: Turning CI Into a Feedback Loop Your Agent Can Read

0:00AI coding agents generate pull requests faster than humans can review them, and the CI pipelines we built were designed for human pacing. 0:24Stack five single-purpose linters, a formatter and two scanners, and the pipeline becomes the bottleneck it was supposed to remove: minutes of execution, overlapping rule sets, and 0:41a wall of warnings that trains everyone to ignore the output — or, worse, to disable the security checks so the build goes green.

The subject of this video is mokevnin/dev-quality-gates: not a tool, a curation — an opinionated list of one recommended tool per job, chosen so each one can fail a build deterministically and hand the failure back in a form an agent can parse. The video walks it against a sample polyglot monorepo, the "OmniStack API".

The velocity problem

0:11The argument's shape is worth stating plainly, because it inverts the usual "add more checks" advice. CI was built for a world where a human wrote the diff and a human read the report. 0:17When the diff is machine-written at machine speed, advisory tooling is worse than nothing: it produces volume without enforcement, and volume is exactly the resource that runs out first — human attention.

0:44The failure the video describes is not "the linter missed a bug". It's that a build throwing hundreds of stylistic warnings next to one critical vulnerability gets ignored wholesale, and the team's response is to route around it — disable checks, add ignores, force the merge. A gate that can be argued with is not a gate.

What a quality gate is, and the five rules

1:49The definition offered: a predefined, configurable checkpoint in the lifecycle that blocks a change from merging or deploying unless it meets measurable criteria. 2:02Around that the repo organises five principles, and all five are in the README as written — this part of the video is accurate to the source:

2:16The "coverage over quantity" rule sits alongside them: a tool that replaces three narrow checks beats three narrow tools. 1:44And the video's own summary line is the thesis worth keeping: if you want to secure a supply chain at the speed of AI generation, abandon passive advice and build impassable deterministic constraints.

Agent-friendly output is the load-bearing idea

2:26Of the five principles, the one that is genuinely new relative to a 2019 CI article is the fourth. 2:43Human engineers read text logs; agents parse structured data. A diagnostic in JSON or SARIF, carrying a file, a line and a rule id, is a specification for the fix. Prose is not.

2:53That reframes what CI is for: not a dashboard for humans to consult, but a policy control interface that a machine calls and reacts to. The gate stops being a report and becomes a function whose return value the agent branches on.

TypeScript: Oxlint and oxfmt, and the exit-code trap

3:12For the TypeScript layer, the ESLint + Prettier pair collapses into Oxlint and oxfmt — the Rust-native Oxc toolchain, 23,358★, MIT, an ESLint-compatible linter plus a Prettier-compatible formatter in one binary. 3:28The video repeats the project's own performance claim (syntax analysis "often measured at 50 times faster" than the JavaScript equivalents) — that is Oxc's benchmark of itself, not an independent measurement.

3:38Then comes the most practical minute in the video: by default Oxlint exits 0 on warnings, so a gate built naively around it lets non-compliant code straight through. 3:50The fix is a flag. I confirmed it in Oxc's CLI docs: --deny-warnings "ensure warnings produce a non-zero exit code", with --max-warnings=INT if you'd rather set a budget than a hard stop.

One detail the video omits that matters for the machine-readability principle: Oxlint's --format accepts json, sarif, github, gitlab, junit and unix — and also agent, a format aimed squarely at the audience this whole framework is written for.

Knip and the static-graph blind spot

3:54Next job: dependency bloat. Manifest scanners read package.json and stop there; Knip (12,621★, ISC) builds a full import graph across every workspace to find unused files, exports and dependencies.

4:29But a static graph only sees what it can resolve. A module reached through a string-built dynamic import(), an HTML template, or a string reference is invisible — 4:41so Knip reports it as unused and fails your build on code that is very much alive. 4:50The remedy is explicit configuration: declare those dynamic entry points so the analyser knows to skip them.

5:00That yields the honest generalisation at the centre of the video: native static analysis gives speed and precision but no runtime context, and every blind spot must be paid for with an explicit configuration boundary — otherwise the gate generates the exact developer friction it was meant to remove.

Python: Ruff, the type checker, and deptry

5:11The Python layer collapses Flake8, Black and isort into Ruff (50,715★, MIT) — linter and formatter, one Rust binary, one config. 5:36And then the boundary that trips people: Ruff "explicitly does not perform semantic static type checking", so a gate that stops at Ruff has no type safety at all.

5:44Here the video says a dedicated checker "such as Pyright or MyPy" is mandatory. The repository's own recommendation is narrower and more current: it lists ty (20,035★), Astral's Rust-native type checker — not MyPy. Note that the repo is visibly still deciding: its curated README recommends ty while its own research note argues for Pyrefly and calls ty beta (0.0.91) and pyright "the more battle-tested alternative". A curated list that shows its own disagreement is more trustworthy than one that doesn't, but it also means the type-checker slot is not settled.

5:54Dependency hygiene goes to deptry (1,501★, MIT; the video's "dep-tree" is a mis-transcription of the name, and the project has migrated from fpgmaas/deptry to osprey-oss/deptry). 6:04The friction: libraries imported purely inside an if TYPE_CHECKING: block exist only for type hints, so deptry flags them as development dependencies used in production code. 6:21The fix is a per-rule exclusion in the project manifest — again, an explicit configuration boundary.

6:32Which produces the video's most honest sentence: a 0% false-positive rate is impossible out of the box. Effective gates are built by teams who pre-emptively map their analysers' blind spots and configure around them — not by teams who install more analysers.

The repository perimeter: Markdown and GitHub Actions

6:46A gate should cover the non-code parts of a repo too. 7:01Two entries: rumdl (1,630★, Rust, MIT — a Markdown linter/formatter that reads markdownlint configuration, exits 1 on violations, and formats with rumdl fmt) and jactionlint (317★, MIT, Go, by jdx — lints workflows, composite actions and dependabot.yml, with --fix and --online to pin tags to commit SHAs). The video's audio mangles both names ("rumdel MD", "jacksonlint"); the repos are the ones linked above.

7:14The principle this section demonstrates is the fifth one: honesty about gaps. Where an ecosystem has no mature native tool, the list keeps its established legacy tool rather than forcing a broken replacement — Ruby, Java, .NET and Swift keep their standard toolchains, and the repo says so.

The remediation loop: what the gate is really for

7:30This is the payoff, and the reason the content belongs on an agents site rather than a linter blog. A passive toolchain leaves an agent in "limbo": it has to audit hallucinated dependencies, half-formatted imports and invented APIs by reading prose warnings. 7:48A gate that blocks the merge and returns a structured JSON payload turns that into a loop: non-zero exit → parse → locate file, line, rule → rewrite → push → re-run.

8:02The agent never needs to ask a human what "warning: expected indentation" means; the deterministic exit code plus the machine-readable diagnostic is the instruction. 8:13Which redefines CI from "a test suite" into a self-correction engine — and quietly reassigns the human: review stops being about formatting and becomes about whether the thing should exist at all.

8:32The video's impact claims here — review time drops, defect density plummets, compute costs fall — are stated without a number, a source or a measurement. Treat them as the framework's premise rather than as findings. 8:53What is true is the cost side of the same sentence: these gates are rigid and tunable, and the tuning is ongoing. 9:03A stale config is a gate that either blocks legitimate work or waves through what it was built to catch.

What the video leaves out — and it's the best part

The video covers four ecosystems' worth of a list that contains 69 recommended entries, and skips the parts most useful to anyone actually adopting it:

• It's built to be applied by an agent. The README's own instruction is a prompt: "Apply https://github.com/mokevnin/dev-quality-gates to this repository. Read and follow docs/adopt.md. Show me the plan before you change anything." The agent inspects the project, picks only the entries that fit, wires hooks and CI, and proves each check can fail — that last step is the one most "add linting" tasks skip.
• It lints your agent configuration. One entry, agnix, checks CLAUDE.md, AGENTS.md, SKILL.md, hooks and MCP configs for Claude Code, Codex, Cursor, Copilot, OpenCode and Kiro, with --fix and --strict. If your agents are part of the pipeline, their instructions are part of the pipeline's input.
• Cross-cutting categories the video never reaches: secrets (Betterleaks, Gitleaks-compatible rules, optional live credential validation), vulnerabilities (OSV-Scanner with call analysis), Dockerfiles (Hadolint), Terraform (TFLint), Kubernetes (Kubeconform), SQL migrations (squawk), policies in Rego (Conftest).
• The data is machine-readable too. The README is generated from tools.json, which records each tool's review date, sources and limitations — so an agent can read the list as data instead of scraping prose.

Use it or skip it

Use it as a map, exactly as the video suggests: one tool per job, chosen because it can fail a build and speak JSON, with explicit configuration for the blind spots you actually hit. The five principles are sound and apply whether or not you adopt a single entry from the list.

Don't treat it as an installation. The README says it outright: this is not a universal stack, do not install everything here. A new repo is 12 days old, the type-checker recommendation is visibly in flux, and every entry carries a "limits" note precisely because the authors know a gate you didn't configure is a gate that fires on the wrong thing.

And one thing worth copying whatever your stack: a gate is only real if you have watched it fail. That is the step the repo's adoption prompt forces and most CI migrations skip — and it is the difference between a policy and a hope.

📚 Sources & further reading

⏱ Timestamp index