Skip to content

My own practice · 2025–2026

How I manage AI-assisted delivery without losing quality

The operating model behind three products I build and run solo: scoped work, gates with attribution, no spend in the toolbelt, verification before anything ships, and a written record of every decision.

Headline

4 checks

between a proposed change and production

9,655

phantom trade rows caught by a reconciliation audit

54.7 pts

overconfidence found by a calibration check

1

accountable lead per repository

0

pipeline tools that can spend money

The problem

Everything I build independently has to fit around other commitments, so the constraint is hours. AI coding assistants change that math, but only if reviewing and verifying their output costs less than writing the code myself. That’s a management problem, not a tooling problem.

The four checks

Every change passes through the same four questions before it ships:

  1. Is it scoped? Work starts from a written task with the files, the constraint, and what “done” means. Project rules live in the repository, and deploy steps live in runbooks, so nothing depends on memory.
  2. Does it build and type-check? Deploys are blocked on the type checker and the build. Cheap, automatic, and it catches a surprising share of mistakes.
  3. Is it verified where users are? I check the change on production or a production-like target: the page at 390px on a phone, the API response, the row in the database. “Tests passed” isn’t the same as “it works.”
  4. Would I sign it? Every change carries a written rationale, including what was measured, what the fix deliberately doesn’t do, and how it was verified. I read that like a small design doc before approving.

Controls that held up

  • One accountable lead per repository. I run a small CLI that keeps one persistent working session per project in its own git worktree, with task notes that survive restarts. My own checkout and uncommitted work are never touched.
  • Gates with attribution. In TigerMill I started with “every gate needs a human,” then changed it: automated steps may close objective gates, but every review records who acted, and a revision check rejects stale writes. Subjective acceptance still needs me.
  • No spend in the toolbelt. TigerMill’s automation interface has 13 tools, and none of them can generate an image. Paid generation is dry-run by default, needs an explicit confirm, and never retries.
  • Invariants over vibes. In TrendVesting, a test now asserts that an exit’s label can never change its price, after an audit found losses recorded as target hits.
  • Destructive fixes wait for approval. Repairs to production data happen on the read path first; deleting records is a separate, explicitly approved step.

What went wrong

  • A delegated approval failed. I let an automated reviewer approve TigerMill art that I then rejected. The fix was a better structure to review against, not more trust.
  • Project docs drifted. TendForm’s instructions kept describing email infrastructure replaced on day one. Instructions are infrastructure and need the same maintenance as code.
  • Verified live wasn’t complete. TendForm’s HIPAA tier passed live checks and still had edge cases between plans, teammates, and existing data for weeks. Now every fix ships with a regression test.

What it means for a team

AI makes producing code cheap. It doesn’t make accepting code cheap. The unit to manage is dollars per accepted change: the merged work, including rework, review time, and the fixes that followed. Most teams adopting AI measure none of that. The checks above are where I’d start.

Cash-pay advisory
from $250/hr

Check fit