AINotes

On Building Tools That Respect Your Attention

Why most productivity tools fail, and what makes a tool worth returning to

·2 min read

There's a paradox in modern software development: tools built to save time often consume more of it than they give back. We adopt new systems, learn their quirks, maintain them, and eventually abandon them for the next promising alternative.

I've been thinking about why this happens, and what separates tools that stick from those that fade.

The Attention Economy of Software

Every tool makes a claim on your attention. Not just the time spent using it, but the mental overhead of keeping it in mind—updating it, checking it, thinking about how to integrate it better.

Most tools don't account for this. They're designed around feature completeness, competitive differentiation, or developer convenience. The user's cognitive load is an afterthought.

What Makes a Tool Worth Returning To

A few properties keep coming up in tools I actually use:

**Minimal surface area.** Fewer features, but each one works reliably. No decision paralysis about which approach to use.

**Fast feedback loops.** Seeing results quickly reinforces the habit of using the tool. This is why CLI tools often stick better than GUIs—the immediacy matters.

**Quiet presence.** It doesn't demand attention. No notifications, no update prompts, no "pro" upsells. Just available when needed.

AI as a Case Study

Large language models are interesting here. They have enormous surface area, but the interaction model is simple: give context, get response. The tool adapts to you, not the other way around.

This is why AI assistants have such high initial adoption—but also why retention is harder. The quality of output depends heavily on how you ask. Users who don't invest time in learning good prompting often conclude the tool "doesn't work."

Building for Longevity

What I'm left with: the best tools are those that fade into the background. They become part of how you think, not something you have to think about maintaining.

This is the standard I'm holding my own work to. Not impressive demos or compelling feature lists, but whether someone still finds it useful two years from now.

Comments