The feature is cheap to code, so we might as well build it. (Probably not)

The cost of implementation is falling. Complexity, lost trust, and months spent iterating around a badly framed problem still don’t come for free.

For years, the cost of development acted as a natural brake on which products and features were prioritized. Ideas had to compete for limited time and engineering capacity, which gave decision-makers a reason to think carefully before committing to them. Business cases, research and product planning all helped reduce the risk of that investment.

I read Bent Flyvbjerg and Dan Gardner’s How Big Things Get Done last week, and one of Flyvbjerg’s formulations kept coming back to me while writing this: think slow, act fast. It is a simple idea, but a useful distinction here.

AI is making the acting part easier. The thinking part may be getting easier to overlook.

Ideas that would previously have needed a stronger case for being prioritized can now be shipped in an afternoon.

That makes building and shipping seem more attractive.

In product development, some of that thinking happens through research. AI can make parts of research cheaper too, but qualitative research still requires spending time with actual people. If a few days of research can prevent weeks or months of engineering work on the wrong solution, that investment is relatively easy to defend. When implementation itself takes hours, the same few days can suddenly look expensive.

I have heard some version of the same argument for years: The feature is cheap to code, so we might as well build it.

AI makes that argument more persuasive simply because more features now qualify as cheap to code.

But implementation cost is only one part of the economic decision. It is easy to assume that if AI makes a feature dramatically cheaper to build in the first place, the product decision as a whole becomes proportionally cheaper too. That is less certain.

The hidden costs compound

A recent study offers at least one indication that the productivity gains from AI-assisted development may not even carry over to the developer work that follows. Developers using AI completed the initial work faster, but that advantage did not show up when other developers later had to change and maintain the code.

And maintenance is only one of the costs added by a new feature. Once a feature ships, the work around it continues. Complexity, user friction, support, training, workarounds or lost trust may be distributed across people and time, making the total cost difficult to trace back to the product decision that created it.

That does not make those costs less real, but it does make them easier to leave out when evaluating whether a feature is worth building.

In B2B software, the distance is even structural. The person who signs the contract rarely does the daily work, while the person doing the daily work may have no influence over the buying decision. Friction can therefore persist for months without showing up as churn or even reaching someone who can act on it.

Timing makes attribution harder still. A feature can solve a real problem for a few people while adding a little more friction for everybody else. Months and dozens of small features later, the product feels harder to use, support or change, with no obvious point where things went wrong.

The initial implementation cost is visible immediately. Some of the cost of living with the decision may only become visible months or years later.

You can learn fast and still be wrong

Flyvbjerg and Dan Gardner describe the tendency to commit before enough thinking has happened as the commitment fallacy.

AI makes the initial commitment unusually cheap. Once the feature exists, a decision has been made and there is now something to improve. And adding and removing functionality are not symmetrical. Once people rely on a feature, removing it becomes another product decision with consequences of its own.

Shipping earlier creates more opportunities to learn from real behavior. But there is a risk that “ship and learn” quietly becomes just “ship.”

Even when that learning happens, it still takes place inside the frame of the initial assumption. A drop in conversion might point toward on-boarding. Friction in a workflow might point toward usability. Each response can be reasonable, and each iteration can improve the numbers, while the original assumption remains unchallenged.

Once a solution exists, looking for ways to improve it is often easier than questioning whether it should exist at all. The evidence needed for another iteration may already be sitting in the analytics. Evidence that challenges the original framing may require deliberate exploratory research to uncover.

Finding out that you were wrong in research is one thing. Finding out after the product has reached thousands of customers is another.

Restraint has to become deliberate

None of this started with AI. Product teams have always worked with incomplete cost estimates and imperfect assumptions.

What changes is the scale and speed at which the same incomplete decision logic can now be repeated.

It’s just the feature factory, now running at full speed on AI.

If cheaper implementation means a team can ship substantially more, the less visible consequences can be cheaper per feature but still become a larger problem overall. The same incomplete economic calculation is simply being repeated more often.

AI is exceptionally good at helping us act fast. That makes the first half of Flyvbjerg’s principle more important, not less.

When almost anything can be built, knowing what not to build becomes more important.

References and further reading

On planning, commitment and bias

• How Big Things Get Done by Bent Flyvbjerg and Dan Gardner, on the commitment fallacy, planning before commitment, and the principle of thinking slowly before acting fast.
• Top Ten Behavioral Biases in Project Management: An Overview, Bent Flyvbjerg, Project Management Journal, on optimism bias, the planning fallacy, availability bias, escalation of commitment and other biases that distort project decisions.

On product decision-making and operations

• Product Operations by Melissa Perri and Denise Tilles, on bringing product, customer, operational and financial inputs together to improve prioritization and decision quality across functional silos.

On AI-assisted development

• Echoes of AI: Investigating the downstream effects of AI assistants on software maintainability, Markus Borg et al., Empirical Software Engineering, on whether productivity gains during AI-assisted initial development carry over when other developers later change and maintain the code.

On software maintenance

• Open Source Software Maintenance Effort Estimation: A Systematic Mapping Study, Chaymae Miloudi et al., on how software maintenance effort is measured in empirical research and why direct maintenance-effort data is often difficult to obtain.

The feature is cheap to code, so we might as well build it. (Probably not) was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.