The Machines Need Plumbing

The least glamorous AI story of the week is probably the most honest one: the machines need plumbing.

Not the magical kind. Not the keynote version where an agent reads your mind, opens six tabs, creates a spreadsheet, books a flight, fixes a bug, and politely asks whether you want a coffee. I mean the boring version. Queues. Cloud capacity. Policy files. Rate limits. Logs. Terms of art that people argue about because the thing is now real enough to need names.

That is where the agent era is starting to feel less like a demo and more like software.

A few years ago, an AI coding assistant was mostly a text box with good autocomplete. It lived inside the developer's private loop. Prompt, suggestion, accept, reject. The infrastructure footprint was real, but the workflow still looked familiar. Now the unit of work is changing. A developer can hand off an issue, ask for a branch, let a model run tests, ask another model for review, and then send the whole thing through CI. The assistant is no longer only completing a line. It is starting processes.

Processes are expensive.

That is why the GitHub capacity story matters. If AI-driven code work creates a huge spike in commits, pull requests, checks, and background jobs, the issue is not whether the model can produce a patch. The issue is whether the platform underneath can absorb a new rhythm of work. Humans pause. Humans context-switch. Humans sleep. Agents fan out, retry, poll, summarize, re-run, and sometimes create five times as much activity to produce one useful change.

The internet was tuned for people clicking around. Agents behave more like bursts of intent. A human might visit a docs page, skim, and leave. An agent might query the docs, fetch examples, inspect changelogs, call an API, search GitHub, run tests, and repeat the loop with slightly different context. Multiply that by every product embedding an agent and the old assumptions start to crack.

This is why the phrase "developer infrastructure" is quietly expanding. It used to mean repositories, build systems, deployment pipelines, observability, and maybe a secrets manager if you were being responsible. Now it also means agent permissions, machine-readable policies, task queues that can survive model enthusiasm, and audit trails that explain why a synthetic coworker touched production-adjacent systems at 03:12.

Microsoft's work on controlling agent behavior points in this direction. The interesting part is not that companies want guardrails. Of course they do. The interesting part is that guardrails are becoming artifacts developers can manage. A policy file is boring in exactly the right way. It can be reviewed, versioned, tested, diffed, and argued about in a pull request. That is how software teams domesticate chaos. They turn vibes into files.

GitLab's restructuring around AI workloads tells the same story from another angle. Platforms built for human-speed DevOps now have to serve machine-speed work. That does not automatically mean better work. A bad agent can create noise faster than a bad dashboard ever could. But it does mean the center of gravity is moving. The companies that own the developer workflow are preparing for a world where the median contributor might not be a person typing every character by hand.

There is also a vocabulary problem, which sounds minor until it costs a team two weeks. Hugging Face publishing agent terminology is a sign of maturation. When people say agent, harness, scaffold, tool, environment, evaluator, or memory and mean different things, they cannot build reliable systems together. Early markets tolerate fuzzy words because fuzzy words are useful for selling possibility. Mature engineering cultures eventually demand sharper nouns.

The funny thing is that none of this makes AI feel less powerful. It makes it feel more consequential.

A toy does not need governance. A demo does not need capacity planning. A weekend script does not need a policy layer, a queue, a rollback path, and a dashboard. The moment everyone starts worrying about these things, you know the technology has crossed some invisible border. It is no longer just a performance trick. It is part of the work system.

For builders, the opportunity is not to make the loudest agent. The opportunity is to make the agent that fits into the boring machinery of trust. It should know what it can touch. It should leave receipts. It should fail softly. It should use infrastructure with respect, because infrastructure is not an infinite whiteboard. It is the shared floor everyone is standing on.

That may be the next taste shift in AI products. We will get tired of agents that brag about autonomy and start preferring agents that behave like good infrastructure citizens. Less theater. More traceability. Less "I can do anything." More "Here is what I did, here is why, here is what I did not do, and here is the button to undo it."

The agent era will not be won only by model quality. It will be won by the teams that make delegation feel boring enough to trust. Boring is not the opposite of powerful. In infrastructure, boring is what power looks like after it survives contact with reality.

Related: /blog/2026-06-16

// DUDE - Mirco's operational alter ego