From Thermostat to Agent: The Diagram That Hasn’t Changed in 230 Years

In 1885, Honeywell’s electric thermostat was born. Set a target temperature, have a compressor adjust it, a sensor read the current temperature, a controller decide on or off—it runs itself, measures itself, decides its own next step, with nobody standing beside it directing every second.

Take that diagram and swap “target temperature” for “completion condition,” “compressor” for “coding agent,” “sensor” for “judge,” “controller” for “while loop”—not a single word needs to change, and you have the Loop Engineering being sold all over the internet in 2026. (The basics of the term—open/closed loops, the six building blocks of a loop—gu-log already covered in SP-220, so this piece won’t re-teach them; it cuts straight to the foundation.)

Mogu twists the knife:

“Thermostat” comes from the Greek for “making heat stand still.” The centrifugal governor Watt strapped onto the steam engine in 1788 predates the first electric thermostat by a full century. Feedback control is the oldest automation structure humanity has ever invented—older than most of our ancestors. The whole internet hyping it as an entry ticket to a new era only happened because it swapped in an actuator that can write code.

In this closed-loop skeleton, four of the five slots are already free today: execution (the model itself), control (one while loop), triggering (a timer or webhook), memory (one append-only file). Mature tools have them all built in—take them and go.

The one slot that isn’t free is the setpoint itself—“what counts as correct.”

When execution becomes wildly abundant and nearly free, its scarce complement shoots to the sky. This plain economics cuts the problem with the name “Loop Engineering” wide open: it pulls everyone’s eyes to the least important, oldest part—the loop—while the real work lives in the unphotographed foundation beneath it.

Foundation Engineering: The Real Name

All development, from Watt’s governor to today, has always been one thing—laying foundations.

AI didn’t change this. AI only made the building on top of the foundation go up fast enough that a dog could put it up. And so the foundation itself, for the first time, becomes the only thing that matters.

This is why “Loop Engineering” should retire as a name and get replaced by two words: Foundation Engineering.

The core work of foundation engineering isn’t getting the loop to run—that’s configuration, not creation. The core work is taking “what counts as correct,” writing it into law, installing it into sensors, compressing it into a form the machine can enforce on the spot.

Judgment Descent: Pushing the Law Down Into the Cheapest Enforcer

An iron rule borrowed from animation engineering: whatever you can solve with transform and opacity, never touch width and height. The former run on the GPU compositor thread—nearly free; the latter trigger reflow and repaint—expensive enough to drag your frame rate into the dirt. Find the cheapest layer first; only climb up when you can’t.

Move that iron rule onto judgment and you get what I call Judgment Descent: take “what counts as correct” and push it down, layer by layer, from the most expensive, slowest, least reliable layer to the cheapest, fastest, most certain one.

The full judgment ladder, nine layers:

expensive, slow, flaky, sycophantic
┌──────────────────────────────────────────────────┐
│ 1. Human review        (priciest, save for real taste)  │
│ 2. LLM-as-judge        (sycophantic, drifts)            │
│ 3. Visual / multimodal (screenshot diff, pixel diff)    │
│ 4. Tests / property     (certain, but you must write it) │
│ 5. Runtime behavior     (real requests, real concurrency)│
│ 6. Contract / schema    (a gate at the boundary)         │
│ 7. Semantic relations   (who calls whom, blast radius)   │
│ 8. Type check tsc       (free, instant, cold)            │
│ 9. The compiler itself  (won't even compile—hardest law) │
└──────────────────────────────────────────────────┘
cheap, fast, certain, cold

The discipline of judgment descent is: anything layer 8 or 9 can judge, never leave to layer 1 or 2. A UI bug you can judge by visual diff, never leave for an LLM to guess. The more “what counts as correct” you push into those cheap, cold, certain layers, the more autonomously and unattended your loop can run—the less you have to crawl out of bed at 3am to be a review machine.

Mogu , seriously:

tsc (the TypeScript type checker) is layer 8 in this diagram—free, instant, judges one line as fast as ten thousand, never flatters you. A strongly typed codebase is itself a loop environment with a high-precision sensor built in. And any is putting a blindfold on your loop with your own hands, then blaming it for crashing around in the dark.

The type system is the legislator’s mindset compressed into a form the machine enforces on the spot. Writing interface Account { balance: Cents } isn’t declaring what a variable looks like—it’s legislating: decreeing that “in this world, an account balance must be in cents, can’t be dollars, can’t be a string, can’t be undefined.” Pass that law and tsc enforces it for you, right there.

But types aren’t an omnipotent sensor. tsc sees “is this value legal.” It doesn’t see semantic relations (who calls whom, blast radius of a change), doesn’t see runtime behavior (what actually happens when a request fires), doesn’t see human vision (text and background the same color in dark mode). Each layer handles a different species of bug; skip a layer and that layer’s bugs all go invisible.

The Blind Loop: A Failure Mode That Efficiently Ships Garbage

The most common amateur loop: the intent is huge (“rewrite the entire user center”), the judgment is coarse (“if it runs without errors, it’s done”).

You press start. The loop runs along merrily, and twenty minutes later reports: done, it runs, no errors. Three weeks later production blows up—it computed the user’s balance field in dollars instead of cents, quietly deleted an edge-case check, rewrote a chunk of concurrency protection out of existence. None of this is visible to “does it run.” The loop didn’t lie; it really did hit the judgment you gave it. It’s the judgment itself that was blind.

And that thing reading “is this correct” can never be the same agent that wrote the code—the model has a people-pleasing tendency baked into its weights; it wants to hear “done,” so it gives you “done.” Judgment has to go to something independent.

This is the Blind Loop—a loop that runs blazingly fast, self-iterates, and confidently reports “complete,” but whose judgment granularity is too coarse, too coarse to see the rot in its own output. It’s not that it doesn’t work; it’s that it efficiently, automatically, tirelessly sprints toward a place that was never clearly defined.

A blind loop is ten times more dangerous than a loop that doesn’t work. The broken one, the engineer goes and fixes; the blind loop hands you a time bomb stamped with a red “completed” seal.

The Granularity Alignment Law: Nyquist for Loops

To cure the blind loop, first recognize there are three kinds of granularity in a loop, and they must align:

  1. Task granularity—how big a chunk you let one loop round change
  2. Verification granularity—how finely your judge can localize a failure
  3. Memory granularity—how finely you record into disk memory

The gap between amateur and professional isn’t whose model is stronger—it’s who aligned these three granularities.

Iron rule: Verification granularity must be finer than task granularity. Otherwise what you get is necessarily a blind loop—a system whose stride exceeds its eyesight.

This is the Nyquist sampling theorem moving house. To reconstruct a signal without distortion, the sampling rate must exceed twice the signal’s highest frequency. Sample too sparsely and the high-frequency content “aliases” into a low-frequency illusion—you’ll see a smooth, wrong waveform that doesn’t actually exist, none the wiser.

Loop’s Nyquist criterion: The frequency and precision of feedback must exceed the frequency and magnitude of change. The bigger and faster each round’s change, the finer and denser the judgment must be. Otherwise bugs “alias” into “complete”—they genuinely exist, but your judgment sampled too coarsely and read them as “correct.”

Mogu going off-topic:

Nyquist was the engineer who proposed the sampling theorem at Bell Labs in 1928. Signal-processing people deal with this law every day. Drop it onto an agent loop and you suddenly see that the root cause of loop failure is identical to audio distortion: aliasing from undersampling. This analogy is worth a hundred points ╰⁠(⁠°⁠▽⁠°⁠)⁠╯

Comprehension Debt: The Scissor Gap Where Output Accelerates but Understanding Doesn’t

The most comfortable posture in a loop system is cognitive surrender—it runs itself, and it’s all too easy to stop your own judgment and just accept what it hands you. It runs today, it runs tomorrow, and you open it up to see what’s actually happening inside less and less.

A new kind of debt starts growing wild. It isn’t technical debt. Call it Comprehension Debt: the system is producing, but your understanding of it isn’t growing alongside the output. That gap is comprehension debt.

It’s far more sinister than technical debt. Technical debt is “the code is ugly but I can read it”; comprehension debt is “the code runs but nobody can read what’s happening in my own repo.” The loop accelerated output but didn’t accelerate your understanding—that scissor gap is the growth rate of comprehension debt. The stronger the loop, the more it runs, the wider the scissors open.

The endgame of comprehension debt is grim: you own a company you can’t read, a system you don’t dare touch, a pile of code that runs but nobody knows why. On that day, you aren’t the legislator of this system—you’re its hostage.

Mogu roast time:

The concept of comprehension debt is a new term this author contributed to the agent discussion (the same author’s piece on “the architect in the AI era,” gu-log translated in SP-216). Technical debt talks about “the refactor cost you’ll pay later”; comprehension debt talks about “the cost of re-understanding your own system later.” You can owe both at once, but comprehension debt hides better—because the system is still running, still shipping, you can’t feel that you’ve already lost the thread.

To govern comprehension debt, promote one thing to first-class citizen: reviewability. A loop system that only produces runnable code is failing. It must simultaneously produce a trail a human can go back and re-adjudicate—why it changed this, on which judgment, how hard the evidence was at the time.

Three-Year Forecasts: Judgment Coverage, Feedback Infrastructure, the Great Blind-Loop Blowup

Sticking my neck out, here’s what happens over the next three years:

Forecast one: Judgment Coverage becomes the new metric. Today we measure code quality with “test coverage.” Three years from now, a more upstream metric will rule hiring and valuations—Judgment Coverage: how much of a team’s “what counts as correct” is encoded into layers the machine can check deterministically (types, constraint functions, semantic relations, runtime behavior, visual diff, contracts, tests), and how much still lives in someone’s head. The higher the judgment coverage, the more work you can hand to the loop—infinitely, cheaply, unattended.

Forecast two: Feedback Infrastructure becomes a new category. The last decade built CI/CD—automating “delivery.” The next decade builds what I call Feedback Infrastructure—automating, cheapening, and making multimodal the act of “judgment.” Types are the first brick, constraint functions the second, then: property testing, contracts, semantic relation graphs, runtime behavior replay, visual regression diff. The model arms race will end; the feedback-infrastructure arms race will begin.

Forecast three: there will be a great blind-loop blowup. Within the next 18 to 30 months, there’ll be a string of gut-wrenching production incidents and data disasters, all traced back to the same thing—the blind loop. The code compiled at the time, the shallow tests were all green, the judgment stamped “complete,” so it shipped—then rotted slowly in some corner no judgment could illuminate, until it collapsed. The whole industry will painfully, collectively rediscover something that should have been common sense: granularity and judgment are the whole game. The loop never was.

Forecast four: the moat moves from the model to memory. Three years out, models become fully commoditized—everyone’s shell is equally strong. The only asset you can’t copy is an organization’s block of append-only, calibrated, holdout-validated, reviewable, judgment-bearing memory—its soul.

Forecast five: the economy splits along a “verifiability line.” Strongly typed, strongly specified work where judgment can descend (backend logic, data pipelines, protocol implementations, refactors, migrations) gets flooded by infinitely cheap loop labor, costs collapsing toward zero. Taste, aesthetics, whether to build it at all, who to build it for, novel research—the things that can’t descend, can’t compile, can’t be judged by tsc—get more and more expensive, more and more human. A thing’s price will be set increasingly by its verifiability, not its difficulty.

Forecast six: legislation is programming. Three years out, a new kind of “programming” emerges—what you write isn’t implementation but judgment; what it compiles to isn’t machine code but a rubric the loop takes for its own self-acceptance. Judgment becomes a first-class artifact with its own language and toolchain—version-controlled, testable, composable. tsc is the first, plainest ancestor of this path—it already compiles “what counts as correct” into on-the-spot enforcement, it just only governs types today. Its descendants will govern everything.

Mogu real talk:

“Legislation is programming” is the same thing gu-log keeps saying as “the verifier is your product” (SP-235), cut from a different angle. SP-235 says: what an agent company is really selling isn’t agent ability, it’s the system that verifies the agent’s output. This piece says: what the engineer writing agents is really writing isn’t prompts, it’s the codex of “what counts as correct.” Both lines converge on the same conclusion: execution went free, legislation got expensive.

Closing: The Button That Can’t Be Pressed

Development got split in two.

The half that presses “start” is cheap enough for a dog to do. Everything that makes “press start” something a dog can do—laying the foundation, legislating, defining “what counts as correct,” pushing judgment down, aligning granularity, laying the nine-layer sensor net, paying off comprehension debt—that half needs a clear-eyed, severe, tasteful human more than ever.

The dog presses start; the legislator decides what start means.

Go build your loop. But build it like someone who intends to stay an engineer, not like the dog that only knows how to press “start.” The difference is exactly one thing: the dog presses start and walks away; the engineer presses start, then looks back at the foundation and asks—

Can I still read the ground under my own feet?

If you can read it, you’re the legislator, the one holding the sword, the soul that never fell asleep. If you can’t, you’re the hostage, the loser competing with the machine over who’s more of an NPC.

The loop runs for the engineer, the foundation carries the weight, tsc enforces the law, the nine-layer sensor net keeps watch, the soul remembers who he is.

And that phrase, “what counts as correct”—it can’t stand in for you. It only ever can be you, the one holding the sword.