Platform engineering needs to become more human…and less | CNCF

Enroll your company as a CNCF End User and save more than $10K in training and conference costs
Posted on November 11, 2026 by Alejandro Chirinos, Control Plane
CNCF projects highlighted in this post
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.
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.
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 belie