The four tools referenced below are open source at github.com/officialwhitebird.
When you run AI coding agents one prompt at a time, the model is the thing you watch. When you run them at volume — many small jobs, handed to agents, coming back as diffs and files and result records — the model stops being the interesting risk. The interesting risk moves to the edges of the run: what went in, what came back, what the agent was allowed to touch, and what got written into public-facing copy on the way out.
That is the same place a physical factory puts its attention. Not on any single machine, but on the boundaries between stations: incoming inspection, work authorization, the contract each station has to meet, and final inspection before anything ships. A run that produces a plausible-looking output but fails one of those boundary checks is not a success. It is a defect that happens to look finished.
This is a description of how I structure that discipline for AI coding runs, and the small set of local, offline command-line checkers I use to make each boundary an explicit, deterministic step instead of a feeling.
A single AI coding run has four practical boundaries. Each one is a place where a run can quietly go wrong, and each one can be checked mechanically — before or after the model does anything.
| Boundary | The question | The check |
|---|---|---|
| Input | Is the work instruction structurally complete? | handoff-lint |
| Execution authorization | Is this command allowed, owner-gated, or rejected? | policy-lint |
| Execution contract | Did the result satisfy what was declared? | contract-lint |
| Output | Does the public copy contain configured claim or internal-name findings? | claim-lint |
None of these tools call a model. None of them send your files to a hosted service. Each one is a small local CLI that reads a file, applies deterministic rules, and returns an exit code and a list of findings. That property — the check itself is boring, offline, and reproducible — is the whole point. A check you can re-run and get the same answer from is a check you can put in front of a human decision. A check that is itself an LLM guess is just another run to audit.
Most bad runs are bad before the agent starts. The work instruction is missing its acceptance criteria, or its scope bounds, or the section that says what the agent is not allowed to do. handoff-lint
reads a work instruction and checks whether it is structurally complete: the metadata, the sections, the bounds an agent needs in order to stay inside the job.
It does not judge whether the instruction is a good idea. It checks whether the instruction is complete enough to hand off. Those are different questions, and keeping them separate is what keeps the check honest.
An agent proposes a command. Some commands are fine to run unattended. Some should never run. Some sit in the middle: they are the ones a human should explicitly approve — anything external, paid, destructive, or public. policy-lint
classifies a proposed command against a declared local policy and returns one of a small set of verdicts: allow, owner-gate, reject, forbidden.
The verdict I care about most is owner-gate. It does not block anything. It makes the "a human decides this one" moment visible and mechanical, instead of leaving it to whoever happens to be reading the log. The authority stays with the person. The tool just refuses to let that decision be silent.
The agent comes back and says it is done. Done against what? Before the run, I declare a contract: the outputs that should exist, the verification that should have happened, the gates that should have been respected. After the run, contract-lint
compares the recorded result against that declared contract and reports where they disagree.
This is the boundary that catches the most expensive failure mode in agent work: the confident, well-written result record for a job that did not actually meet its own terms. A diff can look clean and still miss half the contract. Comparing the two deterministically is how a "looks finished" turns back into a checkable "finished, and here is the record."
The last boundary is the one that decides how the work is seen from outside. A README, a release note, a post. Two things routinely go wrong here: claims that are not backed by anything in the run's own evidence, and internal names or private paths that were never supposed to be public. claim-lint
scans public-facing text against a configured rule set and reports both.
I run it on my own copy. The README of the pack that ties these four tools together was scanned this way before it was published — including a check that it contained no internal names or private paths. The check is not a courtesy. It is the difference between publishing a document and publishing whatever happened to be in the buffer.
The obvious alternative to all of this is to ask a second LLM to review the first one's work. I do use models for the work itself. I do not use them for the boundary checks, for three reasons.
The goal is not to remove the human. It is the opposite. Each check exists to put a clean, mechanical finding in front of a human at exactly the moment a human should be deciding — and to make sure that moment is not skipped because everything looked done.
Being precise about the edges of a claim is part of the discipline, so:
Each tool checks one boundary, deterministically, and hands the decision back. That narrow scope is intentional. A checker that pretended to do more would be exactly the kind of confident, unverified output the checkers exist to catch.
None of these four tools is impressive on its own. What they add up to is a way of running distributed, semi-autonomous work — jobs handed to agents — where the thing holding the system together is not a central controller watching every step, but a set of boundary checks and an evidence trail that any station's output has to pass through before it counts.
That structure is not specific to software. The same idea — distributed units doing real work, held together by explicit boundary checks and a checkable record rather than by central supervision — is how coordinated production works in general. I am building it where I can build it end to end today, which is in software. The tools above are the first, smallest, fully-working version of it.
These are local, offline command-line checkers published at github.com/officialwhitebird. Each checks one boundary and keeps the final decision with the human operator.