The New Role of the Software Engineer in the Age of AI

Why this shift isn’t the threat, and why ignoring it is

I’ve spent years leading engineering teams. And over the past year and a half, I’ve had to rethink almost everything I believed about how software engineers grow and create value.

Not because engineering has changed at its core. But because the most powerful tool ever created for writing code is now available to anyone with an OpenAI or Anthropic account.

And that changes the central question of the job.

What the role is really asking for now

For decades, an engineer’s value was closely tied to production: writing code quickly, remembering APIs, mastering the syntax of multiple languages, and generating output at scale. A big part of technical seniority came from years of accumulated experience doing exactly that.

That frame no longer holds in the same way. Engineers still matter, but the question behind their value has changed. Before, it was about who could write more code. Now, the more relevant question is who can design, evaluate, and build complex systems using AI as an amplifier.

That shift marks the difference between engineers who generate output and engineers who create more value.

The comparisons that helped me make sense of this

When I try to explain this transition to someone outside engineering, two comparisons usually help:

1. The architect and the builders

An architect isn’t the one pouring concrete, mixing cement or laying bricks, but they are still accountable for how the building comes together. Their job is to understand the problem, make the right design decisions, and make sure the final result is sound, useful, and aligned with what the client actually needs.

A software engineer in 2026 is increasingly closer to that role. AI builds, letting the engineer decide what should be built, how it should fit into the larger system, and whether the result is actually correct.

2. The accountant and Excel

When spreadsheets became common, nobody seriously thought accountants would disappear. What changed was the nature of the work. Tasks that once took hours could suddenly be done in minutes, and over time, knowing how to use Excel became a basic requirement of the job.

The same thing is happening with AI and software engineering. The role isn’t going away, but in a few years, it will be hard to imagine a strong engineer who doesn’t know how to work effectively with AI. And, just like with any powerful tool, the difference between using it well and using it poorly will be significant.

Where AI helps most, and where it still falls short

It is worth slowing down here, because this is where the discussion often loses clarity.

AI is already very good at certain tasks:

• Generating boilerplate and repetitive code
• Writing endpoints from a schema
• Creating basic unit tests
• Refactoring mechanical code
• Documenting functions
• Explaining unfamiliar code

But there are still things AI can’t do, and likely won’t do well for a long time:

• Understand the business context and real client constraints
• Make architecture decisions with long-term consequences
• Detect when a technically correct solution is architecturally wrong
• Evaluate trade-offs across scalability, cost, maintainability, and complexity at the same time
• Identify subtle security issues in the code it just generated

Here’s an example. A tool like Cursor or Claude Code can generate an authentication endpoint quickly, but unless it has the right context, it will fill in the gaps on its own. It may create new constants instead of using the project’s existing ones, ignore helper files that are already there, or make assumptions about the schema. And if you don’t audit the output, the generated token may have no expiration, or authentication errors may expose information that it shouldn’t. 

This means the code works, but the solution can still introduce real problems. The quality of the result depends on the engineer’s ability to guide the tool, review the output, and decide whether it actually fits the system it’s meant to serve.

How AI can accelerate mediocrity

One of the patterns that worries me most in teams adopting AI is what I would call “AI-assisted mediocrity”.

To be fair, this didn’t start with AI. Most teams have known some version of this engineer for years: the one who copied from Stack Overflow, saw the code work, and moved on without fully understanding it. Without taking five minutes to read the explanation right below the answer.

Now the process is even more frictionless. Instead of searching through forums, comparing answers, and piecing together a solution, someone can ask a model for code, paste the result, and keep going. And because the output often looks polished and confident, it becomes even easier to accept it without much analysis. 

That is where the real problem begins. Code that seems correct enough to pass, while quietly adding complexity, hiding weak decisions, or introducing risks no one took the time to examine. Over time, that creates systems that technically work, but are harder to understand, maintain, and trust.

If engineers stop reading carefully, questioning decisions, and reasoning through trade-offs, they don’t just produce weaker code. They also weaken the skill that makes them valuable in the first place (the Stack Overflow engineer at least had to read the thread title to find the right answer).

The skills that matter more now

As AI changes the shape of the work, it also changes what engineers need to be good at:

1. Architecture design: Engineers need to think through a system before building it, defining responsibilities, understanding how the parts connect, and considering how today’s decisions will affect scalability and maintainability later on.
2. Trade-off analysis: Balancing speed and quality, flexibility and simplicity, or short-term delivery and long-term cost is still a core part of engineering work. AI can suggest options, but it can’t decide which trade-offs make sense in context.
3. Code auditing: Reading generated code critically, spotting weak decisions, and catching risks that may not be obvious at first glance matters even more when AI increases the volume of output.
4. Giving AI the right context: Providing the model with the right structure, including project conventions, helper files, shared constants, relevant types, and business rules, has a major impact on the quality of the output.
5. Domain understanding: Understanding the client, the constraints, and the business logic behind the code remains a key part of good technical judgment, because that context still lives with the engineer.

Deep technical knowledge of the language still matters

None of this makes software engineering language-agnostic. Architectural judgment and systems thinking matter more than ever, but they don’t replace real knowledge of the language and stack you are working with.

Let’s go back to the architect's example for a moment, with one important nuance. An architect with decades of experience may understand structure and spot obvious issues, but if you show them a house built with traditional Japanese woodworking, they will miss details that only someone trained in that method would catch.

The same applies in software. AI can generate Go code that compiles and passes tests,  but if you don’t understand Go’s concurrency model, you can miss a race condition. If you don’t understand Rust’s ownership model, you might not know whether the solution is idiomatic or just a forced translation from another language. And if you don’t understand Node’s event loop, it becomes harder to see why an asynchronous flow could behave unpredictably in production.

And there is another layer: choosing the right language for the problem. That decision shapes performance, ecosystem fit, maintainability, and how easily a team can work on the system over time. While some think language is just stylistic preference, it really is a technical choice with long-term consequences.

Does this mean engineers need to master 20 languages? Not at all. It means deep technical knowledge of the languages and stacks they actually work with is still something AI can’t replace. Actually, it’s what makes the review of generated code meaningful in the first place.

What this means for engineering teams

As a technical leader, this change has affected the way I think about developing and evaluating engineers.

I used to focus on whether engineers could build a solution. Now I care about whether they can judge the quality of what gets built, especially when AI is part of the process. 

That matters because AI can increase output in both directions. In the hands of an engineer with strong judgment, it multiplies capacity. In the hands of someone who accepts code too easily, it multiplies mistakes, weak decisions, and technical debt.

I don’t believe AI will replace software engineers altogether. But engineers who don’t develop judgment will be outperformed by those who do, and who also know how to use these tools well.

The practical upside of using AI well

A lot of this conversation focuses on the risks, and those risks are real. But there is another side to it. Used well, AI can give engineers practical advantages that were much harder to access before:

• Faster learning: Engineers can use AI to understand paradigms, compare patterns, generate examples, and analyze real code much faster (when it used to take months).
• Less mechanical work: Documentation, repetitive tests, boilerplate, and migrations can be handled more quickly, leaving more time for higher-value work.
• Broader technical perspective: AI can help engineers engage more confidently with technologies outside their core expertise.
• Faster onboarding: A new codebase, its architecture, and its dependencies can be understood much faster with AI, reducing the time it takes to become productive.

These advantages don’t remove the need for strong fundamentals, but they do change what engineers can do with them.

What will set engineers apart

To me, the role of the software engineer is becoming more distinct. The gap between strong and weak engineering judgment is only getting wider.

Some engineers will use AI as a faster way to search, copy, and produce code without fully understanding it. Others will use it for what it actually is: a powerful tool that still requires judgment, context, and responsibility. This difference will come from how engineers are trained, how they think, and whether they stay intellectually engaged in the work.

The accountant who learned Excel didn’t stop being an accountant. They became more effective, as long as they still understood what the formulas were doing.

That is the standard I believe engineering teams need now. Use the tool, configure it well, review the output carefully, but don’t hand off judgment.

Anything that reaches production is still going to be their responsibility, not the model’s.