Journal · The AI Architect · 2026-09-04
Describe the destination, not the route — say what "done" looks like and let your AI find the way there.
Describe the destination, not the route — say what “done” looks like and let your AI find the way there.
The tension isn’t really about AI. It’s about control. When you write out every step — do this, then this, then check that — you get to feel like you’ve done your job. You’ve been thorough. If something goes wrong, you followed the process, so it’s not really your fault. But that same instinct is exactly what makes AI tools frustrating to work with. You end up managing the machine’s hands instead of using its judgment, and you’re left wondering why you bothered delegating at all.
The shift isn’t just a communication trick. It’s a different way of thinking about what you’re actually trying to get.
Know what you want before you explain how to get it
Most of us don’t naturally think in outcomes. We think in tasks, because tasks are what we’re used to doing ourselves. So when we sit down to ask an AI for help, we default to narrating our own process: open this file, look for that pattern, change it this way. It feels helpful. It’s actually a constraint. You’ve just told the tool to replicate your habits, including the inefficient ones, instead of letting it find a better path.
Try this: before you type a single instruction, write one sentence that describes the finished state — not what you’ll do, but what will be true when you’re done. “The report flags any customer who hasn’t paid in 60 days, sorted by amount owed.” Not “search the spreadsheet, filter by date, then sort by column C.” If you can’t write that outcome sentence, you’re not ready to delegate yet. You’re still deciding what you actually want, and no amount of route-planning will fix that.
Build in the checkpoints, not the choreography
Letting go of the route doesn’t mean letting go of judgment. It means moving your judgment to a different place. Instead of approving each step, you approve the destination criteria and then check the arrival. This is a real shift in where your attention goes, and it takes some practice to feel natural.
Say what “done” looks like in specific, checkable terms. Not “make it good” but “under 500 words, no jargon, ends with a clear next action for the reader.” These aren’t style preferences dressed up as vagueness — they’re the actual acceptance criteria, the things you’d check if someone else on your team handed this to you. The AI can be creative about how it gets there, but it shouldn’t be creative about what “there” means.
Try this: next time you’re about to give step-by-step instructions, stop and write your criteria as a short checklist instead — three to five bullet points, each one something you could look at the output and say yes or no to. Hand over the checklist, not the choreography. See what comes back. Often it’s a route you wouldn’t have thought of, and sometimes it’s better than the one you had in mind.
Expect to revise the destination, not just the route
Here’s the part that trips people up: the first time you describe an outcome instead of a process, the result often isn’t quite right. It’s tempting to read this as proof that the approach failed — that you should go back to giving instructions because at least then you get what you asked for. But usually what’s happened is simpler: your destination wasn’t as clear as you thought it was. The AI followed your criteria faithfully and exposed a gap in them.
This is useful information, not failure. Adjust the destination — add a criterion you left out, tighten one that was too loose — and try again. You’re not debugging a set of steps. You’re sharpening a description. That’s a faster loop than most people expect, and it gets easier with repetition, because you start to notice in advance which parts of your outcome are fuzzy before you even hit send.
None of this means abandoning expertise or oversight. It means putting your expertise into defining what a good result actually is, and trusting the tool to handle the mechanics of getting there — then checking its work against the standard you set, not the process you imagined.
This idea sits at the center of a larger argument in the book about how to actually work with AI rather than just use it, and there’s more there about how to write criteria that hold up, what to do when the AI’s route reveals a better destination than the one you started with, and how this changes over longer, messier projects. But the core move is the one above: describe the finish line clearly enough that someone else — human or otherwise — could tell when they’d crossed it.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.