ublo
bogdan's (micro)blog

bogdan » Platform Engineering in the Agentic Era

11:02 pm on Jul 10, 2026 | read the article | tags: ideas

We spent the last decade optimizing the technical substrate. We built internal tools, automated cloud infrastructure, streamlined CI/CD, and simplified deployment pipelines. It worked. And by automating away the mechanical friction of software delivery, we exposed the one underneath it.

As generative models and LLM coding agents make software implementation faster and cheaper, the bottleneck has migrated.

The limiting factor is often no longer whether the code can be written, but whether the human system surrounding it will pay attention, agree, decide, review, and act.

More of our highest-leverage work now applies the same hacking instinct to the organization itself: attention, incentives, trust, and coordination. I do not mean manipulation or political maneuvering.

The Migration of Latency

To understand why our day-to-day feels different, look at a simplified delivery model:

$$T_{delivery} = T_{thinking} + T_{implementation} + T_{coordination} + T_{approval} + T_{waiting}$$

Historically, \(T_{implementation}\) was often one of the dominant costs: infrastructure toil, repeated setup, and raw coding took time.

Today, coding assistants are shrinking the implementation part of that equation, while \(T_{coordination}\), \(T_{approval}\), and \(T_{waiting}\) do not automatically scale with an LLM license. They are bound by human bandwidth.

The paradox of this accelerated era is that individuals become faster while organizations fail to become proportionally faster. As technical execution gets faster, organizational latency takes up a larger share of total delivery time.

From Infrastructure to Coordination Engineering

When the bottleneck moves, the engineering instinct doesn’t change. The medium does. Experienced platform engineers are quietly repurposing their systems thinking from microservices to people.

There is a direct structural analogy between solving technical friction and solving organizational friction:

The optimization target across both columns remains identical: shorten the feedback loop between hypothesis → action → observation → correction. A slow approval chain and a slow CI pipeline differ in execution, but both make iteration expensive.

We are no longer just mapping API endpoints; we are mapping the undocumented interfaces of our organization. It’s still systems engineering. But the components are human.

The Unplanned Control Plane

In distributed systems, a control plane does not perform the primary workload itself. Instead, it maintains the conditions under which the system can successfully run by configuring routing, reconciling competing states, applying policy, translating intent, and reacting when actual state diverges from desired state.

That is what many of us are now doing inside organizations. We have become the control plane nobody designed.

This is especially true in machine learning platform roles, where problems rarely arrive as clean, bounded tasks. When an internal customer says, “The model cannot deploy,” the root cause is rarely a single broken line of code. It is a tangled knot of IAM roles, cloud quotas, networking policies, and data contracts spanning three different teams.

The architecture of a technical problem and the architecture of an organization rarely align perfectly. Problems cross the boundaries of formal ownership, and someone has to absorb that ambiguity.

Work develops a gravitational pull toward reliability. The organization implicitly learns: “Give it to them. They will figure out what is actually wrong.”

The difference is that while software control planes scale horizontally, human ones break down under load. Worse, the state they maintain – trust, context, informal ownership, half-finished negotiations – often cannot be failed over cleanly to another person.

The Shock Absorber Paradox

This creates a dangerous systemic pattern: we become organizational shock absorbers.

A firefighter responds to visible outages. A “glue person” connects gaps between formal responsibilities. A shock absorber quietly prevents internal organizational turbulence from reaching the outside service boundary.

The organization sees a stable interface: deployments happen, internal customers remain supported, and delivery matches expectations. They do not see the context-switching, the repeated negotiations, or the raw emotional effort required to manufacture momentum for work that would otherwise stall. Sometimes, the “platform” is simply the senior engineer who takes on another on-duty rotation because the alternative is letting the service boundary crack.

This creates a cruel failure signal loop. Successful compensation destroys system observability.

$$\text{Observed Team Performance} = \text{Sustainable Team Capacity} + \text{Invisible Extra Labor}$$

Because that extra labor is highly effective, the organization loses the telemetry that would reveal how fragile the underlying system actually is. Planning, staffing, and expectations are calibrated against a baseline that only exists because we are overextending.

The organization mistakes observed performance for sustainable capacity because the human control plane is hiding the difference. Our competence delays the repair of the very system that is exhausting us.

The Counterfactual Output

The most exhausting coordination work produces no durable artifacts.

Nobody can look at a git log or an executive dashboard and see the escalation that never happened, the project that didn’t stall for three weeks because we chased a dependency, or the architectural disagreement resolved quietly over a private Slack conversation. Its output is entirely counterfactual: it is the failure that did not become visible.

A deployed API gateway or a production inference platform can be demonstrated in a sprint review. The weeks we save through trust-building, context translation, and quiet coordination cannot. Yet, as technical execution gets faster, that invisible work can create more business value than writing more code.

The Reality of the Substrate Shift

As we move deeper into an ecosystem where machines take on more of the mechanical work of software implementation, the senior engineer’s role is splitting.

The machine loop is accelerating while the human loop remains stubbornly slow. Every improvement in execution makes the gap between what we can build and what we can coordinate harder to ignore.

If we find ourselves spending more time routing attention, building trust networks, and manufacturing consensus than writing software, we haven’t stopped engineering. We haven’t graduated, either. We have simply become responsible for a substrate nobody formally assigned us.

But as we navigate this transition, we have to ask ourselves the central system design question:

Are you actually improving the system, or are you just becoming the runtime mechanism by which its dysfunction remains survivable?