The constraints are what make this work, because an agent with a narrow job and a short list of things it isn't allowed to do is worth more than a clever one told to use its judgment.
The rule the crew is built around
No agent is allowed to check its own work.
The first four
1. architect
It reads the actual codebase first and then writes the plan: ordered steps, the exact files to touch, and the risks a reviewer should check later.
It's not allowed to write any code.
2. developer
It implements the plan end to end and matches the conventions already in the repo. Then it reports what changed and the exact command to test it.
3. review: simplify and end-to-end
It runs the test suite and then hunts for redundancy and dead complexity.
It's told to leave the bug hunting to number 4.
4. review: adversarial
Its job is to break the change instead of praising it, so it goes after empty input, race conditions, permission gaps, off-by-one errors and injection.
It runs at the same time as 3 and never sees its findings.
This is the one that saves me.
The other four
5. review: screenshot
It launches the app, walks every affected screen and flags layout breakage.
It only spawns when the build touched the frontend.
6. arbiter
It reads every finding, merges the ones pointing at the same root cause and drops the bikeshedding. Then it turns whatever survives into surgical instructions.
7. fixer
It applies only what the arbiter ordered, and it works through them in priority order.
It's not allowed to refactor past the instruction or add new behavior.
8. verifier
It re-runs the suite to confirm the fixes hold and lists anything that's still broken.
It had no hand in the fixing, and that's the point.
Why it's built this way
The one that wrote the code has already made up its mind, and everything after that is a defense, so nothing here gets to review itself.
If the four words in here are new to you, start with How AI Agents Actually Work.
This one's also up on Substack, if you'd rather read it there.