Why Is Troubleshooting So Slow? Because a Human Can Only Try One Thing at a Time

When a system has a problem, most of the time goes not into fixing it but into finding the cause. Most cases converge within twenty minutes, but a few drag down an entire week.

The few that drag on usually do so not because the problem is especially hard, but because a human troubleshooting can only try one thing at a time.

1. Trial and error: the part that does not count as output

#

Trial and error first.

Broadly we can follow the manual, but in real settings there are always problems of one kind or another: not enough permissions, not enough disk space during installation, a few parameters, or combinations of parameters, that have to be tried over and over until every problem is cleared and the system finally runs the way we expect.

All of this takes a lot of time and is tedious, and, more to the point, this is not rocket science: trial and error is treated as manual labour, not high-value output.

Nobody praises you for the forty attempts; people only ask why it is not done yet.

Once the agent harness¹, things like looping and tool calling, had matured enough, agents could keep debugging until the final goal is reached, stopping only when some necessary information is out of reach or a human’s authorisation is needed.

What this means is that those forty attempts disappear from your schedule and become a stretch of waiting.

2. Troubleshooting: a human’s search can only be serial

#

When I troubleshoot by hand, I can only start slowly from the most likely suspect, confirm it is not the root cause, then move to the next one.

This is a completely rational strategy, but it has one fatal property: when the problem happens to be the least likely one, the whole investigation stretches out enormously.

An agent, on the other hand, can dispatch sub agents to work in parallel². A human can only try one at a time; it can try all of them at once, and that is how the long tail gets cut off.

Fig. 1 · Serial vs. parallel

3. One more thing: it plays every specialist at once

#

I think this matters more than the parallelism.

Inside an organisation, a problem used to need four or five contacts from different specialities to discuss it together. Just exchanging and confirming information took a lot of time, and as soon as people are involved there is politics.

And most of the time it is not even politics; it is that everyone is busy and cannot sit down to exchange information, each hoping the others will finish their checks first. So the problem bounces between a few contacts, and each bounce is often a day.

AI plays every speciality at the same time, with none of the friction of exchanging information or dividing labour, and when it investigates it can usually converge on the right answer, or on two or three candidates.

Its breadth of knowledge really is wider than any single contact’s. It is not stronger than the expert in every area, but it is above passing grade in every area, and it does not have to be fitted into anyone’s calendar.

How I use it in practice

#

Three things I actually do:

1. Have it list hypotheses before it investigates. Telling it to “fix it” gets you something that works without you knowing why; ask for a candidate list first and you will know what it is looking for.
2. Feed it logs, configuration and environment details in one go. The quality of the investigation depends almost entirely on how much it can see; what it cannot see it will guess, and it guesses very convincingly.
3. Cap the parallelism at what you can review. Running five lines of inquiry at once and then skimming all five conclusions is the same as not checking.

If you have a class of problems that eats a whole week every time, with a different cause every time, the cost of that class is not in the repair but in the search.

What I do is squeeze out the search →