Common questions

No. People decide, agents build, checks guard main. A person approves the spec and the plan, decides which tasks agents may build, and reviews and merges every change.

The work changes. Engineers type less code and spend more time deciding what to build, describing it clearly, judging the result and the architecture, and improving the rules.

Plan for more review, not less. More code from agents means more to read. If you add agents without adding review time, changes queue up or get merged unread.

No. The gate, the guard and the checkers are the same whatever AI tool you use, and every tool reads the same AGENTS.md. The real gate runs in CI on every pull request, whichever tool wrote the change.

What differs is how much a tool can run by itself. Claude Code with a frontier model has the most wired in: the guard, a lint warning after each edit, the stop loop and the checkers. Some tools offer only the guard; then you run the full check yourself before you stop.

You can also mix: a frontier model plans and reviews, and an open-weight model on your own machines does the long building work. State your limits first, such as your budget and whether code may leave your machines, then run the same test on each setup and decide from your own results.

Not proven. The practices taught here were built and tried on a small codebase. They have not been shown to hold on a large one.

A large codebase needs more. No step may assume that the whole code fits into a model's working memory, or that every test can run on every change. That means a short map and small context files per folder, and a gate that checks the parts a change touches, with the complete run as a stage of its own.

Whatever you build, a part that was not checked must say “not run”, never “pass”.

It depends on your team, your models and how you work, so measure it rather than trust a headline figure. Published figures per developer differ several times over, mostly because each one averages over a different group of people.

The price per token keeps falling, yet bills do not. What drives cost is how many tokens agents use: several agents working at once, long contexts, and cached context that gets missed. Keeping the strongest model for the work that needs it, and a cheaper one for the rest, is one of the largest levers.

Track cost per finished task or pull request, not cost per token. Log the tokens each run uses and turn them into a cost with a dated price list. Label it an estimate: it does not know your discounts or a monthly plan.

Count people's time too. More agent output means more review.

No. Only fixed checks block a merge: tests, lint, the type check, the secret scan and the package audit. An AI checker's verdict is advice for the author and the reviewer.

A task is closed when the gate passes and a person has read the checker report. A failing verdict needs a fix, or an override that a person records in the pull request.

Checkers raise false alarms too. Read a finding before you act on it.

It can skip the ones on its own machine. Git hooks, the guard and the stop loop give fast feedback, but a person or an agent can switch them off, and a guard that reads command text can't catch everything.

That is why the real gate runs in CI on every pull request, with the check scripts and their settings taken from main. A pull request that edits the check to always pass is still judged by the real one.

A rule written only in an instruction file is a request. And a gate only blocks if the main branch is protected and the check is required.

You can set it up that way: an AI coding tool with an open-weight model on a server you run. The gate and the guard work the same.

Check it before you rely on it. Look at the network traffic yourself: that is the proof that no code leaves.

Expect weaker checkers. The spec and security checkers are meant to run on the strongest frontier model, and a local setup doesn't meet that rule. Treat their reports as a first reading, and have a person or a second model family read the change.

With one gate. Put tests, lint, type check, a secret scan and a package audit behind one command. Run it in CI on every pull request, protect the main branch, and make the check required.

Then score your codebase for readiness and fix the cheapest fail first. Keep a person on every merge, and give agents more room only when your own numbers show it is safe.