How AI Is Changing the Role of Software Engineers

For most of the history of software development, writing code has been one of the clearest ways to describe what software engineers do.

They translate requirements into logic, turn that logic into code, debug what breaks, review what others write, and gradually build enough context to make better technical decisions.

That workflow is changing.

AI can now generate code, explain unfamiliar systems, write tests, suggest fixes, and help engineers move through tasks that once required hours of manual work. GitHub's own controlled experiment found that developers using Copilot completed a coding task 55% faster than those who did not use it. (The GitHub Blog) McKinsey has reported similar gains across common software development tasks, while also finding that the benefits are much smaller for more complex work. (McKinsey & Company)

The interesting question is what happens to the role of the engineer when producing code is no longer the main constraint.

Less typing, more judgment

The easiest way to think about AI in software development is as a faster way to write code. That is certainly part of it, but it leaves out something important.

Someone still needs to decide what should be built.

AI can produce a technically valid solution that solves the wrong problem. It can make assumptions about an architecture it doesn't fully understand. It can introduce a dependency that creates problems later. It can write a test that passes without actually testing the behavior that matters.

The engineer remains responsible for recognizing those things.

As AI gets better at producing code, knowing how to evaluate that code becomes more valuable. Understanding architecture, system behavior, security, performance and tradeoffs matters because engineers are increasingly reviewing work produced at a speed no individual could match manually.

The bottleneck moves from production toward judgment.

That distinction also appears in the research around AI productivity. DORA's 2025 research describes AI as an amplifier of an organization's existing strengths and weaknesses. Teams with strong engineering systems can capture more of the benefit, while weak processes can absorb the gains before they reach software delivery. (Dora)

EZOps explored a related issue in Why AI productivity gains stay with your engineers and how to change that, looking at what happens when individual engineering productivity improves but the delivery model around it stays the same. The engineer can move faster while the organization continues to operate at the speed of its slowest downstream process.

Context becomes part of the job

There is another reason AI doesn't simply remove engineering work: software systems contain a lot of context that isn't obvious from the code itself.

Why was a particular service built this way? Which dependency is difficult to replace? What does a specific customer require? Which part of the system tends to fail under heavy traffic? Why does a seemingly harmless change create problems three services away?

An AI model can work with that information when it has access to it. Getting the right context into the workflow, however, is an engineering problem of its own.

This puts more value on things teams have sometimes treated as secondary: good documentation, clear interfaces, useful tests, consistent development practices and well-defined requirements.

A messy codebase doesn't become easier to understand just because an AI assistant can read it.

In fact, the opposite can happen. AI makes it easier to produce more software inside an environment that hasn't necessarily become easier to operate. DORA's research has found that higher AI adoption can coincide with larger changes that take longer to review and can introduce delivery instability. (Dora)

The lesson is fairly practical: faster code generation still needs a disciplined path to production.

Engineers are becoming orchestrators

The role is also expanding beyond individual coding tasks.

An engineer might use one AI tool to explore a repository, another to generate an implementation, another to review the changes, and automated systems to run tests and security checks. The engineer coordinates the process and decides what moves forward.

This becomes more significant as AI evolves from assistants into agents that can take multiple actions with less direct input.

EZOps's Artificial Intelligence explained: from origins to agentic systems looks at this progression in more detail, including the shift from generative systems toward agentic AI that can plan steps, interact with tools and adapt based on outcomes. (EZOps Cloud)

For software engineers, that changes the nature of the workflow.

The question is increasingly less “Can AI write this?” and more “How should this process work?”

That means thinking about permissions, verification, observability and failure modes alongside the software itself.

Once AI systems start operating with access to production environments, these concerns become even more concrete. EZOps's What is AgentOps? Running AI agents in production with governance and observability explores that operational layer and the need to keep AI-driven systems observable and controlled as they move into production.

The junior engineer problem

One of the more complicated questions is what AI means for people entering the profession.

AI can remove a lot of the repetitive work through which junior engineers traditionally learned. Writing simple features, debugging straightforward problems and searching documentation can all happen faster with an AI assistant.

That is useful, but it creates a learning challenge.

A significant part of becoming an engineer comes from encountering problems that don't have obvious answers. You read unfamiliar code. You make a bad assumption. You break something. You figure out why. Over time, those experiences build intuition.

If AI handles every frustrating part of the process, junior engineers may become productive faster without necessarily developing the same depth of understanding.

Research already suggests that experience matters when working with AI coding tools. McKinsey found that more experienced developers tended to see larger productivity gains, while less experienced developers could struggle to critique and improve AI-generated output. (McKinsey & Company)

That doesn't mean junior engineers become less valuable. It means the way they develop expertise may need to change.

Senior engineers face a different opportunity. Their accumulated context and judgment can potentially be applied across much more work when AI handles more of the execution layer.

Productivity becomes a team problem

This is where measuring AI productivity gets complicated.

How many lines of code did an engineer generate? How many pull requests did they open? How many tickets were completed?

Those numbers were never perfect measures of engineering performance. With AI, they become even less useful.

An engineer can generate hundreds of lines of code in minutes. That doesn't tell you whether the software is better, whether the team can maintain it, or whether it actually solves the customer's problem.

The more useful measure is the entire path from an idea to reliable software: planning, development, testing, review, deployment and maintenance.

DORA's research points in the same direction. Its 2025 report argues that the biggest returns from AI don't come from the tools alone. They depend on the underlying organizational system around those tools. (Dora)

That changes the unit of analysis.

AI productivity is no longer just about what an engineer can accomplish in an afternoon. It is about what the engineering organization can reliably move from an idea into production.

The role is changing, even if the title isn't

Software engineers will still write code. They will still debug systems, review pull requests and spend plenty of time inside codebases.

The difference is that they are increasingly working alongside systems that can produce and modify code at a scale that wasn't possible before.

That makes technical judgment, system understanding and the ability to design reliable workflows more important, not less.

The engineer's value is gradually moving up the stack: from producing every line to defining what good looks like, providing the right context, evaluating what machines produce and making the decisions that still require human understanding.

The title may remain the same.

The job underneath it is already changing.