Every product in the time-tracking category — including ours — asks the user to do a lot of clicking before it starts being useful. Project settings. Permission groups. Notification rules. Custom report builders. The drag-and-drop in the schedule view. The first week with any of these tools looks the same: you click into a dialog, you pick from a list, you save, you wait for the page to refresh, you click into the next dialog. Half a day later you have a workspace that does roughly what your team needs.

For a long time, those clicks were what software cost. The friction of setup was part of the work.

What is changing, slowly at first and now quickly, is that the cost has stopped being necessary. There is another way to get a user’s intent into a product, and once you have used software built on that other way, the old way starts to feel heavy. Not slow. Heavy. As if it is asking you to do work you no longer think belongs to you.

That feeling is doing something to a lot of people right now, quietly. It is the small private moment a category shift looks like from the inside, before the public discourse catches up.

The translation contract

Until very recently, the only mechanism we had for getting a user’s intent into computer behavior was the interface: menus, buttons, fields, dialogs, drag handles. The user thought “I want sales reps and ops to see this report but only ops to edit it,” and the user’s job was to translate that thought into the right sequence of clicks across three screens. The product’s job was to make the sequence as short and unambiguous as possible. Whole careers were built on the difference between four clicks and three.

We did our best work inside that constraint. Some of the most loved products of the last decade were just teams who got the sequence shorter than anyone else.

But the constraint was always there. It was the contract of the era: the user does the translation, the software executes the result.

A careful claim

I want to be careful about what I am claiming here, because the AI-and-software conversation has gotten loose.

I am not claiming features are going away. Products still have to do specific things; the world still needs invoicing and time tracking and inventory and CRM. I am not claiming “natural language is the new UI” in the strong sense that everything becomes a chat box. Chat is one shape, and a lot of the time it is the wrong shape.

What is happening, specifically, is that the configuration layer of software — the thousand small decisions a user has to encode through clicks to get the product to do the right thing for their situation — is becoming addressable in language. The thing you used to set up by hand, you describe. The thing the product used to require you to assemble out of primitives, the product assembles for you, from your description.

This is a smaller claim than “AI is changing everything.” It is also a more durable one. The interface era is not ending because someone invented something brand new. It is ending because the part of every interface that was asking the user to do translation work no longer has to.

Inside our own product

At WebWork we have built this directly into the tracker. WebWork AI is an agentic assistant that lives alongside the rest of the product. You ask it what you need to know about your team, and it tells you. You tell it to create a task, a project, a standup, and it does it. It watches the day-to-day signal — who logged in when, who is tracking what, where activity is rising or falling — and surfaces what matters without you having to go look. Burnout risk, budget overrun, anomalies in someone’s pattern: a manager hears about them before they would have had to think to ask.

What gets replaced is not the configuration screens themselves. Those are still there for the people who want them. What gets replaced is the work of operating them. The questions you used to answer by opening three dashboards, you now ask in a sentence. The tasks you used to set up by clicking through five fields, you now describe in voice or in chat. The weekly report you used to assemble by hand is assembled for you and arrives in your inbox.

The interface did not disappear. The work of operating it did.

What the work becomes

The natural question, for anyone working in software, is whether any of this puts us out of a job — if building product is, in the limit, just describing the product to a model.

I don’t think so, but the answer is more interesting than no. The work that goes away is the work of translating user intent into interface primitives. That work was always derivative; we did it because the user couldn’t, not because it was the interesting part. The work that remains, and gets harder, is figuring out exactly what the product should do, for which users, in which situations, with which tradeoffs. The decision work. The taste work. The “why this and not that” work.

Anyone who has worked in software for more than a few years knows that the design of a settings page was rarely the bottleneck on what made a product good. The bottleneck was knowing what the settings page should let the user say. That knowledge is not going anywhere; if anything, it becomes more visible, because there is nowhere to hide it behind UI craft.

Translation as a defect

For people building software today, the thing I would offer — not as a prediction but as something we are acting on with our own product — is that every place you currently require the user to translate intent into clicks is now a defect. Not a feature surface. A defect. It was always borrowed against the limits of what software could understand. The limit has moved.

What replaces the clicks will not be the same in every category. In some places it will be a description. In some places an example. In some places a single agent that watches what you do for a week and then asks, gently, three questions. The shape varies. The principle does not: the burden of translation moves from the user back to the system, where it always should have been, and where for the first time it can actually live.

The software people will use a few years from now will be quieter than the software they use today. Less to click. Less to configure. Less to remember. More of what they actually wanted, faster, with less of themselves spent getting there.

We are not building toward a louder interface. We are building toward a quieter one.