The Rise of the Systemmer

AI slop was a symptom

Last time I argued that slop is an effort problem — that AI didn't make software bad, it made low effort cheap — and that the cure is annealing: run the loop hot until the synthetic luck burns off and what's left is craft.

That was a fight about effort. It was the right fight. But it was the surface.

Because once you hold effort constant — once everyone is annealing, everyone is dogfooding, everyone is running the loop — a deeper distinction surfaces underneath it. Two people can pour identical effort into the same system and produce completely different work. The gap between them isn't discipline. It's what they were looking at the entire time.

Slop was the symptom. The thing underneath it is a way of seeing.

The bottleneck moved

For most of this trade's history, engineering was shipbuilding. You won by cutting the cleanest boards and joining the tightest seams. The craft was construction.

The boards cut themselves now.

A model writes the API, scaffolds the UI, stands up the data layer, ingests a codebase the size of a city and maps it before lunch. The plank-cutting — the thing we spent decades getting good at — is exactly the part that evaporated.

This has happened before. It happens every generation. And every generation makes the same mistake: it confuses the current bottleneck for the permanent one.

When the bottleneck was raw instructions, assembly was the craft — until the compiler ate it. When the bottleneck was the compiler, hand-tuned low-level code was the craft — until frameworks ate it. When the bottleneck was the framework, wiring and configuration was the craft — until the cloud ate it. When the bottleneck was infrastructure, standing systems up and scaling them was the craft — until AI ate it.

Each time, a generation of experts watched its hard-won skill collapse into a checkbox. Each time, they mistook the loss of their bottleneck for the loss of the work itself. And each time they were wrong, because the bottleneck never disappeared. It moved upward — toward intent, toward design, toward judgment.

It's moving again. This time it's moving off implementation entirely.

And the skill waiting on the other side of it isn't building. It's navigation.

The emergence of the Systemmer

The traditional coder operates by direct control. A requirement comes in, code goes out, and the line from cause to effect stays short enough to hold in one head.

That line is getting longer.

Modern software is agents, retrieval, event streams, ranking loops, persistent memory, evolving state — all interacting, all at once. The path from I changed this to that happened now runs through a dozen feedback loops you never touch directly.

So the unit of thought has to change.

That is the whole distinction, and it is larger than it looks. The programmer asks what does this do. The architect asks how do these fit together. The Systemmer asks what will this whole thing tend toward — left running, under load, over time.

It shows up the moment something goes wrong. A coder hits instability and hunts for the broken part. A Systemmer hits the same instability and hunts for the force producing it, because they already assume nothing is broken — that the system is simply doing what its incentives told it to do, and doing it perfectly.

A Systemmer's unit of thought is the system itself. Not the parts. The thing the parts add up to when no one is holding them in place.

Why it can't be taught

Ask an engineer to name the hardest thing to learn in this trade and they'll reach for something like writing a compiler. A compiler is hard. But a compiler is also teachable. There's a canonical text — engineers call it the Dragon Book — and a known path through it: lexing, parsing, the syntax tree, optimization, code generation, each stage feeding the next. Hand a determined person that book and a year of nights and they come out the other side able to build one. The same is true of a framework, a database, a kernel. The knowledge is explicit. It can be written down, handed over, and rebuilt intact inside another head.

Systems thinking has no Dragon Book.

The closest thing we have is Donella Meadows, and the most important thing she ever said is that it doesn't transfer. Drawing on Jay Forrester's work at MIT, she observed that people living deep inside a system can usually feel where its leverage points are — and then push them in precisely the wrong direction, worsening the problem while certain they're solving it. And even trained analysts, dropped into a system they've never seen, don't arrive with the right instincts. Their intuition isn't calibrated yet. Give them months or years inside the thing, she said, and they'll find the leverage. The rules don't port. They get re-earned, one system at a time.

That is the fingerprint of what Michael Polanyi called tacit knowledge — the kind where, in his phrase, "we know more than we can tell." It's the knowledge in a surgeon's hands and a sailor's grip on the tiller: real, decisive, and impossible to fully set down on paper. You don't get it from the book. You get it from exposure.

It's why MIT, trying to teach the dynamics of delay and feedback, didn't write a sharper lecture. They built a game. In the Beer Game, students run a small supply chain, and within a few rounds the orders swing wild, the warehouse floods or runs dry, and the players turn on each other — real arguments break out — until the lesson finally lands: nobody made a dumb mistake. The structure did it. The delay did it. You cannot be told that and actually know it. You have to sit inside the loop and feel it whip.

So here's the uncomfortable part. You cannot bootcamp a Systemmer. You cannot prompt your way into one. There's no curriculum that ends in a certificate, because the thing being learned isn't a body of facts — it's a calibrated intuition, and intuition only calibrates against contact with the real thing.

You must live it.

The sailor

A sailor does not command the ocean.

They can't. The wind has no interest in the plan. The current was there before the boat and will be there long after. The beginner fights this and loses. The expert stops fighting and starts reading.

A sailor reads forces. They identify currents. They trim a sail a few degrees and let leverage do the rest — because they know a small adjustment to a constraint produces an enormous effect downstream, and that the same effect could never be won by shoving on the hull directly.

That is exactly the Systemmer's craft.

You don't command a system into the behavior you want. You can't; it has too many forces, too many loops, too much momentum. You adjust the constraints. You move an incentive, a threshold, a boundary, a rate — and you let the dynamics carry the thing where you aimed it.

In a dead calm, those look like roughly the same job. In a real wind, they are not the same job at all.

The separation event

Here's the part I undersold last time.

What's happening isn't AI. It isn't slop. It isn't even coding. What's happening is a separation event.

For decades, the ability to build and the ability to steer were welded together — because you couldn't get anything worth steering until you had built it by hand. Construction was the toll you paid to even reach the interesting problem. So the two skills traveled as a bundle, we called the bundle "being a good engineer," and we never had to learn which half of it was actually ours.

Abundance broke the weld.

When construction costs nothing, it stops hiding what kind of thinker you are. Hand one person infinite cheap construction and they simply build more — faster, louder, in greater volume, oceans of disposable software. Hand another person the same gift and they go quiet and start asking what the whole thing is going to do.

That sorting was always coming. The Systemmer didn't appear in 2026. The role was always there, fused to the builder, invisible only because building was the bottleneck. The abundance of code didn't create it. It revealed it.

AI is not replacing either one.

It is revealing which one you always were.

Built and shipped by Deep Blue Dynamics. Reach Kord at kord@deepbluedynamics.com.

// transmission ends