Predictions for how AI will change product delivery

Introduction

Before generative AI went mainstream, the pace of change in tech already felt rapid and accelerating. We’re only starting to come to terms with the disruption caused by the widespread availability of advanced large language models (LLMs). It will take years for us to converge on a new equilibrium, and no one can confidently foretell what that will look like.

What follows are some tentative predictions. Some of them are uncomfortable, but what is certain is that changes will be inevitable and the only thing we can choose is how we respond.

Prediction 1: Demand for product innovation will continue to increase

The economics of product delivery are changing, and businesses are playing catch up. Organisations used to thinking of product development as a cost centre are responding by cutting costs through hiring freezes and layoffs. In most cases, this is short-sighted.

In practice, most organisations have more product ideas than capacity to deliver them, and the rate of product innovation is a key determinant of their ability to deliver the business outcomes that backers expect.

Pre-AI investment in product innovation was not limited by ambition, but the cost of delivery. When that cost falls, the rational response for most organisations is not to pocket the saving, but to reinvest it for greater returns.

This is Jevons Paradox applied to software: greater efficiency tends to drive greater demand, not less.

Prediction 2: The shape of product delivery teams will change

While demand for product delivery may be stable or increase, the nature of product delivery won’t be unaffected. AI is leading to changes in how product delivery is done that will reshape tech organisations.

A typical non-AI-enabled product team looks like this: one Product Manager (PM), one UX/UI designer, three to five engineers, and one tester. This shape is optimised around coding historically being the most labour-intensive activity in the SDLC (Software Development Life Cycle). But AI changes that picture.

AI can augment and accelerate every activity in the SDLC, but the gains are distributed unevenly. A large part of engineering work has always been relatively mechanical: unique in its business context, but following common patterns that AI is excellent at capturing and applying. It’s not implausible that an engineer could double their impact with effective use of AI.

But the work of understanding users’ specific problems and designing solutions that meet them demands a much greater ratio of novel thinking. AI can assist, but it accelerates this work far less.

So the optimal team shape will be different. A PM and designer working with five AI-accelerated engineers would continuously fall behind, as the bottleneck shifts from implementation to discovery and design. To rebalance, you need to increase the ratio of product and design capacity relative to engineering. A team with one PM and one designer may need only two AI-enabled engineers to keep pace with the rate that implementation-ready designs can be created.

But that creates a resiliency problem, particularly for teams operating in You Build It You Run It mode. Two engineers is not enough for a sustainable on-call rota. Scaling the team proportionally addresses this: two PMs, two designers, four engineers, one tester. This is an unfamiliar configuration. Scaling PM and design work on a small team could result in fragmented product vision, conflicting priorities, and design inconsistency. These don’t have the same established mitigations as scaling engineering, but in principle similar approaches can be used.

With code generation becoming cheaper, and AI enabling engineers to work competently across less familiar tech stacks, all automated tests should be implemented alongside production code by the same engineers who write it. The tester’s role shifts: less implementation, more coaching in testing techniques, and customer-focused validation that features deliver valuable user experiences in line with the product vision.

Prediction 3: A shift of focus in the SDLC

Not the end of code

Some are theorising a concept called “spec-driven development.” In the extreme version, software would be fully implemented using human language without ever inspecting the generated code, treating code as throwaway and easily replaceable. This is plausible in narrow, well-trodden areas of software development, but in general, it’s not. Code is a formal language, which can define functionality with a rigour and precision that human language cannot match.

Although human language cannot replace code, AI raises the bar for how precisely intent needs to be expressed. The following sections describe where teams will need to tighten their discipline.

Small slices

Teams often talk about the benefits of small stories, but splitting stories into small slices of value is an underdeveloped skill. Engineers often take on overly large stories and muddle through. Their logic reasoning ability and large persistent working memory means they can usually find a way.

LLMs lack the capacity for logical reasoning or a real persistent working memory and struggle much more in this situation. They give much better results when implementing a small, focused set of changes. Teams need to develop more discipline about breaking work down into genuinely small pieces. AI can help with this task, but you should always review and refine the output.

For practical guidance on how to break down user stories into AI-friendly slices, see Tech Lead Handbook: Feature Slicing.

User stories

Despite what most SDLCs say about writing clear user stories with comprehensive Acceptance Criteria (ACs), most teams get by with scrappy notes. This works because of the tacit knowledge that team members accumulate through experience, conversation, and shared problem solving. Think about how much information surfaces in a Three Amigos or refinement session, and how little of it makes its way into the ticket.

AI coding tools have none of that tacit knowledge. Given a typical user story, there usually isn’t enough written down for AI to know what is needed. Teams will need to get far better at writing down intended outcomes to achieve reliable results without excessive iteration.

Plan first

Even with well-written user stories and considered ACs, AI can lose its way. Before letting it write any code, get it to produce a written plan for what it intends to do. Only once you have reviewed and refined that plan should implementation begin. Aligning on thinking first leads to far better results, and far fewer surprises to unpick later.

Test-driven

Once you’ve split stories into small vertical slices, written comprehensive ACs, and agreed an implementation plan, you’re ready to start implementation. The question is where to begin.

Unit tests are essential. Without them, code quality and maintainability suffer unacceptably. Most engineers know about test-driven development (TDD) but rarely use it in practice. Instead they implement production code first, then write tests, with the risk that the tests validate what the code does rather than whether it meets the original requirements. The tests protect against regression but may not catch bugs in the initial implementation.

Asking AI to write unit tests after it has written production code creates the same problem, but amplified. AI is prone to producing tests that confirm its own output rather than checking it against the intended behaviour. The only reliable approach is to ask AI to write the tests first.

This is another example where a disciplined approach that has often been thought to not be worth the effort is essential to get good results with AI.

When tackling each step of the agreed plan, the approach should be the classic red, green, refactor.

Red: Use AI to write unit tests, which should initially fail (be “red”). Engineers should review these tests carefully to check they encode the correct business logic before proceeding.

Green: Use AI to write production code to make the tests pass (be “green”). This code can be reviewed more selectively. Assuming the tests are right, the main focus of this review is to guide the structure of the code.

Refactor: Use AI to refactor if needed. AI can identify possible refactorings, but engineers should lead on deciding how to move the code toward the target architecture.

Prediction 4: Engineers will need to rebalance their skills

Where are we coming from?

In recent years, engineers have relied less on memorising specific language syntax, thanks to powerful web search and IDE features that surface answers quickly. It has still been important to maintain a mental map of what is and isn’t possible, but the precise way to achieve a given outcome has been ever easier to discover.

Writing high quality code still required intimate knowledge of language, libraries, design patterns, and conventions, and developing these skills was the main focus for early-career engineers.

Higher-level skills such as code architecture, designing with scalability and security in mind, and optimising for flexibility and maintainability, took years to develop and emerged from sustained experience. As engineers progressed into senior roles, they learned to distinguish between problems that have known solutions (safe to delegate) and those that are genuinely novel, fiddly, or high impact (where they need to stay closely involved).

Where are we going?

Working with a code-generating LLM is like working with an engineer who is inexhaustibly keen and superhumanly knowledgeable, but also unusually erratic and prone to basic logic errors. The intuition and taste that historically took years to develop turns out to be exactly what you need to know when to intervene before AI veers off course.

The uncomfortable truth is that the ways AI falls short (judgement, taste, architectural thinking) are also the areas that are underdeveloped in today’s early-career engineers. Organisations need a way to continue to bring early-career engineers into the workforce, as they will develop into future senior engineers. But for this to make business sense, these engineers need to be able to deliver high quality outcomes with AI, and this means they need different skills.

Fortunately, there is a way forward. The higher-level skills needed to effectively steer AI are learnable and teachable. They are not inherently harder to acquire than raw coding skills, but they are different. Formal training, hands-on experimentation, and mentorship are all still relevant; they just need to evolve to focus on these skills rather than syntax and implementation mechanics. An early-career engineer equipped with these skills will contribute meaningfully from the start. And as has always been the case, hiring early-career engineers is a sound long-term investment: they learn your domain, absorb what good engineering looks like in your context, and grow into exactly the people you need.

Conclusion

AI is not making product engineering simpler, it’s shifting where the complexity sits. The mechanical work of writing code is becoming cheaper and faster. But the hard work of understanding problems clearly, designing solutions deliberately, and maintaining quality through discipline is more important than ever.

Organisations that treat AI primarily as a cost-cutting tool are likely to find that their competitors are using it to move faster and build better. Teams that adapt their shape, sharpen their practices, and invest in developing engineers who can think clearly about problems rather than just implement solutions will have a meaningful advantage.