Stop Blaming the Model: Write a Real Brief (PACE) and Fix the Process

We all trade tales about the model blowing a task. It is funny, and it is safe. Blame the bot, not the way we work. But ask this. Are we blaming the model for work we never spelled out?

Here is my claim. Many “AI failures” are brief failures. A brief is a short, concrete set of instructions that states what you want, for whom, under what limits, with a couple of examples.

Status sits under the jokes. We like being valued for having the answer. When a tool looks like it can do our job, we calm ourselves by finding its limits. That impulse is human. It also hides a simpler cause. We did not give it a real brief.

Think of the system like a flexible machine that runs whatever job you hand it. No work order, no predictable result. It will guess the job. Guessing looks like incompetence.

Use a tiny checklist. I call it PACE.

• Purpose: the outcome in one sentence.
• Audience: who it is for.
• Constraints: rules, limits, and things to avoid.
• Examples: one or two concrete samples to copy.

Add format and success criteria when it matters. Then ask the model to propose a plan. Edit the plan. Only then ask for the draft or the code.

A small story. A friend had a gnarly spreadsheet. He wrote, fix this. The model produced nonsense. We slowed down. We named the columns. We wrote the rule in plain language. We asked for a step by step formula with a test row. The next answer worked. Same model, new work order.

A second story from writing. A founder asked for a product update email. His prompt was, write an exciting launch note. The draft read like a TV ad. We used PACE.

• Purpose: a clear update that earns replies.
• Audience: current customers, not press.
• Constraints: 150 words, no hype words like revolutionary or game-changing, include a one-click upgrade link.
• Examples: two past emails with the tone we wanted. We first asked for an outline. We cut a section. Only then did we ask for the full email. The result matched the brand and shipped in ten minutes.

This pattern is not new. In factories, most defects trace back to missing or vague work instructions. Toyota’s playbook is boring on purpose. Name the job. Name the steps. Name the checks. Quality follows clarity.

There are real limits. A tight brief will not give you private data it cannot access, a novel proof in pure math, or flawless legal advice in a gray area. I once wrote a crisp brief for a valuation model, with sample rows and edge cases. It still hallucinated current revenue for a private company. The fix was not a better prompt. We pulled the numbers from the source and had the model work only on the math. When the tool cannot know, change the tool, or change the scope.

What about the cost of all this? Writing a brief takes a few extra minutes. It pays back by cutting loops. You get fewer wrong turns, clearer handoffs to teammates, and a prompt you can reuse. Like writing a small test before you code, it saves you from hours of debugging later.

A few practical habits help:

• Break work into small steps with checks between them.
• Ask for sources when facts matter. Verify them.
• Use code or external tools when correctness is strict.
• If the answer is high stakes, run a second pass with a different tool.

We are shifting from mastery of answers to mastery of instructions. Next time the bot flubs a task and the room laughs, pause. What work order did we hand it? If none, write one. If a good brief still fails, adjust the job or pick a better tool. That is not about defending the model. It is about fixing the process we control.