How Teams Must Adapt to AI-Assisted Development

Something shifted in how we build software, and it did not arrive with a playbook. As an engineering manager, I spend less time debating whether AI belongs in our workflow and more time answering a harder question: what should our teams look like now?

The old defaults still linger in our heads. Scrum taught many of us that a "proper" squad meant four or five developers, a product owner, maybe a designer, ceremonies on the calendar, and velocity as the north star. That model made sense when throughput was bounded by typing speed, context switching, and the cost of translating intent into code.

That constraint is loosening. Not disappearing — loosening. And teams that keep their shape while the ground moves under them will feel friction long before they understand why.

Smaller teams, sharper focus

I no longer believe we need four- or five-developer squads as the default unit of delivery.

What I see working — and what I am intentionally moving toward — are teams of two or three developers who are deeply product-oriented: people who understand the problem, the user, the trade-offs, and the business context; not engineers waiting for perfectly groomed tickets at the top of a backlog.

AI compresses parts of the implementation curve. A small group with strong product judgment can explore more options, prototype faster, and ship meaningful slices without the coordination tax of a larger team. Fewer handoffs. Shorter feedback loops. More time in the work that actually matters.

This is not an argument for understaffing. It is an argument for right-sizing: fewer people, higher leverage, clearer ownership.

More multidisciplinary by design

Smaller does not mean narrower.

If anything, teams need to become more multidisciplinary. The line between "engineering work" and "product thinking" was always thinner than our org charts suggested; AI makes that obvious. When implementation is faster, the bottleneck moves to problem framing, quality bar, architecture fit, and knowing what not to build.

Design, data, domain knowledge, customer empathy, operational awareness — these stop being nice-to-haves that other departments provide and start being core team capabilities. The best squads I have seen recently look less like a dev factory and more like a compact product unit that happens to ship code.

As a manager, my job is to compose teams where those skills overlap, not to hope they appear at the right moment in a sprint.

Supporting engineers through the transition

This part matters more than any tooling decision.

For many engineers, the message has landed wrong: fewer people per team, more automation, faster output. Read uncharitably, that sounds like devaluation. Read honestly, without support, it can feel like devaluation.

Leaders have to intervene in that narrative.

AI is not a replacement for engineering judgment. It is a multiplier for engineers who know what good looks like. The opportunity is not "do the same with less." The opportunity is build things that were previously out of reach — richer features, tighter iteration, more ambitious bets — because the cost of exploration has dropped.

I tell my teams directly: the goal is not to go faster on the same roadmap. The goal is to raise the ceiling of what we can deliver with the time we have. When someone worries that their craft is shrinking, I want that conversation in the open, not in a hallway after a reorg slide.

Practical support looks familiar: protected learning time, shared prompts and patterns, explicit quality standards, pairing on harder reviews, celebrating work where AI helped us reach a better outcome — not just a faster one. Transition support is not a one-off training session. It is ongoing leadership.

Roles are evolving — all of them

The "pure engineer" role, as we used to describe it, is evolving toward something I'd call quality engineering in the broadest sense: less about typing every line, more about system thinking, correctness, maintainability, security, performance, and knowing when generated code is good enough versus dangerously shallow.

At the same time, product managers need more architectural literacy. Not to become architects, but to reason about constraints, incremental delivery, debt, and why a feature that looks simple on a slide might be expensive — or vice versa. When implementation speeds up, bad product decisions fail faster and louder.

Design, QA, platform, data — everyone feels the shift. All roles evolve. The mistake is to update the tooling and leave the career paths, expectations, and performance rubrics unchanged.

As an engineering manager, I see my responsibility as accompaniment: honest conversations about where each role is heading, training that is tied to real work, and performance frameworks that reward judgment and outcomes, not activity metrics from a previous era.

What I am optimizing for

I am not trying to recreate 2020 Scrum with an AI copilot bolted on. I am trying to build teams that are:

• Small enough to move with intent
• Multidisciplinary enough to make good decisions early
• Supported enough to see AI as expansion, not threat
• Clear-eyed enough to know that speed without quality is just a faster way to accumulate regret

The teams that adapt well will not be the ones with the flashiest tools. They will be the ones whose shape, skills, and culture match the new economics of building software.

That is the work I am doing now — not as a prediction about the distant future, but as a management practice for the team I have today.