Your Logic Is Fine. Your Premise Expired an Hour Ago.

I spent an hour with my assistant debugging a blank window. Every explanation it gave me was well argued. Every one was wrong.

Twice during that hour I said "maybe just restart it." Twice it talked me out of it, with reasoning that sounded solid.

Restarting fixed it in about thirty seconds.

The setup

I was working on the Linux build of a remote-desktop app, running inside the Linux environment on a Windows machine. The goal was a small opt-in flag that makes the desktop build show the app's existing phone interface.

It worked. The assistant confirmed it with logging, I confirmed the normal desktop view still looked right, and we had a clean baseline.

Then the phone view came up as a blank grey window.

The first explanation was real

The assistant went and read the source code for the launcher and found something genuinely interesting. On Linux, the window is created invisible, at zero opacity. The desktop startup path reveals it once it's ready. The phone startup path never does, because phones don't have a window to reveal.

A real difference in the code. It explained the symptom perfectly. The assistant wrote a fix.

Still blank.

So it instrumented everything. The window reported full opacity, visible, the right size, the right position, no errors. Then it swapped the whole interface for a plain red box, just to see if anything at all could paint.

Blank.

Then it ran the same red box on the desktop path. The one that definitely worked an hour earlier.

Blank.

The moment that should have stopped everything

That result contradicts the baseline. The desktop path worked. Now it didn't, with a red box, which is about the simplest thing you can draw.

The right response is to stop and ask what changed. Instead, the assistant built a second explanation.

Partway through, to iterate faster, it had switched from the project's full build script to a quicker bare build. The full script does more. So, obviously, the shortcut was producing a broken app. It reverted every change, rebuilt with the proper script, and ran it.

Still blank.

What it actually was

We'd launched and killed something like fifteen graphical apps in one session of the Linux environment. Its display system had quietly wedged. Every app rendered blank, including ones that had rendered fine minutes before from the exact same file.

One command, wsl --shutdown, restarted the Linux environment. Everything drew again.

None of the code changes had anything to do with it.

Valid logic, expired premise

What gets me about this is that every step of the reasoning was sound.

The opacity difference was real. The build script difference was real. Each conclusion followed from what came before. The problem was underneath all of it: a premise that said "the baseline still works." That had been true an hour earlier. It stopped being true at some point, and nobody re-checked.

A chain of reasoning carries its premises forward invisibly. You don't re-examine step one while you're on step six. You assume it, because you checked it, and checking it felt like settling it.

When two results contradict each other, don't interpret a third one. Re-run the case you know passes.

That one habit would have saved most of the hour. The moment the red box failed on the desktop path, run the original working version again. When that fails too, the code is off the hook and the environment is the suspect.

Two more habits from the same hour

Don't change your method mid-investigation. Switching build scripts to go faster added a whole new variable. If you must switch, re-establish the baseline straight away with the new method, before you test anything else.

Suspect the environment before the code when displays are involved. Displays, compositors, emulators, simulators, long-running sessions: these degrade over time while your code sits still. If something that worked stops working and you haven't touched it, look at what's been running all day.

The hunch you can't justify

This is the part I think about most.

"Maybe just restart it" isn't reasoning. I couldn't have defended it. I didn't have a theory. I just had a feeling that we'd been poking this thing for a while.

But that's exactly why it was valuable. It came from outside the frame the assistant was reasoning inside. Every argument against it was built from the same stale premise that was causing the problem. The hunch wasn't trapped by that premise, because it wasn't built on anything.

An AI assistant is very good at producing a reason not to do something. It can always articulate why the restart won't help. The person offering the hunch usually can't argue back, so the hunch loses.

The fix is about cost, not who's right. A restart costs thirty seconds. An hour of confident debugging costs an hour. When a cheap test is on the table, run it first, and argue about it afterwards.

The confidence is what makes this kind of mistake dangerous. A confident wrong answer doesn't just fail. It stops you looking anywhere else.