How I use AI
Five AI roles help me deliver my work under a written standard. One writes files, the other four only report, and I make the decisions.
- Size
- 44 documents, 1,920 lines
- Roles
- 5 agent roles
- Status
- Written by me, not adopted by an employer
- Reading
- 1 min
Why I wrote it down
Two projects that share conventions by memory will drift apart. So I wrote the conventions down as one engineering standard for all my projects: stack defaults, the performance budget, testing priorities, and a ranked list of what counts as the source of truth. The last rule on that list: when a document and the code disagree, the code is right and the document is a bug.
How AI helps with the work
The same standard sets out how I use AI to deliver work. There are five specialist roles, and each role’s contract spells out what it may do. They report findings as P0, P1 or P2 by severity, and I decide what happens next. This is about how I build software, this site included. It isn’t an AI feature that customers use.
Those limits live in each role’s instructions, not in tool permissions. No role declares `allowed-tools`, so nothing in the tooling enforces them.
The tester works from one rule: the pull request description is a claim, the diff is the truth, and any gap between the two is a finding.
- Builder
- May write files.
- Reviewer
- Report-only.
- Tester
- Report-only.
- Auditor
- Report-only.
- Content strategist
- Report-only.
What’s left out on purpose
The standard also lists what the stack leaves out on purpose. If you don’t write those choices down, whoever joins next argues them all over again. Adding one back takes a written operating need, and “it would be convenient” doesn’t count.
- No CMS
- Content lives in typed accessors. Left out for now; a CMS is on my roadmap (see Open gaps).
- No client-state library
- Server components hold the state.
- No component library
- The design system is the tokens.