How AI Changes Who You Need on a Software Team

I ran a leadership session with a group of developers recently. I told them AI had changed the work their teams do, and that a lot of them were not going to fit the job that was left. They pushed back. Their response was that they could still write TypeScript, Python, and Go by hand.

I asked who still knows hardware registers, and who can explain what the compiler, interpreter, or runtime is actually doing with that code.

Nobody had the whole answer. A few remembered something they had read years ago. They had been shipping software for years without being able to explain the tools between their source code and the machine.

I asked the question to make a simple point: software jobs have already moved above work that tools learned to handle.

Why I asked about registers

The exact path differs by language. Go is compiled. TypeScript is compiled to JavaScript and then handled by a JavaScript runtime. Python commonly runs through an interpreter and virtual machine. In each case, application developers work above the machine because the toolchain handles the lower steps.

Compiler engineers, runtime engineers, and embedded engineers still work in those lower layers. Product teams call them when the problem reaches that depth. Most teams do not staff every product effort with that expertise.

AI now generates a lot of the source code that the toolchain receives. The compiler, interpreter, and runtime still do their jobs. The person no longer has to type every line for the software to reach them.

Writing code remains useful. It gives someone another way to inspect a problem and correct a bad result. It is a weaker staffing argument when the role is limited to producing source code that AI can already produce.

The change reaches the whole delivery path

The same change is happening outside implementation. AI can now do much of the execution that used to require a separate person at each step:

• Product: summarize research, compare options, draft requirements, and build a working prototype. A person still chooses the problem, the constraints, and the result worth pursuing.
• Project management: break work down, maintain status, identify dependencies, and prepare updates. A person still resolves tradeoffs and keeps decisions moving.
• Development: write code, refactor it, trace defects, and explain an unfamiliar codebase. A person still sets the boundaries, reviews the result, and operates what ships.
• QA: generate tests, run them, reproduce failures, and check expected behavior. A person still decides what must be proven and which risks are acceptable.
• Infrastructure and DevOps: write configuration, change pipelines, inspect telemetry, and work through routine operational problems. A person still owns reliability, cost, recovery, and production risk.

This is why I do not expect every product effort to pass through five separate seats. For a growing amount of product work, one experienced person can drive the whole path or own a larger section than one old function. AI handles much of the technical execution. The person defines the problem, keeps the work moving, checks the output, and owns what happens in production.

Complex, regulated, high-scale, and high-risk systems still need deep specialists. The specialties remain. Staffing every initiative as a chain of separate silos is what is shrinking.

A high-performing team is smaller because each person can own more of the result. It is still a team. Its members share context, review the important decisions, and bring in specialists where the risk or complexity requires them. One person owning a wider span does not mean one person works alone.

This also changes the cost of being wrong. A pivot or refactor used to require another round through the whole chain. The same person or small team can try an approach, measure the result, change direction, restructure the code, and check again. From Concept to Cloud covers what that working loop looks like on a serious system.

Who fits the wider role

The people who fit can define the problem, direct the work, refuse a bad result, and tell whether the change worked in production. They may have started in product, project management, development, QA, or infrastructure. Their original function matters less than the span they can now own.

Some experienced people were never the strongest coders. Coding used to block them from completing the work themselves. AI removes much of that blocker. Their knowledge of the customer, system, failure modes, and operating environment can now carry a change all the way to a verified result.

Some strong developers already work this way. Give them the larger span. Someone whose value stops at writing TypeScript, Python, or Go has a real role problem. The same is true for someone who can only execute a test plan, update a project tracker, or tend a pipeline after another person has decided what needs to happen.

Judgment still has to come from somewhere. A lot of people developed it by writing code, watching systems fail, and learning where their assumptions were wrong. That path is thinner when AI handles more of the execution. Leaders have to teach it deliberately: walk the critical paths, the money paths, the production signals, and the failures the business cannot afford. Cognitive Debt explains why generated output still requires someone who understands enough of the system to direct it.

Wider ownership needs better guardrails

Removing handoffs increases the span one person can cover. It can also increase the damage one person can cause.

A team working this way needs automated checks, clear production signals, repeatable deployments, access controls, and a recovery path that has been tested. Without those controls, wider ownership only gives someone more ways to be wrong.

The review capacity has to keep up as well. When AI produces changes faster than the team can understand and verify them, the work backs up in The Review Bottleneck. Faster generation is useful only when the team can still judge, ship, and operate the result.

What I change

On a team I am responsible for, I do four things:

1. Assign a wider span. One person owns the whole path or a meaningful section of it: the problem, implementation, QA, delivery, and production result. They use AI for the execution and bring in specialists when the work reaches a boundary that needs them.
2. Test judgment with real work. Give them a real change, including a generated change that is wrong. Ask what must stay true, what they would refuse to ship, how they would know it worked, and what they would do when it fails. I use the register question in a working session. I do not use it as a trivia test in an interview.
3. Remove default handoffs and strengthen the controls. Stop assigning a separate seat to every function when AI can handle the routine execution. Put automated checks, observability, deployment controls, and recovery procedures around the wider owner.
4. Measure the result. Check whether the team solved the problem, reduced the time to production, maintained reliability, and learned fast enough to correct a wrong direction. Measuring AI-Assisted Engineering covers the measures I use.

Start with one product area. Give one capable person a wider span, keep specialist support available, and measure whether the team can ship, operate, and correct the result faster.