How I work with AI, step by step — what it still needs at team scale, and how I'd approach it.
Every project starts with a written spec, and nothing gets called done until it survives verification — a screenshot, a test, a real device. The rules I hold agents to live in plain files: skills for procedures, memory for facts, hard rules for the mistakes I never want repeated. A knowledge graph of each codebase grounds every session, so agents reference structure instead of rediscovering it. Cheap local models do the mechanical work while the expensive ones plan, judge, and verify. When something goes wrong, the mistake becomes a written rule — the graph below is that system, live.
Download the setup packHow a piece of work moves through this.
Calibrate
Before any design work starts, two interviews run: one on taste — what this surface should look and sound like — and one on who it's actually for. The answers bind every later judgment to a real person, not a generic user.
Three steps before anything
Every task, however small, starts the same way: check whether a skill or tool already does this, write a short spec of what done means, and name how I'll prove it worked. The spec defines done; the verification proves it.
Set the goal
Substantial work goes in as a goal: the outcome, the surfaces it touches, the constraints, and the bar it has to clear — often written so a session can run it start to finish without me.
stepskillSpend models like a budget
One model plans and reviews. Standard engineering goes to cheaper ones running in parallel. Mechanical legs — inventories, conversions, greps — go to a free model on my own machine. The expensive model reads and decides; it rarely types.
Loop until it holds
Long-running work runs in loops with an explicit exit condition: watch the deploy, poll the build, keep going overnight. Each pass reports; the loop ends when the condition holds, not when the output looks plausible. Before anything is called done, a second model tries to prove it isn't.
Judge and steer
Generated work gets judged against my own recorded taste before I look at it — then I look at it. A rules pass catches violations; my eyes make the call. Corrections get recorded, so the judge gets closer to my taste each time.
Today, this is a one-person system.
For a team, it still needs six foundations. The steps below are proposals for how I would add them, not evidence that they already work at scale.
Interview the judgment, not every request
A few designers cannot sit in every team's room. Capture their standards once — interviews, recorded decisions, references — instead of routing every piece of work through their calendar.
Publish judgment as an API
Tokens, interaction patterns, motion specs, and negative prompts become machine-readable. An engineer's agent queries the same source of truth from inside whatever constraints their team works under — the system travels where the designers can't.
Gate at generation, not at review
The standards run inside the loop that produces the work, so a tool built where no designer is present still arrives compliant. Review is left for taste, not violations.
Record every override
Each correction — an engineer's override, a designer's audit note — becomes a rule. A design system for work that changes weekly can't be finished; it converges instead.
A few author, everyone relies
The system stays small and owned by the people with the judgment. Teams build against it without waiting in a queue — design scales by authorship, not headcount.
Gaps become intake, not drift
A pattern the system doesn't cover gets built anyway and flagged inline — shipping doesn't stop. The flag searches the existing system for an analog first; true gaps land in a prioritized intake, and the answer folds back into the system.