当我们什么都能做，还知道自己想做什么吗？When We Can Do Anything, Do We Still Know What We Want? — Ryo Lu, ex-Cursor

Ryo Lu asked an AI to make a tool for recording his day. Two minutes later, he had a journal. It could score his mood, track a writing streak, remind him to make an entry, and produce a weekly report. The AI supplied a reason for each feature it explained. Mood scores would reveal trends. Reminders would help him build a habit. Weekly reports would give him an occasion to reflect. Lu could imagine agreeing to all of it on the strength of those explanations.

Somewhere between the request and the result, recording a day had become something he was supposed to do every day. That assumption was easy to miss because the journal worked and the rationale made sense. Lu’s concern was about the practice he was getting as a designer. Reviewing enough polished answers might make him adept at recognizing a plausible justification while giving him fewer occasions to work out, from experience, why he wanted a feature in the first place.

Lu turned the usual feature review around. Given the mood scores, streaks, reminders, and reports, which would you remove? He would drop the streaks, reminders, and weekly reports. Missing a day would already make him feel as though he owed somebody an entry. A tool he could open when he had something to record would fit his purpose better. For someone trying to establish a writing habit, that same reminder might be worth keeping.

Asking what was missing would have let the journal’s premise pass unexamined. Asking what to remove gave Lu a specific experience to consider. How would it feel to open this thing the day after skipping an entry? He could answer that question more readily than he could write a specification for his ideal journal. The speed of generation helped here. It gave him something he could react to before he had the vocabulary to describe his preference.

Lu compared two interfaces for revising the journal. The first worked like a service counter. You asked for a change and received a new version. If that version removed a reminder you liked, or changed the design along with the features, you had to describe what to restore and what to keep. For moving data or converting a file, Lu was happy to hand the job over. The cost of this arrangement became apparent when he was still figuring out what he wanted.

The second interface worked like a workbench. Before execution, it showed which features the tool planned to remove and what else it proposed. Seeing the reminder marked for removal gave Lu a chance to realize he wanted it. After execution, he could adjust the result in a live preview. These two opportunities served different purposes. A proposed deletion could prompt a decision before the edit, while a layout he thought he wanted might reveal its flaw only when he tried it.

For engineers building such a tool, the practical question is how much of a change a user can control independently. Lu looks at plans, files, edits, and differences between versions as places someone can step in. Few people need every line of code or a confirmation prompt at every step. They do need a way to inspect an assumption they care about, try a small change, and take back a task they delegated. A chat interface can support that workflow too. The test is whether someone can keep one reminder without having to explain the entire journal again.

Even a tool with a good editing surface leaves one choice to its user. Sometimes Lu wants help sorting through a complicated job. Sometimes he wants to write a few rough lines himself first, because seeing what comes out is the reason for writing them. Sometimes he has already done enough analysis and would learn more by having tea with the person involved. He gives speed its due in the first case and sees a reason to spend the time in the other two.

Moving from San Francisco to Taipei brought that choice into focus for him. An empty calendar made him decide what he wanted to do each day. A conversation, an unfamiliar street, or a song he kept replaying could give him an idea worth pursuing. For Lu, the value of handing work over depends partly on what he gets to do with the time. Filling every saved hour with another generated version leaves less room for the experiences that give him something to make.

Consider two stripped-down versions of the journal. One gives each day a page. The other is a scrapbook with an open canvas. A daily page makes it easy to return to a particular date. A canvas lets someone place fragments from different times beside each other. Two people could agree on the entire brief for recording their lives and still choose different versions for good reasons. Asking someone who chose the other version why they chose it tells you something a vote for the winner would lose.

Lu traces much of his own judgment to encounters like these. Someone tried his work and found something odd, or insisted on a detail he had dismissed. An AI’s patience can make it easier to explore an idea, and he values that. Another person brings priorities he might never have thought to ask about. Keeping both journal prototypes around makes those priorities available for discussion. The people trying them can then decide whether to keep the versions separate or bring parts of them together.

Lu’s closing exercise starts with the next polished answer you receive. Find one decision in it you have yet to think through. Change the part you care about and, if possible, give the result to someone else to try. In the journal, a single reminder is enough. Whether you want it, when you discovered that preference, and why a colleague would choose differently are all things the original feature list left open.