Journal · The AI Architect · 2026-08-17
Best tools to build: work that repeats, keeps the same shape, and is tedious. Leave the judgment calls as tasks.
Best tools to build: work that repeats, keeps the same shape, and is tedious. Leave the judgment calls as tasks.
The tension isn’t whether to automate. It’s that the moment you start building, everything looks automatable. You see the shape of a workflow and you want to hand the whole thing to a tool, judgment calls included. That instinct is where most AI projects quietly go wrong. The fix isn’t a better tool. It’s a clearer sense of what you’re actually looking at before you build anything.
Separate the shape from the decision
Most work is a mix of two different things: motion and judgment. Motion is the part that looks the same every time — pull the data, format the report, sort the requests, draft the first version of the email. Judgment is the part where someone has to weigh something — is this customer worth an exception, does this draft actually sound right, is this the moment to push back.
The mistake is treating a whole workflow as one thing. You look at “handling customer refunds” and either automate all of it or none of it. But inside that workflow, there’s a repeating shape — checking order dates, pulling account history, generating a standard response — and there’s a judgment call buried in the middle: should this particular customer get an exception to policy. Build the tool for the first part. Leave the second part as a task a person does, informed by what the tool already prepared.
Try this: Take one workflow you do often. Write out the steps in plain language, then mark each one with an “R” for repeats-the-same-way or a “J” for judgment call. Don’t build anything yet. Just look at how many R’s cluster together before the first J shows up. That cluster is your build target. The J is not.
Tedious is a feature, not an insult
People sometimes resist automating tedious work because it feels like admitting the work didn’t matter. It’s the opposite. Tedious work is often necessary and still worth doing badly by a machine and well by a person elsewhere. The tedium itself is a signal — it tells you the task has a fixed shape that doesn’t change much from one instance to the next. That sameness is exactly what makes it buildable.
The trap is chasing variety instead. Builders get excited about the interesting edge cases — the weird customer complaint, the unusual contract clause — and want to build for those first, because they’re intellectually satisfying. But edge cases are, by definition, not repeating. You’ll spend weeks building a system for something that happens twice a year, while the thing that happens two hundred times a week still eats someone’s whole afternoon.
Try this: Ask the people actually doing the work, “what’s the part of your day you’d erase if you could?” Not “what’s hard” — hard often means judgment, which you want humans doing. Ask what’s boring. Boring is where the shape repeats. That’s your first build.
Leave room for the call, not just the exception
There’s a subtler version of this mistake: building a tool that handles the repeating part but tries to also handle the judgment call by hiding it — a scoring system, a threshold, an automatic approval under some dollar amount. This feels efficient, but it quietly removes the moment where a person notices something the rules didn’t anticipate. The judgment call isn’t just a decision point, it’s also a chance for someone to catch what the system can’t see.
So the practical move isn’t just “leave the judgment call to a human.” It’s “make sure the tool hands the human enough context to actually judge well.” A tool that drafts the refund response but flags “this customer has three prior exceptions” is doing its job. A tool that auto-approves anything under a certain amount is doing something else — it’s making a policy decision disguised as automation.
Try this: For any tool you build, write one sentence describing what a person sees right before they make the judgment call. If that sentence is vague — “they review it” — the tool isn’t finished. The review only works if the tool surfaces the specific thing that matters for that decision.
None of this is complicated once you see it, but it’s easy to miss in the moment, because building feels like progress and progress feels like automating more. The instinct to build everything is strong precisely because building the repeating parts works so well that you start to believe it’ll work for the judgment parts too. It won’t, and that’s not a limitation to solve — it’s the actual boundary of what these tools are for. There’s more on how to find that boundary in different kinds of work, and what to do when it’s genuinely blurry, in the fuller chapters of the book. This is just the starting edge of it.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.