Working with AI in 2026 -- Part 6
The IT Guy Who Listens
TL;DR: AI changes the cost of execution. It doesn’t change the cost of judgment. The person who keeps the diagnostic loop open, asks the question that reframes the problem, and knows what the system is actually for — that’s the human moat. That’s the IT guy who listens.
The infrastructure runs. The prompts are good. The system executes cleanly. So what are you doing?
This is the question Parts 1 through 5 were building toward. Not as a threat — as a genuine accounting. If the scaffolding handles the logistics, if the session structures carry context forward, if iteration is built into the process — where is the human contribution, exactly?
I think the answer is judgment. But that word is doing a lot of work, so I want to be specific about what I mean.
The first four parts of this series were about craft: how AI processes language, how context management works, how iteration functions as a method, how input quality shapes output quality. Part 5 was about economics: why AI changes the cost of building infrastructure, and what that infrastructure makes possible.
What I didn’t name in any of those posts — but what runs underneath all of them — is that every one of those layers requires someone who understands the system well enough to know when it’s working, when it’s drifting, and when the question being asked is the wrong question.
That understanding is not in the infrastructure. The infrastructure doesn’t know what it’s for.
Most people — and most systems — pattern-match until they have enough and stop.
This is not a flaw. It’s efficient. You get a plausible frame for the problem, you act on it, you move. The failure mode is when the presented problem and the actual problem aren’t the same thing, and you’ve already stopped listening.
A few years ago I got a call about app performance and throughput issues on a smart TV. Easy to start building hypotheses: streaming service problem, plan limitation, device issue. Instead, I asked how many WiFi bars showed on their phone when they were in the living room. Two bars — fifty feet from an access point with a clear line of sight. That’s not right. We checked the indicator LED on the AP. It was down. Rebooted it; it didn’t come back. Replaced it. Problem solved.
The diagnostic move wasn’t technical knowledge. It was a question that kept the loop open a little longer. The person calling had already framed the problem — app/TV/streaming — and I almost inherited that frame. The question was the intervention.
I don’t close the loop easily. I keep working a problem until it shifts into a different frame, until something that wasn’t visible becomes visible. The loop stays open by design.
Here’s what’s interesting about that in the context of everything else in this series.
A language model does the same thing as the failure mode: it pattern-matches to the most plausible completion. That’s not a criticism — it’s how the architecture works. The model closes the loop at the point where the training distribution says “this is likely what comes next.” It is extraordinarily good at this. It produces fluent, plausible, often correct completions at a speed no human can match.
But it doesn’t keep the loop open.
It doesn’t ask “wait — what are we actually trying to do here?” It doesn’t notice when the question being asked is a proxy for a different question. It doesn’t catch the two-bar WiFi signal hiding inside a smart TV complaint. It answers the question it was given.
The human who listens is doing something structurally different. Not slower, not less efficient — structurally different. The loop stays open until the actual problem is visible. That requires understanding the system well enough to know what questions reveal drift.
This is what I mean by the judgment layer.
Not all decisions require it. Most execution doesn’t. The infrastructure handles what it handles, and it handles it well — that’s the whole point of building it. But somewhere in every system there are decisions that require someone who understands what the system is actually for. Who knows the difference between the problem as presented and the problem as it actually exists. Who can make the architectural call that the system can’t.
That layer doesn’t get cheaper when execution gets cheaper. If anything, it gets more visible — because once the scaffolding handles the logistics, the human contribution is clarified rather than obscured.
Before AI made execution cheap, the human role was mostly execution. The judgment was in there too, but it was hard to see because it was wrapped in hours of work. When the execution cost drops, what’s left becomes more legible. The judgment layer is what remains.
The phrase “the IT guy who listens” sounds simple. It’s not meant to.
It implies that most IT people don’t listen — which has been my experience often enough to be honest about. The default move in technical work is to pattern-match fast, propose a fix, and move on. That works a lot of the time. It fails specifically when the framing is wrong.
The listener isn’t slower. They’re asking the question a beat before acting. That question — “what are we actually trying to do here, and is the problem I’m being handed the real problem?” — is the most valuable thing I bring to any engagement. It costs nothing and it changes the whole diagnostic.
In a world where AI handles execution at scale, that question becomes the work. Not in every moment — most moments are just execution, and the infrastructure handles it. But in the moments that matter, when the system drifts or the problem is misframed or a decision requires architectural sense — that’s where the human earns the infrastructure they built.
Parts 1 through 5 described the tools, the methods, the economics. This post is about who uses them and why it matters.
The infrastructure doesn’t know what it’s for. The prompts don’t know what they’re navigating toward. The session structures don’t know when something has drifted from the actual goal. The person running the system does — or should.
That’s the moat. Not the ability to use AI faster, or to build bigger systems, or to automate more. The ability to keep the loop open long enough to understand the actual problem. To ask the question that reframes the diagnosis. To be the person who listens.