TL;DR: Do not ask “how do I fix X.” Ask the model to produce a ranked list of hypotheses with a distinguishing test for each, then run the tests in order of cheapness and report results as data. You are using it as a diagnostician, not an oracle — and the discipline that makes it work is changing one variable at a time.
Why the obvious approach fails
You describe the symptom: “my internet keeps dropping.” You get eight suggestions — restart the router, update firmware, change the DNS, check for interference, replace the cable, contact your provider. All plausible. None ranked. So you try them in a semi-random order, change three things at once, and if the problem goes away you never learn what caused it. When it returns in a fortnight you start again from nothing.
This is not a limitation of the model. It is a badly-formed question. “How do I fix this” invites a list; “what could cause this and how would I tell them apart” invites diagnosis.
The method
Five steps, in order. The order is the method.
Step 1: Describe the observation, not your theory
The most common mistake is embedding a diagnosis in the question: “my router is failing, how do I fix it?” That commits everything downstream to a hypothesis you have not tested.
Write instead what is observably true:
“I am diagnosing a problem. Here are the observations, with no diagnosis from me.
SYMPTOM: internet connection drops for 20-60 seconds, then recovers on its own.
FREQUENCY: 4-6 times a day.
WHEN IT STARTED: about three weeks ago.
WHAT CHANGED AROUND THEN: nothing I am aware of.
SCOPE: affects laptop and phone on wifi. I have not tested a wired device.
PATTERN: seems more frequent in the evening, but I have not logged it.
WHAT I HAVE ALREADY TRIED: restarted the router once, no change.
ENVIRONMENT: [router model, ISP, connection type, approximate distance from router, flat or house].Do not give me fixes yet. First, list the 6-8 most likely causes ranked by probability given these specific observations, and for EACH cause give me the single cheapest test that would confirm or eliminate it. A good test distinguishes between causes — it should give a different result depending on which cause is real. Note which of my observations is missing that would most narrow this down.”
Step 2: Fill the information gaps first
The model will tell you what it needs — in this case almost certainly “have you tested a wired connection?” That single test splits the entire problem space in half: if a wired device also drops, the wifi is innocent and you are looking at the line, the router’s WAN side, or the ISP. If only wireless drops, you are looking at interference, channel congestion, or the access point.
Answer the gaps before proceeding. Diagnosis on incomplete observations is guessing with extra steps.
Step 3: Run the cheapest distinguishing test first
Not the most likely cause — the cheapest test that eliminates the most possibilities. Plugging in an ethernet cable takes two minutes and halves the search space. Replacing a router takes an evening and money, and tells you nothing if the fault was the line.
Change one thing at a time. This is the rule that people break and it is the reason problems get “fixed” without being understood. Three simultaneous changes followed by improvement teaches you nothing.
Step 4: Report results as data, then re-rank
“Test results: wired connection also drops, at the same times as wifi. Router logs show [paste exact log lines]. Drops correlate with the evening but occurred twice at 11am today.
Given these results, update the ranked hypothesis list. Which causes are now eliminated and why? What is the next cheapest distinguishing test?”
Paste raw output — log lines, error messages, command results — rather than your paraphrase of it. Your summary has already filtered out the detail that mattered, because you did not know it mattered.
Step 5: Confirm the cause before applying the fix
When you have a candidate cause, test it explicitly before fixing:
“My current hypothesis is [X]. What evidence would I expect to see if this is correct that I would NOT see under the alternative explanations? And what would disprove it?”
Confirming first means that when the symptom disappears, you know why. That is what stops the problem recurring in a month as a total mystery.
The same method on a completely different problem
To show it is not a networking trick — a spreadsheet that produces the wrong total.
Bad question: “My spreadsheet total is wrong, how do I fix it?” You get: check for hidden rows, check the range, check for text-formatted numbers, check for circular references. A list, unranked, and you start clicking.
Good question:
“Observations, no diagnosis from me. SYMPTOM: the SUM in cell H400 returns 48,210 but manually adding the visible values gives 51,887 — a difference of 3,677. SCOPE: only this column; the adjacent column totals correctly with the same formula structure. WHEN: the file was fine last week; three people have edited it since. NOT YET TESTED: whether the difference matches any individual row.
Rank the likely causes given these specific observations, and for each give me the cheapest test that distinguishes it from the others.”
The ranked response leads with the one the generic list buries: because the discrepancy is a specific number rather than a rounding-scale difference, check first whether 3,677 equals the value of one row or a contiguous block — which would point at a range that stops short of the last rows, the single most common cause of exactly this symptom. Test: change the formula range to cover the whole column and see whether the difference disappears. Ten seconds.
If that is not it, the next distinguishing test is a COUNT versus COUNTA comparison on the range, which separates “numbers stored as text” from “hidden or filtered rows” — two causes that look identical from the total alone.
Same structure, entirely different domain: observations without a theory, ranked hypotheses, cheapest distinguishing test first. If you work with data regularly, this pairs directly with cleaning a messy spreadsheet — most wrong totals are a data quality problem wearing a formula costume.
Why this generalises
The example above is a network fault because most people have had one, but the method is domain-independent. It works on a spreadsheet producing wrong totals, an application crashing intermittently, a car making a noise, a recurring billing discrepancy. The structure is always the same: observations without diagnosis, ranked hypotheses, cheapest distinguishing test, one variable at a time, confirm before fixing.
It works because it plays to what these models are actually good at — recalling the space of known causes for a described symptom and reasoning about what would distinguish them — while keeping the part they are bad at, namely knowing what is true in your specific situation, firmly with you. The observations are yours; only the hypothesis generation is delegated.
Where it goes wrong
- Anchoring. If you mention a suspicion early, the model will over-weight it for the rest of the conversation. Keep your theory out of step 1 entirely.
- Confident fabrication of specifics. Menu paths, exact command flags, and settings names for specific hardware are frequently invented. Verify against the actual documentation before running anything — and never paste a command you do not understand into a terminal.
- Agreeing with you. Ask “is it the router?” and you will often get agreement. Ask “what are the arguments against it being the router?” instead. Phrase questions so that agreement is not the path of least resistance.
- Losing the thread. Long diagnostic conversations drift, and earlier eliminated causes get resurrected. Every ten exchanges, ask for a restated summary: current hypotheses, eliminated causes with reasons, next test.
- Safety limits. Anything involving mains electricity, gas, structural work, or a vehicle’s braking or steering is not a domain for this. Diagnose to understand, then hire someone qualified.
The habit worth taking from this is smaller than the method: stop asking for fixes, start asking for hypotheses and tests. It changes the quality of what you get back on almost every technical question, and it is the same underlying principle as specificity in prompting generally.
About the author
Shahid Saleem is the founder and editor of PickGearLab. He tests AI tools in the real world – writing, automation, content – and writes up what actually worked. Based in Dubai.
New workflows, straight to your inbox.
Workflows like this one, as they are published. Free. Unsubscribe in one click.
Subscribe free →
