If you've been writing software for ten, fifteen years, you've seen hype cycles. Microservices would change everything. Then serverless. Then blockchain. Every few years, the same breathless announcement: the old way is dead, the new way is here.
Each time, reality was more nuanced. The old way wasn't dead. The new way was useful, but limited. And the people who panicked either burned out or missed the point.
This time, I'm less sure.
Not because AI is smarter than us. It isn't. But because it changes a fundamental assumption we've built our careers on: that writing code is hard, and therefore valuable.
When the Easy Part Was the Whole Job
Let's be honest: a large part of what most developers do day-to-day is implementation. Writing REST endpoints. Setting up CI/CD pipelines. Creating database schemas. Implementing CRUD operations. Wiring up frontends to backends.
None of this is rocket science. But it took time. And because it took time, it was valuable. Companies paid for it. Careers were built on it.
AI doesn't struggle with this. It writes decent REST endpoints. It generates CI/CD configurations. It creates database schemas that work. Not always perfectly, but well enough that you edit rather than write from scratch.
This isn't a quality problem. It's a value problem. When something takes five minutes instead of five hours, its market value changes. Whether you like it or not.
What Doesn’t Lose Value
Not everything gets cheaper. Some things become more valuable precisely because everything else is easier:
Domain knowledge. Understanding why a particular bank needs a specific audit trail. Knowing that a logistics company's "real-time" actually means "within three seconds, or the conveyor belt stops." This doesn't come from prompts. It comes from years of presence.
Organizational awareness. Knowing that the CTO says one thing and means another. That the architecture review board has a hidden agenda. That the team in Munich and the team in Berlin have a rivalry that affects code reviews. AI can't read a room.
Judgment under ambiguity. When the requirements are unclear, the timeline is aggressive, and the stakes are high – someone has to make a call. AI can present options. It can't weigh politics, risk appetite, and team morale simultaneously.
The ability to say "no." To push back on features, to simplify scope, to challenge assumptions. This requires standing, experience, and courage. An AI assistant has none of these.
The Identity Question
Here's the part nobody talks about: For many senior developers, coding skill is identity. We spent years getting good at this. We take pride in elegant solutions. We feel valuable when we solve a hard problem in code.
When AI can write the code, what happens to that identity?
This isn't a trivial question. People don't just lose tasks. They lose a piece of who they believe themselves to be. And that's a grieving process, even if nobody calls it that.
The Bridge
The transition isn't from "old" to "new." It's from "I write code" to "I decide what code gets written."
That sounds like a small shift. It isn't. It's a fundamental change in how you spend your day, what you're evaluated on, and where you derive your sense of competence.
Practically, it means:
– Less time in the IDE, more time in conversations.
– Less debugging, more reviewing and evaluating.
– Less "how do I implement this?", more "should we implement this at all?"
– Less being measured by lines of code, more by decisions and outcomes.
The Enterprise Buffer
If you work in enterprise, regulated environments – banking, insurance, public sector – you have more time. These organizations move slowly by design. Compliance, procurement, security reviews – all of these slow down adoption.
But this buffer isn't a reason to ignore what's happening. It's a window of opportunity. The time to adapt is now, while the pressure isn't yet existential.
The worst position three years from now won't be "didn't learn the right AI tool." It will be "didn't evolve how I think about my own value."
What I’d Do
If I were a senior developer reading this, I'd ask myself one question: What am I paid for in three years?
If the answer is "writing code" – I'd start shifting. Not away from code, but toward the layer above it: architecture, domain modeling, system design, technical strategy.
If the answer is "making decisions about complex systems in messy organizational contexts" – you're fine. Double down.
You're not obsolete. Your knowledge, your judgment, your ability to navigate complexity – these are more needed than ever. But your Monday will look different. And the sooner you shape what that looks like, the better.