Halfcycle is a module that runs a five-layer build method inside your own Claude Code (npx halfcycle).
Your coding agent is a very good engineer. It is also working alone. Nobody decides what is being built before it starts, nobody works out how the pieces fit, nobody cuts the work into tasks, and nobody checks its work except the agent that wrote it.
Halfcycle is the rest of that team, running inside your own Claude Code:
- a product owner, who drafts what you are building and asks the decisions only you can make, one at a time, each with a recommended answer;
- an architect, who works out how the pieces fit and writes down the rules the system has to keep;
- a planner, who cuts the work into tasks a team can build in parallel, and puts the things only a person can do into the plan as tasks of their own;
- reviewers, who check every plan and every finished task, and never the work they wrote;
- builders, named agents that take the tasks, each sized to the job.
You do not need to know any of that process. You say what you want to build, and Halfcycle works out the next step every time. You watch the team on the project console while it works.
The clearest way to show what that gives you is a real build. So we built a small service, kept everything (every question, every answer, every screenshot) and wrote it up here.
The build: a webhook inbox
Webhooks get lost. A handler throws during a deploy, the provider retries on its own schedule or not at all, and a week later somebody asks why a customer's payment never showed up. The fix is a small service in front of the handler: receive every webhook, check its signature, keep a copy, and let you replay any delivery your handler failed.
It looks like a weekend job: three endpoints and a table. It is also exactly the kind of thing where the expensive mistakes are decisions rather than code: what happens on a retry, what counts as failed, what a replay looks like to the handler. A single coding agent makes those calls silently, as defaults. A team asks them first. That is why this build is quicker and easier with Halfcycle than without it.
Installing it
The whole install is one command, run in the repository you want to work in:
npx halfcycle
It starts by reading where you are: the version, your Claude Code, the repository, and whether Halfcycle is already set up in it.
Then it signs you in through your browser, creates the project, and sets up the repository. Its last lines give you the address of the project's console: the page where you will watch the team work.
The install also suggests running a setup command next. You do not need to. As the rest of this build shows, telling Claude Code what you want to build gets you to the same place.
Open the console straight away and it is already there, empty, with the six stages the project will move through: set up, define, persist, scope, design, build. It fills in as the team works.
What we typed
Then we opened Claude Code in the repository and typed one sentence:
I want to build a webhook inbox: a small self-hosted service that receives webhooks from Stripe, GitHub and similar, checks their signatures, stores every delivery, shows them in a simple list page, and lets me replay a stored delivery to my own handler when it failed.
That was the last instruction about process. We did not run a setup command, pick a phase or look anything up. Halfcycle read the empty repository, decided there was nothing recorded yet, and started with setup.
From there it asked one question at a time, each with a recommended answer, what it would cost to change later, and the reason. A note on honesty: the answers in this run were typed by an agent acting as the product owner, and every one of them is in the run's decision log.
What the team caught before any code
The product owner and the architect found six problems before a builder was given a task. None of them is a coding mistake, and every one would have survived a normal code review, because the code would have been correct.
Replay would have broken the handler. The first draft forwarded each stored delivery with the provider's original signature. Halfcycle checked how Stripe signs: the signature carries a timestamp, and Stripe's own libraries reject it after five minutes. So every replay of a Stripe delivery would fail the handler's signature check, which is the one feature the product exists for. The fix was for Hookbox to sign what it forwards with its own secret, so a replay looks exactly like a live delivery however old it is.
Sitting in front of the handler switches off the provider's retries. Once Hookbox answers Stripe with a 200, Stripe considers the job done. Stripe would have retried a failing handler for days. Without a retry of its own, Hookbox makes every deploy blip a manual clean-up, which is worse than having no Hookbox. Four automatic retries went into the first version.
The goal could fail without anyone noticing. We agreed the measure was "no lost webhooks". Halfcycle pointed out that nothing in the plan told anyone when a delivery ran out of retries, so failures could pile up unseen, which looks exactly like a lost webhook. A single notification to a URL you choose went in.
The assumption that kills the product. Retry and replay both resend deliveries. If the handler is not idempotent, Hookbox turns its recovery features into duplicate charges. Halfcycle named this as the claim the whole product rests on and set a thirty-minute test to run against the real handler before Hookbox goes in front of it.
Whether to build it at all. Before any design, it compared building Hookbox with two existing webhook services and with doing nothing, and recommended an hour trying the cheapest credible alternative first. We overrode it: the alternative needed a database server, a queue and two processes for one inbox. That override became a rule the rest of the design had to keep: one process, one file.
A bad signature answered with a 200 strands real events. If Hookbox's signing secret were misconfigured, every genuine event would fail verification. Answering 200 tells Stripe to stop, so all of them would be stuck. Answering 400 keeps Stripe resending until the secret is fixed. It checked that claim against Stripe's documentation, and where the documentation did not give a number (Stripe's response timeout), it wrote "unverified" instead of guessing.
The part that took too long
Before any build task was handed out, the feature specs went to review by an agent that had never seen them. If that review found problems, they were fixed, and the specs went to another new reviewer, never back to the one that asked for the fixes.
That took sixteen rounds. Problems found per round started at 21, 13, 13, 6, 11, 4, 6, 2, 3, then between one and five a round until the sixteenth reviewer let the specs through. Every one was real. Among them: a sign-in redirect that could send you off-site, a send that shutdown would have cancelled halfway, an example config file that would have stopped the service starting. Each round took seven to ten minutes. Finding any of those in production would have cost far more.
But sixteen rounds is heavy for a proof of concept, and later rounds were mostly finding edge cases in the previous round's fixes. We are not defending the sixteen. It is going back into the method.
The things only a person can do
Some of the build needed us, not an agent: create a Stripe test account, install the Stripe CLI, capture one real event to test against, and walk the finished thing by hand. We asked for those to go into the build plan as tasks of their own, with steps, so nothing waited on us that did not have to.
That is what happened. The plan has nineteen tasks. Five are ours, each with numbered instructions and a check that says when it is done. Only the tasks that need a real Stripe event wait on them. Everything else built.
The team at work
Once the plan was approved, the build ran as a team. Each task went to a named agent with the right depth for the job: ADA on the delivery store, OTTO on the Stripe receiver, NOVA on the inbox page, MILO on the test handler, HUGO on the build checks. Each finished task went to a different agent for review before it was merged. A builder never reviews its own work.
The console shows all of it as it happens. The Live Build view is the plan as a graph, wave by wave, with each task's agent and state.
The red node is a review that failed. CASS rejected OTTO's Stripe receiver: its test fixture did not match what the spec required, so the test proved less than it claimed. OTTO fixed it, and THEO, a different reviewer, checked it again and passed it. Nobody had to notice. The console did.
The Overview also keeps a "first catch": the first problem Halfcycle found in this project's code. Here it was a database update aimed at a row nothing in the change creates, so the update would silently do nothing.
Two hours and eleven minutes after the build started, every task that did not need a person was built, reviewed and merged. The build stopped where it should, at our tasks.
What it took from us
One sentence to start. Thirty-seven answers, most of them a recommendation we agreed with, and a couple of overrides. No process to learn, no command to remember, no prompt engineering. Halfcycle told us what came next at every step, and the console showed what the team was doing while we were not looking.
That is the difference between an AI engineer and a software team. The engineer would have built this webhook inbox quickly, and built the six problems into it with the same confidence. The team found them while they were still sentences in a document, where fixing them took minutes, then built it in parallel and checked every piece with someone who had not written it. That is where Halfcycle makes building quicker and easier: the rework you never have to do.
Your coding agent already writes good code. Give it the team it was missing: run npx halfcycle in your repository, then tell Claude Code what you want to build.
Top comments (0)