Journal · The AI Architect · 2026-08-12
Read every plan before approving. Ask: do I understand it? Is it what I asked for? Could it lose anything?
Read every plan before approving. Ask: do I understand it? Is it what I asked for? Could it lose anything?
There’s a particular kind of tiredness that sets in around the fourth or fifth plan of the day. Your eyes skim, your thumb hovers over “approve,” and some quiet part of you says close enough. This is the real tension: not whether you know how to check a plan, but whether you’ll actually do it when you’re depleted, behind schedule, and the plan looks plausible enough to pass. Approval is easy. Understanding is work. Most of the damage in AI-assisted work happens in that gap.
Slow down at the moment of least resistance
The plan arrives well-formatted, confident, organized into neat steps. That confidence is exactly what makes it dangerous to rubber-stamp. A plan that looks finished doesn’t mean it’s correct — it means the system is good at producing things that look finished. The two are unrelated skills.
The fix isn’t to distrust everything. It’s to notice that approval requests always show up at the moment you’re least equipped to scrutinize them: end of a long day, middle of a busy stretch, right when you just want the task off your plate. That’s not a coincidence you can eliminate, but it’s one you can plan around.
Try this: before you read any plan, say out loud (or type) one sentence describing what you actually asked for. Not what you hope the plan says — what you originally wanted. Then read the plan against that sentence, not against your memory of the plan itself. This small step interrupts the autopilot that turns “reading” into “confirming what I already assume is there.”
Ask the three questions in order, not all at once
The three questions in the line — do I understand it, is it what I asked for, could it lose anything — aren’t interchangeable. They work best asked in that sequence, because each one filters out a different kind of failure.
“Do I understand it” catches plans you’re tempted to approve simply because they’re too complex to argue with. If you can’t explain a step back to yourself in plain words, that step is a risk, regardless of how sound it might actually be.
“Is it what I asked for” catches drift. Plans have a way of quietly solving an adjacent problem instead of your problem, especially when the adjacent one is easier or more common in the system’s training. This isn’t malice, it’s gravity — the path of least resistance pulls toward familiar patterns.
“Could it lose anything” catches the quiet deletions: a file overwritten, a step skipped because it seemed redundant, an edge case dropped because it complicated the plan. This question matters most for anything that touches real data, real money, or real relationships, because those losses are often invisible until much later.
Try this: keep the three questions as a short checklist you paste above any plan before you respond to it. Answer each one in a single sentence. If you can’t answer a question in one sentence, that’s your signal to slow down further, not to guess and move on.
Build a habit, not a heroic effort
None of this works if it depends on willpower. You will be tired. You will be in a hurry. The review process has to survive those conditions, or it isn’t a process — it’s a hope.
This means making review the default friction point rather than an optional extra step. Some people do this by never approving a plan the same minute it arrives; they let a few minutes pass, which is often enough to catch the plans that only looked reasonable under time pressure. Others keep a running log of near-misses — cases where a plan looked fine but wasn’t — and reread that log occasionally, since specific memory of past mistakes tends to outlast good intentions.
Try this: pick one recurring type of plan you approve often, and write down, once, what a bad version of that plan looks like. Keep that description somewhere visible. Pattern-matching against a known failure is faster and more reliable than trying to evaluate every plan from scratch.
None of this is about becoming suspicious of every output or slowing everything to a crawl. It’s about recognizing that approval is a decision, not a formality, and that the moments when it feels most like a formality are exactly when it needs the most attention. The book goes further into how to build these checks into a working rhythm without turning your day into an audit — but the core of it starts here, with three honest questions and the discipline to actually ask them.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.