Why Process-First Fails

When you instruct someone or something to follow a process, you're betting that your process is the right one for their context and capabilities. Sometimes it is. Often it's not. You designed your process for yourself — for your expertise, your tools, your way of thinking, your constraints. When you hand that process to someone else (or to AI), they have different constraints and different capabilities. A process that works for you might be suboptimal for them.

More importantly, process-first instruction prevents the executor from exercising judgment. If their job is to follow your steps, they can't decide to deviate from your steps when they see a better way. They can't adapt to unexpected problems. They can't take advantage of capabilities you didn't know they had. You get compliance instead of competence.

This matters especially with AI. AI systems are not human junior colleagues — they don't have the same constraints or capabilities. They can't do some things you do effortlessly. They can do other things in ways you wouldn't think of. If you instruct them to follow your process, you lose the advantages of their different capabilities. You get an inefficient human-replacement instead of a powerful tool.

Another problem with process-first instruction: it's often vague. "Write in plain language" sounds simple until you try to evaluate whether someone did it. Did they use short enough sentences? Is this jargon or is this a necessary technical term? Process-first instructions often paper over the actual standard with language that feels specific but isn't. Outcome-first direction forces you to make your standards explicit.