Built in three hours.

Andrew built Hōzō in a single early-morning session before the kids were up. 278 tests. 99% coverage. Zero lint errors. It was not a prototype. It was production software — deployed and running.

"The AI wrote the code. I built the system. Those are different things."

What "building the system" meant

Before any code existed, the architecture did. The scope was bounded in writing: what Hōzō would do, what it would not do, what its failure modes were, what the data model looked like, what the test strategy would be. The AI received a specification. It did not invent one.

Building the system meant watching the AI's execution in real time — not glancing at a diff at the end, but attending to each file as it was written. The first agent pass produced code that drifted from the spec in two places. Both were caught during the session. Neither made it to commit. If the practitioner had not been watching, both would have shipped.

All code changes were subject to ruff, mypy, and pytest before being committed. Coverage stayed above 99% because failing to write a test for a new code path meant the commit was blocked. Nothing past the gate without a passing test.

The session was the implementation. The system design, the architectural decisions, the verification standards — those came first and took longer. The development was fast because the upstream practice was rigorous and intentional.

Why this was possible

Eleven weeks of deliberate Python practice preceded the session. Not tutorial practice — project practice. Real systems with real specs, real tests, real deployments. The months before that were architecture and systems thinking accumulated over years of design work at a different scale.

The working principle underneath the session was simple: "Anything I can specify, I can build." The limit on what gets built is the practitioner's ability to specify it clearly — not their ability to type Python.

The Ho System

The Ho System is a methodology for structured human-AI collaborative development. It is modeled on the martial-arts arc of shu-ha-ri: follow form precisely, then break form deliberately, then transcend form entirely. The practitioner internalizes discipline through repetition until the discipline becomes invisible.

Sessions are bounded by scope documents (called "hos") so the agent and practitioner share the same model of what the session will do. Verification is non-negotiable — lint, types, tests, in that order, before every commit. The repository itself encodes the quality practices, so the agent conforms to the standard it finds in the environment rather than to whatever its defaults would otherwise produce. Documentation is not overhead; it is the bootstrap that makes the next session possible. Read more about the Ho System ↗

Speed without stability is just accelerated chaos

DORA's research showed: elite teams deploy frequently and have low change failure rates. Speed and stability are not a tradeoff; they are the same discipline at different time scales. The verification stack that kept Hōzō at 99% coverage in three hours is the same discipline that keeps production systems from failing on Friday afternoons. Going fast without it is not speed. It is accumulated debt moving quickly.