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. Know what you want before you ask. What you want is the intent, and 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, and AI Project Setup is how I build it.
3. The model offers options, and you choose. It can produce lots of options cheaply. Picking the right one 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.

Setup has its own playbook.

Everything the AI gets before the work starts is in AI Project Setup: the rules files, the brief, memory for corrections, the checks and the session commands, in the order I put them in place.

This playbook starts once the work is running: how I spot drift, the phases I work through, and the checks every output has to pass before it ships.

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 product's voice.
• Every phase has ready made prompts in my Prompt Library, each paired with the check that goes with it.

The checks every output has to pass.

This is what "a person makes the final call" looks like in practice. The first three checks run on every push to main, and a failure stops the deploy. The last two run in a browser test on my machine before a release. They are actually run, not assumed. If they pass, I sign off. If not, the work goes back.

• Dash sweep. No em dashes or en dashes, including HTML entities and escapes that display as one.
• Structure scan. No duplicate ids, the main structural tags (divs, sections, navs, lists and tables) all close, and every link to a spot on the page works.
• Machine readability. The JSON-LD (the structured data search engines read) parses, and every inline script is checked for syntax errors.
• Render proof. The browser test loads the page at four widths in light and dark, confirms the theme switch works, and checks that nothing scrolls sideways at phone width. Then I check the rendered page by eye.
• Contrast proof. The same test measures the navigation text against the background it actually sits on, at every width in both themes, and it must meet WCAG AA.

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 pre-ship checklist you can adapt.

The five checks, plus a final review, in plain text. The brief and the rules files that come before the work are in AI Project Setup.

# 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 loads in a browser test, render checked by eye
[ ] contrast measured on the real background, WCAG AA
[ ] whole reviewed against original intent, then signed