What AI Changes About Software Engineering

More leverage, broader ownership, and a higher quality bar

AI will change software engineering. That does not require believing that software engineers disappear. A more useful way to think about the change is that AI alters the economics of producing software: implementation gets cheaper, one engineer can direct more execution, and work that used to be too expensive can become practical.

That creates real competitive pressure between engineers, but it also expands the field. The opportunity is not merely to complete today’s backlog faster. It is to take responsibility for larger outcomes, to raise the quality of what we ship, and to build useful things that previously could not justify the engineering cost.

Technology changes jobs by changing what is worth doing

There is a good historical reason to expect the shape of work to change substantially. Research by David Autor and coauthors estimates that roughly 60 percent of U.S. employment in 2018 was in job titles that did not exist in 1940. The point is not that technological change is painless. It is that technology repeatedly destroys some tasks, creates others, and changes the mix of skills that are valuable.

AI is large enough as a technological shift that software engineering should not expect to be exempt. The profession may persist while the day-to-day job changes dramatically. In that sense, the question “Will AI replace software engineers?” is too coarse. The better questions are: Which parts of the work become cheap? Which parts remain scarce? What new work becomes possible when the cost curve moves?

AI changes the economics of software engineering before it settles the question of how many software engineers there will be.

Automation does not eliminate responsibility

Airline pilots are a useful analogy, as long as we use the analogy carefully. Modern aviation relies heavily on automation, yet the presence of automation has not made human competence irrelevant. FAA human-factors guidance explicitly treats automation skills as part of pilot competence rather than a substitute for it. Automation handles routine execution and reduces workload, while pilots still monitor the system, respond to unusual conditions, exercise judgment, and remain accountable for the flight.

Software is moving toward a similar division of labor. AI can increasingly perform implementation work that once consumed a large share of an engineer’s time. But a human still has to determine what should be built, understand the tradeoffs, decide whether the result is safe and useful, and own the consequences when it is wrong. The human role moves upward from producing every artifact by hand toward exercising judgment over a larger result.

Software has a different leverage ceiling

The pilot analogy breaks in an important place. No matter how capable the automation becomes, a pilot is not normally going to fly several commercial airliners at the same time. Software work has a much weaker concurrency constraint. An engineer can have an agent working on a feature while another run develops tests, a third investigates a bug, and a fourth improves a deployment pipeline. The engineer’s attention is still finite, but implementation can happen in parallel.

That means differences in AI effectiveness can create large differences in engineering leverage. An engineer who can successfully delegate larger, more complete units of work can simply attempt more. As models improve, the gap can widen further because the strongest workflows have somewhere useful to put the new capability.

This is the individual competitive pressure I would take seriously. It is less about a company choosing “an AI” instead of hiring a software engineer, and more about engineers who become excellent at using AI outcompeting engineers who do not. The same unit of work becomes easier for one person to absorb.

If the models get substantially better over six months and your own output barely changes, your workflow is probably leaving capability on the table.

Demand for software is not fixed

The scary version of the productivity story assumes a fixed amount of software work. If one engineer can do twice as much, the conclusion seems obvious: employ half as many engineers. But software demand has never been fixed. There is an enormous amount of software that is not built today because the value it would create does not justify the cost of building and maintaining it.

Think about the internal tool that would save a team a few hours every week but would take six months to develop. The niche product that would be wonderful for a few hundred users but cannot support a traditional product team. The manual workflow that everyone dislikes but is too specific to justify custom software. The technical debt everyone knows is there, but whose payoff has never beaten the next feature on the priority list.

When the cost of producing software falls, some of that non-consumption becomes viable. We do not only make existing software more cheaply. We move the boundary of what is economically worth creating.

This may also change the character of software. Today, many products have to be generalized because the development cost must be spread across a large market. Cheaper production makes more specialization possible. Instead of a product that moderately serves everyone, we can afford more tools that fit a particular company, team, workflow, or small user group exceptionally well. For engineers, that can be more satisfying work because the value delivered to each user can be much more direct.

The productivity dividend can become quality

There is another assumption worth challenging: every AI productivity gain has to become more features. It does not. Additional capacity can go to more output, broader ownership, or higher quality.

Engineering has always been full of economically rational compromises. A system may have a strong architecture and a reliable backend while the front end is merely fine. The main paths may be thoroughly tested while edge cases are covered less deeply. CI/CD may work without being elegant. Observability may be adequate. Documentation may be enough to hand off the system but not genuinely excellent.

Those choices do not imply bad engineering. They reflect scarcity. Teams put the next hour where it creates the most value. When AI makes implementation and iteration cheaper, the cost side of that calculation changes. A polished front end, stronger accessibility, more robust tests, better deployment automation, richer telemetry, cleaner documentation, and debt reduction can all fit into the same economic envelope more often than they used to.

For years, we have had to choose which parts of a solution deserve the expensive engineering time required to make them great. AI lets us expand the number of things we can afford to make great.

For individual contributors, the opportunity is broader ownership

This is where I would be careful with the phrase “supervising AI.” For many engineers, it sounds like an invitation to stop engineering and become a manager. That is not the useful direction. The more compelling opportunity is to take responsibility for more of the engineering lifecycle.

Instead of defining the job as “I implement this component,” define it increasingly as “I own this outcome.” That means understanding what should be built and why, shaping the experience, making architectural decisions, deciding how correctness will be established, thinking through deployment and rollback, designing observability, handling operations, and maintaining the system as it evolves.

AI can perform more of the execution underneath that ownership. The engineer still exercises technical judgment across the whole. In some ways, this is a more engineering-heavy version of the job because it rewards people who understand how the pieces fit together rather than people who can only produce one piece quickly.

There is still a ceiling. Human attention, context, judgment, and accountability remain scarce. One person cannot meaningfully understand and own an infinite number of systems simply because agents can generate infinite code. As implementation gets cheaper, those human constraints become more visible and more valuable.

What engineers should do now

1. Expand what you can successfully delegate. Do not stop at autocomplete and isolated snippets. Keep experimenting with giving AI larger, more complete pieces of real work, while preserving the ability to understand and evaluate the result.

2. Expand the outcomes you can own. Learn more of the lifecycle around your code: requirements, product thinking, UX, architecture, testing, deployment, operations, maintenance, and evolution. Broader ownership is a technical skill, not merely a management role.

3. Spend some of the productivity dividend on quality. Do not measure AI adoption only by ticket throughput. Use some of the additional capacity to make the user experience, testing, automation, observability, documentation, and maintainability better than the old economics allowed.

4. Look for work that was previously uneconomical. Ask what your team is not doing because it would take too much engineering time. Internal tools, specialized workflows, debt reduction, and small automations are exactly where a lower cost of software can create new value.

5. Make model progress become your progress. Build a way of working that has somewhere to put new model capability. When models become better at reasoning, coding, testing, or operating tools, your span of successful delegation and responsibility should grow with them.

A larger definition of the engineer

The most interesting future for software engineering is not one where engineers simply close twice as many tickets. It is one where a single engineer can responsibly take on work that previously required a much larger team, where more of every solution can receive real craftsmanship, and where niche problems that were never worth solving can finally receive software built specifically for them.

That future still contains competitive pressure. Engineers who learn to turn model improvements into practical leverage will have an advantage over engineers who do not. But the same technology that creates that pressure also expands the frontier of useful work.

The opportunity is to keep expanding what you can successfully delegate and what you can responsibly own.

Sources

David Autor et al., “The Origins and Content of New Work, 1940–2018,” NBER Working Paper 30389 (2022). https://www.nber.org/papers/w30389

Federal Aviation Administration, “Determining Appropriate Levels of Automation.” https://www.faa.gov/sites/faa.gov/files/training_testing/training/fits/research/Det_App_Lvl_Atm.pdf