Even my family thinks I’m a little robotic. Logical, linear, sequential, methodical. But hey, I’m an engineer, and that’s part of what makes me good at my job.
If I were operating on the same volatile cocktail of emotions, knee-jerk reactions, and intuition that most people operate on, I wouldn’t have been nearly as effective building enterprise software architecture at Disney, Dell, SAP, VMware, and now Control Plane.
Worse yet, I might have had to become a marketer, or a designer, or a human resources specialist…or even a salesperson.
Not very long ago (in 2024, and for fifty years before that), software engineers like me were the best robots anyone had access to. The CIO at Disney would ask me to redesign FastPass from the ground up, and I would do it in one long-running process over a weekend while he sipped coffee and watched the game. The head of Dell’s Identity Management business would bring me a huge project, and I would dive in, writing thousands of lines of code by hand.
And even though I was pretty consistent and logical, and so were (most of) my engineering colleagues, things could get messy fast. That’s where platform engineering came in, and that’s when I met Dan.
Dan Wilson was this brilliant platform engineer at SAP/Concur. He was one of the early open source contributors to a lot of fundamental projects. He knew Kubernetes like an old friend, and he could make your cloud infrastructure sing.
I loved working with Dan because he got my logically organized code to production more logically and a heckuva lot faster. A merge to main kicked off a containerized build, then unit tests, integration tests, and a security scan, and every stage had to pass before the image was promoted to the next environment. Deployments were declarative, the desired state lived in version control, and Kubernetes made the cluster match it. It warmed my engineer’s heart to watch the CI/CD pipelines hum through their stage gates.
But the whole process, the whole platform, was still made for engineers. It assumed deep technical knowledge. It required strict compliance with established protocols. It wasn’t hard. It was just logical. Just a little robotic, but that was fine because it was designed for people who were a little robotic…at least a little more robotic than the average person.
I mean, what engineer would try to name a production database final_v2_USE_THIS_ONE? (Several, it turns out. But they had the decency to feel bad about it.) The platform never had to defend against this behavior, because the people using it were not completely normal humans.
We designed internal platforms for engineers who read the docs (allegedly), knew what a rollback was, and had a decent sense of when not to deploy.
That is so Oct 2025
But then Opus 4.5 was released and everything changed. Or more specifically, everyone changed. Everyone changed from being a normal human to being an engineer…just without the pocket protectors, inside jokes, and strict adherence to protocol. The systems that took me weekends at Disney could now be vibe-coded by the receptionist in a few hours. And they would work (they might not be secure or performant, and they might be a usability train wreck, but bear with me).
Everyone was now an engineer because everyone now had agents. They had their own little fleet of Dorons doing their bidding. GitHub’s 2025 Octoverse report counted more than 36 million new developers joining in a single year, more than one every second, for a total past 180 million.
What this means for platform engineering is that now the humans using the platform act more like humans than they ever have. They improvise. If the form won’t take their input, they find another way in. They share the password because sharing is polite. They ask the person at the next desk instead of reading the docs, and they copy whatever worked last time, even if last time was a different project in a different region. They name things for other humans, so production ends up running something called “Q4 launch page FINAL (Jen’s edits).” These aren’t really flaws. In most of the company, they’re called “initiative”. Or “creativity”. But you might also call it “chaos”.
Of course, engineers are creative too. But what we’re about to see…what we’re already seeing…is an EXPLOSION in creativity entering the software development world. Because now creativity of all sorts, from all sorts of very non-robotic people, has been given direct access to the code. Musicians. Copywriters. Recruiters. The finance lead who has opinions about dashboards. These are people who were never going to learn a programming language, and now they don’t have to. They bring taste, empathy, and a feel for what customers want, which the old pipeline often filtered out long before anything reached production. They also bring their own idea of what “done” means and no idea how a typical internal developer platform operates.
But these new humans and this explosion in creativity are here. And they’re not going away. So platform engineering has to find a way to harness all this creativity without it taking anything important offline or leaking company secrets all over the internet.
Making room for the more-human builders
Here’s what I think needs to happen for that to take place.
The rules have to move out of people’s heads and into the platform.
For as long as most of us have done this work, the guardrails lived inside the engineers…at least in large part. Nobody had to tell a senior engineer not to expose a database to the internet, not to paste an API key into a chat window, or not to name a production table test. They had learned it the hard way, usually at 2am, usually once. Those lessons got passed along in code reviews, in onboarding, in the raised eyebrow of a colleague. The platform didn’t have to enforce what its users already believed. It could be a little naive, because its users weren’t.
That arrangement is finished. The copywriter shipping a landing page has never been paged at 2am, and I hope she never is. The recruiter building an interview scheduler doesn’t know a public bucket from a private one, and there’s no reason she should. The finance lead with opinions about dashboards will happily connect one to the production database, because that’s where the real numbers are. They’re doing what every smart, motivated person does with a new tool: click around until something lights up.
So the platform has to know these things on their behalf. Every app has to get its own identity the moment it’s created, scoped to what it needs and nothing more. Secrets must get injected at runtime, not handed to a person, so there’s nothing to paste into Slack and nothing to save in a notes app for later. Policies have to check every change before it lands: no public endpoints without a reason, no direct line from a dashboard to the production database, no resources without an owner. Every deployment has to go out small, get watched, and roll itself back if the numbers turn bad.
When the platform does have to say no, it should say it the way a good colleague would. Not “Denied by policy 0042.” More like, “This would make your customer list public on the internet. Here’s the setting that keeps it internal.” An error message is the closest thing these builders will ever get to that raised eyebrow, so write it like one.
Done well, most of these new more-human builders never notice any of this. And that’s as it should be.
Agents, the less-human builders
But wait a minute. We’ve had an explosion in human creativity entering the platform engineering chat, but we’ve also had a super explosion in agents…who are more robotic than any of (well, most of) the engineers I’ve ever worked with.
Here’s what I mean. An agent will read every line of your documentation, which already puts it ahead of most of us. It follows instructions exactly. It doesn’t get bored, doesn’t take lunch, and doesn’t get a nervous feeling in its stomach before touching production. Give one a task at 6pm and it will still be working at 6am, cheerfully, having opened more pull requests overnight than your team reviews in a month. And it’s never just one agent. It’s dozens, then hundreds, each one launched by a person who has already moved on to something else.
The new humans get into trouble by improvising around the rules. Agents get into trouble by following them perfectly, including the ones that are wrong and the ones you never wrote down. Ask an engineer to “clean up unused resources,” and she knows that doesn’t mean the production database that’s quiet because it’s Sunday. An agent may not.
When an agent hits a wall, it doesn’t stop to ask someone. It retries, and then tries another route, and then another, until it finds a path that’s open. That’s the agent version of a marketer finding another way in, except it happens in four seconds and across forty services. And it’s always confident. (Incidentally, In all my years working with engineers, I’ve met a few who were never unsure of anything. I didn’t put them in charge of production, either.)
Agents don’t learn the 2am lessons any more than the copywriter does. Most of them start every session fresh, with no memory of past outages and (just as important) none of the emotions that come with them.
So what do we do about these less-human engineers?
Every agent has to be treated as its own accountable actor, with limits set for machine speed rather than human speed.
That starts with identity. Every agent has to have its own identity, tied to the person who launched it, with permissions scoped to the task and an expiry that matches it. When the task ends, so does the access. Then it needs a speed limit: a cap on how many changes it can make, how many resources it can create, and how much it can spend in an hour, so a loop that would have done damage at machine speed hits a ceiling instead. Agents should do their work in preview environments that look like production but aren’t, and changes should reach production only through the same small, watched, self-reversing rollouts the humans use. Every action has to go into an audit trail that answers “which agent, launched by whom, to do what.” And there has to be a kill switch that someone can find in under a minute.
Most importantly, the rules have to be written down, in a form a machine can read. The unwritten rules your platform used to depend on simply don’t exist for an agent. When it breaks one, the platform’s answer should be a clear, structured reason and the specific thing to change, so the agent fixes its request instead of hammering the same door 500 times.
Here’s the good news. Once the rules are written down, agents become the most reliable builders you have. They don’t argue with the template, skip the checklist, or decide the standard doesn’t apply to them this one time.
Taking a page from Kubernetes
I’m optimistic about our ability to build for these new platform users, and the reason is Kubernetes. We’ve solved this problem before. Just not for people.
Before orchestration, running software at scale meant a person watching servers. Someone noticed a process had died and restarted it. Someone decided which machine had room. Someone approved every change. That worked with a dozen servers and fell apart at a thousand. Kubernetes didn’t fix it by hiring faster operators. It changed the contract between the operator and the work, and four parts of that contract map almost exactly onto the new builders.
You declare, it reconciles. You don’t tell Kubernetes how to keep three replicas running. You say you want three, and a control loop works continuously to make it true. That’s what the new humans need. The copywriter should be able to say “a landing page customers can reach, that can read the product catalog,” and the platform works out the identity, the network, the secrets, and the rollout. Agents get the same contract in its most literal form. A spec is exactly the kind of thing an agent is good at writing.
Every request goes through admission. Nothing gets into a cluster without passing the admission controllers, where policy can reject the request or fix it. The API server doesn’t care whether the request came from a senior engineer, a CI pipeline, or a script someone found on Stack Overflow. That’s the attitude platforms need now. A change from the designer, a change from an agent, and a change from Dan all go through the same door and get checked against the same written rules. There’s no VIP entrance for people who “know what they’re doing.” (Sorry, Dan.)
Limits are part of the spec. A container declares the resources it needs and the most it’s allowed to use, and a namespace can carry a quota. One runaway process can’t starve the cluster, because the ceiling was set before it started. That’s the agent speed limit from earlier, and it isn’t a new idea. It’s a resource quota for builders.
Assume failure, and heal on your own. Kubernetes expects containers to crash, and it doesn’t take it personally. It checks health, restarts what dies, rolls changes out gradually, and rolls back when the new version isn’t ready. Builders deserve the same treatment: assume any change might be wrong, whoever made it, and make being wrong boring.
Kubernetes let a handful of people run tens of thousands of containers without knowing what was inside them. The next job for platform engineering is letting a handful of people support thousands of builders (humans, engineers, and agents) without needing to know what’s inside their heads.
More human, and less
Platform engineering has to become more human and less human at the same time.
Less human in how it enforces things. No rule that lives only in someone’s memory. No review that depends on someone being awake. No guardrail that relies on a raised eyebrow. All of that becomes control loops that run at 3am without complaint.
More human in how it talks. It takes intent instead of instructions. It explains a “no” in plain language. It lets a recruiter build something real without first becoming me.
Dan used to make my infrastructure sing. The job now is orchestrating a much bigger choir: thousands of new voices, some who have never seen sheet music, some who read it perfectly and far too fast, and a few old robots like me. Kubernetes taught us how to orchestrate containers. Now we have to do the same for the humans, the sort-of-robotic humans, and the definitely-not-humans, all on one platform.
