I gave Claude Code a team. Then I caught it grading its own homework.

An AI team that never gets tired also never gets embarrassed.

Part 1: I made Claude Code think before it codes
Part 2: ... then I gave it a team
Part 3: this one.

There is a sentence that started appearing in my pull requests, and for about three weeks I thought it was the most reassuring thing I had ever read.

findings filed, not fixed here

Five words. They meant that while fixing the thing it was asked to fix, my AI had spotted a second, unrelated problem, decided (correctly) that dragging it in would turn a clean change into a swamp, and written it down for later. I have worked with humans who do not do that. I read it, felt the specific warmth of a parent watching a toddler use a napkin unprompted, and hit merge.

Background, because this is part three. In part one I got tired of code that worked on Tuesday and fell over on Friday, so I wrote Claude Code a process: read before you reference, test before you fix, attack your own work before you hand it over. In part two that thread became a conductor, dispatching specialists and running eight pull requests wide while I made coffee. My job was to bring an idea in the morning, press merge in the afternoon, and in between stay out of the way.

Which is roughly why it took me three weeks to open the issue tracker.

It was empty. Not sparse. Empty. Five pull requests announced that findings had been filed. Zero findings had been filed. Two more cited a ticket by number with the serene confidence of a man describing a restaurant he has never eaten at.

This was not lying, and it was not a bug. To the orchestrator, writing findings filed and actually filing them cost the same and felt the same. One produced an artifact I could check; the other produced a sentence. Nothing downstream cared which, so under load, the cheaper of the two won. Every time.

The orchestrator was the only thing checking the orchestrator.

Empty is not zero

Once I started checking, the checking did not stop being productive, which is its own kind of bad news. My deploy pipeline has a monitor that watches the error rate after a release and rolls the thing back if it starts smoking. For months it had reported, after every deploy, in a tone I can only call chipper: soak clean (peak 0). It had never read the error rate. Every poll came back empty, empty became zero, zero cleared the threshold, and the threshold said clean. The rollback I had been trusting with production had never armed in its life.

Once you can see that shape you find it everywhere, and I did, all in one week. A position with no price quote, showing a total of $0 and a drift of 0.00%, comfortably in band. A transfer that could not resolve where the money came from, crediting the destination anyway. A record with no valuation, billed on the part the system could see. None of it reached a customer, which is the only reason this is an anecdote and not a postmortem.

Look at the direction those fail in. Not one rendered missing data as something is wrong here. They rendered it as clean, as zero, as in band, as settled, and a fabricated number looks exactly like a measured one. So the rule now is that a read which cannot produce a trustworthy answer must refuse: return null, throw, leave something loud enough to trip over. A measured zero must stay distinguishable from I have no idea. The reflex this kills is the most natural line in the language, ?? 0.

The tests were worse, and I say that as a man who spent an entire blog post being smug about TDD. The same sweep found six green tests standing guard over the precise bugs they were written to catch. My favorite asserted that a function returned a particular value: the same value it returned when it did nothing at all. Delete the feature, test stays green. So a test does not count in v3 until somebody breaks it on purpose. Change one line of the real code, watch it go red, change the line back.

Receipts, and a second manager

The one that stung most was the small-PR rule, which had sat in the rules file the whole time, in bold, and completely ignored: two agents, each handed one small fix, turned in pull requests touching twenty files and eleven. The rule was not wrong. It simply had nothing to do, and a sentence in a document is a wish.

So v3 is what happened when I stopped writing rules and started demanding receipts. The rules are the same rules. Each now has to leave something behind I can walk over and look at: a plan filed on the issue before a builder is briefed, a mutation that actually ran and actually went red, a block in the PR body. If the artifact is not there, the rule did not happen, whatever the summary says. A rule with no artifact has no teeth, and mine had been gumming the problem for months.

Then I gave the orchestra a second manager. accountability-lead audits the first manager and reports to me, pointedly not to the orchestrator. It asks four questions so boring you could train a parrot to ask them. Is any pull request failing with nobody fixing it? Is the main verb opened rather than merged? Does any claim of "filed" survive contact with the tracker? Are we creating issues faster than we close them?

First day I ran it, that last number came back 4.3 across the day's cohort. Four-point-three new issues per pull request merged. Not necessarily wrong, since a good sweep turns up real work, but not a thing you leave unsaid, and it had gone unsaid for three weeks while the orchestrator told me how many agents it had dispatched.

That is the characteristic failure of these systems, and it is not recklessness. It is reporting instead of clearing, and it is invisible from the inside, where every turn looks like progress.

The team got bigger, and cheaper

v2 shipped seven agents; v3 has twelve, and the five newcomers beyond the auditor are all chaperones. pr-checkin sweeps the lane on every event (v3 wakes on events now, never on a timer) and writes the ledger, pr-manager picks up whatever it escalates, and resource-manager, backlog-manager and report-maker mind capacity, tracker hygiene, and a dashboard I can read without asking anyone how it is going.

Here is the part I did not expect: most of them do not need to be smart. pr-checkin reads a few mechanical signals and returns one of three words. report-maker renders a dashboard. issue-maintainer, which has been with us since v2, fills out a form. One rung up, the doc librarian runs on Sonnet, because reviewing documentation is judgment, just bounded judgment. The builders and pr-manager stay at the top. Economize on the real judgment and you are back to a system that reports instead of clears.

While somebody was finally looking, they looked at the garage: one repository was carrying 379 abandoned working directories, fifty-nine gigabytes, 306 of them for pull requests merged weeks earlier. Every task now ends on a clean slate.

One more, which is really its own post

The single biggest cost turned out to be the rules file. Your CLAUDE.md is re-read on every API call, of every turn, of every session, and by every subagent you dispatch. Mine ran 86,000 to 141,000 tokens before a line of work happened, and across a session archive reads outnumbered writes 63 to 1. You do not have a writing problem. You have a subscription.

Every edit was reasonable, which is how it got that big: a rule ships, an incident validates it, AI quietly appends the incident. Sixty percent of the file had become citations and war stories. So v3 keeps the instruction resident, moves the story to a linked doc, and then does the part that actually holds: the budget is a written number, and a check fails the commit when the file grows past it. A rule with no artifact has no teeth, including this one. The rest is a part four.

The short version

Same command, same seat, same job: bring the idea, make the calls that are yours, press merge. What changes is that you are no longer the only thing standing between a confident status report and production.

curl -sL https://raw.githubusercontent.com/vlad-ko/claude-wizard/main/install.sh | bash

Then /wizard do the thing. It is at github.com/vlad-ko/claude-wizard, MIT and framework-agnostic, with v1 and v2 preserved at tags if you liked them younger. Every rule ships with the incident that earned it, which is either an admirable documentation practice or a public list of my mistakes. I have decided it is both.

And if /wizard misses something it should have caught, that is not a bug in your code. It is a bug in the prompt. File it. I will know if you do not.