Building fast is the easy half: notes from a month of 80 million tokens

Short answer: AI made GuardianStack far cheaper to build. It did nothing to make customers easier to reach. Once anyone can rent the same frontier model, the question stops being “can you ship?” and becomes “can you get in front of the people who need it?” We have been running GuardianStack on real token volume lately, north of 80 million in the past month, and two things fell out of that. Spend the money on infrastructure so compute buys finished work instead of extra turns. And treat distribution as the problem that is still sitting there after every model upgrade.

The numbers that forced the conversation

Here is what my personal AI usage looked like over a recent 30-day window:

• Favourite model: Opus 4.8
• Total tokens: ~80.9 million
• Sessions: 333
• Active days: 26 of 30
• Longest session: 5 days, 4 hours
• Current streak: 18 days

For scale, that is roughly 1,200 times the length of Slaughterhouse-Five, and all of it inside a single month. Not because I am writing a novel. Because I am building a compliance product, running autonomous dev loops, and trying to get a system to improve itself.

None of that volume is for show. It is what it costs to run like a small team when you are, in practice, one founder with a stack of agents. The question was never whether to use less AI. Coinbase asked the better version of it: how do you let usage grow without letting waste grow at the same rate?

What Coinbase got right (and why it maps to a solo builder)

Coinbase reported cutting AI spend by nearly 50% while token usage kept climbing. They did not do it with caps or guilt. They changed the default path, with five infrastructure moves rather than five new policies.

We are not Coinbase, and we do not run a company-wide LLM gateway yet. The pattern still holds. Make the efficient thing the default, so nobody has to be lectured into it.

What we are doing in GuardianStack: the Dev OS loop

GuardianStack runs on two axes:

• The product axis: a self-improving compliance OS for UK SMEs (GuardianBot, deterministic trust layer, cite-or-fail gates).
• The dev axis: a Dev OS of agents, harness, loops and memory that autonomously build the product, safely and to spec.

The Dev OS is how I stop every agent session starting from zero. Its thesis is RION: codified human capital multiplied by token capital. Anyone can rent Opus. Very few people have written down how to point it at UK compliance product work, wired that judgement into hooks and manifests, and then run serious compute through it for months.

Here is how the Coinbase playbook looks once you shrink it to founder scale:

1. Model routing instead of “always Opus”

We enforce a three-eyes model. Opus plans and reviews architecture, Sonnet builds in an isolated worktree, and cheaper models do research where they can. One rule sits above the rest: never let the same model write a change and then approve it. We added that after an agent quietly marked its own work as safe. That can never be allowed to pass.

My dashboard says Opus 4.8 is my favourite model, and that is true when the work is judgement. It should not be true for every file edit. Pretending otherwise just burns tokens.

2. Mechanical routing, not vibes

A dev capability manifest maps each kind of work (a backend change, a GuardianBot quality loop, a docs round) to the exact skill pack, gate and definition of done. A hook injects that context when the session starts, so a fresh agent does not have to guess which of 23 live skills to load. Skill selection becomes a lookup instead of a guess.

Coinbase routes at the gateway. We route at the harness. Same idea, much smaller scale.

3. Lean context and fewer turns

We run loop-doctor at the end of a session. It is a dev-process check-up that opens with a token-efficiency read: redundant file re-reads, oversized context, Codex rounds chasing polish long after the bar was met. Whatever it finds gets wired in as a hook, because automatic enforcement sticks and memory notes usually get ignored. The order of preference is deliberate:

HOOK  >  script  >  rule  >  memory note

The rest is habit: one agent, one worktree; scoped tasks; a clear handoff before wiping a session, so the next one does not have to rediscover branch rules and production traps from scratch.

4. Loops that stop when the work is done, not when I am

Both the product and dev sides run the same shape: run, score, fix, re-run until a typed bar is met.

• Product: GuardianBot conversation quality has to hit a defined soft bar (median ≥ 9, p10 ≥ 8) before I treat a slice as done.
• Dev: deterministic gates first (build, lint, typecheck), then an independent certifier, with a Codex round budget so stamp-thrashing cannot quietly eat a weekend.

The point is better output in fewer turns. A five-day session is as much a warning sign as a badge of commitment, and I try to read it that way.

5. Visibility without shame

We log friction events, publish a Dev OS maturity scorecard (about 7/10 today, scored honestly), and regenerate the blueprint state from real files, so the numbers are read from the repo rather than invented by an LLM. Coinbase wants org-wide dashboards. I want founder-grade receipts I can actually show.

“The loop builds the product, and the loop builds the loop.”

I keep that line around because it is less a tagline than a description of how the work actually runs.

Efficiency is the easy half

This is the part I am least comfortable with, and the part most worth sharing.

AI is a genuine leveller on the build side. A non-technical founder with disciplined agents, a spec-first culture and months of encoded judgement can ship infrastructure that would have needed a small team five years ago. Product creation has tilted towards people who can orchestrate, not just people who can type syntax.

But building only gets you to the start line. In a crowded category, and compliance software is crowded with fear-based marketing and black-box wrappers, distribution is what decides who compounds.

The incumbents who already own trust channels can flip this on you. Accountancy networks, app-store rankings, agency relationships and regulator-adjacent brands can bolt AI onto distribution they already hold and move faster than a pure builder expects. Those of us who gained the most from AI still face the slow, unglamorous work: finding customers who genuinely feel the problem, in a channel that reaches them, with a message they believe.

For GuardianStack today:

• Year 1 focus: UK Shopify merchants (Cohort A), reached through the App Store, content and reputation-led readiness rather than fine-fear headlines.
• Live proof surface: data protection and ICO obligations on Shopify, not the whole of compliance yet.
• Honest state: we are still learning which merchants feel the pain sharply enough to act. That is not failure. It is what a beta actually looks like. AI shortened the build cycle for us. It did nothing to shorten customer discovery.

The strategic flip I keep coming back to:

We are betting on the third row, knowing full well that row two is the default trap for AI-native startups.

What we are not claiming

• We have not built a Coinbase-scale LLM gateway. Our optimisations live in the harness, the hooks and the loop design.
• Our Dev OS is about 7/10. It is strong on roles and rules and still hardening the certifier boundary that is meant to be unforgeable.
• Our product self-improvement loop is real but young. Dev-time autonomy is running ahead of merchant-facing compounding.
• Distribution is an ongoing task, not a solved slide in a deck.

Those gaps are exactly why this essay exists. Building in public should include the GTM grind, not just the architecture diagram.

The takeaway

Coinbase showed that usage can climb while spend stays flat, once you treat routing, caching and context as infrastructure instead of leaning on people to be disciplined.

We are applying the same logic at founder scale through the Dev OS: codified judgement, model tiering, mechanical skill routing, loop bars and token-aware retros. That is how 80 million tokens turn into a product and a trust layer rather than an expensive chat history.

When every competitor can rent the same model next quarter, the moat was never the model. It is codified judgement, multiplied by disciplined compute, multiplied again by distribution that actually reaches the merchants who care.

So the rule I am trying to hold to is an unglamorous one: use AI to shorten the build loop, then spend the time it frees up proving the market cares. Shipping is not the same as winning, and that is easy to forget when the building feels this good.

Run the free public check if you want to see what the product side of this stack produces: about 30 seconds, cited findings, no login.

---