DEV Community: Halfcycle

Replit Agent tests its own app. Who reviews the code?

Halfcycle — Sat, 31 Oct 2026 03:11:41 +0000

Halfcycle is a team of AI agents that plans, builds, checks and tests software inside Claude Code. We make it, so read this with that in mind; the full comparison, with every source, is on our site.

Replit Agent is impressive. Describe an idea and it sets up the database and logins, builds the app, opens it in a real browser, clicks through it and fixes what it finds, then publishes it. All in one place.

What Replit does well

Everything in one place. Writing, running, data, logins and publishing. Halfcycle does not host apps; it recommends where yours should run and sets that up as a step in the plan.
It tries the app itself. Halfcycle does this too: when a phase is finished, an AI agent that built none of it clicks through the live app in a browser and sends back what it finds.
Plan mode. It talks the work through and suggests a task list without touching files. Halfcycle does this too, without you asking: it works out whether a change needs a plan and writes it into your repository.
Existing projects. It imports GitHub repositories. Halfcycle reads the code you have too, and carries on from there.

Where the difference is

From Replit's own docs, linked on the full page:

Review. Its docs describe no separate review of the code by another agent. In Halfcycle, each piece is reviewed by an AI agent that did not build it before it is added.
The plan. Replit's plan appears in the chat. Halfcycle writes the product spec, the architecture and a design for each component into your repository, where every later agent works from it.
Logins. With Replit Auth, your users sign in with Replit accounts on a Replit-branded page. With Halfcycle, logins are whatever suits your project and your users.
Where it runs. Replit apps are published on Replit, billed by use. Halfcycle leaves the code with you to put live where you choose.

How to choose

An idea you want running in one place, today, and you are happy for it to live on Replit: Replit.
Software you own, reviewed piece by piece and hosted where you choose: Halfcycle. It can have a first version up today too.

Full comparison: https://halfcycle.ai/compare/halfcycle-vs-replit

Lovable or your own code? What changes when the app has to last

Halfcycle — Sat, 31 Oct 2026 03:05:32 +0000

Lovable is one of the best AI app builders around. You describe a web app in the browser and it builds it, with a database, logins and hosting on its own backend. The question worth asking before you start is not how quickly it appears. Both can have a first version working today. It is what the app depends on once it is running.

What Lovable does well

The code is yours. Its docs say so, and two-way GitHub sync is on every plan. Halfcycle does this too: the code is in your own folder from the first line.
A plan before big changes. Plan mode writes a plan you approve before code changes. Halfcycle does this too, without you asking: it works out whether a change needs a plan, and when it does, writes the product spec, the architecture and a design for each part into your repository.
Nothing to set up. A database, logins and hosting come built in. Halfcycle does this too: you run one command and describe what you want, and it suggests a database, logins and hosting that take minutes to set up, then sets them up as a step in the plan.

Where the difference is

From Lovable's own docs, linked on the full page:

Where the app lives. The code can go elsewhere, but the built-in backend, AI features and connectors keep running through Lovable until you replace them.
What it is built with. Lovable chooses the tools; its docs say it does not offer a choice of framework or database. Halfcycle picks what suits the project.
Existing code. A ZIP upload is rebuilt on Lovable's backend, and GitHub sync cannot connect an existing repository. Halfcycle reads the code you have and carries on from there.
Checking. Lovable runs security scans. Halfcycle plans security in from the start: who can see what is written down once, and each piece is reviewed against it by an AI agent that did not build it, before it is added. At the end of each phase another AI agent clicks through the finished app in a browser.

How to choose

A quick app you are happy to keep on Lovable's backend: Lovable.
Software you need to own, host where you choose and build on for years: Halfcycle, which runs in Claude Code and leaves ordinary code in your repository.

Full comparison, table, FAQ and sources: https://halfcycle.ai/compare/halfcycle-vs-lovable

Base44 or your own code? What to check before you build on an AI app builder

Halfcycle — Thu, 29 Oct 2026 19:58:36 +0000

AI app builders like Base44 have made "describe an app, get an app" real. For a lot of work that is exactly right. But the question that decides whether it is right for your project is not how fast the first version appears. It is what you hold when the building stops.

What Base44 does well

Nothing to set up. A database, user logins, analytics and hosting come with every app.
No terminal. You work in a chat and a visual editor in the browser.
Good for internal tools: admin panels, trackers, booking forms and dashboards, where speed matters more than owning the code.

What its docs say about leaving

These come from Base44's own documentation, linked on the full page:

Export: on paid plans you can copy the code to GitHub. The copy includes the screens, the backend functions and the structure of your data. Records come out separately as CSV files; users and secret keys stay on Base44.
Running it elsewhere: exported code "still relies on Base44 to run", and self-hosting is not supported. Moving off means replacing the database, logins and integrations yourself.
Bringing code in: importing code from GitHub is not supported.

None of that is a criticism. It is the shape of a platform: the same thing that makes it quick to start is what ties the app to it.

The other way to have AI build it

If the software has to last, you can have AI build it as ordinary code you own. That is what we built Halfcycle for. It runs inside Claude Code and works like a software team made of AI agents:

You describe what you want in plain language. It asks the questions a product owner, an architect and a senior engineer would ask, one at a time, with a recommended answer for each.
It writes the product spec, the architecture and a design for every component into your repository.
Builder agents write the code, each on its own copy. A separate set of reviewer agents checks every piece before it is added, and a tester agent checks the finished app.
An online console shows the plan, the agents and the live build.

On our own webhook inbox project it raised six problems before any code was written, including one that would have broken resending Stripe's payment notifications.

How to choose

A quick internal tool that only has to work this month, and you are happy for it to live on the platform: Base44.
Software your business depends on, that you need to own, move, or build on later: build it as your own code.

The full comparison, with the table, Base44's limits, a FAQ and every source, is here: https://halfcycle.ai/compare/halfcycle-vs-base44

One page per project: everything the Halfcycle console shows you

Halfcycle — Tue, 27 Oct 2026 14:14:58 +0000

Halfcycle is a module that runs a five-layer build method inside your own Claude Code (npx halfcycle).

Halfcycle's agents work in your terminal. The console is where you see what they did, and where you make the decisions that are yours to make.

Every project you run with Halfcycle gets its own private console on the web. It shows where the project stands, what is being built right now, which agents are working on it, what problems were caught along the way, and what is waiting for a decision from you. It updates in real time, so nobody has to be in the session, read the repository or ask for a status update to know where things are.

In this guide, we walk through each page of the console: what it shows, and what you can do on it.

Your projects

When you sign in, you see a list of your projects. Each one shows its current state and your access level. In this example, you are an admin on one project, a viewer on another, and your access request to a third is still pending.

From here you can:

open any project's console;
see which projects have access requests waiting for your approval;
give someone access to a project without giving them access to your terminal or your code.

To start a new project, run npx halfcycle in a new folder. It appears in this list automatically.

For the rest of this guide, we use one example project, Northwind Ledger: a payments product with two phases built so far and a third waiting for approval. Every screenshot from here on is from that project.

Overview

The Overview page is the first page you see when you open a project. It answers two questions: what needs my attention, and where does the project stand?

What is waiting on you. Anything that needs your decision appears in a banner at the top. Here, the next phase (Notifications) has been planned and needs your approval before any agent starts building it. The banner tells you what to do and links you straight to it. You can also approve from your Claude Code session by typing approve notifications.

The six stages. Every Halfcycle project moves through the same six stages, in order:

Set up: name the product and prepare the repository.
Define: agree what you are building and who it is for.
Persist: write down the architecture and the rules the system must follow.
Scope: split the work into phases small enough to finish.
Design: specify each feature in detail, with a second reviewer checking it.
Build: build each phase, then test it the way a real user would.

Each stage shows whether it is complete and how many decisions were recorded in it. Below the stages are the approvals that moved the project forward, each signed by a person and dated. Because every project uses the same stages, you can compare several projects at a glance.

Further down the page are three lists:

In flight: tasks running right now, with the agent working on each and how long it has been running.
Needs a seat: tasks only a person can do, such as answering a question the spec left open, or testing the finished phase. Agents never sit waiting silently; anything that needs a person is listed here with the reason.
Flagged: tasks that are still moving but need a closer look.

At the bottom, you can see which agents are working and on what, along with the latest entries from the Ledger (the problems that were caught, who caught them, and where).

System view

The System view draws your whole product as a diagram: clients, the edge, services, data and outside services, with a card for each part. You use it to see what each phase will change, approve it before it is built, and review it when it is done.

Each phase can be viewed at three stages, using the Stage switch at the top:

Scoped: what the phase plans to change, before anything is built.
Building: progress on each part while the phase is being built.
Closed: what actually changed, once the phase is finished.

While a phase is building, each card shows its status: built and reviewed, building, not started, waiting for a person, or blocked. Two statuses are worth watching:

Not in plan: a part that changed even though the plan did not include it.
No task builds this: a part the plan expects to change, but no task has been created for it.

Both would normally only surface at the end of a project. Here you see them as they happen.

Approve a phase before it is built

Before any agent builds a phase, you approve its scope in the System view.

The diagram shows exactly what the phase will touch. In this example, one part will be added, four will change and none will be removed.

To approve a scope:

Open the System view and select the phase.
Click each planned part to see what will change and what it connects to.
Mark each part Looks right, or click Request a change and describe what should change.
Once every part is checked, click Approve phase scope.

The approve button stays disabled until every part has been checked.

If you request a change, the phase goes back with your note, and the parts you already marked stay as they are.

Approving from Claude Code. You can also approve without opening the console. Type approve notifications in your session, and the console records the approval: who approved, that it was done in chat, and which version of the plan was approved. It is also added to the phase's Build Record. Only a person can approve; text written by an agent never counts as an approval.

When the plan changes after you approve. If the plan changes after your approval, Halfcycle does not carry your approval over. In this example, a push provider was added and the event queue now owns more code. Your approval no longer covers those two parts, and no agent will build them until you approve them again. The other four parts stay approved.

Review and close a phase

When a phase finishes building, a close review opens in the System view.

Every part is listed with what actually happened to it: added, changed, removed, not in plan, or planned but not built.

For each part, you can accept it, ask a question, or send it back. Any planned part that was not built must be either carried over to the next phase or dropped, with a reason. Once every part has a decision, you close the phase.

Closed phases keep their diagram. Click any part to compare what the plan said with what Halfcycle actually found in the code. In this example, the audit trail was planned but not built, so it was carried over to phase 2, and the reason is recorded on the card.

This gives you a written record of every phase: what was agreed, what was delivered, and what moved to the next phase and why.

Live build

The Live build page shows the current phase as it is being built.

Tasks are arranged in waves, in the order their dependencies allow. Each card shows the task, the agent working on it, the reviewer who will check it, and how long it has been running. The bar across the top shows tasks completed, in flight, waiting for a person and blocked, along with time elapsed and overall progress.

Task details. Click any task to open its details beside the graph.

The panel shows:

time spent against the estimate, and whether it is on time;
the agent building it and a different agent reviewing it;
which tasks it is waiting on, and which tasks are waiting on it;
whether it is on the critical path.

Critical path. Click Critical path to highlight the chain of tasks that determines when the phase will finish. A delay on any of these tasks delays the whole phase.

Crew

The Crew page shows the team of agents working on your project.

The team is grouped by role:

Analysts and architects question the idea and design the system before anything is built.
Builders write the code and the specs.
Reviewers check what the builders produced.
Leads run the team and watch every change.
You approve the scope, answer the questions only you can, and accept each phase.

Below the team, a grid shows which roles lead and which help at each of the six stages, with the current stage highlighted.

Each agent is listed with its role and current status: working on a task, idle, waiting for a person, or stood down because its part of the work is finished.

The assignment rules are shown in plain language:

A task only goes to an agent with the right skills for it.
A builder never reviews its own work.
Each agent works on one task at a time.
The final acceptance test is done by a person, and that person cannot be the builder.

Layers

The Layers page lists every step in every stage, with its status and the evidence behind it.

Evidence can be a document, an answered question, a code change, or the reason a step was put on hold. Steps that need a person are marked, and steps that cannot run yet explain why. Below the list are the documents each stage produced and the approvals that closed it.

Use this page when you need to check whether something was decided, and where. Every answer links to its source, so you do not have to search through chat history.

Ledger

The Ledger records every problem Halfcycle caught on your project, newest first.

Each entry shows:

what happened: blocked in the code, fixed automatically, corrected in the spec, corrected in the scope, prevented by a question, raised for a person, or approved in the System view;
when and where: the stage it happened at, and a link to the evidence;
who caught it: the agent or person;
what changed as a result.

Checks in force lists the automatic checks running on this project, what each one looks for, and whether it blocks a change or only warns. Most checks apply to every Halfcycle project: when an implementation goes wrong anywhere, the cause and the fix reach every project automatically. Some checks are specific to this project.

Machines lists every computer working on the project and whether Halfcycle's checks are running correctly on it. If a check is missing on a machine, this section tells you which one.

The Ledger is a record of the problems that never reached your product, and exactly where each one was stopped.

Phases

The Phases page shows the history of the project, one row per phase.

For each phase, you can see its dates and duration, its approvals, the defects found when a person tested the finished phase, and the outcome. In this example, one phase was accepted after a second round of testing with three defects fixed, and another was accepted first time with its Build Record delivered.

Each phase is locked when it closes, so its history cannot change afterwards.

On mobile

The console works fully on a phone.

When something needs your decision, the console opens on your to-do list. Otherwise, it opens on the project diagram.

Summary

With the Halfcycle console, you can:

see what needs your decision as soon as you open a project;
review every phase as a diagram and approve it part by part before anything is built;
rely on approvals that stop counting for any part of the plan that changes afterwards;
compare what was delivered with what was agreed when each phase closes;
see the critical path, so you know when a phase will finish and what could delay it;
manage all your projects from one screen;
share a live page instead of writing status updates;
keep a record of what was agreed, built, carried over and dropped, phase by phase;
see every problem that was caught before it reached your product.

Get started

npx halfcycle

Run this command in the folder you want to work in, then open the folder in Claude Code and describe what you are building. When the install finishes, it shows the address of your project's console.

Rolling Halfcycle out across a team or a company? Talk to us about fitting it to your process.

halfcycle.ai

Introducing Halfcycle: the software team your AI engineer was missing

Halfcycle — Tue, 20 Oct 2026 14:26:13 +0000

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.

Nine blockers on a feature that was two screens and a button

Halfcycle — Fri, 09 Oct 2026 19:45:24 +0000

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.

The thing they have in common

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.

The honest part

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.

What it would have cost

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.

halfcycle.ai

The first useful thing it does is disagree with you

Halfcycle — Fri, 09 Oct 2026 19:44:19 +0000

Halfcycle is a module that runs a five-layer build method inside your own Claude Code (npx halfcycle).

Node 20 or newer, and Claude Code. That is the whole prerequisite list. Everything below happens in one sitting.

mkdir tally && cd tally
npx halfcycle

That command signs you in through your browser and creates the project your work gets recorded against. It talks to one address, the same one for everybody, and it ships in the CLI, so there is nothing to configure and no value anyone has to give you first. If it cannot reach us it stops and writes nothing, which is deliberate: a folder set up with no cover behind it is worse than one that is not set up at all.

When it finishes it points you at your project's page on the web. You can also just sign in at app.halfcycle.ai whenever you want.

Click one and you are looking at its console. There is nothing to set up and no second account — it is the same sign-in as the install.

The part worth opening on day one is the crew.

That is the team, live. Twenty-one agents grouped into builders, reviewers, and the ones that are always on. Each shows what it is for and how deep it goes, and each is busy, idle or stood down right now — not a log of what ran an hour ago.

You will not have much on that page twenty minutes in, and that is the point of looking at it early: you can watch it fill up. The first time you run real work, the page stops being a roster and starts being the answer to a question that has no good answer in a terminal. If three agents are running, "what are they all doing" gets you three scrollbacks and a guess.

The other page to know about on day one is the overview, which is where the project's shape lives.

Where each gate stands, which phase is active, and what is happening right now. A phase is a slice of the product that ships and can be shown to someone, and the strip along the top is every gate between you and closing this one.

On a solo project all of this sounds pointless right up until the first time you come back after two weeks away and cannot remember where you were. The console is a faster way to reload a project than your own notes, because it is a record of what happened rather than a record of what you meant to do. On a team it is the only place the work exists for somebody who was not in the session.

Then open the folder in Claude Code.

That is the last instruction in this article, which is worth pausing on, because it is unusual. There is no command to learn, no next step to remember, and no order to get right. Say hello, or say what you want to build, and it takes it from there.

The next ten minutes are questions

This is the part people are not expecting, so it is worth saying plainly: nothing asks you to fill in a form. It reads the folder first, works out what it can, and then asks you only the things it genuinely cannot answer.

The questions come one at a time, in an order where nothing gets asked before the thing it depends on. Each one arrives with a recommended answer and the reasoning behind it, so the cheap path is to read the recommendation and say yes. And where the answer is a fact about your repo rather than a decision, it has already gone and looked, and it shows you what it found rather than asking you to confirm something it could have checked.

You also cannot get ahead of it. Ask for something three steps away and it either does it, because that is what came next anyway, or it tells you why not and what is missing. There is no path through this where you skip a step by accident, which means there is nothing to hold in your head and no checklist to keep open in another tab.

The one thing it will not do is let you record a decision without a reason. Not a spelling of a reason. An actual one. This is the first place the tool has an opinion, and it is worth understanding why it holds it: in three months, the only difference between a decision you can revisit and a decision you have to re-litigate from scratch is whether anyone wrote down why. Every agent session after this one reads what you decided here. A decision with no rationale attached is a decision the next session will quietly reinterpret.

Answer them honestly rather than quickly. You are the only person in this loop who knows what you are building.

Then it asks what you are making

Say it in your own words. Not a spec, not a structured brief. A paragraph.

I want a thing where I can log what I ate and it tells me roughly what I have had this week. Just for me. Web, phone browser mostly.

What comes back is a draft of what you just described, longer and more specific than what you said, and about seventy percent right. That draft is not the product. It is the strawman, and the strawman exists because pushing back on a specific wrong claim is enormously easier for a human than answering an open question against a blank page. Anyone who has been handed a template with an empty "Non-functional requirements" heading knows exactly what that difference feels like.

So it drafts, and then it turns on the draft. Same interrogation shape as the setup: one question at a time, ordered, each with a recommended answer.

The moment worth waiting for

Somewhere in there, it asks you something you had not decided.

On a food log, it is usually this one, or a version of it: what happens when you log the same thing twice in one day. That sounds trivial. It is not, and here is the honest shape of why. If two identical entries are one row with a count, your weekly total is a sum over counts and your history is lossy. If they are two rows, your total is a row count and you can show the day back to the user exactly as it happened. Both are fine. But one of them is a schema, and you are about to build on it, and nobody was going to ask.

That is the intervention. It is not a bug caught. It is a decision surfaced before it became a default, which is the only time a decision is cheap.

The tell that it landed is that you stop typing for a second.

What you have after twenty minutes

Files, in your own folder, in plain markdown. The context your agent sessions read on every future session, the decisions you made and the reasons you gave, and the beginning of a description of your product that is more specific than the one in your head.

Nothing of ours is left in there. The process itself — the steps, the templates, the questions — arrives in the session that asks for it, sized for the step you are on, and is not at rest in your repository. What stays is what you wrote.

You have not built anything yet. You do not need to know what happens next, either. It will say.

Getting started

npx halfcycle

halfcycle.ai