How I work with AI, and how I keep it on track.

What I do, and what I let AI do.

Seven ways AI work drifts, and how I catch each one.

"Stay in control" is advice nobody can act on. What helps is knowing the specific ways AI work goes wrong. There are seven. Each one has a sign you can learn to spot, and a check that catches it.

The six rules everything else is built on.

1. Intent is the artifact you own. Intent means what you actually want. The prompt is just one way of writing it down. If you aren't clear on what you want, no prompt will fix the output.
2. Context is the work. A plain instruction only gives results that fit your system if the setup around it was built for that. Building that setup is your job.
3. The model proposes, you dispose. The model can produce lots of options cheaply. You pick the right one, and that is the real work.
4. Verify before you trust. Output that reads well isn't proof that it's right. Everything the model makes passes the checks before it counts as done.
5. Keep a human legible trail. Write down why, not just what, so the next person or agent can follow the reasoning.
6. Taste does not transfer. The model can follow a standard once you set it. It can't come up with the standard. That part stays with you.

What the model gets before any work starts.

This is what makes good results repeatable instead of lucky. Before work starts, the model gets three things. With them, a request like "make me a case study page" already follows my conventions, my voice and my quality bar.

• Role specific system prompts. Standing instructions written as personas, one per discipline: architecture, full stack build, content, growth and discovery. Each one carries the standards of that craft, so the model starts out working like someone in that role.
• A project operating standard. A document kept in the root of the repo. It covers git habits, folder structure, backups and how to hand off between sessions, so whoever picks the work up next, me or the model, can carry on cleanly.
• A precise brief. The problem in one line, the constraints that can't change, and what done looks like. Short, but exact. This is where the goal gets pinned down before anything is generated.

Eight phases, from a vague request to a shipped product.

This covers the whole process. The early phases turn a rough request into a clear goal. The later ones measure what shipped. For each phase, the table shows what I own, what the model does, the drift most likely to show up, and the check that catches it. My other playbooks plug in where noted below.

• Discover and Define use my Discovery to Scope playbook: Jobs to be Done to find the real job, and the Double Diamond to explore widely and then narrow down.
• Design runs inside my Figma Operating System. The agent works in the file, and the naming, tokens and status labels keep it on system.
• Build applies the Interface Content System to every piece of text the model writes, so the copy stays in the customer's voice.

The checks every output has to pass.

This is what "a person makes the final call" looks like in practice. Nothing the model makes goes live until it passes these five checks. They are actually run, not assumed. If they pass, I sign off. If not, the work goes back.

• Dash sweep. No em dashes, en dashes, or dashes used as punctuation, including HTML entities that display as a dash. A hyphen check also runs on the visible text.
• Structure scan. No duplicate ids, every div, section, article and nav tag is closed, and every link to a spot on the page works.
• Machine readability. The JSON-LD (the structured data search engines read) parses, and node checks every inline script for syntax errors.
• Render proof. A jsdom smoke test (a quick load of the page without a browser, with the right polyfills) confirms it boots, and I check the rendered page by eye.
• Contrast proof. Color pairs are measured with exact oklab math and must meet WCAG AA before any color change ships.

When I keep AI out of it.

Part of working with AI is knowing where it shouldn't be involved at all. These are the four cases.

• When a small mistake could do serious harm. Legal, medical, financial and security decisions cost too much to leave to something that only sounds right. A person decides, with help from a qualified expert.
• When you can't say what you want yet. If the thinking is the point, do the thinking yourself. Give a model a vague goal and you get a confident, average answer, which is what you were trying to avoid.
• When the work is the relationship. A hard conversation or a judgment about a person isn't something to generate. Handing it off loses the thing that mattered.
• When you'd ship something you can't check. If there's no check for it, it can't pass. Don't ship on faith.

The whole approach on one screen.

A starter template you can adapt.

A small version of the brief, a persona and the checks, ready to adapt to your own setup. The persona sets the role. The pre-ship list is the five checks, plus a final review, in plain text.

# brief.md  (write down the goal before generating anything)
Problem (one line): ____________________________________
Definition of done: ___________________________________
Hard constraints:   ___________________________________
Out of scope:       ___________________________________

# persona.md  (the role the model works in)
You are a [discipline] specialist. You hold the standards of
that craft. You propose, the human disposes. You cite real
sources only. You never present a guess in the voice of a fact.

# preship.md  (the checks, run before shipping)
[ ] dash sweep clean  (entities included)
[ ] no duplicate ids, tags balanced, anchors resolve
[ ] JSON-LD parses, inline scripts pass a syntax check
[ ] page boots in a smoke test, render checked by eye
[ ] color pairs measured, WCAG AA confirmed
[ ] whole reviewed against original intent, then signed