And created a generation of burned-out engineers in the process
Industry executives and experts share their predictions for 2026. Read them in this 18th annual VMblog.com series exclusive.
By Rick Clark, Global Head of Cloud Advisory for UST
In April 2011, at the OpenStack Diablo Design Summit in Santa Clara, Dr. Debojyoti Dutta and I presented a proposal for a container project called Donabe. This was nearly two years before Docker launched. Our approach had one critical difference from what the industry eventually adopted.
It was built on the principle of declared constraints.
In our design, you didn’t just deploy a workload. You declared its constraints. You specified what you needed and what it should cost. The platform’s job was to determine the “how” that satisfied those rules.
The industry chose a different path. We forced engineers to declare the implementation detail, the “how” directly, without mechanisms to enforce constraints.
This choice might be fine if those implementation details were the domain of operations or infrastructure engineers.
But that is not what happened.
The Conflation Nobody Examined
Somewhere in the last fifteen years, the enterprise technology industry made a category error. We confused developer flexibility with developer productivity.
These are not the same thing.
Flexibility is the ability to choose. Any tool. Any database. Any deployment pattern. Any infrastructure configuration. The assumption was simple: if developers can choose anything, they will choose what makes them most productive.
Productivity is the ability to produce. To ship features. To solve business problems. To deliver value. Productivity requires focus. It requires that developers spend their time on work that matters, not on work that should have been decided for them.
Because of this conflation, everything shifted left.
Every choice a developer makes about infrastructure is a choice they are not making about the product. Every hour spent configuring a deployment pipeline is an hour not spent understanding the customer. Every debate about which observability tool to use is a debate that should never have happened.
Choice is a tax. We marketed it as a benefit.
The Burden We Called Empowerment
A decade ago, Cloud Foundry offered developers one command: cf push. The platform handled containers, networking, scaling, placement, health management. Developers declared intent. The platform owned implementation.
We said it was too opinionated. Not flexible enough. We wanted choices.
So we got Kubernetes. Every team building custom pipelines. Infrastructure as Code becoming Infrastructure as Drift. Hundreds of YAML files no one fully understands. Developers debugging networking instead of shipping features.
We traded one command for infinite configuration. And we celebrated.
What did we actually gain?
We gained the freedom to make thousands of infrastructure decisions that have nothing to do with the products we were hired to build. We gained the freedom to cover the same cognitive territory over and over again, team by team, project by project. We gained the freedom to burn out.
The platforms that “constrained” us were actually protecting us. Opinions are not limitations. They are decisions someone else already made so you do not have to. Every decision a platform makes is cognitive load a developer does not carry.
When we rejected opinionated platforms, we did not gain freedom. We shifted the burden of thousands of infrastructure decisions onto people who were hired to build products.
We called it empowerment. It was abandonment.
The Weight Developers Now Carry
Consider what we now expect from a single developer.
They must understand application architecture. They must understand infrastructure. They must understand networking. They must understand security. They must understand observability. They must understand cost management. They must understand incident response. They must understand their CI/CD pipeline, their container orchestration, their service mesh, their secrets management, their certificate rotation, their database operations, their caching layer, their message queues.
They must understand all of this while also understanding the business domain they were actually hired to work in.
This is not a job description. This is cognitive overload.
No human can maintain genuine expertise across this surface area. The expectation is not that developers will be excellent at all of these things. The expectation is that they will be adequate at most of them and heroic when adequacy fails.
The industry normalized this. We celebrated engineers who could “do it all” while quietly losing the ones who could not sustain the pace. We treated attrition as an acceptable cost of velocity.
Meanwhile, the specialists who once carried this burden were pushed aside. Operations engineers. Security professionals. Database administrators. Network architects. They became consultants to teams that did not have time to listen. Their expertise was available but never accessed because every team was too busy reinventing what those specialists already knew.
We did not distribute knowledge. We fragmented it.
What We Measured Instead of Value
Here is the uncomfortable truth about how we evaluated all of this flexibility.
DORA metrics. Deployment frequency. Lead time. Change failure rate. Mean time to recovery. For a decade, we measured these and called ourselves elite performers. We built dashboards that made executives feel confident.
DORA metrics measure the engine. They do not measure the destination.
They tell you how fast the gears are turning. They do not tell you if you are creating value.
The business does not care about your deployment frequency. They care about your value frequency. If you are bad at something, measuring how often or how fast you do it is not useful.
We convinced ourselves that if we deployed fast enough, value would follow. We optimized the mechanics of delivery while ignoring whether what we delivered mattered.
Now AI coding tools are inheriting the same failure.
GitHub measures Copilot by acceptance rates. Suggestions taken. Lines of code accepted. Time to complete tasks. They published research claiming developers are 55% faster.
Faster at what?
These are input metrics. Activity at the keyboard. None of them connect to production. None of them measure what breaks. What costs money. What users actually experience.
AI coding assistants have no feedback loop from outcomes. They are autocomplete trained on patterns, not results.
We trained an entire generation to confuse throughput with progress. Now we are teaching machines to do the same.
We are adding horsepower to a car pointed at a wall.
What Flexibility Actually Cost Us
The outcome of unbounded autonomy is now visible everywhere.
Trillions of dollars in cloud waste. Not because cloud is expensive, but because no one governed the relationship between cost and value. Developers were told to own the stack, so they provisioned what they needed. They had no mechanism to know whether what they provisioned was economically rational. They had no feedback loop. They had no constraints.
Architectural fragmentation at scale. Every team choosing its own tools means every team building its own world. Integration becomes negotiation. Knowledge becomes tribal. Patterns exist only by accident.
A generation of engineers facing burnout. Not because they are weak, but because they were asked to carry weight that should never have been theirs. They were made responsible for outcomes they did not have the information or authority to control.
And underneath all of it, systems held together by heroics. Engineers memorizing undocumented dependencies. Hand-tuning critical paths. Improvising around gaps that no one had time to fix. The system works not because it was well-designed, but because exhausted humans compensate for its flaws.
This is what flexibility produced.
Why This Matters Now
Unbounded autonomy relies entirely on tribal knowledge. It forces humans to fill in the gaps with intuition and heroics.
AI cannot do this.
AI cannot reason with tribal knowledge. It cannot guess your unwritten rules. It needs explicit, enforced constraints. It needs systems that describe themselves consistently.
Until we replace implicit intuition with platform-enforced structure, AI will not solve our problems. It will accelerate our chaos.
The enterprises deploying AI into environments shaped by fifteen years of unbounded autonomy are about to discover something uncomfortable. The flexibility they celebrated was debt they had not yet paid.
The bill is coming due.
The Correction
The answer is not to reject flexibility entirely. The answer is to recognize that flexibility has a cost, and that cost must be weighed against the value it provides.
Some choices matter. A developer choosing how to model a business domain is making a meaningful decision. That choice should remain with the developer.
But a developer choosing which deployment pipeline to configure, which secrets manager to integrate, which observability stack to instrument: these choices do not differentiate products. They create cognitive load that compounds across every team, every project, every year.
Platforms should absorb the choices that do not differentiate. They should provide clear defaults. They should make the right thing the easy thing. They should protect developers from decisions that should never have reached them.
The Kubernetes ecosystem spent a decade rebuilding what Cloud Foundry already provided. Service meshes. Ingress controllers. Operators. Platform abstractions on top of platform abstractions. We fragmented the solution and now we are duct-taping it back together.
Choice is a tax. Clarity enables intent. Constraints deliver coherence.
Actual high-performing teams are not the ones with the most choices. They are the ones where the platform has already made the choices that do not matter, so developers can focus entirely on the ones that do.
The correction begins with admitting we went the wrong direction.
##
ABOUT THE AUTHOR
Rick Clark is Global Head of Cloud Advisory for UST, was the initial lead of Ubuntu Server, co-founded OpenStack, and has held senior technology leadership roles at Mastercard, VMware, and Reliance Jio.
