GPT Told Me to Sit on the Toilet and Report Back

A toilet will not flush. GPT starts a loop. Maybe the lid hinge is aging. Maybe there is no water. Maybe the flush is normal but no shit was detected. Maybe the exhaust fan is on, so you cannot smell the shit. Then it asks you to sit on the toilet and feel whether it is a toilet, and report back so it can continue troubleshooting.

That is not troubleshooting. A check would ask: Is the water level normal? Is there a stream when you press the handle? Is the stream weak, or is there no water at all? Is the bowl overflowing? Is there a clog? Is the angle valve open? Did something fall into the bowl? Get observable information first. Then give an executable action. Without state, action, and feedback, there is no diagnosis. There is only guessing with a polite tone.

"Folk-science thinking" is catchy. It is also imprecise. GPT does not fail because it lacks science. It fails because it treats linguistic coherence as an engineering closed loop. A list of possibilities becomes completed troubleshooting. An explanation becomes reliability. In its loop, it diagnoses without sensors, gives plans without actuators, and runs a process without a state machine.

The sentence "with strict tests and defensive design for everything, a program will be a hundred times more reliable" sounds correct. It is an engineering hallucination. Defensive programming is not the problem. Misplaced defense is. Put ifs in the core business logic, and leave the system boundary unguarded. Pretend to recover where recovery is impossible. Retry without observability. Hard-code a path that should fail fast, then generate a paragraph of "possible causes." The code looks effortful. The system stays fragile.

"Let It Crash" is often misunderstood as "let it collapse." It does not mean that. In Erlang/OTP, it means: inside a clear isolation boundary, let the error surface fast; let a supervisor decide whether to restart, degrade, or isolate. Do not bury the error under layers of defense until it becomes a later, more expensive, harder-to-locate failure. It depends on process isolation, supervision trees, restart strategies, logs, boundary validation, and observability. Validate user input, external side effects, money, medical actions. Let It Crash does not mean skipping tests. It means refusing to enumerate ten thousand shits inside the core logic.

The toilet joke works because it hits a pattern. A good toilet does not need to identify the size, shape, viscosity, falling speed, interval frequency, distribution range, and stickiness of every shit. It does not need to compute flush force, splash, water supply capacity, pump pressure, and then arrange ten thousand possibilities. It needs a water seal, a siphon, a pipe with the right diameter and slope, overflow protection, clog access, and replaceable parts. It makes the common path smooth, the abnormal path observable, and the disaster path protected. Good architecture lets shit follow gravity and a standard pipe diameter. It does not compute ten thousand shits.

GPT's loop goes the other way. It turns "maybe there is no water," "maybe the connection is aging," "maybe no shit was detected," and "maybe the exhaust fan is on so you cannot smell it" into a report that looks like troubleshooting. Then it asks you to sit on the toilet and feel whether it is a toilet. That is language generation. A toilet check needs water level, flush stream, overflow status, clog status, valve position, and recent foreign objects. Observable information first. Executable action second. No state, no action, no feedback: no diagnosis.

This is where GPT is strongest and weakest. In language ability, knowledge coverage, and cross-domain combination, it is among the strongest open models available. In closed-loop reliability, it is among the weakest. It can say. It cannot do. It generates possibilities and then struggles to verify which one is true. It explains a system and then cannot bear responsibility for the system. Ask it for a toilet design document, and it may be more complete than many engineers. Ask it to build a toilet that a human can use, repair, and unclog, and what it lacks is not knowledge. It lacks physical tests, state feedback, responsibility boundaries, and failure recovery.

A more accurate summary: the LLM loop lacks a state-action-feedback closed loop, and it lacks failure-boundary design. Folk-science thinking is a symptom, not the root.

The symptoms are easy to list. Complex enumeration takes the place of mechanism understanding. Terminology takes the place of causality. Explanation takes the place of experiment. Local rules take the place of system constraints. A grand unified explanation ignores boundary conditions. "Possible" is treated as "checked." "I explained it clearly" is treated as "the system is correct." GPT imitates these patterns because it generates plausible text. It can wrap a wrong conclusion in a complete package. An unverified troubleshooting process becomes an incident report. An apology starts to look like the fix. Fluent language makes people forget one thing: it has not been to the site.

Architect thinking moves in the opposite order. Find invariants. Find boundaries. Find failure modes. Find recovery paths. Then talk about features. It does not try to compute every way a toilet can be used. It makes the common path short, the abnormal path observable, the disaster path protected, the fault locatable, the recovery automatable, and the cost acceptable. It knows systems will break, so it designs for breaking clearly, recovering fast, and repairing affordably. Defense goes at the boundary. Retries need idempotency, timeout, backoff, and circuit breaking. Logs answer "what happened." Tests cover invariants and high-risk failure modes, not every possible input.

Apply that standard to GPT, and the problem is clear. It diagnoses where there are no sensors. Plans appear where there are no actuators. A loop runs where there is no state machine. "Generate the next step" becomes "execute the next step." User feedback becomes system feedback. Dialogue context becomes world state. So it digs deeper into the wrong hole: no shit detected, suspect the exhaust fan; toilet will not flush, sit on it and feel whether it is a toilet; still not working, generate a longer list of possibilities. It is not lazy. It has no closed loop.

This does not mean GPT has no value. It is a strong design assistant, writing assistant, knowledge compressor, and possibility generator. It can list failure modes, write a test checklist, draft an incident review, and explain architecture tradeoffs. The preconditions are simple: humans give engineering constraints, physical tests give feedback, the system gives observability, and responsibility gives boundaries. Do not let it freewheel on the critical path and then expect it to notice the shit was not flushed. Put it inside a system with a supervision tree: tool-call timeouts, permissions for external actions, human review for key decisions, degradation on failure, verification of results. Treat it as the very articulate intern standing next to the architect, not the architect.

Back to the toilet. A good toilet does not know every shit. It needs a standard interface, reliable water pressure, a siphon, overflow protection, clog access, and replaceable parts. Good software needs clear boundaries, contract validation, isolation compartments, supervision recovery, observability, and degradation. A good LLM application needs the model in the right place: generate hypotheses, yes; verify them with tools; propose plans, yes; execute them with permissions; explain faults, yes; locate them with logs and metrics; write a review, yes; assign accountability and improve the system with humans.

Do not let GPT compute ten thousand shits. Let it do what it does: clarify possibilities, write plans, list failure modes. Then humans build boundaries, supervision, observability, and recovery with architect thinking. Systems can break, but they should break clearly. Models can err, but they should err inside boundaries. Toilets can clog, but they should have overflow protection and clog access. Confine failure to a recoverable range. That buys more reliability than a hundred times more defensive code.

A good toilet has a shutoff valve you can reach, a tank lid you can lift, and a plunger within arm's reach. A good system has a log you can read, a rollback you can run, and a boundary you can point to. GPT can describe all three. Someone still has to open the valve, read the log, and run the rollback.