Skip to content
H1VE

The case

How H1VE builds H1VE.

H1VE Flow has been built under the H1VE method since its first line. This is not a staged demo. It is the real record of a production product, with one human architect and AI agents writing most of the code: the numbers, one real cycle, and what the project memory captured along the way.

The numbers

What the method produced, counted.

155
SPECs
written and approved before any code
170+
pull requests
every one merged through the same human gate
1,243
tests
in the suite, with a CI gate on every PR
33
database migrations
applied migration-first in production
1
architect
with exclusive merge authority
0
features
entered development without an approved spec

Numbers from the H1VE Flow repository as of July 2026. Every SPEC and every DONE is versioned next to the code.

The cycle in practice

A real example, from the project record.

The project's real swim lane: each card is a feature crossing the stages to main.

H1VE's memory layer writes project decisions to a file the agent loads at the start of every session. The first version committed that file straight to the default branch. It worked in tests. It failed in the real world: the H1VE method itself recommends protecting the default branch, and on a protected branch the direct commit is rejected. The product was violating its own method's recommendation.

The cycle caught it. The fix's spec (SPEC-151) defined the right behavior before any code: try the direct commit and, when branch policy blocks it, open an idempotent pull request that the architect merges. No PR spam, no exception to the rule. The adversarial review ran with three lenses and a second agent verifying, raised five findings, all low severity, all documented. The architect merged. The project memory recorded the decision.

That is what the method does. It does not stop mistakes from existing. It stops them from reaching production unseen.

What the memory captured

The project remembers, so the team doesn't have to.

Project memory started as a hand-maintained rules file that grew past 240,000 characters, too big for any agent's context, too costly to maintain. That pain became a feature: today H1VE distills each delivery's decisions into atomic notes, anchored to the part of the project they belong to, and the drift judge checks every change against them.

Decision
Database migrations are append-only
Never edit an existing migration, always create a new one. The rule was born from an incident and has never been violated since.
Gotcha
The drift judge saturated its own query
It built the query with a term cap, and spec terms filled the cap before the diff's files got in. Found in an adversarial review, fixed by prioritizing the diff paths.
Invariant
Memory never blocks the flow
If distillation fails, the delivery proceeds. Governance that halts the pipeline becomes bureaucracy, and bureaucracy gets abandoned.

What we learned (and admit)

The method doesn't eliminate rework. It makes rework visible and cheap.

Some SPECs were folded into a single PR when one depended on the other. Some acceptance criteria can only be proven with a live smoke test in production, and the record says so explicitly instead of faking certainty. Promising 90 and delivering it beats promising 100 and failing.

The same cycle on this page is available for your team.

Explore H1VE Flow