How to read an AI-advice thread

I get sent these threads constantly. A practice owner reads one over the weekend, decides their AI problem is really a setup problem, and forwards me the screenshot Monday morning. So I read a lot of them.

Last week it was a thread on setting up Claude Projects. "Most people treat Claude Projects like a folder with a label on it," it opened. Then a 6-part blueprint, a copy-paste template, and a promise: 45 minutes of setup buys back 6 work weeks a year.

Some of it was genuinely good. Most of the certainty wrapped around it was manufactured. Telling those two apart is most of what keeps a practice from burning a quarter on advice that sounded airtight. Here's how I read one.

The receipt that proves nothing

Every thread like this opens with a receipt. This one: "I spent three weeks testing every possible project configuration. I rebuilt the same project twelve times until the output was consistently excellent."

Read that as what it is: a credibility prop. There's no metric behind it. "Consistently excellent" against what scale? Measured how? Twelve rebuilds of what task, scored by whom?

Later it gets bolder: "I tested this by removing each component one at a time and measuring the difference in output quality. The drop was immediate every single time." That's the language of an experiment with none of the parts of one. No baseline, no rubric, no numbers. You can't cleanly measure writing quality by deleting a paragraph and eyeballing the result, which is the only thing that actually happened.

When a thread shows its work, the work is usually a story.

The math that falls apart when you do it

The payoff is where these threads stop being careless and start being wrong. This one promised "a 90% reduction in editing time across every single task."

Then it did the arithmetic, and the arithmetic used a different number: "If you use Claude for two hours a day and this saves you 60% of your editing and correction time, that is over an hour saved daily. Five hours per week. Over 250 hours per year. Six full work weeks."

90% in the headline, 60% in the math. An hour saved out of 2 hours that were supposedly almost all editing to begin with. 250 hours resting on a 60% that rests on nothing. Every number leans on the one before it, and the first one was invented.

I run these calculations for practices for a living. Real time savings from a good AI setup are real and worth chasing. They're also specific, smaller, and they never round up to "six work weeks of your life back."

The mechanism that's actually folklore

The slicker threads smuggle folk wisdom in as engineering. The tell here was the identity instruction: tell the model "you have been working with me for two years" and it "defaults to confident, specific output rather than generic safe output."

Part of that holds. Giving a model a clear role and a concrete audience does change the output. The fictional tenure does almost nothing. What's carrying that example is the line right after it, the one naming a specific audience and a specific job. The thread credited the result to the wrong half of its own example.

This is the most common move in the genre: find something that works, then explain it with a mechanism that sounds clever and isn't. The advice survives. The reasoning doesn't.

The thread breaking its own rules

My favorite tell is self-contradiction, because spotting it takes no expertise. This thread published a banned-words list: never use "leverage" or "utilize," never open with "In today's," never use em dashes, never write the "most people do X, the ones who do Y" cliché.

Then it closed: "Most people will keep using Claude Projects as labeled chat windows. The ones who build their blueprint today will never prompt the old way again." It broke its own rule in its own last line. A few paragraphs earlier it ran the "that is not a project, that is a labeled chatbox" move it would also tell you to cut.

A thread that can't follow its own rules for 4 paragraphs is telling you exactly how much it tested any of this.

What I kept

Here's the part that makes the genre worth reading at all. Underneath the props and the bad math, the structure was sound. Stripped of the certainty, this is what I'd actually hand a practice:

• Write specific instructions, not "be a helpful assistant." The model already knows how to be helpful. It doesn't know your voice, your patients, or the 10 things you hate seeing in a draft.
• Give it reference files. 3 of your best emails, a 1-page audience note, your real standards. This is the single biggest lever, and it's the step most people skip.
• One workflow per project. A project that handles intake, marketing, and billing handles all 3 badly.
• Turn every correction into a written rule. After a month, that list is the asset.
• Make it plan before it drafts. Outline first, write second.

That's about 20% of the thread. It's also most of the value.

How to read the next one

The structure in these threads is often fine. The certainty wrapped around it is the problem, and the certainty is easy to test. Find the receipt and ask what was measured. Do the math yourself. Check whether the mechanism explains the example or just decorates it. See whether the writer can follow their own rules to the end.

What's left after that is usually a short, useful list and a calmer set of expectations than the thread wanted you to have. Keep the list. Drop the rest. Then write your rule down, test it on real work, and look at it again in a month. That's the part no thread can do for you.