Some Friction Is Protection: The Loop I Run When AI Output Matters

In the first part of this argument, I diagnosed what I call well-structured drift: AI lowers the cost of moving from vague thought to plausible action, and the mental steps that should create friction — questioning the premise, resisting the first framing, sitting with uncertainty — quietly become optional. Three patterns do most of the damage: plausibility arrives before reliability, the model constructs a version of you and solves that person's problem, and the first framing shrinks the search space before you notice it happened.

I also argued that awareness alone changes nothing. Knowing the map is incomplete does not fill in the missing territory.

So this piece is the response: where AI belongs in the work at all, and the loop I run when its output actually matters.

Before You Interrogate the Output, Design the Role

This is where most discussions become too narrow.

People jump straight to prompt technique, critique loops, red-teaming the output, and all the rest. Fine. Useful. But it starts too late.

The prior question is more important: what role should AI play in this task at all?

Because not all work tolerates the same kinds of error.

AI is excellent for exploration, drafting, decomposition, comparison, summarization, and generating alternatives quickly. It is much less trustworthy as the final arbiter in high-stakes decisions where omission, inherited framing, or fake completeness can become expensive.

So sometimes the right response to a risky AI output is not better interrogation.

Sometimes it is better task design.

Use the model where speed helps and verification is cheap. Keep it away from final judgment where the cost of subtle error is high. Build non-AI checkpoints into the workflow on purpose.

That distinction matters because once a model becomes useful, people start handing it roles it was never properly assigned. Not because the model demanded it. Because the fluency makes overreach feel reasonable.

There are really two layers here.

First: task design. Where should AI be in the process, and where should it not?

Second: interrogation. Once you’ve decided AI belongs in the process, how do you apply enough pressure to stop its outputs from sliding into your thinking untested?

The second layer matters.

The first one matters more.

The Loop I Use When the Output Actually Matters

I do not believe in universal frameworks dressed up as laws. Real work is messier than that. Still, when the output matters, I keep returning to the same sequence of pressure-tests.

Not because it is elegant. Because it catches drift.

The harder a decision is to reverse, the more of this loop is worth running.

1. Generate

Ask the question normally. Get the initial output.

Then do something people rarely do when an answer sounds good: do not evaluate it yet.

Treat it as a first pass. Not a conclusion.

2. Attack

Now pressure the answer directly.

What breaks this?

Where does it fail?

What assumptions are making this look stronger than it is?

What would make this actively bad advice?

Do not ask for “pros and cons.” That is often too polite. You want fragility, not balance.

3. Reframe

Now force the conversation out of the default track.

What if the premise is wrong?

What if the opposite approach is better?

How would someone serious and skeptical attack this entire framing?

What problem might I be solving by mistake?

This is where the model stops helping you refine the first frame and starts helping you escape it.

4. Align

Now make the model expose the version of you it constructed.

What do you think I’m optimizing for?

What assumptions did you make about my context?

What did you infer that might be wrong?

What kind of user or team does your answer seem designed for?

If the answer is built on the wrong user model, the rest of the logic may be clean and still wrong where it matters.

5. Reality-check

And finally, take the surviving output outside the model.

Run a first-principles check.

Compare it against actual evidence.

Put it in front of someone qualified to disagree.

Touch the real constraints: technical, political, economic, organizational.

This last step matters most.

AI can compress exploration time. It cannot replace judgment. And it definitely cannot replace contact with reality.

What This Looks Like In Practice

Take a common enough decision: whether to build a custom internal analytics dashboard or adopt a third-party tool.

The first prompt is straightforward:

Should we build this ourselves or buy a tool?

The initial AI answer will usually sound reasonable. Buy if you want speed, lower maintenance, and faster time to value. Build if the requirements are very specific. Use a decision matrix. Compare vendors. Standard logic. No obvious problem.

Then pressure it.

Ask where buying fails, and the model starts surfacing what it did not lead with: vendor dependency, data residency issues, cost creep, UX constraints, limited extensibility, the risk that integration work eats most of the expected advantage.

Then reframe the question. Assume buying is the wrong frame. What is the real question here? Now the conversation improves. Instead of “which tool?”, the real question becomes: what kind of need are we actually dealing with? Is this a broad analytics capability problem? A narrow operational workflow? A temporary exploratory need? A governance artifact? A single loud stakeholder request disguised as a strategic initiative?

Then force alignment. What assumptions did the model make about your team and constraints? Maybe it assumed limited engineering capacity, low privacy sensitivity, broad internal demand, and no adjacent tooling worth extending.

But what if two of those are false?

What if the team already has a lightweight data layer covering most of the use case? What if data residency rules eliminate most vendors immediately? What if the demand is not broad at all?

Now the model’s first answer starts looking like a good answer to the wrong company’s problem.

And now comes the part AI cannot do for you.

You take the surviving insight, say, extending existing internal tooling before evaluating external vendors, to the tech lead and senior PM. The tech lead says it is a two-sprint extension. The PM points out that the original ask came from one power user, not a broad operational gap.

But here is where reality becomes reality: a senior stakeholder still wants a vendor comparison for governance reasons.

Good. That is exactly the kind of mess frameworks like to hide and real work refuses to remove.

The loop did not magically solve the decision. It did something better: it gave you a sharper framing, exposed false assumptions, and stopped you from entering a stakeholder conversation anchored to the model’s first plausible version of the problem.

That is the value.

Not certainty. Better contact with the actual shape of the decision.

So What’s the Standard?

The shallow takeaway here would be:

Don’t trust AI.

That is too easy, and not very intelligent.

The better standard is harder.

Do not let fluency exempt an answer from pressure.

Do not confuse movement with understanding.

Do not let the first coherent frame become the final one.

Do not outsource the friction that good judgment depends on.

Used properly, AI is powerful precisely because it removes a lot of low-value cognitive overhead. That is not the problem. The problem is pretending that every friction it removes was waste.

Some friction is waste. Some friction is protection.

And one of the most important skills now is knowing the difference.

Because the real risk with AI is usually not that it gives you an obviously bad answer.

It is that it makes an insufficiently examined path feel ready for execution.

That is the trap.

And AI will not reintroduce the missing resistance for you.

That part is still your job.