$ essay
The Fleet That Builds Quill
Quill moves fast, and the obvious question is how. The honest answer is printed in the repository itself: “Quill is developed by a fleet of autonomous agents under human direction.” It is not a secret and it is not a gimmick. It is the method, and the method is mostly rules.
The Split
The split is the same one I described in Running a Company of Agents. Creative direction is human: what to build, what matters, what the quality bar is, what ships. That layer is not delegated. The operational layer, how to build it, how to test it, how to deploy it, how to keep it running, belongs to the agents end to end. I define the scope; they execute. A bench of fast juniors is a superpower when someone owns the scope and a liability when nobody does.
Work arrives as events rather than chores somebody has to remember. A failing CI run, the automated checks that run on every change, becomes a card. So does a new issue or a security alert. A dispatcher routes each card to the agent that owns that domain, and each domain has exactly one owner, so two agents never fight over the same failure. It is the same reason a kitchen puts one cook on the grill.
Five Rules
The workflow document lists five rules, and they are enforced by review, not by hope:
- Everything TechdeclarativeDescribing the result you want and letting the machine build it, instead of listing every step. Read the file and you know what the machine is.. Configuration lives in git, and the running cluster is a rendering of the repository. A change that only exists on a live server is a bug.
- Root cause, not symptom. A red pipeline is diagnosed before it is patched, and a workaround that switches a feature off is rejected.
- Every error becomes a test. A failure that reaches production or CI gets a regression test, a test that fails if the same bug ever comes back, in the same change that fixes it.
- No stubs. A deliverable is complete and executed, or it is not done. Placeholders and “implement later” do not pass.
- Verify, then claim. A green check is evidence; a summary is not.
The fifth rule does the most work, because the most dangerous thing an agent produces is not bad code. It is a confident report about code it never checked.
What Verify, Then Claim Looks Like
Here is a small, real example, because small and real beats grand and imagined. For a while Quill’s own documents disagreed with the running server about how many tools it had. The paperwork said 182; the live server reported 184. The server was right and the paperwork was stale. The module count drifted the other way, high by one, because a counting script mistook a type definition for a real entry. Nobody lied. Numbers just rot when they are typed by hand into a dozen files.
The fix was not a find-and-replace. It was a checker: a script that now fails the build whenever any published count disagrees with the generated metrics file or the live registry. The error became a test, so the same drift cannot quietly come back. That is the whole philosophy in one paragraph. When a claim can be generated, generate it. When it cannot, check it. Never just repeat it.
The same rule covers secrets. A gate in CI scans the full git history, the whole saved record of every change, and fails on any credential-shaped string it has not already reviewed, so a careless commit becomes a red build instead of a headline. And code from outside contributors never runs on my own machines; it goes to a throwaway hosted runner instead.
What Agents Are Bad At
Agents are tireless, quick and literal. Left alone, they are also delighted to declare victory. They will write “done” over a test that never ran, and they will happily paste last month’s number into this month’s README. None of that is malice. It is the shape of the tool, and the answer to the shape of a tool is a jig, not a lecture. The five rules are the jig. The human part is deciding what is worth building, saying no to scope creep, and reading the TechdiffThe line-by-line record of what changed between two versions of a file. Read it and you know exactly what someone touched. that matter.
Build Canada1 built Builder MP, a trained model that reviews bills and judges whether they are pro-growth. I like that kind of project for the same reason I like my own fleet: it puts a model to work on a real task, in public, where its output can be checked against the bill itself. A model that shows its work is a tool. A model that asks to be trusted is a liability with good grammar.
No Privileged Path
The last rule matters as much as the five. Agents go through the same CI as a human contributor. There is no side door, no special branch where the robots get to skip the tests. If the fleet disappeared tomorrow, the repository would still install, build and test with the same three commands, and a person could pick up any card on the board. That is the test of whether you built a company or a dependency.
Related: Running a Company of Agents · Quill Reads Canada · MapleSpike Costs Nothing to Leave · Root Access and the API of the Sovereign Mind · The Sysadmin Protocol · The Dojo Kun Is a Permissions Model
Further reading: Build Canada’s projects1, including Builder MP · Quill2, live.
Credit: the sentence on how Quill is developed is quoted from Quill’s own README. Builder MP is PeopleBuild CanadaA group of Canadian builders and founders pushing for growth: more homes, more projects, less red tape. Linked and credited here, never rewritten.Read the essay’s project, described from their projects page1.
