Over the past year, I have spent a significant amount of time experimenting with AI-assisted development. Like many engineers, I started with simple coding tasks. Generating functions, explaining unfamiliar libraries, creating test cases, and automating repetitive work were obvious entry points. As the tools improved, I began using them for larger tasks, including entire features, architectural exploration, documentation, and prototype development.
The productivity gains are real. Anyone who spends time with modern development tools can see that. Tasks that previously required hours can often be completed in minutes. Prototypes that might have taken days can be assembled in an afternoon. Even when the generated output is imperfect, the amount of effort required to reach a working solution is often dramatically lower than it was only a few years ago.
What surprised me, however, was not how much faster software could be produced. What surprised me was how quickly software development stopped being the bottleneck.
When I look back at projects I have worked on throughout my career, relatively few failed because engineers were unable to build the solution. Certainly there were technical challenges, architectural mistakes, scalability problems, and implementation issues. Those things happen in every organization. But more often than not, the larger difficulties appeared much earlier in the process.
Teams struggled to understand customer needs. Stakeholders disagreed on priorities. Business objectives changed. Assumptions turned out to be incorrect. Products solved problems that customers did not actually have. Features that seemed important during planning ended up being rarely used after release.
None of these problems were fundamentally engineering problems.
They were decision-making problems.
For a long time, organizations could partially hide this reality because implementation was expensive. Building software required enough effort that engineering capacity naturally became a visible constraint. Since everyone could see the constraint, many processes evolved around managing it. Roadmaps, prioritization frameworks, governance models, funding approvals, and portfolio reviews were all mechanisms for deciding how scarce development resources should be allocated.
As AI reduces the cost of implementation, some of those assumptions start to look different.
A team that can build significantly faster does not automatically become more effective. In fact, increasing execution capacity can sometimes expose weaknesses that were previously hidden. If an organization struggles to identify meaningful opportunities, faster implementation simply allows it to pursue more questionable opportunities. If priorities are unclear, additional productivity may generate more activity without generating more value. If teams lack a deep understanding of their customers, they can now build unwanted features at unprecedented speed.
This is one of the reasons I have become increasingly interested in product management as a discipline. Not product management as it is sometimes caricatured—the endless meetings, roadmap negotiations, backlog maintenance, and stakeholder coordination—but product management as a mechanism for navigating uncertainty.
The most valuable product leaders I have worked with were rarely the people who wrote the most detailed requirements. They were the people who consistently improved the quality of decisions. They understood customers. They recognized patterns. They identified assumptions that needed validation. They knew when additional information would change a decision and when it would merely delay it. Most importantly, they understood that building something successfully and building something valuable were not the same thing.
This distinction becomes more important as technology lowers the barriers to execution.
For decades, software organizations invested heavily in improving their ability to build. New programming languages, development frameworks, cloud platforms, deployment pipelines, testing practices, and engineering methodologies all contributed to making implementation faster and more reliable. AI appears to be the latest step in that progression.
What has not improved at the same pace is our ability to decide what deserves implementation.
Understanding markets remains difficult. Understanding customer behavior remains difficult. Predicting the success of a new product remains difficult. Distinguishing between a temporary trend and a lasting opportunity remains difficult. Many of the hardest questions in business continue to involve ambiguity, incomplete information, and trade-offs that cannot be resolved through technical optimization.
Seen from this perspective, AI does not diminish the importance of product thinking. It amplifies it.
The easier it becomes to build, the more important it becomes to direct that capability toward problems that matter. An organization that develops exceptional execution capabilities but weak decision-making capabilities may find itself producing enormous amounts of software with limited impact. An organization that combines rapid execution with strong product judgment gains something much more powerful: the ability to learn, adapt, and allocate resources more effectively than its competitors.
I sometimes wonder whether future historians of technology will view this period differently than we do today. Much of the current discussion focuses on AI's ability to generate code, automate tasks, and increase productivity. Those are important developments, but they may ultimately be secondary effects. The deeper shift may be that software creation is gradually becoming less scarce, forcing organizations to confront a constraint that was always present but easier to ignore.
The challenge was never merely building things.
The challenge was deciding what was worth building.