Four of Those Are Standard. One of Them Hovers.

Feature lists have always mixed the routine with the impossible. AI made that harder to sort out, and it broke the old assumption that anything on the list could be built at all.

Set software aside for a paragraph and pretend your company builds cars. The feature list for next year’s model comes around, and it says the car should steer, it should go forward and backward, it should have a radio, the seats should be comfortable, and it should hover a few feet off the ground. Four of those are standard equipment. One of them is an open research problem, and probably not one anybody closes this year.

That list is easy to laugh at, because at a car company somebody catches the hovering item on the first read; it is different in kind from the other four and nobody needs an analysis to see it. Software feature lists are harder, since the difference in kind does not show on the page. They have always mixed the routine with the impossible, whether they came from sales, from an executive with a competitor’s demo still open in another tab, or from the product team’s own roadmap, and in my experience the misjudgment runs in both directions about equally often. Sorting out which item is a week of work and which is an open question is ordinary product work, and it has little to do with AI.

What AI actually changed

What did change is that a great many genuinely hard things became easy at once. Pulling meaning out of unstructured text was a research budget five years ago and is now something a product team tries on a Tuesday afternoon. When that many hard problems fall over together, the whole category starts to look like magic in a bottle, something you pour over any problem and expect results from. The old estimation error doesn’t go away in that environment, it gets louder, because the intuition people use to sort hard from easy was trained on the wrong decade.

The magic comes with strings

Overshoot is the failure everybody recognizes, though usually only as cost and schedule. There is more attached than that. Sending a model your support transcripts, contracts, or customer records means those things are leaving your security boundary, with the PII, contractual, and compliance consequences that follow, and that decision tends to get made by someone who framed the whole thing as a feature request rather than a data transfer. (The economics of keeping that data inside your own boundary have shifted lately.) And a lookup table, a regular expression, or an API you already have is sometimes the better answer: cheaper, easier to debug, and correct every time rather than most of the time.

The error nobody files a ticket for

The other direction is quieter and, I would suggest, more expensive. Plenty of capable people on your own team look at a problem, conclude it is insurmountable, and never put it on the list, and those are frequently the exact problems a model handles well. Nobody files a ticket for the feature they never proposed, so underestimating shows up as an absence, which is much harder to notice than a project that ran long.

Nobody files a ticket for the feature they never proposed.

Buildability used to be assumed

The reasonable question here is why the team can’t estimate better. With conventional software it can, because the logic is static: a system with an enormous number of states is a cost and QA problem, never a question of whether the thing can be done at all. Edmar Ferreira put the contrast well, observing that traditional software development assumes buildability, and that “we don’t necessarily stop to ask ourselves, is building this thing even possible?” With a model in the middle of the feature, whether it performs reliably within your bounds, on your data, for your users, is unknown until somebody goes and finds out; Carnegie Mellon’s Software Engineering Institute has called that research programming since 2020, with the budgeting difficulty it implies.

Start with the problem, then go find out

The remedy is a sequence whose first step is the one most often skipped: start with the problem rather than the technology, which means real problem definition and the research behind it, before anybody has decided what gets built. Bring to that an informed sense of what this generation of models can and cannot do reliably, since the calibration has to come from somewhere. Then run tests during requirements definition, while changing your mind is still cheap, including tests whose most useful conclusion is that AI is the wrong tool here.

For something to try on Monday, make the check bidirectional: for any AI feature on the list, ask what would make it trivially easy, and ask what would make it a science project. If nobody in the room can answer both, that is your gap, and it is not the AI team’s gap to fill.

Software quality has been a product concern for as long as there have been software products, and it is by now largely solved; we know how to specify it, test it, and hold someone accountable for it. AI quality is a product concern too, and it is nothing of the sort.

Software quality is a solved problem. AI quality is not.

That difference is why “can we build it” has stopped being a scheduling question and turned into a research question, and it is why so many product teams are still answering it the old way without noticing the switch.

This is the first of four articles on the work an AI feature demands before anyone can write requirements for it. The next one picks up with the question product has always been the one to answer, whether the thing is good enough to ship, and what it now takes to answer it.