How to Stay Relevant as a Software Engineer in the Age of AI

I’ve been in software engineering for over 15 years now and I don’t think I’ve experienced another period in which so many of my established ways of working have changed in such a short time. Especially in the past 12 months.

I’m aware that this is not a benchmark, but I don’t think anyone can deny that coding agents have fundamentally changed how much software we can produce and how quickly we can produce it. However, I noticed in my day-to-day work that the changes are deeper than just writing code. Looking back, I feel that the way I plan, make architectural decisions, validate implementations and organize engineering work has changed quite a bit as well.

This raises an important question for me and for everyone else working in software engineering: how do we keep our skills relevant when the industry changes faster than our traditional learning processes can accommodate?

And, yes, I have a decent amount of fear that I might be lagging and that I’m not adapting fast enough.

I’ve been thinking about this a lot over the past 8-9 months and also analyzed my behavior and the actions I take in my effort to keep the pace. For me, staying relevant as a software engineer in the age of AI comes down to four practices: focusing on the fundamentals that shape daily work with coding agents, measuring and benchmarking what you do, understanding the economics behind engineering decisions, and moving your own work closer to architecture and ownership. Here is how each of them looks in practice.

Why the Job Changed More Than the Code

Before the practices, it’s worth being precise about what changed. Most of the attention goes to code generation, because that’s the part everyone can see. Coding agents turn a clear plan into working code faster than any of us can type.

When one part of a system speeds up, though, the other constraints become visible. In Cycle-Driven Engineering I described what I saw across a 5,000-engineer organisation, my own company and two consulting engagements: accelerating execution inside systems built for slow feedback does not improve those systems. It amplifies their inconsistencies. Requirements, reliable context, architecture, review, testing and production feedback start to dominate delivery time.

That’s also where the skills that keep you relevant are moving. If generating code is cheap, the valuable work is everything around it: deciding what should be built, making the system understandable for both humans and agents, planning in enough detail that an agent doesn’t improvise the architecture, and verifying that what ships is actually right. As I put it in why AI-assisted engineering fails, AI can write the code, but it cannot hold the accountability.

1. Focus on What Matters

There is an endless stream of new models, agents, frameworks and tools being announced almost daily. Trying to keep up with everything quickly becomes overwhelming and I don’t think it’s physically possible. Add to this the fact that most of the models, agents, frameworks and tools we are bombarded with won’t survive the market.

I think a better approach is to focus on the fundamentals. And by that I don’t necessarily mean the programming fundamentals (those remain important as well), but the changes that affect your day-to-day work with AI coding agents. Like context management, memory management, token economics, agentic orchestration and so on.

Extracting what matters most and focusing on that is the 20% of the effort that yields 80% of the outcome (long live Pareto). If this is done right, then adopting new models, tooling and frameworks around those fundamentals becomes trivial. And you can then adopt only those new shiny things that prove they can withstand the test of time. Which in AI is just a few months.

Here’s a practical example. Around 10 months ago everyone was crazy about something called TOON, which was essentially a re-invented CSV format that allegedly played nicely with coding agents. A lot of people wasted a tremendous amount of time with it and in the end it never proved to bring meaningful improvements. I simply let it slide away because I didn’t think it would become part of the fundamentals.

Instead, I focused on better understanding skills, skill execution, hooks and ways to introduce as many deterministic guardrails as possible into the probabilistic system that an LLM is. I wrote about how that played out in my own setup in Claude Code skills vs sub-agents (and rules), and about context management as an engineering discipline in the Context Layer deep dive.

2. Measure and Benchmark Everything You Do

One of the aspects I find almost hilarious is all the polarization that occurs when a new model comes out or when two competitors release their new models in a short amount of time. Everyone is claiming that “model X is killing it” or that “model Y sucks.”

But based on what? Mostly it’s just gut feel and the bias created by ingesting marketing materials about benchmarks.

What is way better is to create yourself a way of working (for example, a set of skills and defined measurements tailored to your real work) that allows you to benchmark models yourself. That’s quite easy to do: give the same task to two different models working on independent worktrees and then compare the outputs against the measurements you have already defined.

That’s how I figured out that Fable 5 doesn’t really justify its price tag, given the minimal difference in output quality for most tasks. That’s how I immediately called out Opus 5 as the weakest Anthropic model ever. And it’s how I found that Sonnet 5 actually costs more than Opus 4.8, even though it’s theoretically the cheaper model.

Those tests taught me something that goes beyond any single model. In an agentic workflow, the model’s behavior determines how many tokens, tool calls and turns a task needs. A pricing table or a vendor benchmark can’t tell you how a model behaves on your codebase, with your harness and your rules. Your own measurements can.

3. Understand the Economics Behind Engineering Decisions

As engineers, we naturally gravitate toward technical challenges. Architecture, performance, scalability, developer experience and technology choices are all interesting problems. What we tend to overlook is that every technical decision has a price tag attached to it.

Building Atherio is what made me more conscious of this. Engineering decisions influence operating costs, product capabilities, customer experience and the speed at which we can respond to new requirements. It’s also why I run a quarterly technology and cost-to-serve review, which I described in how I know my system is healthy.

One exercise worth doing is to revisit a recent technical decision and explain its business implications. What problem did it solve? What did it cost to implement? What will it cost to operate and maintain? What value does it create?

This exercise is particularly important for engineers because it forces us to think about engineering in a way that most engineers were not required to until a year ago. From my point of view, this will be one of the most important skills in the future, and we need to build and sharpen it.

4. Move Your Work Closer to Architecture and Ownership

The fourth practice is about where you spend your attention.

As my own agent setup matured, one thing surprised me. Onboarding a new piece of work no longer required me to mentally reconstruct what the agent needed to know. My job shifted from supplying context to specifying intent, which moved my work closer to architecture and further from prompt engineering.

That shift is available to every engineer, but it doesn’t happen by accident. It means writing plans detailed enough that an agent doesn’t have to invent anything along the way. It means keeping the documentation that humans and agents reason against current. And it means turning every review comment that keeps coming back into a constraint, an example or a piece of reusable context, which I went deeper into in why most code reviews should never happen.

Underneath all of it is the definition of AI-assisted engineering I work from: AI accelerates the work, but a human stays the owner of the system and remains accountable for everything that ships, whether or not they typed it. The engineers who keep that ownership are the ones whose skills keep their value as the tools change.

Here’s Something Else That Might Help

All this experimenting, researching, documenting, benchmarking, measuring and learning takes time, and unfortunately not all work environments promote it as a way of working.

That’s one of the reasons I recently started Modern Engineering. It’s a community built around a simple idea: keeping our engineering skills relevant as the industry changes around us.

I’m sharing practical lessons from building Atherio, modern engineering workflows, software architecture insights and reusable resources that can help accelerate the learning process.

There is already a Context Layer starter kit for coding agents, a Production Investigation Kit with a scoped, least-privilege security model, a technology health and unit economics toolkit, an engineering efficiency diagnostic and my book on API versioning. I’ll continue adding new resources and field notes every week.

If you’d like a more structured way to keep learning, with practical material and a community of engineers navigating the same changes, you’re welcome to join us.

FAQ

How do you stay relevant as a software engineer in the age of AI?

Focus on the fundamentals that shape daily work with coding agents, such as context management, token economics and agentic orchestration, rather than chasing every new tool. Then benchmark models on your own work, learn the economics behind engineering decisions, and move your work toward architecture and ownership.

Which skills matter more now that AI writes so much of the code?

When code generation gets faster, the constraints move to requirements, reliable context, architecture, review, testing and production feedback. Planning in detail, managing context, verifying what ships and owning the system matter more, because AI can write the code but cannot hold the accountability.

How should I evaluate a new AI model for coding?

Give the same task to two models in independent worktrees with the same harness, then compare the outputs against measurements you defined in advance. That’s how I found that Fable 5 didn’t justify its price for most tasks and that Sonnet 5 cost more than Opus 4.8 on a real refactor.

Why should software engineers care about the economics of technical decisions?

Every technical decision has a price tag. It affects operating costs, product capabilities, customer experience and how quickly you can respond to new requirements. A useful exercise is to revisit a recent decision and explain what it solved, what it cost to build, what it costs to run and what value it creates.