How I build

I direct AI coding agents the way a lead runs a small team. Each one has a job:

• Claude Code is the senior developer and coordinator. It builds and coordinates the work of the other two.
• Codex handles design (UI and UX) and reviews code.
• Gemini does research and checks the finished site in a real browser, through the Gemini CLI and Antigravity. Antigravity is the newest tool on the team: I have used it for about a week.

Every step works from a written spec, with a review gate before the next one. I approve every phase myself.

Nothing ships until it survives the Trial by Fire:

1. Automated tests, on every change.
2. Stress-test agents that try to break it. All five run before a project first goes live. After that, each change gets the testers it touches, and every two weeks the testers chosen for that project run a full check-up.
3. A review by a second AI model.

The full rulebook is below. It is the same document the agents work from, published so a technical advisor can audit exactly how the work gets done.

The Trial by Fire, one real example

One true chain from this site's first release, from its security log.

The chaos tester, one of the five stress-test agents, pressed the site's Hard refresh button (it downloads fresh offline copies) and cut the connection a moment later. That wiped 14 of the 30 files the site keeps for offline use. The fix: download everything first, and replace nothing until it has all arrived.

Then Codex, the second AI model, checked the fix and found the next weak point. Each one was fixed, given a test to prove it, and sent back for another check:

1. The connection could drop halfway through a file. Now every file arrives in full before any old copy is deleted.
2. A full disk could stop the save after the old copies were gone. Now old copies go only after every new one is saved.
3. Two tabs refreshing at once erased each other's copies. Now one refresh runs at a time.
4. An offline visitor could see an older leftover copy. Now the fresh copies live in one place, checked first.
5. A disk too full to open that place stopped the search for a backup. Now each step moves on if it fails.

After six rounds of checks, the release was cleared with 41 tests passing. Still on record: the full-disk cases were tested in simulation, not in a real browser.

See the code yourself

This site's own repository is private, so the open example is Digital Sorcery, a free app built the same way and fully public. You can read every file, and run the app. Its stress testers are where this site's Trial by Fire came from.

A real snippet. This is how Digital Sorcery saves a visitor's draft: only on their own device, never crashing when the browser blocks storage, and treating what it reads back as untrusted. Quoted from src/storage.js:

/** Read the saved draft. Always returns a valid, cleaned draft. */
export function loadDraft() {
  try {
    const raw = window.localStorage.getItem(DRAFT_KEY);
    if (!raw) return emptyDraft();
    // SECURITY: the stored value is treated as untrusted: it is parsed, then rebuilt
    // field by field by normalizeDraft(), which drops unknown keys and unsafe characters.
    return normalizeDraft(JSON.parse(raw));
  } catch {
    return emptyDraft();
  }
}

/** Save the draft. Returns false if the browser refused (the app keeps working anyway). */
export function saveDraft(draft) {
  try {
    window.localStorage.setItem(DRAFT_KEY, JSON.stringify(normalizeDraft(draft)));
    return true;
  } catch {
    return false;
  }
}

The handoff folder. Every project keeps one, so another developer can pick it up cold. Digital Sorcery's holds:

Rules, tools and workflow

How Steven Cruz builds software by directing AI agents as a managed team. This is the working rulebook for this project, not a summary written afterwards: the agents follow it, and the files it points to are the evidence that they did.

In one paragraph

I build by directing AI agents as a managed team, with me as product owner. Claude Code is the senior developer and coordinator. Codex handles design and reviews the code. Gemini does research and checks the finished site in a real browser. Every task has a written spec and a list of the files its agent may change. Nothing ships until it survives the Trial by Fire: automated tests, stress-test agents that try to break it (all five before the first live release), and a review by a second AI model. Then I approve it. The task files, results, decisions and security log live in this repository, so a reviewer can audit exactly how each piece was made.

1. Who does what

Each agent has one lane. Lanes never share files.

2. Rules

Working together

1. Two agents never edit the same file, at the same time or on two branches that will later merge. Every task lists the files its owner may change; the owner changes only those.
2. One agent per project at a time, unless the coordinator gives a second agent its own git worktree and branch with a file list that doesn't overlap.
3. Hand off in writing. Every finished task gets a result file: what changed, how it was tested, and what was not tested. Nothing is left half-finished and uncommitted.
4. Second opinions at three moments only: before a plan locks, after the same error twice, and before a task is marked done.

Approvals (the agents propose, Steven decides)

5. Nothing goes live, costs money, deletes data, or reaches a client or member without Steven's explicit word.
6. Phase gates: each phase ends with a working demo, a checklist and a summary of ten lines or fewer. The next phase waits for approval.

Security

7. Security is part of "done", not a final pass. A finding is fixed, or logged in SECURITY.md with a severity. A rule is never weakened to make something work.
8. No secrets in the repo, the client, prompts, task files or logs. Agents never see production credentials.
9. Database rules deny by default. Anything of value (points, badges, roles, status) is written server-side only.
10. Dependencies stay few and pinned, with a lockfile and an audit at every gate. New packages are checked for typosquats and abandoned maintainers.
11. No member, donor or other personal data is sent to an AI tool without written approval. Agents work on seeded fake data.
12. People and tools get only the access they need. The organization owns its data, accounts and code; accounts are in its name, with me added as a user.
13. Any change to database security rules gets a written security audit and my explicit approval before it goes live. Rules live in one tested file per project and deploy from one place.

Quality

14. Tests and the project's check script ("doctor") run before every release. Errors get fixed first.
15. Code is human readable: plain names, short functions, comments that explain why, so another developer can take over.
16. Every web app has an install button and a safe "hard refresh" that never touches user data.

Honesty

17. No invented facts: no testimonials, statistics, credentials or prices that can't be traced to a source. A gap gets [CONFIRM].
18. A feature isn't claimed until it is built and checked. Planned work is labeled as planned.
19. Every scope cut gets one line in DECISIONS.md.
20. When unsure, stop and ask in plain words, with a recommendation.

Keeping the system lean

21. One source for each rule, tool and record. Before adding a file or a process, check whether one already covers it, and improve that instead. Dead code is deleted as soon as it's found.
22. The workflow is reviewed at the end of each working session. What worked better is kept; what overlapped is removed.

3. Stack and tools

The stack in plain words

The tools

One surface at a time. On a Windows laptop with 8 GB of RAM, the agents run one after another, not side by side. The task and result files carry the context between them.

Plan limits. All three AI tools are on $20 plans, so usage caps are real. Claude Code does the bulk of the building; Codex is spent on diff reviews (called read-only from Claude Code) and Gemini on research and QA. Tasks stay small, and the Trial by Fire runs only the agents a change needs; all five run once, before a project first goes live.

Experience, stated honestly. Claude Code and Codex are in regular use. Antigravity is new to this workflow (about a week, October 2026).

4. The loop: nothing ships until it survives the Trial by Fire

1. Ask questions. Before a plan locks, the open questions go to Steven in one list. Nothing is guessed.

2. Set the rules. Claude Code writes docs/agents/tasks/NNN-title.md: goal, files to read, the only files the owner may change, done means, and "do not".

3. Build. The assigned agent works on its own branch and writes docs/agents/results/NNN-title.md, including what it did not test.

4. Trial by Fire. Three layers try to break the work before it merges:

   • Automated checks: tests, contrast and hidden-character checks, and the build.
   • Stress-test agents (.claude/agents/): all five before a project's first live release; after that, the ones chosen by what changed (table below), plus a check-up every two weeks by the project's designated testers.
   • A second model's review: Codex reviews Claude Code's diffs; Claude Code reviews Codex's and Gemini's work.

   Every CONFIRMED finding is fixed and gets a regression test, then the work goes back through the Trial. A finding that is accepted instead gets a reason in SECURITY.md or DECISIONS.md.

5. Ship. Steven approves the gate. The release checklist runs, the site goes to a preview channel, then live on Steven's word. Gemini (or Steven) checks the live result in a real browser.

6. Next version starts with new questions. What the round taught goes back into these rules (rule 22).

All five run only once, at the first live deploy (Steven, 2026-10-21). After that, testers run as each change needs them, and the two-week check-up catches what drifts without a change: expired links, browser updates, outdated dependencies.

Only CONFIRMED (reproduced) findings block a merge; PLAUSIBLE ones get a written decision.

The Trial is sized to the change because every tester costs AI usage (Steven, 2026-10-19: "the trial by fire really eats up tokens"). Re-checks after a fix go to the one tester that found the problem, not all five.

Steven may choose to ship before a Trial by Fire. Each time is one line in DECISIONS.md, and the full Trial runs on the next release, before it ships.

Each tester works in its own copy of the release (git archive <commit> into a temporary folder, its own npm ci), never in the shared checkout, and only one tester drives a browser at a time. Testers that only read code run side by side. This came from the first release: testers sharing one checkout disturbed each other's builds.

Release checklist (every release; nothing goes live until Steven says so)

[ ] Tests pass.
[ ] The project's check script passes.
[ ] Apps with real users: released to a preview channel first, and reviewed there.
[ ] The deploy command names the exact target.
[ ] Any change to database security rules has a written security audit and Steven's approval.
[ ] A second opinion was taken before the task was marked done.
[ ] Steven has said "deploy".
[ ] A handoff line is logged.

5. Images and licenses

Real photography of the community beats generic stock; stock is a placeholder only. Every file in assets/ gets a row in assets/LICENSES.md before it is used:

Open each license page and copy what it says. Prefer CC0 or public domain. Never hotlink. No identifiable people without a release.

6. What a reviewer can audit

• Commit history: small commits, each labeled with the agent that made it.
• agents/: every task (who was asked to do what) and every result (what came back, what was not tested).
• .claude/agents/: the five Trial by Fire stress testers' exact instructions.
• DECISIONS.md: every scope cut.
• SECURITY.md: every finding, its severity and its fix.

This repository is private; reviewers get access by invitation. Studio-wide coordination (locks, the live task board and the handoff log across all projects) runs in a separate private operations repository, because it covers client work.

7. Common questions

What if Steven is unavailable? Continuity depends on documentation, not memory. Every task has a written result, every change is a labeled commit, and the code is written for someone else to read. Another developer can pick the project up from those records.

What does AI do, and what doesn't it do? AI tools write and review code, plan work and do research, all under Steven's direction and review. They don't go live, delete data, handle money, contact anyone outside, or touch passwords and keys.

What will it cost? Free tiers first, and the cost of anything is stated before it's added.

How do we leave, or bring in someone else? The code is in a repository with its full history, the accounts are in the organization's name, and the work is recorded task by task. A new developer gets access to those.

8. Open items

• Antigravity's plans and terms changed several times during 2026: check the current terms before relying on it for anything critical.

Sources: Codex approvals and security · Google Antigravity