Scope before you build

The most useful sentence I say to an AI system is "not yet."

There is a specific moment this happens in. Someone spots a manual process, gets excited about automating it, and wants to start building immediately. The instinct is understandable. The fastest-looking path is to open the tool and start generating. It is also the path that produces systems nobody trusts six weeks later.

The discipline that actually works is duller than it sounds: scope before you build. Plan before you scope. Only then does anything get built. Every step in that order exists to answer a question the next step cannot answer on its own.

What scoping actually stops

Scoping is not a formality bolted onto the front of a project to make it feel rigorous. It answers three questions that, left unanswered, come back as production problems.

What is this system actually for. Not the workflow it touches, the specific decision or output it needs to produce. A tool built to "help with inventory" will drift in whatever direction its builder's attention drifts. A tool built to answer one named question stays answerable to that question.

Who reads the output, and what do they do with it. A system built without a reader in mind tends to produce something technically correct and practically useless: numbers nobody checks, reports nobody opens, tasks nobody closes. The reader is not a detail to fill in after the build. It is the build.

What must this system never touch. This is the question people skip most often, and it is the one that prevents the worst outcomes. A tracking layer built to show sampling stock without specifying that it must never feed into demand forecasts will, eventually, feed into demand forecasts. Not from malice. From convenience, the first time someone is in a hurry.

Manual first, AI second

There is a second half to this discipline that matters as much as scoping: understand the manual version before you automate it.

I do not mean documenting the manual process in the abstract. I mean watching it run, by hand, long enough to know where it breaks and why. The workflow someone describes from memory is rarely the workflow that actually happens. There are always exceptions the description leaves out: the vendor shipment that comes in over the ordered quantity, the approval that happens in a hallway conversation instead of the system of record, the report that gets skipped in a busy week without anyone noticing.

If you automate the described version instead of the real one, you have built a fast, confident system for handling a situation that does not exist. The exceptions do not go away. They just have nobody watching for them anymore.

Human in the loop is not a compromise

The systems I trust in production share one more trait: they draft, they do not act. A recommendation gets previewed before a task gets created. A connector that touches sensitive data gets approval-gated before it runs. Backend repairs happen with someone watching each change land, not after the fact.

This gets read, sometimes, as a lack of confidence in the technology. It is the opposite. Approval gates exist because the technology is capable enough to move fast, and speed without a checkpoint is exactly how a small scoping mistake becomes a large one. The gate is not slowing the system down. It is the reason the system gets to keep running unsupervised on everything it has already earned trust on.

The actual test

Before the next AI build in your business, ask the three scoping questions out loud, in front of whoever is building it. What is this system for, specifically. Who reads what it produces. What must it never touch.

If any of the three answers is vague, the system is not ready to be built yet. That is not a delay. It is the step that decides whether the thing you ship next month is still running, unmodified and trusted, a year from now.