How I Build

I code with words. Everything on this site was built by a software company with one human employee. I decide what should exist, describe it as clearly as I can, review what comes back, and keep working through it until it does what I meant.

The short version

I spent more than a decade managing developers: writing specs, reviewing plans, making calls, holding people accountable for shipping. It turns out that's exactly the skill set for running AI agents. I didn't learn to program. I built an organization.

Fair warning: this system is very much a work in progress. But it's also, ultimately, the most fundamental thing I'm building (probably the thing I'll be proudest of) because it's the foundation everything else on this site gets built on, and everything I'll build in the coming years.

How the orchestration actually works

A typical job starts with a plain-English ask: "Create a daily digest, laid out like a newspaper, that aggregates all the newsletters I already subscribe to. Have it identify the most important stories and summarize them, so I only have to read one thing." That ask becomes a spec, then a design, then a build, then a run of tests against the original promise. The agents do the production work. I make the decisions that have to survive each handoff.

The core is a small fleet of AI agents with defined roles, the way a real team has defined roles: a strategist I think out loud with, an architect who reviews every plan and design before anything gets built, a coordinator who owns the project tracker and keeps the timeline honest, and an implementer who writes the actual code. Beneath those sit about two dozen specialist personas (accessibility auditor, API tester, backend architect) that get pulled in when a task calls for them.

Work moves through the system the way it moves through a company. Everything starts as a written spec in a standard format; the architect reviews it; the implementer builds against it; the tracker records what's in flight, what's decided, and what's blocked. The agents even brief their successors: when a session ends or runs out of memory, the system writes a handoff note so the next session starts knowing where things stand, because an agent with amnesia is just as dangerous as an employee who never reads their email.

And because a foundation is only as good as its failure plan, the whole thing backs itself up four different ways, every day, without me thinking about it.

None of this was invented in a vacuum. Open-source projects like NTM (a multi-agent orchestration tool that does much of what this system aspires to) served as a reference throughout; I borrowed patterns from it here and there rather than adopting it wholesale, because the point of this build is that the system fits how I work.

What makes it actually work

• Specs are the product I make. Every build starts from a written spec in a standard format. If I can describe it precisely, the fleet can build it. My job is precision in English.
• Rules live in code, not in prompts. Early on I learned that telling an AI "never do X" is a suggestion, not a guarantee. So the guardrails that matter are enforced programmatically (checks the system literally cannot skip) instead of hoping an instruction is remembered.
• Everything is tracked. A ledger of what's in flight, what's decided, and what's blocked, because work that isn't tracked quietly disappears, whether your team is human or not.
• Verification against the spec. Things get tested against what was specified before they count as done. "It looks right" is not a state in this system.

The pain points, honestly

Managing agents feels uncannily like managing people, with the same failure modes at higher speed. Work stalls silently if nobody owns follow-up: I once lost nearly two days of progress to a task that everyone assumed someone else was watching. Two builders will happily duplicate each other's work down to the byte if the tracker doesn't stop them. Instructions written in plain language get ignored under pressure, which is why every rule that actually matters is now enforced in code the system cannot skip, rather than in a prompt it might not honor. And the costs will surprise you: I've had to diagnose runaway token consumption the way an ops team diagnoses a memory leak, finding the hooks and scheduled jobs quietly burning budget in the background.

The difference from managing people: with agents, every management lesson can be turned into a system the moment you learn it. That's why this thing compounds.

What's next

The next thing on the line isn't for the factory; it's for the people the factory serves. As Income Factory takes on real users, it needs real customer support: onboarding them, answering the questions, catching confusion before it turns into a cancelled account. A little of that plumbing exists already. A lot of it doesn't yet, and support is the classic thing you underbuild right up until the day it's on fire.

Naturally, my instinct is to run it the way I run everything else here: as a system, not a hero with an inbox. I admire what Bret Taylor is building at Sierra, and I'm learning what I can from how they do it.

That, for now, is the shop. The crew that runs it clocks out somewhere.

▸ Shall we play a game?