How to stay relevant in the era of AI

I’ve been thinking a lot about what AI is changing for engineers.

Not only in how we write code, but in what it means to be an engineer in the first place.

A few years ago, I wrote about the rise of the Product Engineer and how engineering was moving closer to product, business, and customers.

Looking at my role today, that evolution feels even more obvious.

AI is accelerating it.

Coding is no longer the whole job

There was a time when being a JavaScript engineer, a backend engineer, or a frontend engineer could describe most of what you did.

I’m not sure that is enough anymore.

If AI can generate a large part of the code we used to write ourselves, the value of knowing how to write that code doesn't disappear. But the value moves somewhere else.

The engineer needs to be able to take a problem from beginning to end.

Understand the problem.

Understand the customer.

Understand the business impact.

Choose the right solution.

Build it.

Measure it.

And, maybe most importantly, unblock yourself when something doesn't work.

The technology is still important. But it is becoming one part of a much bigger picture.

AI rewards adaptability

AI is a tool, just like many of the tools that changed engineering before it.

The people who adapt faster can use those tools to increase what they are capable of doing.

That doesn't necessarily mean learning every new AI framework or trying every new model.

For me, it means understanding where AI can remove friction from my work and where human judgment is still needed.

I've already seen my own role change quite rapidly over the last few months.

Things like AI costs, business impact, product metrics, customer feedback, and experimentation are becoming part of conversations that, not so long ago, would have felt well beyond the scope of an engineer.

The code used to be the main focus.

Now, the question is increasingly what should we build, why should we build it, and what happened after we built it?

The end of one-person dependencies

There is another change I find interesting.

Async work has been a huge part of how many engineering teams operate. But having a single person become the dependency for a particular area is becoming harder to justify.

If AI allows one engineer to investigate, prototype, implement, test, and iterate much faster, waiting for another person to unblock a small piece of work can become a significant bottleneck.

This could push us toward more autonomous engineering.

But there is a risk here.

If we optimize everything for individual productivity, we might lose something important: feedback.

Pairing, reviews, discussions, and simply explaining your thinking to another person are not only ways to coordinate work. They are part of the iteration process.

Moving faster doesn't automatically mean learning faster.

We need to be careful not to replace collaboration with isolation just because AI makes solo work easier.

Engineering judgment becomes more important

I've been experimenting with AI coding tools for a while now, and one thing keeps becoming clearer.

The better the instructions, context, and constraints, the better the result.

This is why I don't think the future is about telling AI:

"Make this."

It is about giving AI enough context to understand what we are trying to achieve and then applying engineering judgment to the result.

I recently watched an interview where the idea was explained in a way that resonated with me: asking AI to simply "make this without mistakes" is very different from iterating on a product while applying an engineering background.

Inside Vercel's AI-era playbook: "Recursive Founder Mode" | Guillermo Rauch (CEO)

The difference is not only the output of the model.

It is the person guiding it.

An engineer understands trade-offs, constraints, architecture, edge cases, maintainability, observability, user needs, and business context.

AI can help with the implementation.

But knowing what implementation makes sense is still a human responsibility.

The product engineer was only the beginning

This is why I see this as the next evolution of something I wrote about years ago.

The Product Engineer was already moving beyond the traditional idea of an engineer as someone who receives requirements and turns them into code.

Now AI is pushing that boundary even further.

The engineer can participate in more parts of the product cycle because the cost of implementation is changing.

We can prototype faster.

We can test ideas faster.

We can explore alternatives faster.

We can analyze more information.

And we can spend less time on repetitive implementation.

That gives us more room to focus on the things that are harder to automate: context, judgment, communication, and ownership.

Staying relevant is not about chasing AI

I don't think staying relevant means becoming an AI engineer overnight.

It means becoming the kind of engineer who can adapt when the tools change.

The JavaScript engineer wasn't suddenly useless when new frameworks appeared.

The frontend engineer didn't disappear when design systems became common.

And engineers didn't stop being valuable because cloud platforms removed the need to manage every server manually.

The abstraction changed.

The expectations changed.

The people who continued learning changed with it.

AI is another step in that evolution.

Maybe the most important skill now is not knowing exactly how to build something.

It is knowing what is worth building, how to approach it, and how to use every tool available to get there.

The code still matters.

But the problem matters more.

And in a world where AI can write more of the code, engineers need to become better at everything around it.

That might be what staying relevant really means.