What they did
Shah wanted to see whether a small team of agents could turn a vague idea into email and password sign-up a reviewer would accept. He defined five Claude agents, each with its own instructions and a list of things it may not touch: a product manager that owns the sprint plan, a business analyst that owns requirements, a designer that owns the screens, a developer that owns the code and tests, and a QA agent that alone can mark a task done. The agents never spoke to each other directly. Every question, decision and bug report went into files in a docs folder. Shah approved the requirements, then the designs, then reviewed the final pull request, and let the agents run on their own between those three gates. The target was a Flutter app on Supabase auth with a layered architecture whose boundaries are checked by tests.
How it went
The analyst wrote 33 numbered acceptance criteria, seven user stories and a table mapping Supabase error codes to messages, and raised six open questions, two of them security choices Shah says he would have found late. The designer audited his colours against contrast rules and changed the failing ones. QA rejected two tasks on the first pass: a committed env example with real values, and an offline network error misread as an expired email link. The developer fixed both. The result had 272 passing tests and a clean analyzer run. QA could not verify email delivery, deep links on a device or small screens, so those went to a manual checklist.
Worth knowing
The post says only "Claude agents" and does not name the harness. The agents keep no memory between sessions, so output quality depends on how good the written docs are. Scope calls stayed with Shah: email codes needed a paid Supabase plan, so he switched the design to confirmation links. All agent definitions and the docs they wrote are in the public repo.