NPS
Everyone is building. Everyone is shipping. But how much of it will still matter next year?
I recently asked our product and engineering team a question:
If AI has made building software dramatically easier, what has become harder?
The answers changed how I think about our roadmap — and I suspect they apply to almost every technology company right now.
Writing code is becoming faster. Generating tests, queries, documentation, interfaces and even complete applications is becoming easier. The 2025 DORA research found that 90% of respondents were already using AI at work, while more than 80% believed it had increased their productivity. DORA’s 2025 State of AI-Assisted Software Development
This is extraordinary progress.
It is also creating a dangerous illusion:
Because we can build almost anything, we start believing we should build everything.
The Gold Rush Is Becoming a Feature Arms Race
We are living through an AI gold rush.
Like every gold rush, it began with a genuine discovery. AI has dramatically lowered the cost and time required to create software.
But genuine opportunity quickly attracts speculation, imitation and urgency.
Every technology company now has an AI strategy. Every roadmap has AI features. Every engineering team is being asked to increase velocity. Every competitor announcement creates pressure to announce something in response.
Companies are building because their competitors are building. Teams are shipping because everyone else is shipping. Activity is rising rapidly — but strategic clarity is not rising with it.
The greatest risk in technology is no longer moving too slowly. It is moving very quickly in the wrong direction.
AI Is Making the Feature-Factory Problem Worse
The term “feature factory,” popularized by product thinker John Cutler, describes an organization that measures progress by what it produces rather than what changes for the customer.
A feature factory asks:
- How many features did we release?
- How much code did we generate?
- How quickly did we match the competitor?
- How many AI capabilities did we add?
It rarely asks:
- Did customers meaningfully adopt them?
- Did retention, revenue or efficiency improve?
- Did we eliminate an important source of friction?
- Did the product become more valuable — or simply more complicated?
Cutler identified lack of impact measurement as one of the defining signs of a feature factory: the team keeps producing and sending features “down the line,” often without knowing whether the work delivered the intended result. John Cutler: “12 Signs You’re Working in a Feature Factory”
AI intensifies this problem because it removes the natural friction that once forced teams to prioritize. When development was expensive, organizations had to make difficult choices. When almost every idea appears inexpensive to build, saying yes becomes easy.
But the first version of a feature is only a fraction of its true cost. Every feature introduces maintenance, security exposure, architectural complexity, testing, documentation, customer support, product confusion and future migration costs.
Code may be getting cheaper. Ownership is not.
The result can be an organization that appears extraordinarily productive while creating very little durable value. A feature factory can ship more than ever and still fall further behind.
The Shelf Life of Differentiation Is Shrinking
Earlier generations of technology could remain strategically relevant for five or ten years.
That is still possible for foundational assets: proprietary data, deep integrations, trusted infrastructure and embedded workflows.
But the shelf life of many surface-level product differentiators is shrinking from years to months.
A feature that required an entire team yesterday may become a native LLM capability, an API call, an open-source component or a checkbox inside a larger platform tomorrow. This is especially true for generic copilots, summarization, search, content generation and basic reporting.
Until recently, software companies invested significant time in dashboards, tables, reports and filters. These interfaces were often the primary way customers accessed the value of the product.
Then the interaction model began to shift.
AI Is an Amplifier, Not a Strategy
The 2025 DORA research describes AI as an amplifier. It magnifies the strengths and weaknesses already present in an organization.
AI adoption was associated with improvements in development throughput and product performance. But it also continued to show a negative relationship with software-delivery stability.
The implication matters: a disciplined organization can use AI to move faster. An undisciplined organization can use the same technology to generate more technical debt, product clutter and instability — also faster.
And adoption is rising much faster than trust. Stack Overflow’s 2025 Developer Survey found that more than 84% of respondents were using or planning to use AI tools, but only 29% trusted their accuracy, down from 40% the previous year. Stack Overflow’s Developer AI Trust Research
We are dramatically increasing the volume of software being generated without an equivalent increase in confidence, governance or strategic judgment.
what has actually become harder?
When implementation becomes easier, the constraint moves somewhere else.
Choosing the right problem
AI can produce an answer once the task is defined. It cannot reliably determine which customer problem deserves years of organizational commitment. The quality of the question is now more important than the speed of the answer.
Knowing what not to build
When every idea appears feasible, prioritization becomes more — not less — important. The discipline to say no may now be more valuable than the ability to ship another feature.
Distinguishing a feature from a capability
A dashboard is a feature. The ability to identify business risk accurately across fragmented data is a capability.
A chatbot is a feature. The ability to understand an industry, recommend the correct action, execute it with permission and maintain an audit trail is a capability.
A report is a feature. A system that continuously observes, decides, acts and learns from the outcome is a capability.
Features can be copied. Capabilities compound.
Designing for an interface you may not control
Tomorrow’s product may not be defined by where customers log in. The durable product may be the intelligence and execution layer delivering value through your application, an AI assistant, a voice agent, an API or a fully automated workflow.
Proving that something changed
Shipping is not success. Adoption alone is not always success. The important questions are: Did revenue improve? Did retention increase? Did service time decrease? Did the customer make a better decision?
Product teams should be given problems to solve and held accountable for outcomes — not handed lists of features to produce. That is the distinction Silicon Valley Product Group draws between feature teams and empowered product teams. SVPG: Product vs. Feature Teams
A better test before we build
My advice to product and engineering teams is not to slow down. It is to become much more deliberate about where they move fast.
Before committing meaningful engineering capacity, ask:
- What measurable customer outcome will this change?
- Is this a durable customer problem or a temporary feature opportunity?
- Could an LLM, model provider or horizontal platform soon provide the generic portion natively?
- What lasting asset does this strengthen — data, integration, workflow, intelligence, trust or distribution?
- If today’s interface disappears next year, will the underlying capability still be valuable?
- Are we prepared to maintain, secure, govern and support what we create?
- What evidence would cause us to stop, simplify or retire it?
The operating principle: slow down before committing, move fast after validating, measure relentlessly after shipping.
Self-Cannibalization Is No Longer Optional
There is another uncomfortable reality.
The feature most likely to disrupt your current product may need to be built by your own team.
I know this tension personally. We spent years building the dashboards, reports and workflows our customers rely on. This year, we shipped an integration that lets customers bypass some of those screens entirely and simply ask an AI assistant for the answer. It was uncomfortable to build something that competes with our own interface. It was also the right thing to do — because our customers’ loyalty is to the outcome, not to our screens.
If customers would rather ask an AI assistant than navigate six reports, we should enable that — even if we spent years building those reports. If an agent can complete a workflow that previously required ten screens, we should redesign the workflow. If a new interface makes an old capability unnecessary, preserving the old interface cannot become the strategy.
The goal is not to protect everything we have built. The goal is to remain the best company to solve the customer’s problem.
If we are unwilling to make our own features obsolete, someone else will do it for us.
Judgment Is Becoming the Real Moat
In the previous era, technology companies asked: Can we build it?
In the AI era, the more valuable questions are: Should we build it? Why should we own it? Will it survive the next interface shift? Did it create a measurable outcome?
Code is becoming abundant. Features are becoming abundant. Even access to intelligence is becoming widely available.
What remains scarce is deep customer understanding, domain expertise, proprietary context, trusted execution and the discipline to avoid playing yesterday’s game.
The winners of this gold rush may not be the companies that build the most. They may be the companies that resist becoming feature factories — companies that know what not to build, what to retire and which capabilities will remain valuable long after the models, interfaces and excitement have changed.
When code becomes abundant, judgment becomes the moat. Build less — but build what survives the next interface shift.
So I will end where I began, with the question I asked my own team — and now I am asking you:
If AI has made building easier in your organization, what has become harder?
I would genuinely like to hear your answer in the comments.
