1. Introduction

At Open Reach Tech, we have recently cut human review of AI-written code substantially. What people look at is now mostly the spec and the design; the code itself gets checked only at key points, and after that we try the finished screens by hand to check the UI/UX before shipping to production. That is the flow we have moved to.

We are, originally, a company that made thorough code review a habit across the organization. It took a certain history before such a company could reduce human review. This is the story of what we learned over the past two years or so of having AI write code and tests, where it hurt, and what we built as the answer by pulling together our in-house know-how.

That pulled-together thing is Hora Kit, which we are releasing as open source today.

https://github.com/openreachtech/hora-boilerplate

In one sentence: we took all of the review guidelines and development knowledge held by our lead engineers and CTO and turned them into Claude Code skills, then generalized our way of working into an orchestration tool: write the spec in dialogue with a person, implement one feature at a time from that spec, pass acceptance, and only then move on to the next feature. The goal is not to stop at "the AI writes the code for us" but to reach "we can ship to production without a person reading the code in detail."

In this article we explain why we could cut human review so much, what we do instead, and how much it costs, with real numbers. The finer details of what is inside Hora Kit are split into separate articles (linked in the second half of this one).

One caveat up front: Hora Kit is not fast. Compared to typical vibe coding it is clearly slower, and it uses a lot of tokens. We would be glad if you read on and think about why we keep using it anyway.

2. Given the right information, AI builds better things than people do

Let us start with the time before Hora Kit.

For about two years we have had the sense that "given the right information, AI produces far better output than a human." When we actually had AI write code and tests, the results, when we properly handed over the requirements, the design, and the conventions, were clearly better than what people wrote.

The problem was that "handing over the right information" is quite hard. Put into words, without ambiguity, what is to be built; settle the design decisions in advance; attach every convention that must be followed, with nothing left out. In our experience, fewer than one in ten engineers can do this at a reasonably high level.

About a year ago we started having AI write tests too, and the gap became even clearer. Some people could get high-quality tests and code out of the AI, while others had tests with many gaps, or let low-readability code through as it was. The quality of the information given to the AI showed directly in the deliverables.

What filled that gap was human review. We had a culture of thorough code review to begin with, so every AI output was looked at by a person. But AI writes several times more than a person does, so the time spent on review kept growing. Large variation between individuals, and review that takes a long time. This was not a new discovery for us; it was a problem we knew about from the start.

So what we asked ourselves was whether the hardest part, "handing over the right information," could be done without depending on individual skill. We felt we needed two things. One was a workflow that organizes the review guidelines and development know-how held by lead-engineer and CTO-level people, so that whoever uses the AI, things get built to the same standard. The other was a mechanism by which the AI interrogates the human to clarify the spec and the use cases. If people cannot write a perfect spec from the start, the AI should ask questions until they can. That was the idea.

Hora Kit is those two things given form. We wrote our in-house know-how out as skills, and wrapped them in an orchestration that calls them in a fixed order and does not move on until verification is done.

We also built security review into this workflow. Security tends to be treated perfunctorily early in a project, and is often revisited in a hurry later. If an audit checkpoint is inserted per feature, it is covered to a high standard from the start.

When we actually ran development through Hora Kit, it found a number of latent bugs and security vulnerabilities that our previous way of working had not caught. What a person can see in review is, in the end, only the cases that person thought of. Tests that were written by tracing the use cases in the spec for every feature, and an audit that mechanically checks a fixed set of items every time, picked up cases nobody had thought of.

What guarantees AI output is not human eyes but this coverage. The decision to substantially reduce human review starts from there.

3. What Hora Kit does

From the user's side, there is only one command to type: /hora. /hora determines where the project currently stands and calls the skills that are needed next, in order.

There is also /hora-hotfix, but it is the only one /hora does not call; a person types it directly in an emergency.

The docs call /hora-spec "the deciding side" and the remaining four "the building side," and draw Hora Kit as two parts. We use the same terms below.

One is /hora-spec, the side that writes the spec. It reads whatever material is at hand (notes, mockups, old design documents, anything), and writes the spec one section at a time while asking questions and making proposals. Each section is presented in full, and only what a person approves is written. The AI never decides requirements on its own.

The other is the building side, where /hora-setup, /hora-plan, /hora-build, and /hora-accept run in order from the finished spec. It takes one feature through 18 checkpoints, and moves on to the next feature only after passing final acceptance. If something not written in the spec turns out to be needed along the way, it does not fill the gap by guessing; it stops and asks.

The only thing the two share is a spec file, specs/<version>/spec.md.

The spec-writing side is a dialogue, so a person needs to sit with it. The implementing side, on the other hand, stops rather than deciding on its own when it needs an answer, so it can be left running. We call this division "spec by dialogue, implementation by automatic execution."

3.1 The orchestration-repo layout: separating the repository that directs from the repositories that hold the code

There is one more management practice that Hora Kit is built on: the orchestration-repo layout (we call it the オケレポ layout, short for orchestration repository).

When you start a project with Hora Kit, a repository named <myproject>-app is created. This is the orchestration repository, and it holds the spec specs/, the execution record .hora/, and the stack declaration docs/stack/. Not a single line of the application's actual code lives in this repository. The actual code lives in separate git repositories such as backend / frontend, which /hora clones inside the orchestration repo. The inner repositories are gitignored, so cloning the orchestration repo does not bring the actual code with it.

myproject-app/            ← orchestration repo. Holds only the spec, records, and stack declaration
  specs/<version>/spec.md
  .hora/
  docs/stack/
  backend/                ← actual code. Independent git repository. Gitignored
  frontend-employee/      ← actual code. Independent git repository. Gitignored

With this separation, "what we decided to build" and "what passed acceptance" can be read from the orchestration repo alone, and the spec and records have a lifetime separate from the actual code. If the implementation repositories are recreated, the spec and records remain; conversely, someone who is allowed to read the spec does not have to be given the actual code. When wrapping Hora Kit around an existing project later, all you do is wrap the existing repositories from the outside.

The details of this layout are in the third article of the series.

4. Why we could cut human review so much

Explaining all 18 checkpoints would take too long, so we narrow it down to the three that were decisive in reducing human review.

4.1 The same use case is verified three times, at different stages

Hora Kit verifies the use cases written in the spec three times.

The first time is at checkpoint 2, looking only at the text of the spec and checking "can this use case be satisfied?" The second is at checkpoint 9, after the backend API is built, tracing the same use case in the order the actual API would be called. The third is at checkpoint 11, doing the same thing against the screen design.

What matters here is what happens when a verification fails. Suppose the second verification reveals that "a field this screen needs is missing from the API response." Normally you would want to add the one field on the spot and move on.

Hora Kit does not do that. It goes back to checkpoint 3 (schema design) and redoes it from the schema.

The reason is that by that point, the frontend side has already started building against the old API contract. If only the backend adds the field, the contract and the implementation drift apart. A drifted contract causes no problem immediately; it surfaces much later as "somehow the frontend and backend do not agree." There is a limit to how far a person can chase this drift by eye, but because there is a mechanism to go back to an earlier checkpoint, the need to chase it went away altogether.

4.2 Tests run in full, across all repositories, every time

At acceptance in checkpoint 18, all unit tests in all repositories are run, every time. Not only the tests related to the feature in question.

This is simple, but it works. When a change for one feature breaks an earlier feature, it necessarily fails in that very run. The situation "it broke at some point and we do not know what caused it" does not occur.

And the sheer volume of tests is on a different scale from what people write. We have succeeded in coding a system with more than 10,000 tests entirely automatically from scratch and taking it all the way to production.

It is not realistic for people to keep writing this many tests, and even if they could, the tests would rot under maintenance. Have the AI write them, and have the AI run all of them every time. This is the single biggest factor that let us move the guarantee of behavior from human eyes to tests.

4.3 The security audit is done by an agent that only reads and does not fix

Checkpoint 8 is the security audit. For a feature that wrote backend code, this checkpoint cannot be skipped.

This audit has a slightly unusual property: the agent that performs it has no permission to edit files. It only reports the problems it finds; it does not fix them. Fixes are made by a different agent, and then the audit runs again.

The reason we deliberately separate them is that if the same agent both "writes" and "checks," an escape hatch appears: loosen the failing test and let it pass. AI agents optimize toward making tests pass, so if that path is left open it gets used. Closing it with permissions was the reliable way.

Deciding "we accept this" for a finding is also done by a person, not by AI. An accepted finding stays in the record as a question; it never quietly becomes a pass.

Security review is work that tends to be deferred, but because this checkpoint is inserted per feature, there is no need to do it all later in one batch.

The scope of the audit is the changes for that feature and the operations and endpoints the feature newly declared. It does not look at the whole repository every time. However, "callers newly connected to existing code" are included in scope. If you only look at changed files, authorization gaps slip through at exactly that point.

5. Honestly, it is slow and it eats tokens

Everything so far has been the good news, so let us talk about cost too.

Hora Kit is slow. For each feature it brings up a set of containers, passes acceptance, and only then moves on to the next feature, so features are not run in parallel. The docs have a section called "why serial," which explains that parallelization is blocked by unresolved problems around git.

It uses tokens too. Each of the 18 checkpoints is handled by a separate agent, so the amount of conversation per feature is inevitably large.

Here are the numbers we actually measured.

In terms of speed it is roughly 5 times slower. Even so, for a release intended for production operation, we consider this a necessary cost.

Note that the "quality" row in this table is, for now, our qualitative assessment from comparing the actual deliverables. We plan to release a separate report measuring quantitative metrics such as circular dependencies, complexity, and test coverage.

And compared to people, it is overwhelmingly cheap. If people were to take a 100k–200k line system to release, it would take several months no matter how much they rushed. That is done with a $110 plan and two weeks.

But where the cost difference really shows is not in new development. It is in maintenance.

6. What helps in maintenance

6.1 The spec is kept per version

The spec lives at specs/<version>/spec.md, one per release version.

From the second version on, the spec contains only the diff against the previous version. Past versions' specs are never touched.

specs/
  1.0.0/spec.md    The first version. Full text
  1.1.0/spec.md    Only the diff against 1.0.0

With this shape, "what we decided to build in 1.0.0" remains readable as is, even after 1.1.0 has been built. Design documents written by people tend to either rot without being updated, or get overwritten with the latest state so that the past disappears; that problem structurally cannot happen here.

Git branches correspond to these versions too: feature branches are cut from release/<version> and merged at each checkpoint gate. Only emergency fixes take a different route: a hotfix/ branch is cut from main and merged straight back, after which /hora brings the open release line up to date with the new main.

6.2 Records keep accumulating in .hora/

Hora Kit has no state file in the usual sense. The state is the .hora/ directory itself, and the Markdown checkboxes inside it are the state.

.hora/
  tasks/<version>/<feature-id>.md      One feature and the checkboxes for its 18 checkpoints
  acceptance/<version>/<feature-id>.md Every acceptance run for that feature. 1 run = 1 appended block
  questions/<version>/open.md          Append-only. To answer, edit specs/
  contracts/<version>/                 Server contracts used from other repositories
  glossary.md                          Append-only

The history of what ran can be followed with git log .hora/. The docs say "there is nowhere else that records anything, and there is no need for one."

This pays off in maintenance. When our engineers want to know "why was this decided this way" about a feature built a while ago, they read .hora/questions/ and .hora/acceptance/. Everything is there: what was asked at the time, what acceptance pointed out, and where it was sent back to, so there is no need to dig up the conversation logs from back then.

7. It runs on a million-line system too

Hora Kit is in actual use on our own products and on some customer projects. The largest is a system with close to a million lines of code, 300 tables, and billions of records.

This system was not built with Hora Kit from the start; the Kit was wrapped around already-running code afterward. Even so, development continues stably.

What matters more as scale grows is the order "take each feature all the way through acceptance." If you build layer by layer, that is, build the entire backend, then the entire frontend, then test at the end, design flaws surface only at that final test, by which point everything is already stacked on top of them. If each feature goes through acceptance, nothing is stacked on top when a flaw appears.

8. The open-source projects that make up Hora Kit

Hora Kit is not a single repository but a collection of open-source projects split by role. The only one users clone directly is the boilerplate; the rest are pulled in as dependencies by the boilerplate's npm install and placed under .claude/.

Core and the skill packages are separated because the skill packages are updated independently of core. If core held copies of the procedures, those copies would go stale the moment a package was updated, and nobody would notice. So core states only "what kind of work this is," and leaves the actual procedure to the packages. The boilerplate's job is to declare both as dependencies and bring them together with npm install.

There is one thing we want to make clear here. What "leans on our technology" is only the hora-boilerplate and the four skill packages. hora-core carries no name of any particular framework or database, and is structured so that it can be used as is for general web development. The order and the checkpoints do not know the stack; that is the design.

So if you define a set of skills for a different technology stack and prepare a boilerplate for that stack, Hora Kit can be carried over to any technology stack. As of today, only our own stack (renchan / furo-nuxt) is provided, but that is not a design constraint; it is just that nobody has written the others yet.

We are looking for development partners to work with us on this activity of "defining a set of skills for each technology stack." Whether it is Rails, Django, or Go, if you want to distill your own stack's conventions and review criteria into skills and put them on Hora Kit, please reach out via an Issue or a comment on the main article.

A sample of a spec written with Hora Kit, and of an app built with it, is currently being prepared. We plan to publish one on the scale of several hundred thousand lines; details are in the "Roadmap" section.

9. How to use it

You do not need to write the spec first. Put whatever you have in place and type /hora, and it starts from writing the spec.

9.1 Create a repository from the template

At https://github.com/openreachtech/hora-boilerplate choose Use this template and create a repository named <myproject>-app.

git clone <the repository you created> myproject-app
cd myproject-app
npm install   # postinstall places Hora Kit and the 4 skill packages under .claude/

Use the active LTS of Node.js. On Windows, it needs to run inside WSL 2.

9.2 Put in what you have

specs/1.0.0/request/   What you want built in this version (a single page of bullet points is fine)
specs/1.0.0/annex/     Material that explains it (mockups, ER diagrams, old design documents, spreadsheets)
specs/1.0.0/sources/   Specifications whose content is already decided (when in doubt, use annex/)

It does not need to be tidy, and PDFs or PNGs are fine.

9.3 Run /hora in Claude Code

/hora

Since there is no spec yet, /hora calls /hora-spec. It reads what you put in and comes back with questions and proposals, and each section you approve is written into spec.md in turn.

Once the spec is written, all you do is type /hora. It proceeds through setup, planning, implementation, and acceptance, stopping wherever it needs an answer.

10. Further reading

The details of the mechanism that this article left out are covered in a separate series of articles, "The design of Hora Kit."

• Hora Kit is two machines sharing one document (the big picture; the map to read first)
• Why Hora Kit holds not a single procedure (the separation of Core and Skills, stack independence)
• A repository with no implementation code directs the whole project (repository layout and git model)
• The 18 checkpoints and 4 gates one feature passes through
• Let the AI write the spec, but never let it decide the requirements (the 7 stages of /hora-spec)
• A re-entrant orchestrator with no state file (the design of .hora/)
• Why Hora Kit does not run features in parallel
• An audit that only reads, and findings that say where to go back (checkpoint 8 and /hora-accept)
• Wrapping Hora Kit around code that is already running (applying it to existing projects)
• Production is broken and you have two hours (/hora-hotfix)
• A rule that takes eight sentences costs eight sentences every time (how to write skills)
• Keeping the spec as a diff per version

The overall design philosophy is collected in the hora-core docs. It is long, but it covers "why this shape" from end to end. https://github.com/openreachtech/hora-core/blob/main/docs/architecture.ja.md

11. Roadmap

Hora Kit is still a work in progress, and we plan the following.

• Further speedups and reduced token consumption
• Support for frameworks and languages other than our own technology stack (renchan / furo). This will proceed by extending the per-stack skills
• Support for AI editors other than Claude Code, such as Codex, Cursor, and Antigravity (most of it already works as is today)
• Adding and improving concrete implementation patterns and design patterns
• Publishing quality-measurement benchmark data: the quantitative metrics mentioned in section 5, such as circular dependencies, complexity, and test coverage
• Publishing sample code and specs on the scale of several hundred thousand lines, built with Hora Kit

12. Conclusion

The two things we were most conscious of in building Hora Kit were "the AI does not decide requirements" and "move the guarantee of behavior from human eyes to tests."

The former is why we can trust the spec; the latter is why we no longer have to read the code in detail. As a result, we have settled into a state where what people look at is mostly the spec and the design, the code is checked only at key points, and after a final hands-on check of the screens it can ship to production. For us, this is automated development in the true sense.

At present, we sacrifice some speed (though it is still far faster than humans). If you are having AI build what goes to production, we think that is a cost worth paying, but this judgment will vary with the nature of the project.

The current hora-boilerplate assumes our technology stack, but hora-core is structured to apply to general web development, and by extending the per-stack skills it can support any framework or language. If you are struggling to find a solution for having AI write production code, please give it a try. If you get stuck using it, or there is something you would like it to do, let us know via an Issue. Anyone who wants to build skills for their own stack together with us is welcome too.

To get started, go here. https://github.com/openreachtech/hora-boilerplate

To read what is inside, go here. https://github.com/openreachtech/hora-core

We hope this is useful to anyone wondering how far to extend the scope of what they hand over to AI.