Projects

The problem

Working alone, there is no second pair of eyes. With AI assistance the bottleneck moves: producing code stops being the hard part, and keeping it consistent, reviewed and explainable becomes it. Unsupervised assistants drift from the conventions of the codebase, re-solve problems that already have an answer, and leave decisions undocumented.

I treated that as an architecture problem rather than a prompting problem. The answer was a system with roles, contracts and gates, in which the AI is the workforce and the governance is mine.

What I built

• Seven specialized roles, each with a written contract and a briefing pack: an architect that plans and never edits code, an implementer that executes a locked plan and surfaces every deviation before acting, a reviewer that returns an explicit verdict, plus project-manager, product-owner, guideline-architect and issue-editor roles.
• Guidelines for them to work under: per-layer and cross-cutting convention documents, each split into its rationale, its rules with stable identifiers, its open backlog and its change log. Amendments go through a formal request-for-changes process, and structural decisions are recorded as Architecture Decision Records.
• An autonomous factory in CI: labeling an issue triggers a GitHub Actions workflow that runs architect, implementer, reviewer and a fix loop inside an isolated git worktree. Stages exchange schema-validated JSON, deterministic gates check types, lint and schema conformance, and when the pipeline is unsure it escalates by commenting on the issue, then resumes from my answer. The output is a pull request I review.

What the evaluation showed

The factory was evaluated against its own run history rather than against impressions. In that first window, every one of the 54 pull requests it opened was merged, and none was reverted. About 40% of runs failed, and reading the traces showed that almost none of those failures came from the model: they were orchestration defects, including a cache permission change on the platform that silently broke resumption, and the absence of a clean exit for runs that correctly concluded there was nothing to do. Both went into a hardening iteration.

The same discipline decided where not to use AI. Asked whether the agents needed retrieval-augmented generation over the codebase, I measured the corpus, wrote the decision record, and adopted embeddings for one narrow job — finding conceptually duplicate issues — while rejecting a vector database outright at this scale. Code is better served by exact search, and a hand-written rule index beats a probabilistic one when every claim has to be citable.

Why it matters beyond my own project

Every mechanism in it has a human equivalent: a definition of done, a review gate, an architecture decision record, a convention that changes only through a documented proposal. That is the point. The system was shaped for one product, and applying it elsewhere means redoing the discovery and rewriting the conventions for that codebase, not copying files. What transfers is the method, and the judgment about which parts of an engineering process should never be delegated.

Architecture

A React Native and Expo client in TypeScript over a Supabase backend, roughly 730 source modules and 70,000 lines, organized in explicit layers: domain logic, services, a server-state layer, hooks, and components. Each layer has a convention document that states what it may depend on, which is what keeps a codebase this size navigable when one person carries all of it.

The database holds 44 tables with the constraints, functions and triggers that enforce the rules the client must not be trusted with. Messaging is realtime, and the interface is internationalized from the data layer up rather than translated afterwards.

The decision that shaped it

The proof of concept ran on Firebase and Firestore. It worked, and I moved off it anyway. Two things decided it: the pricing model charges per read and the document model encouraged fetching more than each screen needed, which together made a near-zero-cost launch implausible at any real user count; and the domain had turned out to be strongly relational, with travelers, trips, destinations, preferences and relationships all cross-referencing each other.

Migrating early, while the cost of moving was measured in weeks rather than quarters, was the cheapest version of that decision. The schema was redesigned around a generic publication model, where a trip is one kind of publication, so that other content types can be added without reshaping what already exists.

Quality and delivery

• 6,746 automated tests across 370 suites, with about 96% statement coverage, gated per path under a policy that a threshold may be raised but never lowered to make a red run green.
• Pre-commit hooks and a two-job pipeline that separates lint and typecheck from tests, so a green lint never disguises a red suite.
• Over 140 merged pull requests and more than 530 closed issues, tracked in GitHub Projects against a milestone-gated launch roadmap.
• Structural choices recorded as Architecture Decision Records, including the one above, and large refactors run as numbered waves that each leave the application shippable.