^{Prefer listening over reading? 🎧 Listen (AI-Generated Audio Version)}

There is a growing confidence in the market that AI will replace software development. The narrative is straightforward:

AI can generate code, therefore software development, and the teams behind it, are at risk of being replaced. This conclusion is being treated as inevitable and it is beginning to shape how organisations invest, hire and plan.

The premise, however, is flawed. And for product teams, the consequences of acting on it are significant.

Software Is a Product, Not Just Code

Software is rarely just a codebase. It is a product that sits inside a broader system of people, relationships and context. Behind every piece of software there are users with real needs and established habits, customers with expectations, support teams handling edge cases and business stakeholders with competing priorities.

The product layer, the decisions about what the software should do, who it serves, what problem it solves and how it should evolve, is what gives code its value. At least for now, AI can accelerate the production of code, but it cannot replace the thinking that determines what that code should do.

Understanding this distinction is the difference between organisations that use AI to deliver better outcomes and those that use it to deliver more output.

The Hard Part Was Never Writing the Code

Fred Brooks, the computer scientist and Turing Award winner, made an observation in his essay No Silver Bullet that has aged remarkably well. Brooks argued that the hardest part of software is not the mechanics of writing it, it is deciding what to build and understanding how it should behave.

He distinguished between accidental complexity, the friction of implementation, tooling, syntax, and essential complexity, which is the inherent difficulty of understanding the problem domain, the users, the constraints and the trade-offs involved in any product decision.

LLMs are extraordinarily capable at reducing accidental complexity. But they operate almost entirely at the level of mechanics. The essential complexity, the discovery work, the prioritisation judgements, the stakeholder alignment, the strategic trade-offs, remains a deeply human problem.

For product teams, this is not a theoretical concern. It is the daily reality of the job.

Discovery Cannot Be Automated

Before a line of code is written, product teams must answer questions that AI cannot answer on their behalf. Who are the users and what are they actually trying to achieve? What is the gap between what exists today and what they need? Which problems are worth solving, and which are symptoms of deeper issues that a feature will not fix?

This is the work of discovery — and it requires context that lives outside any model. It requires conversations with users, observation of behaviour, an understanding of the market, and the ability to distinguish between what users say they want and what will genuinely change their experience.

AI can support discovery. It can help analyse feedback, surface patterns and accelerate research synthesis. But it cannot replace the human judgement required to interpret what is found and decide what it means for the product.

Organisations that skip or compress discovery because they can now build faster are not becoming more efficient. They are becoming more efficient at building the wrong things.

Prioritisation Is a Strategic Decision, Not a Technical One

Product teams operate under permanent resource constraints. Every decision to build something is simultaneously a decision not to build something else. This opportunity cost is one of the most important and least visible dimensions of product strategy.

AI does not change this dynamic, it intensifies it. When the cost of building falls, the pipeline of things that could be built expands. Without stronger prioritisation discipline, teams will find themselves spread across a wider surface area of features and initiatives, many of which were never quite the right investment.

The question is not whether something can be built. The question is whether it should be, and whether it is the most valuable use of the team’s capacity at this moment.

Effective prioritisation requires a clear understanding of the outcomes the product needs to deliver, a view on where the biggest gaps exist, and the ability to say no (or not yet) to ideas that are viable but not valuable enough given the alternatives. None of this becomes easier just because building becomes faster.

Stakeholder Alignment Is Still the Bottleneck

In most organisations, the constraint on product delivery is rarely pure development capacity. It is the alignment between product, technology and business stakeholders on what matters and why. Roadmaps stall not because teams cannot build, but because there is insufficient shared understanding of the problem being solved, the user being served or the outcome being targeted.

AI-assisted development can close the gap between a decision and its implementation. But it cannot create alignment that does not exist.

A team that moves faster in the wrong direction does not benefit from the speed.

The organisations that will gain most from AI in product development are those that have already invested in the foundations: clear product vision, strong discovery practices, disciplined prioritisation and genuine alignment between business and technology. For organisations that are still working through those challenges, AI will accelerate the symptoms rather than resolve them.

Building the Right Thing Remains the Hardest Problem

The risk for product teams in this moment is not that AI will make them redundant. It is that the pressure to demonstrate AI’s value (internally and externally) will drive teams to build more without necessarily thinking more carefully about what they are building.

The half-baked feature that takes a week to ship instead of a month is still a half-baked feature. It still creates support overhead, introduces maintenance cost, adds noise to the product and consumes the attention of users who expected more. The speed of delivery does not change the quality of the decision that preceded it.

Product strategy has always required discipline around what not to build. That discipline becomes more important, not less, as the ability to build accelerates.

Where AI Genuinely Changes the Product Equation

None of this is an argument against embracing AI in product development. The capability is real, the productivity gains are significant and teams that do not engage with it will face competitive disadvantage.

The point is more specific: AI should be applied where the product problem is well understood and the value is clear. When discovery has been done, when the user need is validated, when stakeholders are aligned on the outcome, AI-assisted development can compress the time between a good decision and its delivery. That is a meaningful advantage.

Consider a product team managing a developer platform where consistent feedback, across support tickets, community channels and user interviews, points to the same problem: authentication flows behaving inconsistently across API endpoints. The discovery is done, the problem is validated and stakeholders are aligned. This is exactly where AI-assisted development delivers. The team can accelerate the implementation of a unified authentication layer, compressing weeks of work into days. The value of AI here is not that it identified the problem or decided it was worth solving. The team did that. It is that it removed the distance between a good decision and its delivery.

What AI cannot do is substitute for the work that precedes a good decision. It cannot replace the conversations with users, the debate in the roadmap review, the hard prioritisation choices or the product intuition that comes from deep engagement with a market and its people.

Conclusion

The conversation about AI and software has focused heavily on what will change. For product teams, it is equally important to be clear about what will not.

The tools available to build software will continue to evolve. They always have. What remains constant is that the hardest part of software is deciding what to build and understanding how it should behave.

AI makes building faster. It does not make deciding easier. Product teams that understand this distinction and invest their human judgement where it matters most, will be the ones that turn AI’s capabilities into outcomes that actually count.