What they did
The author, writing as bitpage, owns a book catalog product that a coding agent builds end to end in Python and PostgreSQL. The owner picks what gets built and the product trade-offs; the agent plans each step, makes the technical calls and only asks about product questions. After the catalog import stage was reported done and verified, the owner asked whether an independent agent had checked the plan. None had. A reviewer agent with an empty context was then given only the artifact. It parsed the whole partner feed, about 950,000 records in 2.7 GB of XML, and replayed the import plan without touching the database. The owner then wrote a fixed stage order into a decision record the agent reads every time: plan, independent plan review, code, exactly one independent code review, fixes, checks against real queries, and only then the irreversible step such as a full import.
How it went
On the import stage the reviewer found 2 serious, 12 medium and 4 minor defects. The worst grouped books into a series by title alone, so unrelated authors sharing a title were merged; 2,155 of 2,163 two-author series had authors who never wrote together. After the fix the full import loaded 562,453 books with 0 errors and 3,863 merged works. On the next stage, the API skeleton, the plan review returned 9 blocking issues before any code existed, and the code review later found no critical or serious defects. Three of seventeen stages are done.
Worth knowing
The post does not name the agent; it cites the Claude Code subagent docs for why a fresh context matters. The owner checked only 50 merge groups by hand, about 45 correct, and says that is too small for an error rate. An earlier rule to approve every schema change was broken by the agent on its first migration, and the owner dropped it. A casual go-ahead was logged by the agent as plan approval.