How I Build Software With AI

I've used this small, repeatable AI workflow to build every project on this site, including the site itself. It mirrors a small software team closely enough to be worth documenting, not just because it works, but because it points to where roles like mine may be headed.

The setup uses two separate AI tools, each filling a distinct role. One handles the thinking and planning side of the work; the other handles building. The specific tools I use are my preference, and any capable AI could fill either role. What matters is that the two roles stay separate and each has the right kind of AI for the job.

The Problem This Solves

Most people building something on their own, whether a side project, an internal tool, or anything else, end up doing every part of it themselves: deciding what's needed, writing the code, and checking the result. The middle step is usually where things go wrong. A vague idea turns into code that does something subtly different from what was wanted, decisions get made silently instead of being raised, and nobody notices until the wrong thing is already built.

The Three Roles

This workflow borrows the structure of a small software team: one person directing two AI tools, each in a clearly defined role.

There's a short reference document, which we call the team file, that spells out these roles and how we work together. It sounds like a small thing, but it changes how the work feels day to day. Cleo can say "hand this to CC," or I can tell Cleo "CC flagged a problem with this," and mean it literally, the same way I'd talk about any other teammate. That small shift in language is part of what keeps this feeling like a software team, not operating a piece of software.

How the Work Flows

An idea comes up, whether it's a bug, a missing feature, or something worth adding. I talk it through with Cleo the same way I'd talk it through with an analyst. Once it's clear what we want, Cleo writes it up as a short spec: what's needed, what's deliberately left out this round, anything still open, and how we'll know it's done. I review that spec. Sometimes that's exactly where a "wait, that's not quite right" surfaces, which is the whole point of having it written down before any code exists. Once it's approved, I hand it to CC, who builds precisely what was specified. I review the actual result and test it myself before anything ships. Then we move to the next thing.

A small real example: I wanted a way to mark a maintenance item in Maintenix as "known about, not done yet" instead of just leaving it unchecked forever. That idea went through this exact loop. It was discussed first, written up as a spec, then built.

The Backlog Isn't Just a Bug List

I don't rely on either AI tool to remember past conversations. If something matters, it gets written down somewhere both of them can read, and the shared backlog is where that happens. Over time, it has become less like a bug list and more like the project's working memory: what we've decided, what's still open, and exactly where to resume next time. The "Next Session Pickup" section gets rewritten at the end of each session, so it stays useful instead of turning into a history nobody rereads.

Two short phrases bookend the work. Let's wrap tells Cleo to update the backlog and leave the pickup note. Let's pickup starts the next session by having her read it back before we talk through anything new. In practice, I can ask "what's still open on this?" or "where did we land on that?" and get a real answer. Not because Cleo remembers the last conversation, but because the backlog does, and she has just read it. It's a small piece of structure that ends up doing a lot of work.

Starting a New Project

The workflow only pays off if every project starts the same way, so I turned the setup into a starter kit. It holds the team file, the rules file, an empty backlog, the spec template, and a set of project instructions for Cleo. I create the repo and the new project, drop the kit in, and say one phrase to kick things off. Cleo walks me through a short set of questions: what the project is, where it lives, what the developer must never touch, any house rules. From my answers she fills in the working documents and writes the first spec, which sets up the folder structure and the first commit. The only steps I still do by hand are the ones involving accounts and passwords, and that's on purpose: credentials never pass through either AI. By the end of the first session, the new project runs exactly like every other one.

Why It Works

• A written spec comes before any code, so misunderstandings are caught while they're still cheap to fix.
• Open questions get surfaced and answered by a person instead of being silently guessed at by the AI.
• Each step leaves a trail of spec, change, and review, so it's still clear months later why something was built the way it was.
• Every spec ends in a commit, and the commit hash comes back with CC's summary as the receipt. Without it, "done" is just a claim.
• Every new project starts from the same kit, so the roles, rules, and habits carry over instead of being reinvented.

A Closing Thought

This isn't just a useful AI workflow. It reflects a broader shift in software quality and engineering. As more work becomes AI-assisted, the valuable human role moves toward directing the work, defining what "done" and "good" mean, catching what automation misses, and applying judgment before anything ships. Seventeen years in QA, especially advocating for users and asking the right questions early, turns out to be strong preparation for that role, even if the title hasn't caught up yet.

After building every project on this site this way, the workflow itself has barely needed to change, and that may be the strongest evidence that it works.