- ai-adoption
- engineering-leadership
- product-leadership
AI-augmented development team: expect a new shape
Expect an AI-augmented development team to produce more code and still wait on the same decisions. The code gets cheaper to write. Deciding what to build, and checking that it works as intended, becomes the slow and expensive part.
So expect, and demand, a different team shape. For about twenty years we put a product person inside the engineering team. I expect the next shape to be engineering experts embedded in product teams, close to the client.
I’ve watched big companies, well-run ones included, buy the tools and keep the team shape they had. The question isn’t how to use AI, but what a good software company looks like now.
Each era’s team shape followed its bottleneck
| Era | How software was built | Team shape | The bottleneck |
|---|---|---|---|
| 1970s to early 2000s, on large contracts | Design first, build in sequence, test at the end | Designers, then builders, then testers | Change: requirements moved before delivery |
| Late 1990s to early 2020s | Small batches, shipped often | Small teams with a customer or product owner inside | Communication: what the code does has to fit in a few heads |
| From about 2023 | AI makes code cheaper | Engineers inside the product team (my view) | Decisions: what to build, agreed with the client, then checked |
On large contracts, software was built like a construction project. In 1970 Winston Royce drew the sequential model, with testing left to the end. He warned that it was “risky and invites failure”, and he never called it a waterfall.
The requirements kept moving too. On large systems, Capers Jones measured them changing by 1% to 3% a month during analysis and design. By delivery, the total change could pass half of the original requirements.
Agile methods made two changes that matter here. The first was small teams, because communication has a real cost.
Fred Brooks gave that cost a formula in 1975. Possible coordination paths grow as n(n-1)/2: five people have 10, ten have 45, twenty have 190 and fifty have 1,225.
I’ve seen that cost first-hand. One project I joined was a year late, with 27 engineers on it, and more people had not fixed it. The first things I changed were how decisions were made, and it shipped on its date four months later.
The second change put the customer inside the team. Extreme Programming asked in 1999 for a customer to sit with the team full-time.
The Agile Manifesto of 2001 said business people and developers must work together daily. The Scrum Guide names the role: one Product Owner, accountable for the product’s value. That is the shape many companies still call a product team.
Continuous integration came with Extreme Programming, and continuous delivery followed. DORA’s 2024 survey shows how far apart teams now are: elite teams deploy 182 times more often than low performers.
Team shapes changed when the slow part of the work changed. AI changes it again.
The bottleneck moves to deciding and checking
IDC found developers spent 16% of their time on application development in 2024. A Microsoft study of 484 of its own developers put coding at about 11% of the working week. So faster coding speeds up a small part of the week.
The trials give mixed results. In GitHub’s 2022 experiment, developers using Copilot built a simple web server in 71 minutes on average, against 161 without it. That was one small task.
In METR’s 2025 trial, experienced developers took 19% longer with AI on their own mature projects. They believed afterwards that it had made them 20% faster. METR’s 2026 rerun points to speed-ups, which METR itself calls weak evidence.
A better measure is what reaches customers. A 2026 study of more than 100,000 GitHub developers found AI tools roughly tripled commits but raised shipped releases by only about 30%. The difference is the work people still do: reviewing, integrating, testing and releasing.
Speeding up one stage often leaves work waiting at the stages around it. A lot of what AI does for a team depends on how the team already works. Google’s DORA research put it plainly in 2025: “AI doesn’t fix a team; it amplifies what’s already there.”
So the slow part moves to deciding what to build and agreeing it with the client, and to checking that it works as intended. Andrew Ng wrote in April 2026 that when one product manager decides and one engineer builds, “the communication between them becomes a bottleneck”.
The next shape puts engineers inside the product team
When you build an engineering function, you are building the machine that produces software, not just the software that is built. Now the decisions are becoming the scarce part, so I expect that machine to form around them. In that shape, engineering experts sit inside the product team, close to the client.
The roles merge more than they replace each other. Ng reports some teams moving engineer-to-product-manager ratios from about 8:1 towards 1:1. The fastest teams he sees have engineers who know how to do some product work.
No study proves this shape yet, though the evidence above supports its premise.
In a business of 10 to 50 people, that means a senior engineer in the client conversations. Next to them sits the person who owns the client relationship and decides what to build. The engineer takes part in that decision, saying what is feasible and what it will cost.
The conversation is recorded, with everyone told why. Before the next one, the engineer builds a demo from what was agreed and checks it against the transcript. How to write software requirements with AI covers that loop step by step.
The same engineer owns the quality of what ships. Code that is cheap to write still has to be reviewed, tested and kept secure. DORA’s 2024 report linked each 25% rise in AI adoption to an estimated 7.2% fall in delivery stability.
I’ve worked in this shape at small scale. On one engagement, the person writing the code also sat in the founder’s sales calls and turned what buyers said into the roadmap.
In a business of this size, one senior person can hold the product seat and the engineering seat together. PIMASI offers that seat, and what a fractional CPO does explains its product half.
Expect four things from an AI-augmented development team
Ask for each of them this quarter.
- An engineer in the client conversations. A senior engineer hears the client first-hand and says what is feasible.
- A demo before the next conversation. The client reacts to working software built from what they said last time.
- Releases, not commits. Ask what reached customers and what it changed for them.
- A named owner for quality. One person answers for what AI writes: the review, the tests and the security.
Waiting has a cost. A team in its old shape pays for the AI tools and still waits on the same decisions.
The decision in front of you is whether your team is shaped for the work AI leaves to people: deciding and checking. If that question is open, book the exploratory call.