Career

For Experienced Developers: Staying Relevant as AI Reshapes the Craft

I've had a version of this conversation with several engineers on my teams over the past year, usually senior people, ten-plus years in, very good at what they do, quietly unsettled by how fast an AI assistant can produce code that used to take them an afternoon. I understand the unease. I've been through an analogous transition once already in my own career, moving from hands-on developer to lead to Solution Architect over fifteen years at Spice Digital, and what got me through it wasn't protecting my old value — it was recognizing what my value actually was in the first place.

The Comfort Trap

Deep expertise in a specific stack feels like security because it has been security, for most of the careers of everyone reading this. If you're the person who knows the Java concurrency model cold, or can debug a Spring transaction propagation issue in your sleep, that expertise has been reliably rewarded for years. The uncomfortable truth is that an AI assistant now has broad, shallow familiarity with almost all of that same surface area, and it's getting less shallow every year. If your value proposition stops at "I can write this code," that proposition is under real pressure. If it never stopped there in the first place, you're in a much better position than the anxiety suggests.

What Your Value Actually Was

Here's the reframe I've found genuinely useful, not just comforting: the years of experience were never really about typing code faster than someone with fewer years. They were about pattern recognition earned through consequence — knowing that a particular kind of "clever" solution causes an on-call page eighteen months later, knowing which stakeholder's requirement is actually negotiable and which one isn't, knowing when a system needs to be simple because the team maintaining it will change over twice before the code does. AI assistants don't have that kind of earned judgment. They can't, not because of some fixable technical limitation, but because judgment like that comes from having owned outcomes, and an assistant doesn't own anything. That was always the actual value. AI just made it more visible by commoditizing everything around it.

The code you wrote was never the product. The decisions behind the code were. AI changed the ratio, not the fact.

The Practical Shift

Concretely, here's what's changed in how I work and how I coach senior engineers on my team to adapt. Less time authoring every line, more time reviewing and curating what gets authored — which is a different skill from writing code and needs to be practiced deliberately, not assumed. I've watched strong developers do a mediocre job reviewing AI output the first several times, because critical reading of someone else's (or something else's) code is a distinct muscle from writing your own.

Second, lean harder into domain modeling and architecture — the parts of the job that require understanding a business, not just a language. DDD, bounded contexts, event-driven trade-offs, the kind of thinking that requires talking to people outside engineering to get right. That's exactly the terrain AI is weakest on, because it requires context no prompt fully captures.

Third, become the person on your team who teaches others to evaluate AI output critically, not just the person who produces the most output personally. That's a shift from individual contributor value to force-multiplier value, and it's one I made myself, not entirely by choice, as I moved from developer into technical leadership. It turns out it's the more durable kind of value, AI or no AI.

The Two Failure Modes

I see senior engineers fail this transition in two opposite ways. The first is refusing the tools out of principle or pride, which just means doing the boring 70% of the job the hard way while everyone else doesn't. The second, more common now, is over-relying on them without maintaining the underlying skill — approving AI-generated architecture decisions without really interrogating them, because it's faster to trust the output than to do the harder work of forming an independent opinion. Both erode the thing that made you senior in the first place. The middle path, using the tool aggressively for execution while getting more rigorous, not less, about the judgment calls, is harder to describe cleanly but it's the one that's actually working for the engineers I manage.

What I'd Tell My Younger Self

If I could send one note back to myself twenty years ago, it would be this: stop measuring your growth by how much code you can produce, and start measuring it by how good your calls are when you're the one who has to be right. That was good advice before AI assistants existed. It's just less optional now.

← Back to all posts