Jason A. Hoffman

Written by AI Staff^†

---

I spent Christmas break using Claude Code to build Judoka, a production application for iOS, Android, and the web. Apple approved it for the App Store three weeks after I started.

The result was fast enough to change how I think about software development, but the raw output numbers need context.

---

The Setup

I train at a dojo in Santa Clara. For several years, its owner, Shintaro Nakano, and I had discussed an application to replace paper waivers, group texts about attendance, and manual answers to parents asking whether a child came to practice. I had estimated that the full scope would take years.

My career has been in infrastructure and software, including responsibility for teams ranging from three people to 30,000. I had not shipped a React Native application since the framework’s early years, and I had no prior production experience with Supabase, Expo, or the Claude APIs.

I started on December 21. By December 27, the application had authentication, attendance tracking, AI coaching, and users. By January 4, it had a multi-tenant dojo directory, Stripe payments, and a video marketplace. Apple approved it for the App Store on January 15.

The app is live at judoka.ai. There’s a marketing site at judoka.blog. Real people use it to check into judo practice.

The repository recorded 19 active development days, about 309,000 lines of code, 2,726 tests, and 214 database migrations.

---

The Arithmetic

COCOMO, feature decomposition, and complexity estimates put an implementation of this size at roughly 9,500–12,000 person-hours under their assumptions. That corresponds to five or six years of solo work, or 12–15 months for a five-person team.

I did it in 19 days.

Dividing those estimates by elapsed effort produces a nominal acceleration of about 71 times. This is a throughput comparison, not a controlled productivity study. Generated lines, migrations, and tests do not establish equivalent quality, comprehension, or maintenance cost, and the traditional estimate is itself uncertain.

Phase	Days	Commits	Traditional Equivalent	Acceleration
v1.0 Foundation	7	533	420 dev-days	60x
v2.0 Platform	8	652	645 dev-days	81x
v2.4 Global Ready	4	303	278 dev-days	69x

The estimate was highest during v2.0, after the repository contained patterns that the model could repeat. Reuse increased output, but it also repeated early design decisions before I had much time to reconsider them.

---

What I Learned

Halfway through, I extracted the practices that helped into a reusable setup. Many online instructions addressed limitations that Claude Code 2.1.x already handled. The useful additions were repository constraints, current project context, and a way to record session state.

I published the result as agentic, a small Claude Code setup for React Native and Supabase projects.

Short, enforceable repository rules worked better than long role prompts. At the time, the useful rules were:

Constraints that prevent drift:

• Keep files under 300 lines unless a cohesive module is clearer as one file.
• Put database access in /lib; components do not query the database directly.
• Query key factories, not string literals
• No hardcoded IDs in runtime code

Documentation that grows with the project:

• CLAUDE.md for project context
• _FRAGILE.md for authentication, payments, row-level security, and other changes that require extra review
• _NEXT_SESSION_MEMO.md for continuity between sessions

Session hygiene:

• /wrap at the end of each session to commit and document
• /fragile before touching anything dangerous
• /plan before a nontrivial change that needed review

The setup was intentionally small. Claude Code 2.x already handled much of what earlier prompts tried to teach. Repository-specific context and checks had more value than a general role definition.

---

The Uncomfortable Parts

The speed also exposed four problems.

Review did not keep pace with generation. I produced more code in three weeks than I could read closely in the same period. Tests and TypeScript caught some classes of errors, but they did not close the gap between generation and comprehension.

Implementation ownership became weaker. I designed the architecture and specified the features, but Claude wrote about 70% of the implementation. To trace state through several hooks and context providers, I often had to study the code as work I had not written.

Early patterns spread quickly. Claude applied existing repository patterns consistently. That improved local consistency, but a weak architectural decision could spread across the codebase within hours, before experience exposed its cost.

Debugging began with proposed causes. I described a symptom, Claude proposed causes, and I tested them. This could be faster than tracing from the symptom unaided, but only when I required evidence and rejected plausible explanations that did not survive a test.

---

What I Think This Means

One project cannot establish a general 70-times productivity gain. It does show what becomes possible when implementation throughput rises much faster than review capacity.

Small teams can attempt a wider scope. This application reached production without the team I would previously have budgeted. Whether that reduces total cost depends on later maintenance, support, and rework.

Verification consumes a larger share of the work. Cheap generation produces more code to inspect. Compilation, tests, review, and production evidence still distinguish an implementation from a correct system.

Architecture controls more downstream work. Claude implements an established pattern readily but does not reliably choose the right pattern. Decisions about scope, structure, and invariants therefore affect more generated code in less time.

Maintenance remains unmeasured. The initial build showed generation speed. It did not show the six-month cost of tracing and changing code that I had not fully internalized.

---

Operating Rules

I will require tests or direct inspection before accepting a completion claim. I will understand the architecture even when I did not write the implementation. If I cannot explain why a piece of code exists, I should not ship it.

Faster implementation changes what I can attempt. It does not decide what I should build or what evidence the software needs before release.

---

Links

• The app: judoka.ai
• Marketing site: judoka.blog
• The framework: github.com/jasonhoffman/agentic