I’m not sure whether you’ve been observing a trend in the software industry—especially since the advent of AI and agentic ways of working as a software engineer.
Just five years ago, to become a Principal Software Engineer, Staff Engineer, Principal Architect, or VP, you typically needed many years of experience—usually a decade or more. But now, even people with much less experience are getting these titles. I’m not saying people with less experience aren’t competent to earn those titles. That’s not my point.
What I’m really talking about is this: if people with significantly less experience are getting those titles and positions, are they also getting the corresponding compensation and empowerment that usually come with them?
AI leverage, human squeeze
We’re observing large layoffs in the software industry. Smaller teams are expected to deliver more because AI is seen as a force multiplier. The expectation is that humans will act more like reviewers, system designers, and architects—overseeing AI as it does the work: reviewing what the AI produces, approving it, and then shipping.
With agent-driven development workflows integrated into developers’ day-to-day work, developers are increasingly expected to behave more like architects and less like coders. Some people even suggest there’s no need to learn coding at all. In effect, the narrative becomes: you can start your software engineering career operating like an architect or a principal engineer. The question is—how workable is this approach for the kinds of problems we’re actually facing?
You can’t fast-forward “battle scars”
Historically, many engineers became principal engineers or principal architects after years of building and operating software in the real world. They learned by shipping systems, seeing failures, diagnosing production incidents, understanding trade-offs under pressure, navigating stakeholder expectations, and experiencing the long-term consequences of architectural choices. That experience often develops a kind of systems intuition: an ability to anticipate failure modes, recognize hidden complexity, and reason about the broader impact of seemingly small decisions.
If you bypass those hard yards, or try to compress them, in the formative years of becoming a reasonably good software engineer, how do you expect the same systems-thinking capability to develop?
And if such people are given the responsibility of guiding AI agents to build systems, reviewing the outputs, and orchestrating agents to build applications with complex system interactions—what assurance is there that it’s being done with enough understanding and critical judgment of those interactions? That depth of understanding usually doesn’t form very early in a software engineering career.
More accountability, same support
At the same time, there is a growing expectation that “AI will do the boring coding work,” and humans will focus on higher-level decision-making. In theory, that shift sounds positive: more leverage, more focus on design and architecture, less time spent on repetitive implementation.
In practice, though, it can create mismatches. Sometimes the scope of responsibility increases—more reviews, more orchestration, more system-level accountability—faster than compensation structures, staffing levels, or career support systems evolve. When that happens, people may carry senior expectations without consistently receiving senior-level compensation, authority, or resourcing.
We’ve been here before
This isn’t the first time we’ve seen a pattern like this in the industry. If you turn the pages of recent history, the “full-stack developer” role became popular. Earlier, organizations hired separate front-end teams, back-end teams, and database teams—and it cost money to maintain multiple teams with different skill sets. Then the framing shifted to: now you are a full-stack developer.
The expectation is that you’re empowered to do end-to-end development. That sounds good, but it raises a practical question: does that empowerment translate into proportionate compensation and sustainable workload?
Initially, full-stack developers were often paid more than some other developers, but over time those premium salaries normalized.
Another example is DevOps. Earlier, development teams built features, shipped the product, and handed it to operations. The operations team ran the application in production and handled production issues. Then organizations pushed for a model where development teams also take ownership of operations: not only building features, but also fixing production issues—owning the full end-to-end delivery.
People may not mind taking more responsibility, but whether compensation, staffing, and guardrails evolved proportionately has varied widely.
“Everyone owns it” needs guardrails
We can see similar “sounds good in principle, harder in practice” patterns in a few other places too:
DevSecOps / “Security is everyone’s responsibility.” The philosophy is that security should be integrated into development and operations rather than treated as a late-stage gate.
But if “everyone owns security” isn’t backed by training, standardized guardrails, and real accountability, it can become unevenly executed—especially when delivery pressure is high. My personal unpopular opinion is: if you make development teams have a conflict of interest with security compliance because they are always under pressure to ship code, what is the guarantee that they adhere to good conduct, do not cut corners, and do not bypass the rules?“Citizen development.” This is framed as empowering business users non-traditional developers to build apps using low-code/no-code platforms.
It can absolutely help with speed, but without governance it can drift into shadow IT patterns: inconsistent quality, unclear ownership, and security or compliance risks.“Full-stack data scientist.” This is often positioned as end-to-end ownership: from data prep to modeling to deployment and monitoring.
The practical challenge is that it can compress multiple specialized roles into one set of expectations unless organizations invest in platforms, reusable pipelines, and realistic scope.
The core risk: expectations ≠ rewards
So what’s happening now, in the era of AI, is that this pattern is taking a different dimension. Everyone is expected to think like a Staff Engineer, Architect, or Principal Engineer—but compensation isn’t always commensurate with that level of expectation of responsibility. In some cases, you can get the titles without the matching pay, authority, or support systems.
We don’t know where this is going or what the side effects will be. We’ll have to wait and watch. But one thing is clear: the AI era is driving higher expectations—expectations around delivery speed, efficiency, sprint velocity, and the number of features delivered per sprint. Lesser people are expected to deliver more but compensation will not match that delivery. This can easily become an era of unrealistically high expectations from humans, where people feel they are expected to compete with machines.