Here's a number that should alarm every business leader: developers spend only 16% of their working time actually writing code (IDC Analyst Report). The other 84% disappears into operational tasks - CI/CD pipelines, infrastructure management, security compliance, and monitoring. This isn't speculation. It's what IDC found when they surveyed developers about how they spend their typical month.
I've spent over twenty years watching this problem get worse, not better. At IBM, SaltStack, VMware, and Broadcom, I watched engineering teams drown in infrastructure complexity while their actual products stagnated. The tools we built to "automate" infrastructure created new categories of work instead of eliminating the old ones.
The result is a developer productivity crisis hiding in plain sight - one that costs companies billions in lost innovation and delayed products.
A recent Microsoft Research study surveyed 484 software developers about their ideal versus actual workweeks. The findings were striking: developers want to spend 20% of their time coding, but actually spend only 11%. They want 15% on architecture and design, but get only 6% (MSFT Report). The time they're losing goes to activities they'd rather minimize - communication overhead, security and compliance tasks, and wrestling with development environments.
Here's the critical finding: as the gap between a developer's ideal workweek and their actual workweek grows, both productivity and job satisfaction decline measurably. The researchers found a direct correlation - the further developers drift from the work they were hired to do, the worse their output becomes.
McKinsey's research on developer velocity confirms this from the business side. They separate development activities into the "inner loop" - coding, building, and unit testing - versus the "outer loop" - integration, deployment, and operations. Top-performing companies get their developers to spend up to 70% of their time in the inner loop. Most organizations are nowhere close (McKinsey Report).
The business impact is enormous. McKinsey found that companies in the top quarter for developer velocity see 4-5x faster revenue growth, 60% higher shareholder returns, and 20% higher operating margins. Developer productivity isn't just an engineering problem - it's a competitive advantage that directly affects the bottom line.
So where does all that developer time go? Into what I call the infrastructure tax - the hidden cost of keeping modern applications running.
The IDC study found that security tasks alone jumped from 8% of developer time in 2023 to 13% in 2024. That's not because applications got more secure. It's because compliance requirements multiplied, security tooling proliferated, and developers got stuck configuring and maintaining systems that should handle themselves.
When Microsoft's researchers asked developers which tasks they most wanted to automate, the top answers weren't coding tasks. They were documentation, environment setup, testing infrastructure, task tracking, and security compliance. Developers are begging for relief from the operational overhead that surrounds their actual work.
One developer in the Microsoft study captured it perfectly: "More focus time and fewer meetings." Another said: "Automate EVERYTHING for Continuous Delivery. The word 'manual' should not be in your vocabulary. This way, you will have more time to focus on the creative process that is software engineering."
The platforms that were supposed to solve this problem have become problems themselves. Consider the VMware ecosystem, where Broadcom's acquisition has triggered what Gartner calls a potential “four-year, $300 to $3,000 per virtual machine migration nightmare”. Companies that built their infrastructure on VMware now face price increases of 600% or more, with some enterprises reporting proposed hikes exceeding 1,000% (Gartner Report).
Gartner estimates that 35% of VMware workloads will migrate to alternative platforms by 2028. But that migration itself is enormously expensive - requiring ten full-time staff just for initial scoping, and another six people for up to nine months of technical evaluation. As one Gartner analyst observed: "Everybody's asking what everybody else is doing, and everybody else is asking what everybody else is doing, so nobody's really doing anything."
On the other end of the spectrum, platforms like Heroku that promised simplicity are buckling under their own limitations. After discontinuing their free tier in 2022, Heroku has faced escalating reliability issues - including a fifteen-hour outage in June 2025 that paralyzed thousands of applications. Developers who chose Heroku to avoid infrastructure complexity now find themselves managing that complexity anyway, while also paying premium prices for a platform they can't easily leave (Qovery Report).
The pattern is consistent: platforms either become too complex and expensive (VMware) or too limited and unreliable (Heroku). Neither path leads to developers spending more time on what matters - building great products.
Here's what I believe, based on two decades inside this industry: infrastructure should be invisible. Not “simpler to configure”. Not "easier to manage”. Invisible.
Developers should write code, push to their repository, and have everything else happen automatically. The platform should understand that a web application needs a load balancer, that a database needs backups, that connections need encryption. Security should be the default state, not a configuration option. Scaling should happen in response to actual demand, without anyone watching dashboards or writing scaling policies.
This isn't utopian thinking. It's the logical conclusion of where infrastructure should have gone all along. We got distracted building tools that made infrastructure easier to see and touch, when we should have been building systems that eliminated the need to see and touch it at all.
The Microsoft research validates this direction. When developers use AI tools daily to handle operational tasks, their productivity scores jump to 83.7% - compared to dramatically lower scores for those using such tools less frequently. The pattern is clear: removing operational burden directly improves developer output.
This is what we're building at ContextOS. Not another layer on top of existing complexity, but a platform that eliminates the complexity entirely.
Connect your GitHub repository. Answer a few questions about your application - what it does, what traffic you expect, where your users are located. ContextOS handles everything else: provisioning databases, configuring networking, implementing security, setting up monitoring, managing scaling. No Terraform. No Kubernetes manifests. No Helm charts. No YAML.
Security isn't a feature you enable - it's the default state. Zero-trust networking is built into how services communicate. Encryption happens automatically. Certificates rotate without intervention. The platform makes insecure configurations impossible, not just discouraged.
Scaling isn't a policy you write - it's a behavior the platform exhibits. When traffic increases, resources expand. When demand drops, resources contract. You set boundaries; ContextOS operates within them intelligently.
We can't continue to have our developers waste 84% of their time on operations. With the technology available to use today we can take the infrastructure overhead to zero!
The developer productivity crisis is also a market opportunity. Companies that figure out how to get their developers back to building products will outperform those that don't. The research is unambiguous on this point.
The infrastructure vendors who created this problem won't solve it - their business models depend on complexity. AWS doesn't make money when you use fewer services. Broadcom doesn't profit when VMware becomes simpler. The incentives point the wrong direction.
Real change requires building something fundamentally different. A platform where developer success and vendor success are aligned. Where the goal is to become invisible, not indispensable.
That's what we're doing.
If you want to see how optimized, purpose-built infrastructure can impact your work, we want to show you. Our platform beta is coming soon and we would love your help testing and perfecting our vision for the future of infrastructure.