Building AI Products That Age Gracefully

There is a category of building I admire that has almost no representation in software: things designed to look better after twenty years than they did on the first day. A leather bag. A wooden floor. A stone step worn into a curve by ten thousand feet. They age by accumulating evidence of use, and the evidence is the beauty.

Software mostly does the opposite. It arrives at its best moment on launch day and declines from there — not functionally, usually, but in the way it makes you feel. The interface starts to look like the year it was made. The onboarding references a competitor that no longer exists. The clever bit at the center, the thing everyone praised, becomes the standard behavior of every product in the category, and what was once distinctive is now merely present.

Most software does not die. It becomes embarrassing, slowly, in a way nobody schedules time to fix.

The three clocks

Everything you build sits on three clocks running at different speeds, and confusing them is the root of most premature aging.

The fast clock is capability. What models can do changes every few months. Anything you build whose value comes from a current capability gap will be overtaken, and the overtaking is not a failure of your execution. It is the schedule.

The medium clock is convention. How interfaces look, what gestures people expect, what a product of this type is assumed to include. This moves over two or three years, and it is the clock that makes things look dated rather than broken.

The slow clock is need. Why the person came. What they were trying to accomplish. This barely moves at all. People wanted to keep track of what they owed each other in Mesopotamia and they want it now, and the underlying shape of the problem has changed remarkably little for the effort we have put into it.

Products that age well are anchored to the slow clock and flexible on the fast one. Products that age badly have their identity welded to something on the fast clock, which means every advance in the field makes them slightly less reasonable to exist.

A test worth applying early

Before building, I like to ask what happens to this product if the underlying capability becomes free, instant, and universally available. Not as a thought experiment about the distant future — as a description of two years from now, because that has been the pattern.

If the answer is that the product becomes pointless, you have built a feature that is temporarily a company. That is not always the wrong choice; some businesses are worth running for three years. But it should be a choice made knowingly, with an exit in mind, rather than a surprise that arrives with a competitor's release notes.

If the answer is that the product gets better and cheaper to run, you have built something on the slow clock, and the entire industry's progress becomes a tailwind rather than a threat. That is the position worth engineering for.

Ornament versus structure

In physical design there is a distinction between ornament and structure — the parts that express the moment's taste and the parts that hold the building up. Buildings that survive tend to have honest structure and replaceable ornament. You can update the surfaces of a well-built house indefinitely. You cannot fix a bad frame with paint.

The equivalent discipline in software is keeping your model of the world separate from your expression of it. What objects exist, what they are called, how they relate — that is structure, and it should be argued about for a long time before it is settled. The visual language, the arrangement of the screens, the particular way an interaction feels — that is ornament, and it should be built to be replaced.

Teams get this backwards constantly. They treat the visual design as sacred and the data model as an implementation detail, and five years later they are stuck with a beautiful, unchangeable product built on concepts that no longer describe their business.

Honest structure, replaceable ornament. Everything that survives is built this way.

The patina of use

The one place software can genuinely age like leather is accumulated user history. A tool you have used for four years knows things. It holds your work, your patterns, your record. That accumulation is the closest thing our medium has to patina, and it is the strongest reason anyone stays with anything.

Which makes it worth protecting deliberately. Do not casually break the shape of stored history. Do not migrate away from concepts users have organized their life around. When you must, do it as a considered event with care and communication, not as a background cleanup task shipped on a Thursday.

And design for the loaded state. Most products are designed empty and demoed empty, and then spend their real lives full. The version of your interface that holds four years of someone's work is the version that actually matters, and it is usually the version nobody has looked at closely.

Restraint as durability

The last thing I will say about aging well is the least technical. Products age badly in proportion to how hard they tried to impress on arrival. The animation that delighted everyone in the launch video is the thing people turn off in month three. The bold aesthetic gesture is the thing that dates the product to a season.

Restraint is not blandness. It is the decision to be interesting in the parts that will still be interesting later — the clarity of the model, the quality of the defaults, the way the thing behaves when you are tired and in a hurry. Those qualities are almost invisible on day one and unmistakable on day one thousand.

That is the trade, and it is a real one. You give up some of the launch and you buy the decade. It has always seemed like a good deal to me.

If you are early enough in something to still be deciding what it is anchored to, that is the best moment for this conversation. I am glad to have it.