Your agent can write code fast. That is not the risky part. It compiled and it works are two different claims, and a pressured agent hands you the first while implying the second. The gate fixes that: the same checks, same order, every merge.
Five checks, always in this order. Install clean. Build for real. Typecheck on its own. Run the whole test suite. Lint last. No agent merges without clearing all five, and no exceptions for a change that looks small enough to skip a step.
Start with npm ci, not npm install. It refuses to touch package dot json and fails loudly if the lockfile drifted. Then npm run build, the same pipeline your deploy uses, migrations included. A build that never ran end to end was hoped, not verified.
Typecheck on its own, because a bundler can ship past a real type error. Run every test in the suite, not just the ones near your change. Lint last, and ask your agent which findings are new versus already there before it fixes anything.
npm run typecheck catches what the bundler let through. npx vitest run executes the whole suite once and exits, unlike its default watch mode. npx eslint runs last. Three commands, three separate signals, none of them optional on a real merge.
Before asking for lint fixes, ask which findings are new, on lines this change touched, versus already present before your change. Fix the new ones. List the rest without touching them. That one question stops both ignoring lint and rewriting debt nobody asked for.
Put the rule where your agent reads it, even when you are not in the room. Never say a task is done until the gate passes clean. A gate an agent can talk its way around with probably fine is not a gate.
You are done when all five steps pass on a completely clean install, and one command runs the whole sequence for you. You know the difference between a build that succeeded and types that are actually sound, and that rule now lives in writing.
That is session one. A boring, repeatable gate your agent cannot talk its way around. Next, you take a real browser to your built app and watch it work, not just compile, with console errors, failed requests, and screenshots as evidence.
Your agent can write code faster than any human on your team ever could. That is not the risky part. The risky part is that "it compiled" and "it works" are two different claims, and an agent under time pressure will happily hand you the first one and imply the second. The gate is the fix: a fixed, boring sequence of checks that runs the same way every single time, before anything reaches a real user. No agent, however good, merges without clearing it. No exceptions for "it's a small change."
Session 1 of Let the Agent Test It. Everything else in this course, the browser pass, the adversarial review, the mobile sweep, assumes the gate already exists and already runs clean. Build it today; it takes twenty five minutes once and then never again.
package.json (or your language's equivalent build tool)The first command in the gate is not the build. It is throwing away whatever is cached and installing exactly what the lockfile says, the same way a fresh clone would:
npm ci
npm ci (not npm install) refuses to touch package.json and fails loudly if the lockfile is out of sync, which is exactly the behavior you want before you trust anything that follows. A gate that starts from a warm, possibly-drifted node_modules folder is not testing what your teammates or your CI runner will actually get.
npm run build
If your build step also runs a database migration or a codegen step, that is correct: the gate should exercise the same pipeline production deploys use, not a hand-picked subset. A build that only "looks" green in your editor and has never run end to end is not verified, it is hoped.
npm run typecheck
Bundlers are often configured to tolerate type errors and ship anyway (transpile-only mode is common precisely because it is faster). That is a reasonable tradeoff for the build step and a dangerous one for you, because it means "the build passed" and "the types are sound" can quietly stop meaning the same thing. Run the type checker (tsc --noEmit for TypeScript, or your language's equivalent) as its own step so a real type error fails the gate even when the bundler would have shrugged it off.
npx vitest run
Vitest is a fast, Vite-native test runner; vitest run executes the suite once and exits, which is what a gate needs (its default watch mode never exits, and a gate that never exits never reports back). The same idea applies whatever runner your project uses (Jest, pytest, go test): run the whole suite, not "the tests near the file I changed." An agent that only reruns nearby tests will miss the exact failure mode that matters most, a change in one file breaking an assumption in a completely different one.
npx eslint
Lint findings split into two buckets: things your change introduced, and things that were already there. Ask your agent to tell you which is which before asking for fixes:
"Run the linter. Tell me which findings are new, on lines this change touched, and which were already present on the base branch before my change. Fix the new ones. List the pre-existing ones without touching them unless I ask."
That question alone saves you from the two failure modes of lint in a gate: ignoring it because "there's always noise," and blocking every merge on cleaning up debt nobody asked you to fix today.
Caution. A gate an agent can talk its way around is not a gate. If your agent ever says some version of "the tests fail but it's probably fine" or "I'll skip the typecheck, it's just a warning," that is the exact sentence to stop and push back on. Say: "Do not merge, deploy, or tell me this is done until all five steps pass with no errors." Put that sentence in your project's instructions file so it holds even when you are not in the room to say it.
npm ci, npm run build, npm run typecheck, npx vitest run, npx eslint.All five steps pass, in order, on a completely clean install, and you have one command that runs the whole sequence. You know the difference between "the build succeeded" and "the types are sound," and you have the one sentence that keeps an agent from talking its way past a red gate.
Sources: https://vitest.dev/guide/
Template included: Members get the pre-merge gate checklist as a copy-paste
package.jsonscript block, the "which findings are new" lint prompt, and the one-line project rule that keeps an agent from merging red. Find it in your member dashboard under Templates.
Short on time? Agentic Quarks will implement this end to end, wired into your stack, and hand you the keys.
The gate, a real browser, an adversarial review, and the mobile pass before you ship
4 sessions, 120 minutes, 1 free.
One payment, no subscription, and a 14-day money back you trigger yourself from your account page. This course on its own is $99.