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 categorically smarter than us. But because it changes a fundamental assumption we've built our careers on: that every form of implementation is necessarily scarce, expensive and slow.
When standardized implementation was most of the 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 can draft much of this work. It produces REST endpoints, CI/CD configurations and database schemas quickly enough that editing often replaces writing from scratch. A first draft is becoming cheap. Production-grade engineering is not: context, migration, failure behavior and operations remain specific to the real system.
This is not the end of implementation skill. It is a shift in where that skill creates value. When standardized work takes minutes instead of hours, the differentiator becomes the ability to test assumptions and build the parts for which no generic recipe is enough.
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 draft more of 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 deliver code" to "I take technical responsibility — and prove decisions in working software."
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 "producing implementation on request" – I'd start shifting. Not away from code, but toward responsible engineering: architecture, domain modeling, system design and the ability to prove decisions through working software.
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 and your ability to build inside real constraints are more needed than ever. But your Monday will look different. And the sooner you shape what that looks like, the better.