Halfcycle is a module that runs a five-layer build method inside your own Claude Code (npx halfcycle).
Most process claims cannot be checked, because nobody writes down the bugs that never happened. Here is one that can.
A real feature on a live product: let somebody restore an older version of a document they had edited. Small by any measure. Two screens of work and a button. It was reviewed five times before anybody was allowed to start building.
Blockers found each round: six, then two, then one, then none, then none. Nine in all.
Here are eight of them. The first four would have reached real users.
Restore could overwrite a file that is meant to be locked. The rule was enforced in the normal save path, and nobody copied it into the new restore path. Every test of the new code passes. There is no failing assertion to find, because the thing that is wrong is a rule that is not there. Somebody has to notice an absence.
The undo feature could destroy the backup it exists to protect. Save a backup, update the search index, commit, all one step. If the index update failed, the backup was discarded and the new content had already been written. The window is small and the loss is total.
The button would never have appeared for anybody. It was keyed on a piece of data the system only attaches to exactly the records the feature refuses to act on. The code is correct in isolation. It ships to nobody, silently, and every test is green.
Restoring a document would have silently deleted its labels. A shared helper wipes all labels and puts back whatever it is handed, and the design handed it an incomplete list. Nothing fails. Nothing logs. The loss surfaces weeks later, somewhere else, and looks like a different bug entirely.
The plan described a bug that did not exist. It came from a search of the codebase that was accurate and drew the wrong conclusion from what it found. Everything downstream of it would have been solving a problem that was not there.
The design could not be built where it was going. The place the plan chose to hang the new screen is a sibling of the thing it needed to replace, and a sibling cannot replace anything. Correct design. Wrong address.
The final checklist pointed at addresses nobody had ever written down. It survived four rounds of review doing that. It needed no knowledge of the code to catch — it is a mechanical check that a path exists — and it consumed an expensive human reader anyway.
The summary everybody reads first still described a plan three rounds had thrown out. The document had been fixed. The abstract at the top of it had not, and the abstract is the part people actually read.
Not one of them is a coding mistake.
Every one sits in a join: between two pieces of code, between two people's work, or between the plan and what was already there. An agent writing the file in front of it cannot see any of them, because none of them is visible in the file in front of it. Neither can a reviewer reading the change on its own, for the same reason.
That is the shape of how AI-assisted work actually fails now. Not bad code. Confident, well-tested, well-structured work built on something nobody examined.
And notice which tools would have caught which. A linter: none. A type checker: none. A test suite: none, and worse than none, because four of these ship green and green is read as evidence.
Five rounds on a feature that small is heavy, and we are not going to defend it.
The first round alone returned six blockers. Rounds two through four found five more defects, and nearly all of those five were introduced by the previous round's own fixes. That is its own finding, and it is uncomfortable: the fixes are the highest-risk region of the work. A reviewer who asks for a change is the least able to see what the change broke, which is exactly why the next round has to run in a session that has never seen the last one.
The method was amended in four places because of this feature. What a scoping document has to mark as unverified before it travels. What a design has to check rather than assume. A cheap mechanical pass that runs before any expensive reader is spent on things a mechanical pass can do — the checklist pointing at nonexistent addresses should never have reached a human at all. And when the summary everybody reads first is allowed to be written, which is: last.
That is the loop working, and it is also the argument. A finding on one project becomes a step on every project after it, and nobody has to install anything for that to be true.
The four that would have reached users are not equivalent to four bug reports.
The label deletion is data loss with a delayed and misattributed symptom — the kind that gets investigated as a different problem for a week. The backup destruction is a support conversation you cannot win. The button that appears for nobody is a feature that ships, gets announced, and generates no usage, and somebody spends a sprint on analytics before anyone opens the code.
Against that: five rounds of review on two screens of work, which felt excessive at the time and still does.
We do not have a number for what that trade is worth and are not going to invent one. What we have is the list above, which is checkable, and the note that every finding on it is now a step earlier in the process.
Getting started
npx halfcycle
Run that in the folder you want to work in, then open it in Claude Code and say what you are building. Needs Node 20 or newer. There is nothing to learn first and no next step to remember — it tells you what is next when it is next.