Skip to content

How to Stay a Relevant Developer During the AI Era

A honest conversation about where our industry is heading and how to adapt

Let’s have an honest conversation.

AI can now write code. Not perfect code, but good enough code. It can debug, refactor, and generate entire features from a description. This isn’t coming - it’s already here, and it’s getting better every month.

So where does that leave us?

For years, the deal was simple: learn a framework, get good at implementing features, ship code fast. Companies needed hands to turn requirements into working software.

That deal is breaking down. If your value is “I can turn a Jira ticket into code,” you’re competing with tools that do exactly that - faster, cheaper, and without needing sleep or coffee.

This isn’t doom and gloom. It’s just reality. And reality is something we can work with.

AI is great at the “how.” Give it clear instructions and it executes. But it struggles with the “what” and “why.”

It can’t sit in a meeting and realize the feature being discussed won’t actually solve the user’s problem. It can’t push back on a requirement that sounds good but will create technical debt for years. It can’t notice that two teams are building the same thing differently and suggest a unified approach.

These are human skills. And they’re becoming more valuable, not less.

Here’s the shift I’m seeing: the gap between “people who decide what to build” and “people who build it” is collapsing.

In the past, you could have a successful career just being a great implementer. Someone else figured out what needed to be built, you made it happen. That specialization made sense when coding was the bottleneck.

Now? Coding is getting automated. The bottleneck is figuring out what’s worth building and why.

The developers who thrive will be those who can do both - think strategically AND execute. Not one or the other. Both.

Before I continue, I want you to actually watch this. Google for Developers put together 6 videos that cover exactly what I’m talking about - and they explain it better than I can in text.

Here’s what you’ll learn:


This is the core concept. An efficient engineer does things right - follows instructions, writes clean code, ships on time. That’s valuable, but it’s not enough anymore.

An effective engineer does the right things. They look at the bigger picture, prioritize work that delivers the most value, and focus on impact rather than just completion.

AI is efficient. It follows instructions perfectly. What it can’t do is decide which instructions are worth following.

The video breaks it down by career stage:

  • Junior engineers focus on how to implement
  • Senior engineers think about what approach is right
  • Staff+ engineers question whether it’s even the right problem

That progression - from how to what to whether - is the path to staying relevant.


Stop measuring yourself by activity. Lines of code, tickets closed, features shipped - these are outputs. They measure how busy you are, not how valuable you are.

Start measuring by outcomes. “I improved the conversion rate by 15%” beats “I wrote a thousand lines of code” every time.

This requires learning to speak the language of business. Frame your contributions in terms of revenue, cost reduction, or user satisfaction. Be solution-oriented. Choose projects with clear strategic value.


You need depth AND breadth.

Depth means being really good at one thing. It lets you solve complex problems faster, anticipate pitfalls, and mentor others. This is your anchor - the thing you’re known for.

Breadth means understanding how everything connects. It helps you see the bigger picture, design holistic solutions, and work across teams. This is what makes you adaptable.

The engineers who survive technology shifts are T-shaped. When your specialty becomes automated, your breadth lets you pivot. When new problems emerge, your depth lets you go deep fast.


The playlist covers five patterns that hold engineers back. These become career killers in the AI era:

Knowledge silos - Hoarding information made you valuable before. Now it makes you a bottleneck that AI can route around.

Hero complex - Constantly saving the day feels good but creates dependency. Build resilient systems instead of being the single point of rescue.

Overengineering - AI can generate complexity easily. Your value is in cutting through it, not adding to it.

Inability to delegate - If you can’t trust others (or AI tools) with 90% of the work, you’ll never scale beyond your own hands.

Lack of visibility - Amazing work that nobody knows about has no impact. Share updates, document accomplishments, demo your work.


The playlist opens with a question: IC or Manager?

This matters more now. Both paths are valid, but they require different skills. Management isn’t a promotion from senior IC - it’s a different career track entirely.

ICs influence through ideas, prototypes, and technical expertise. They get deep flow time and solve hard problems directly.

Managers influence through people. They build teams, remove obstacles, and shape execution. Their output is the team’s output.

The good news: you can swing between these paths. Experience in one makes you better at the other. But choose intentionally. Don’t drift into management because it seems like “the next step.”


If you’re early career: master the fundamentals. Clean code, testing, debugging, version control. These compound over time and transfer across any technology shift.

If you’re mid-career: start thinking beyond code. Understand the business. Communicate with product and design. Take ownership of outcomes. Mentor others.

If you’re senior: your value is judgment, not execution. Which problems matter? What approaches scale? Where are the risks? Multiply your team, don’t just add to it.

At every stage: stay curious. The engineers who adapt are the ones who keep learning, keep questioning, and keep evolving.


AI isn’t replacing developers. It’s replacing a certain type of work that developers used to do.

The question isn’t whether you’ll still have a job. The question is: what kind of developer do you want to become?

Be developers, not coders.