Post

Lots of ink spilled on "Loop engineering", but no one seems to connect it to its much older name: Cybernetics. Maybe by the year's end, we'll recognize that it was all Control Theory engineering all along.

The "loop" everyone's excited about (perceive state, compare to goal, act, observe, repeat) has been the fundamental architecture for goal-directed systems since 1948. We keep rediscovering cybernetics. And it's very much connected to precursor-AI. x.com/omarsar0/st...

Norbert Wiener coined "cybernetics" from the Greek kybernētēs, or "steersman." The field was about one question: how does a system observe its own state, compare it to a goal, and act to close the gap? His canonical example was a gun turret tracking an aircraft.

Wiener (cybernetics), von Neumann (computer arch, game theory...too many to name), Shannon (info theory) were all in the same room. The question "can a machine regulate itself toward a goal?" was the question of both cybernetics and AI. Same project, before the fields diverged.

McCulloch & Pitts modeled neurons as logical threshold units in 1943, the direct ancestor of neural networks. They were cyberneticists first. Feedback, not logic, was the original frame for machine intelligence.

This pattern didn't stay in academia. Google's Kubernetes is named deliberately from kybernētēs. This isn't a coincidence. The designers knew exactly what they were building: a system that regulates itself toward a desired state in the presence of disturbances.

That's why Kubernetes is all declarative programming with YAML files. You declare the state of the system that you want your cluster to be in, and the underlying system works to return to that state under perturbations like CPU, disks, and network going down or influx of traffic.

Its controller manager watches actual cluster state, compares it to desired state, and corrects continuously. Every reconciliation loop is a closed-loop regulator responding to hardware going up and down. Kubernetes is applied cybernetics. Explicitly.

Loop engineering is the same architecture again. The LLM is the controller. The environment (filesystem, tests, GitHub) is the plant (sys being controlled). Your goal spec is the setpoint. Same structure as the gun turret. Same structure as the Kubernetes reconciliation loop x.com/mvanhorn/st...

What's new isn't the loop. It's that the controller is now expressive enough to handle unstructured goals: natural language specs, ambiguous tasks, open-ended iteration. That's the actual innovation. Not the feedback loop itself.

"How do I design the loop?" is the wrong question. Instead, how do we get stability, convergence, and disturbance rejection out of an agent controller?

More interestingly, what are the processes that exist to maintain equilibrium in the system that is your company or your personal life? Bug fixing maintains software utility in the face of feature addition perturbances.

Customer support maintains financial viability in the face of changing product and customer needs. I'm sure you can think of others. It's now possible to run our lives or our companies like we run Kubernetes. Control theory has 75 years of tools for this. We should use them.

I have nothing useful to react, but leaving a comment that I enjoyed this post and in general your deeper posts to encourage you to post more and say thanks! :D

Ah, thanks! I have another thread about the Ferrari Luce sitting in drafts that I should publish, if that's the case.

0 reposts3 likes

Yeah, for what it's worth when I see your avatar I always think it's going to be a quality post :).