Say it, don’t spray it.

I dictate almost everything now. Ideas, plans, first drafts, feedback on drafts, replies to emails. I talk to computers the way people in the 80s imagined we’d talk to computers. And when I’m really going -- when the idea is right there and I need to get it out -- I spray it.

So the app is called Spray.

---

What I Actually Wanted

I love reading. I’m a reasonably strong writer. What I’m not great at is writing for public consumption -- the part where you take something that’s alive in your head and shape it into something that works on a page for someone who isn’t you.

That process takes me a long time. Longer than I’d like. And for a while I’ve been watching what’s happened in AI-assisted coding and thinking: why doesn’t this exist for writing?

The experience I wanted was specific. Not “AI writes content for me.” Not a better text editor. I wanted something closer to what I get when I’m in a good coding session with Factory Droid -- a genuine back-and-forth where I can think out loud, get pushback, iterate on a draft together, and end up somewhere neither of us would have gotten alone.

I also knew from the start that dictation had to be central to how it worked. I talk way faster than I type. For getting ideas out and doing early iteration, I almost exclusively use voice now. The only times I reach for a keyboard anymore are when I physically can’t talk out loud, or when typing would genuinely be faster than the overhead of dictation setup. (The juice/squeeze calculation is real. Sometimes it’s just three words.)

So I had two things: a clear problem I wanted to solve, and a set of constraints that would shape the solution.

I started building.

---

The Spec Phase (Where the Real Work Happened)

I’ve written before about how the spec is the work. With coding, I’ve found that when I spend serious time planning before any code gets written, the code almost takes care of itself. The inverse is also true: if I rush to code, I end up with something that technically exists but doesn’t do what I actually wanted.

I believed this. And then I built the initial spec for Spray and immediately forgot I believed it.

The first version of my plan had 13 Python files in a nested structure. MagicLink authentication. A multi-user access model. A bunch of infrastructure I was excited about but didn’t actually need.

I ran a technical review through Factory Droid using the compound engineering workflow, and it had opinions. Good ones. The security review caught some real edge cases. But the more useful part was the scope review -- the questions that forced me to articulate who this was actually for and what it actually needed to do.

MagicLink login: who are the users?

Me. I’m the only user.

So you need a multi-user auth system because...?

I don’t. I need a token in an environment variable that keeps the app from being completely open to the internet. That’s it.

The 13-file architecture became four Python files. FastAPI on the back end, plain HTML on the front. No frontend framework. No login system. No unnecessary abstractions between me and the thing I was trying to build. Each cut made the project smaller, clearer, and more likely to actually get finished.

Constraints aren’t limitations. They’re decisions made in advance. Every door you close before you start coding is a door you don’t have to reason about at 11pm when you’re tired and tempted to just add one more thing.

The final stack:

• Python FastAPI backend

• HTML frontend (no framework)

• Deepgram for dictation (fast API, supports custom dictionaries)

• Claude API with a three-model setup: Sonnet 4.5 for daily work, Opus 4.5 when I need to go deep, Haiku when I need something quick

• Railway for deployment, with a Railway volume as the persistent file system

• GitHub as the deployment trigger -- commit, Railway builds the container, done

No magic. Boring in the best way.

---

The Agentic Part (This Is the Bit That’s Actually Different)

Here’s where Spray is something different from a fancier writing tool.

The agent isn’t just responding to prompts. It has tools -- read files, write files, list files -- and it uses them autonomously as part of doing its job. When I give Spray a dictation and ask for a draft, the agent reads the relevant voice profile, reads corpus samples from my existing writing, checks if there are previous drafts of this piece, and then writes something. It’s not working from the context I happen to paste into the prompt. It’s building its own context before it acts.

This is what “agentic” actually means in practice, as opposed to the way the word gets thrown around. It’s not “AI that seems smart.” It’s an AI that takes sequences of actions -- with real tools, against real files -- in service of a goal you’ve given it. The difference in output quality is not subtle.

The file system was important to me for exactly this reason. I wanted the agent to have persistent memory across sessions in a form it could actually use. A Railway volume attached to the container gives it a real directory structure -- voice profiles, corpus samples, project folders, draft files -- that it can read from and write to on its own. Not a database the agent queries through an API. An actual file system the agent can navigate like a collaborator with filing access.

The context layer is where I spent the most time before I wrote a single line of application code. Voice and tone documents for each writing context. Corpus samples from my existing published work. Custom Deepgram dictionaries for each project -- because when I’m dictating something for BishopricOS, I use different vocabulary than when I’m dictating something for Unruly Context, and I don’t want the transcription guessing. Each custom dictionary took some upfront time and paid back immediately in transcription accuracy.

The agent also has skills -- structured instruction files that tell it how to handle specific tasks. How to triage a new dictation and recommend the right output format. How to draft for each of my different newsletters. How to generate derivative social posts once a main post is approved. The skills aren’t just system prompts; they’re persistent files the agent reads when it needs them, so they stay organized and editable without touching any code.

The result is something that feels -- and I want to be precise about this -- like working with a collaborator who has read everything I’ve written, knows what I’m trying to build, and remembers where we left off.

---

What It’s Like to Actually Use It

I’m on my iPad right now. On the couch. This was the specific thing I wanted to be able to do, and it’s working.

The workflow for a new post is: I open Spray, I tap the dictation button, and I talk. The Deepgram integration is fast -- transcription happens in near-real-time, with the custom dictionary doing its job to get the vocabulary right. I review the transcription, occasionally fix a word or two, and submit it to the agent.

The agent triages it -- is this a full post? A short note? Which newsletter? -- and tells me what it thinks before it does anything. If I agree, it goes and does the work: reads the relevant files, drafts something, saves the draft to the project folder. I read the draft, dictate my feedback, and we iterate.

The model switching turned out to matter more than I expected. Sonnet is fast enough for most of the back-and-forth, but when I need the agent to really wrestle with something -- voice calibration on a tricky piece, structure for a complex idea -- Opus earns its cost. And for quick tasks where I just need the agent to check something or run a formatting pass, Haiku is fast enough to feel instant.

The derivative stack is one of my favorite things. Once I approve a main Substack post, I can ask Spray to generate all the social derivatives at once -- the Substack note, the LinkedIn post, the X post, the OG metadata and image prompt. What used to be a multi-session, copy-paste-and-reformat process is now a single conversation. The agent has the context of the main post, knows the platform rules for each derivative, and produces all of them without me re-explaining anything.

---

The Thing That Surprised Me

I went into this expecting the dictation piece to be the revelation. It’s good, and the Deepgram integration works better than I hoped. But the thing that actually surprised me was how different the agentic experience feels from prompting.

When I’m prompting a model -- copying in context, asking for something, copying out the output -- the AI is a tool I’m operating. When the agent has file access and real task structure, it’s a partner I’m directing. The distinction sounds semantic. It isn’t.

The agent tells me when a dictation doesn’t have enough depth for a full post and should be a Substack note instead. It asks clarifying questions before it drafts because it’s read the skill files that tell it to. It saves drafts with consistent naming conventions because that’s in the instructions. It does things I would have had to remember to ask for.

There’s a reason I’m more productive in a good coding session with an agent than I am with a static code assistant. The agent is doing work between my inputs, not just responding to each one. Writing agents can do the same thing, and now I have one.

---

What’s Still Unfinished

The app works. I’m using it daily. But there’s a list.

The mobile experience is fine, but it could be better. I built for “works on iPad” not “optimized for iPad,” and the difference shows up in the small things -- tap targets, the way the dictation button behaves when you’re holding the device sideways. I’ll get there.

I haven’t built the feedback loop yet. Right now, when a post performs well or a draft gets significantly revised before publishing, that learning doesn’t flow back into the corpus or the voice profile automatically. I have to do it manually. That’s fine for now; I’m one person writing for three newsletters. But the system is designed to support that loop, and I’ll build it eventually.

And there are almost certainly edge cases I haven’t hit yet. The technical review caught several before launch, but production always reveals things that testing doesn’t.

That’s not a problem. That’s just what it looks like when a thing is alive.

---

The name is embarrassing in the best way. Every time I open the app I think of a ten-year-old me getting teased for talking too fast and getting too excited.

Say it, don’t spray it.

Sure. But also: say it. Get it out. Don’t let the gap between the idea and the polished draft be the reason the thing never exists.

That’s what Spray is for.

TL;DR:

AI doesn’t forget because it’s dumb. It forgets because you didn’t build a system that remembers.

This post shows how I fixed that using compound engineering and Factory Droid.

I’ve been coding with AI for about 14 months. Many active projects across Python, SvelteKit, Next.js, and FastAPI. I use Factory Droid as my daily driver — it’s where I live. And until today, every single one of those projects had the same problem.

I’d have a great coding session. Ship something real. Feel good about it. Close the terminal. And then when I came back — maybe the next day, maybe a week later — I’d spend the first few minutes trying to remember where I was. What was working. What was broken. What I’d been deciding right before I stopped.

That’s bad enough. But here’s the part that everyone who codes with AI knows and dreads: your AI agent has the same problem, except worse.

When you come back to a project after a week, you’ve at least got fuzzy memories. You remember the general shape of things. The agent remembers nothing. Every new session starts at absolute zero. It doesn’t know what you built yesterday, what patterns you established, what you tried and abandoned, or what decisions you were weighing. You spend the first several minutes — sometimes longer — just getting your AI partner oriented. Pasting in context. Explaining the codebase. Pointing it at the right files. And then halfway through a long session, when the context window compacts, it can forget again. You’re re-onboarding your own tool multiple times per session. 50 First Dates, but with a bot.

I’m a big believer in good documentation. I’m just not great at remembering to write it. And here’s the uncomfortable realization: in AI-assisted development, documentation isn’t just a nice-to-have for future-you. It’s the operating system for your AI partner. Without it, you’re hiring a brilliant contractor who shows up every morning with total amnesia.

That’s the knowledge decay loop, and it hits both sides of the partnership. Every productive session that ends without documentation is a loan against your future self and your future agent — with interest.

Today I read Every’s guide on compound engineering, and something clicked. This wasn’t just a system for organizing my own memory. It was a system for giving my AI partners the context they need to be useful from the first line of every session.

What Is Compound Engineering (And Why Should You Care)

The core idea is almost offensively simple: every unit of work should make subsequent work easier, not harder.

Most codebases get harder to work with over time. Each feature adds complexity. After enough cycles, you’re spending more time fighting the system than building on it. Compound engineering inverts this. Bug fixes eliminate categories of future bugs. Patterns become tools. The codebase gets easier to understand, not harder.

The mechanism is a four-step loop: Plan → Work → Review → Compound.

The first three steps are normal engineering. It’s the fourth that changes everything. After you ship, you capture what worked, what didn’t, and what the reusable insight is — then you feed it back into the system so the next cycle starts from a better position. Skip the compound step and you’ve done traditional engineering with AI assistance. Do it, and the system learns.

Every built a plugin for this — 26 specialized agents, 23 workflow commands, 13 skills — and shipped it for Claude Code. I don’t use Claude Code. I use Factory Droid.

So I made it work anyway. Here’s how.

Installing the Plugin (The Easy Part)

Factory Droid’s docs explicitly state Claude Code plugin compatibility. The install is two commands:

droid plugin marketplace add https://github.com/EveryInc/compound-engineering-plugin
droid plugin install compound-engineering@compound-engineering-plugin

Note that second command — you need the plugin@marketplace format. If you just run droid plugin install compound-engineering, you’ll get an error about invalid plugin format. The marketplace name is compound-engineering-plugin(the repo name), so the full identifier is compound-engineering@compound-engineering-plugin.

You’ll see something like:

Successfully installed compound-engineering@compound-engineering-plugin (e8f3bbc)

That hex string is the Git commit hash Droid pins to. You can verify the install by running /plugins inside a Droid session and checking the Installed tab — you should see the plugin with user scope, today’s date, and a cache path.

Great. Plugin installed. Now try running /workflows:plan.

Nothing happens.

The Gotcha (way to be non-standard, you Droid user you)

The plugin installs cleanly. It shows up in your installed plugins list. But the slash commands don’t register. Type /plan or /workflows:plan and Droid has no idea what you’re talking about.

This is a known issue — GitHub issue #31 on the compound engineering plugin repo. The root cause: the plugin’s command structure uses nested directories (commands/workflows/plan.md), and Droid doesn’t auto-register commands from plugin subdirectories the way Claude Code does. The plugin format is compatible, but the command discovery isn’t.

The fix is manual, and it takes about two minutes.

First, find where Droid cached the plugin:

ls ~/.factory/plugins/cache/compound-engineering-plugin/compound-engineering/

You’ll see a directory named with the commit hash from your install. Inside it:

CHANGELOG.md  commands/  droids/  LICENSE  README.md  skills/

Good news: the plugin already uses droids/ instead of agents/, so the naming matches Factory Droid’s conventions. Now copy everything to your user-level Droid config:

mkdir -p ~/.factory/commands ~/.factory/droids ~/.factory/skills

cp -r ~/.factory/plugins/cache/compound-engineering-plugin/compound-engineering/[hash]/commands/* ~/.factory/commands/
cp -r ~/.factory/plugins/cache/compound-engineering-plugin/compound-engineering/[hash]/droids/* ~/.factory/droids/
cp -r ~/.factory/plugins/cache/compound-engineering-plugin/compound-engineering/[hash]/skills/* ~/.factory/skills/

Replace [hash] with the actual commit hash directory name.

Restart Droid. Type /plan. It autocompletes. You now have /plan, /work, /brainstorm, /deepen-plan, /technical_review, /document-review, and everything else — registered as top-level commands. The workflows:namespace prefix gets dropped, which is actually cleaner for daily use.

That’s the entire technical setup. Everything from here is about making it actually useful.

The Foundation: Your Engineering Constitution

A plugin gives you commands. But commands without context produce generic results. The thing that makes compound engineering compound is the context — the accumulated knowledge about how you work, what you care about, and what your projects look like.

That context lives in two places.

Global AGENTS.md

Factory Droid reads ~/.factory/AGENTS.md at the start of every session across all your projects. Think of this as your engineering constitution — the baseline expectations that apply everywhere, regardless of which project you’re in.

Mine includes:

A Session Protocol. The agent reads docs/STATUS.md at the start of every session and updates it at the end. If I forget, it reminds me. This single habit solves about 80% of the “where was I?” problem.

Test-Driven Development as a core methodology. Write tests first, always. The agent is instructed to pause me if I jump into implementation without tests. More on this later — there’s a story here.

A security baseline. Input validation, parameterized queries, secrets in env vars, auth on every endpoint. I listed security as a growth area in my AGENTS.md because it is, and I’d rather the agent be proactive about it than wait for me to ask.

The compound engineering loop itself, with TDD included. Plan → TDD → Work → Review → Compound, with specific instructions for each step. The agent knows the sequence and knows not to skip the compound step.

Communication preferences. Speak at a systems level. Explain your reasoning. If there’s a better architectural approach, propose it — don’t just implement what I asked for.

The global AGENTS.md provides defaults. Each project has its own AGENTS.md in the project root that adds project-specific patterns, stack details, and lessons learned. Project-level takes precedence when they conflict.

STATUS.md (The Session Continuity System)

Every project gets a docs/STATUS.md that answers five questions: What’s the project? What’s done? What’s in progress? What’s next? What decisions are pending?

That last one — Open Decisions — is the most valuable section. “What was I building” is recoverable. You can look at the code, read the commit history, figure it out. But “what was I deciding and which way was I leaning” — that vanishes completely between sessions. If you’re weighing two approaches to auth and you close the terminal without documenting your reasoning, future-you either reverse engineers or repeats the process. Let’s not do that, shall we?

I built a slash command called /init-project-docs that bootstraps the entire docs structure for any project. Run it once, and the agent creates docs/STATUS.md (auto-populated from your README and package.json), plus empty directories for plans/, solutions/, decisions/, and brainstorms/. Under 30 seconds, and you never have to remember the template structure.

The First Real Test: BishopricOS

Theory is great. Does it actually work?

I took this system into BishopricOS — a Notion-based operating system for church leadership that I’m rebuilding as a standalone web app. I needed to add a wiki feature: sections, pages, version history, public sharing, the works.

Brainstorm → Plan → Deepen-Plan: The Best Planning I’ve Ever Done

I started with /brainstorm because the requirements were fuzzy. I knew I wanted a wiki. I didn’t know exactly what that meant for this app, this user base, this tech stack. When you’re building for volunteer church leaders who rotate every few years, “wiki” doesn’t mean the same thing as it does for a developer team.

As always, I started by dictating as much context as I could. I use VoiceInk for this (though MacWhisper is also excellent). I’ve had amazing results when working with AI coding partners when I dictate much more than I type, especially during brainstorming and planning. (And let’s be real--it makes me feel like I’m on Star Trek to just talk to the computer.)

The brainstorm command asked me targeted questions after I gave it my dictation dump — one at a time, not a wall of twenty — about purpose, users, constraints, and edge cases. Who creates content? Who reads it? Does content need to be public or just internal? By the end, I had clarity I wouldn’t have reached by just thinking about it, because the questions forced me to confront decisions I was unconsciously deferring.

Then /plan. The agent researched the existing codebase — not just the file structure, but the patterns I’d already established. It found my Prisma schema conventions, my API route structure, my auth patterns with Clerk. And it produced a structured implementation plan that actually matched how the rest of the app was built. This is the part that surprised me most. It wasn’t generic “here’s how to build a wiki” advice — it was “here’s how to build a wiki that fits this specific codebase.”

I pushed back on scope. “This is too much for one session — break it into phases.” It restructured into six phases: database models and CRUD API first, then Tiptap editor integration, drag-and-drop ordering, public page routes, version history UI, and search. Each phase buildable and shippable independently. That kind of progressive disclosure is hard to do well, and I would have been tempted to build it all at once and end up with something half-finished.

Then /deepen-plan. This is where it got genuinely impressive. The command spawns 40+ parallel research agents that go deep on the plan — checking framework docs for SvelteKit-specific patterns, looking for best practices around wiki-style content management, analyzing edge cases I hadn’t considered. Things like: what happens to public share links when a page is deleted? How should version history interact with the wiki section hierarchy? Should page slugs be auto-generated or user-defined?

The plan that came back was significantly better than what I would have written myself. Not because I couldn’t have gotten there eventually, but because I would have skipped half the research and gone straight to building. I would have discovered those edge cases in production, filed mental notes to fix them later, and either never gotten back to them or interrupted the flow of the work by trying to fix things right away rather than sticking to the plan. (That’s my kryponite. Always finding ‘little things’ that will only take a moment to fix. Sure! That’s exactly how it always works. Promise.) The plan caught them before a single line of code was written.

This was the single highest-value part of the entire system. The 80/20 rule from compound engineering is real — 80% of the value is in planning and review, 20% is in execution. When the plan is right, the code practically writes itself. When the plan is wrong, all the AI-assisted coding speed in the world just gets you to the wrong place faster.

Technical Review: Parallel Skepticism

After implementation, /technical_review spawns a dozen specialized agents that review the code simultaneously — security, performance, architecture, data integrity, code simplicity. Each returns prioritized findings: P1 (must fix), P2 (should fix), P3 (nice to fix).

I’ll be honest: I expected this to be the least useful step. I’d already reviewed the code during implementation. The tests passed. What else was there?

A lot, as it turns out. It caught real issues at every stage. Auth boundaries that weren’t tight enough on the wiki page deletion endpoint — a user could potentially delete pages in sections they didn’t own by manipulating the API directly. A database query pattern that wasn’t properly scoped to the current tenant, which in a multi-tenant app is the kind of bug that causes you to want to become a tech-free monk. Performance concerns about how version history was being loaded (fetching all versions when only the latest was needed for the default view).

None of these were things I would have caught in my own review. Not because I’m careless, but because I was thinking about whether the feature worked. The review agents were thinking about whether it was safe, fast, and correct at the edges. Different questions, and both matter.

The graphic I made for this post labels the space between /work and /technical_review as the “Knowledge Decay Zone” — that’s the gap where you’ve built something and it feels done, but you haven’t stress-tested it yet. Lots of bugs that ship to prod in that gap.

The compound engineering guide suggests asking three questions before accepting any AI output:

1. “What was the hardest decision you made here?”

2. “What alternatives did you reject, and why?”

3. “What are you least confident about?”

These are incredibly effective. The agent knows where its weak points are. It knows which parts of the implementation were judgment calls. But it won’t volunteer that information unless you ask. These three questions are the magic pixie dust for getting honest answers from your AI coding partner.

The TDD Gap

Here’s where it gets interesting. After Phase 1 of the wiki feature shipped, the summary reported “All 366 existing tests pass.” That sounds great. But 366 was the number I started with. No new tests were written for the new feature. The agent built the wiki, verified nothing else broke, and called it done.

The compound engineering loop has Plan, Work, Review, and Compound. It doesn’t have a dedicated TDD step. And my global AGENTS.md says “write tests first” — but the slash commands don’t enforce it. The system had a gap.

So I built /tdd.

It’s a custom slash command that bridges /plan and /work. After you approve a plan, /tdd reads it, identifies every testable behavior — API responses, auth boundaries, database operations, edge cases — presents a test plan for your approval, then writes tests that all fail. Every single one. That failing state is your starting line. Then when you run /work, the agent implements until those tests go green.

The key safeguard: if any new test passes before implementation, it flags it — because that means the test is either redundant or not testing what it claims.

The updated loop:
/plan → /tdd → /work → /technical_review → /compound

This was compound engineering compounding on itself. I used the system, found a gap, built a fix, and now every future session benefits. That’s the whole point.

The Cheat Sheet

This is what I keep open during coding sessions now. The full daily reference.

The Loop (Every Feature)

Step 1: /plan [feature]
Research codebase + create implementation plan

Step 2: /tdd
Generate failing tests from the plan

Step 3: /work
Agent implements until tests go green

Step 4: /technical_review
Multi-agent code review (security, perf, architecture)

Step 5: /compound
Capture what was learned, don’t skip this

Session Discipline

Start: Agent reads docs/STATUS.md, orients you in 30 seconds.

End: Agent updates docs/STATUS.md. Run test suite. Run /compound if you solved something non-trivial.

Other Commands Worth Knowing

/brainstorm
Use this when requirements are fuzzy and you need to explore before committing to a plan.

/deepen-plan
When the plan exists, but needs real depth. Spins up parallel research agents to fill in the gaps.

/document-review
Review brainstorms or plans for clarity, gaps, and contradictions before execution.

/triage
Walk through review findings one by one instead of trying to hold everything in your head at once.

/changelog
Generate a changelog from recent merges without reconstructing history manually.

/lfg [feature]
Full autopilot: plan → build → review → PR.
For when you’re feeling bold and the safety nets are in place.

Key File Locations

~/.factory/AGENTS.md
Global agent configuration. Applies to all projects unless explicitly overridden.

~/.factory/commands/
Your custom slash commands. This is where workflow discipline actually lives.

~/.factory/droids/
Specialized sub-agents with narrow responsibilities and opinions.

~/.factory/skills/
Domain expertise the agents can reuse instead of relearning every project.

./AGENTS.md
Project-level configuration. Overrides global defaults when they conflict.

./docs/STATUS.md
Current project state.
Read this first. Update it last. Future You is counting on it.

./docs/plans/
Implementation plans generated by /plan and refined by /deepen-plan.

./docs/solutions/
Solved problems. This is the compound interest account.

What This Actually Cost

Total setup time: about 45 minutes from zero to a working system. That includes the plugin install, troubleshooting the command registration issue, creating the global AGENTS.md, building the STATUS.md template and /init-project-docscommand, and building the custom /tdd command.

45 minutes of setup. The first coding session after that was the best I’ve ever had. Not the most productive in terms of lines of code (which is a dumb way to measure productivity, at least in my opinion) — the planning took longer than I’m used to. But the output was better than anything I’ve shipped from a single session. Tested, reviewed, documented, and with a clear path to the next phase. No knowledge debt. No “I’ll document this later.” No future-me cursing past-me for leaving him with nothing.

The Point

Here’s the mental model that ties it all together.

Compound engineering treats AI-assisted coding as a knowledge multiplier, not a speed multiplier. Each session doesn’t just produce code — it produces plans, tests, review findings, and documented solutions that make the next session start from a higher baseline. The code is a side effect. The system is the product.

The difference between “I built a wiki feature today” and “I built a wiki feature today and my project now has better documentation, a tested API surface, reviewed security boundaries, and a searchable record of how I solved the tricky parts” — that difference compounds. Three months from now, the second version of you is operating in a fundamentally different universe than the first.

Each cycle makes the next one easier. That’s the whole game.

The compound engineering plugin is built by Every. The guide is at every.to/guides/compound-engineering. The plugin repo is at github.com/EveryInc/compound-engineering-plugin. Factory Droid’s plugin docs are at docs.factory.ai/cli/configuration/plugins.

This post was co-written with Claude. The code was co-written with Factory Droid, using Opus 4.5. (’cmon Factory team, I want to use the shiny new Opus 4.6 already!) The graphic was designed with Nano Banana Pro. The system that made it all work was Every’s compound engineering. Turtles all the way down.

Three people. All great. Any of them could go first, second, or third. There’s the usual caveat: the person who goes last is sometimes seen as the most important, but they also risk getting their time squeezed if earlier speakers run long. (Which, incidentally, is exactly what happened.)

These were people of equal seniority in this context. A simple decision. The kind of thing a normal person would resolve in thirty seconds.

But I’m neurospicy, and one of the things I’ve learned about my brain is that low-stakes decisions with no clear “right answer” are exactly where I get stuck. I’ll ruminate. I’ll weigh factors that don’t matter. I’ll think about it again tomorrow.

I didn’t want to do that. I wanted something slightly better than a coin toss—without having to think about how many coin tosses it takes to fairly order three items. (It’s more than you’d think, and now I’m already down a rabbit hole.)

So I did what any reasonable person would do: I built a web app with six different randomization visualization engines.

Meet RandoMatic 3000.

The point isn’t the tool

Here’s the thing: I didn’t even use RandoMatic 3000 to make the speaker decision. By the time the tool was done, I’d already figured it out the old-fashioned way.

But now the tool exists. It’s live. It works. Other people have used it. And I practiced an entire zero-to-one workflow that I’ll use again on projects that actually matter.

This is the part that’s hard to explain to people who think building is about outcomes: sometimes the tool isn’t the point. The process is the point. The having-a-thing-that-exists is the point. The muscle memory of shipping is the point.

RandoMatic 3000 is aggressively over-engineered for what it does. Six visualization engines? Statistical trial mode? Dark/light mode toggle? For picking names out of a hat?

Yes. Because it was fun. Because constraints make projects interesting. And because I wanted to see if I could go from “vague idea” to “live on the internet” in a single working session using AI as my coding partner.

I could. Here’s how.

Start with the end, not the code

Before I wrote a single line of code—before I even opened a terminal—I spent time thinking through three things:

1. Desired outcomes. What does “done” look like? In this case: a working web app that randomly orders or selects from a list of items, with some visual flair, accessible to anyone with the link.

2. User stories. How will someone actually use this? They’ll land on a page, enter some items, pick a visualization style, and get a result. No accounts, no setup, no friction.

3. Constraints. This is the most important part, and the one most people skip.

Constraints aren’t limitations—they’re decisions made in advance that prevent scope creep and make the project actually shippable. Here’s what I decided:

• Single-page web app. No multi-page routing.

• No backend. Everything runs in the browser.

• No login system. Anyone with the link can use it.

• Single GitHub repository, deployed to Netlify.

• HTML, CSS, JavaScript. React for the UI.

• Test-driven development from the start.

Each constraint closed a door. And every closed door made the project smaller, clearer, and more likely to actually get finished.

This isn’t a software-specific insight. It applies to anything you’re trying to get from zero to one: the clearer you are about what you’re not doing, the easier it is to do the thing you aredoing.

Talk before you type

Once I had the constraints and outcomes clear in my head, I did something that might seem old-fashioned: I talked it out.

I use an app called MacWhisper—it runs OpenAI’s Whisper model locally and transcribes speech to text. I opened it, hit record, and just... talked through everything. The goals, the constraints, the user stories, the things I wasn’t sure about.

A few minutes of rambling became a text file. That text file became the context I fed to my AI coding tool.

This is one of the most important things I’ve learned about working with AI: the quality of the context determines the quality of the output. If you give an AI coding agent a vague prompt, you’ll get vague code. If you give it a detailed, thoughtful description of what you’re building and why, you’ll get something much closer to what you actually want.

Dictation is my way of getting the messy thinking out of my head and into a format the AI can use. It’s faster than typing, and it captures nuance I’d otherwise edit out.

The technical bit (feel free to skip)

If you’re not interested in the specifics of AI-assisted coding workflows, jump to the next section. The principles above and below are the transferable parts.

My AI coding setup for this project:

Tool: Factory Droid (though Claude Code works similarly). I like Factory Droid because it gives me access to multiple models under one account—Claude Opus 4.5 for heavy lifting, Gemini Pro for UI polish, OpenAI Codex for quick fixes—and their context management is excellent. Long sessions don’t require constant re-prompting after context compression.

Process:

1. Created a new directory, opened my terminal, launched the AI agent.

2. Pasted in my entire pre-specification dictation—goals, outcomes, constraints, user stories, everything.

3. Switched to Spec/Plan mode(Shift+Tab in Factory Droid, “Plan Mode” in Claude Code). This is crucial. In this mode, the AI researches and plans but doesn’t write code yet. You collaborate on the specification together.

4. Went back and forth several times on the spec. Each time the AI proposed a plan, I’d tweak it—clarifying epics, adjusting scope, adding constraints I’d forgotten. The goal is painful clarity before any code gets written.

5. Once the spec was solid, I approved it and let the AI start coding.

Why this matters: The spec phase is where most of the real work happens. I’d estimate a third of the total effort was pre-spec thinking, a third was spec refinement, and only the final third was actual coding and testing. Most people invert this ratio—they jump straight to code and wonder why projects get messy.

On testing: I always use test-driven development, even for small projects. Here’s why: I don’t read every line of code the AI writes, but I do read every line of the tests. If the tests are well-written and they pass, I have high confidence the code is solid. Tests are my verification layer.

On documentation: I keep an AGENTS.md file updated throughout the project. This makes it easy to switch models mid-session or pick up where I left off later. Good documentation is context you don’t have to re-explain.

The real work is testing

Here’s something that surprised me when I started working with AI coding tools: the coding part is actually kind of boring to watch. Files get created. Tests run. Servers spin up. It’s impressive the first few times, then it’s just... waiting.

The real work—the part that requires human judgment—is testing.

You have to test manually, as early as possible, as often as possible. You’ll find things that are completely broken, things that are subtly wrong, and things that technically work but feel off when you use them.

This is normal. This is how software gets built. The bugs aren’t failures; they’re the work revealing itself.

With RandoMatic 3000, the first bugs I found were UI issues. Elements in weird places. Layouts that didn’t make sense. I made a wireframe—and by “wireframe” I mean I drew a crude sketch on paper and took a photo—and showed it to the AI. Changes were made. Some tests broke. We fixed them.

Then I moved to end-to-end testing. I went to ChatGPT and asked for 15 different scenarios: “ways to pick the order for speakers at an event.” I dictated the context, got back a list of test cases—some good, some silly—and worked through them. Names that looked like code. Names in different languages. Edge cases that might break things.

Each round of testing surfaced more bugs. Each bug got fixed. This is the loop.

The great thing about AI as a coding partner: it doesn’t get tired, doesn’t get defensive, and doesn’t complain when you send something back for the fifth time. You can be as demanding as you need to be.

Ship before it’s perfect

When I felt reasonably good about the state of things, I pushed the code to GitHub and connected the repo to Netlify. A few minutes later, I had a live URL I could share.

I found more bugs immediately. Fixed them. Pushed again.

This is the part that trips people up: you have to ship before it’s perfect, because “perfect” is a state you discover through contact with reality, not through more planning.

RandoMatic 3000 isn’t perfect now. There are probably edge cases I haven’t thought of. Features I could add. Polish I could apply.

But it’s done enough. It exists. It works. People can use it.

That’s the bar for zero-to-one work: not “is it flawless?” but “does it exist and do the thing?”

What I actually learned

The tool was way more than I needed for a three-person speaker order decision. But building it taught me (or re-taught me) a few things:

Constraints are gifts. Every door you close in advance is a decision you don’t have to make later. “No backend” and “no login” turned a potentially sprawling project into something I could finish in a day.

The spec is the work. Two-thirds of the effort happened before any code was written. If you’re struggling to finish projects, you might be under-investing in the planning phase.

AI is a partner, not a replacement. I read every test. I made the wireframe. I did the manual testing. I made all the judgment calls. The AI wrote code; I made decisions.

Testing is where building actually happens. The first version is never right. The iteration loop—test, find bugs, fix, repeat—is the real process.

Sometimes the tool isn’t the point.I didn’t use RandoMatic 3000 for the original decision. But I have the tool now, I practiced the workflow, and I have something to share. That’s three wins from one silly project.

The links

• RandoMatic 3000 — try it yourself

• GitHub repo — see how the sausage was made

One question for you

I’m curious what this sparks.

Maybe it’s a project you’ve been circling but haven’t started. Maybe it’s a dumb tool you’ve thought about building but couldn’t justify. Maybe it’s just the recognition that sometimes the thing you make isn’t the point—the making is.

What’s something you’ve been tempted to over-engineer? Or: what’s a small, silly thing you could build that would teach you something bigger?

Hit reply. I read everything.

adam