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

As AI tools become powerful enough to produce complete, polished answers to almost any creative or technical request, there is a real risk that we stop formi

Abstract

As generative systems return complete, well-justified artifacts from a single prompt, the binding constraint on creative and technical work shifts from production capacity to judgment formation. This synthesis examines an argument, developed from a talk by Ryo Lu (ex-Cursor), that the principal risk of highly capable AI assistants is not labor displacement but epistemic substitution - mistaking a tool's coherent explanation for one's own understanding. The analysis develops a two-paradigm distinction between service counter and workbench interfaces, the former offering only accept/reject/re-explain, the latter exposing plans and assumptions prior to execution. Three interface design guidelines are derived, alongside a collaboration model drawn from ensemble improvisation. Findings indicate that transparency is better operationalized as availability of entry points than as exhaustive disclosure, with direct implications for agentic tool design and individual practice.

1. Introduction

The talk opens with a question aimed squarely at the current generation of AI tooling: "When we can do anything, do we still know what we want?" Earlier creative and technical software reduced the cost of execution while leaving the cost of specification largely intact - a designer still had to decide what to build before a tool helped build it. Contemporary assistants collapse both costs simultaneously, returning not merely an artifact but a complete rationale for each of its constituent decisions. This compression is the condition under analysis.

Two terms are central. Judgment formation denotes the process by which a practitioner converts a vague intention into specific, defensible decisions through contact with concrete alternatives. Epistemic substitution denotes the failure mode in which a system's articulated justification occupies the cognitive position that the practitioner's own reasoning would otherwise have held, without the practitioner noticing the exchange has occurred. The latter is distinguished from simple reliance on a tool: the hazard is not using AI output, but absorbing its stated reasons as though they were self-generated.

The central thesis holds that the appropriate response is neither rejection of AI tools nor uncritical adoption, but deliberate design and use of tools that keep the practitioner inside the decision loop - pausing to notice preference, making small interventions, and inviting others into the process. The analysis proceeds in four parts: a review of the identity-through-capability framing that the talk explicitly rejects; a worked example of epistemic substitution and its proposed remedy; a taxonomy of interface paradigms (service counter vs. workbench) with derived design principles; and a treatment of collaborative judgment formation modeled on jazz ensemble practice.

2. Background and Related Work

The argument is situated against a widespread professional convention in which identity is constructed from demonstrated capability - exemplified by the self-description "I'm a designer because I know design." When a system demonstrates comparable capability, the perceived threat migrates from economic security to self-conception: "If what I do isn't special anymore, what's special about me?" Two prior responses to this threat are explicitly rejected. The first - the claim that some category of work remains categorically beyond machine reach - is dismissed on the grounds that this boundary has repeatedly relocated and offers no stable foundation. The second - a competitive framing in which continued practice must be earned through demonstrated superiority - is rejected in favor of the position: "I shouldn't have to prove I'm better than anyone else to keep doing what I love."

An autobiographical account grounds the alternative foundation offered in place of these two. Early curiosity about Apple computers preceded any professional motive; over time this orientation underwent a characteristic drift - curiosity into planning, play into output, taste into decisions rendered on behalf of others. The proposed foundation for continuing to make things is not comparative advantage but a retained relationship to the act of making: a system may generate ten variants instantly, yet the practitioner can still halt at a single detail, register that it "feels off," and choose to resolve it personally. This framing supplies the intellectual context for the interface and collaboration arguments that follow.

3. Core Analysis

3.1 Completion as an Epistemic Hazard

A worked example anchors the central mechanism. A request to build a day-journaling tool yields a finished product in approximately two minutes, complete with mood scores, daily writing streaks, reminders, and weekly reports - each accompanied by an auto-generated justification (e.g., "mood scores help spot trends"). The risk identified is not that these features are poorly chosen, but that a user can adopt them without ever forming an independent opinion about whether they are wanted. The talk states this directly: "Having an answer doesn't mean I've finished thinking." A further, less visible risk is noted: "What's harder to see are the questions a complete answer covers up before we've even had a chance to ask them." A completion forecloses the space in which a question would otherwise have been asked.

A live audience exercise is used as evidence that this foreclosure is costly: when asked which single feature of the journal they would remove, participants diverged - some rejecting streaks, others reminders, reports, or mood scores - demonstrating that individual preference exists and differs, but is typically never surfaced because the tool supplies a complete, internally justified package before the user is prompted to react. The proposed remedy is procedural rather than attitudinal: pausing on one concrete decision and noticing one's own reaction is how a vague intention ("I want to record my life") begins to take specific shape. Critically, the talk argues that a practitioner need not know what they want before starting - self-knowledge in this domain is frequently discovered through the act of making rather than specified in advance of it.

3.2 Service Counter vs. Workbench Interface Paradigms

The talk's central technical contribution is a distinction between two interaction models. In the service counter model, a tool processes a request and returns a finished result; the user's available actions are limited to accept, reject, or re-explain the request. In the workbench model, a tool exposes its plan before executing - specifying what it intends to change, remove, or suggest - allowing the user to intervene before execution and to fine-tune the result afterward via a live preview.

The workbench model's advantage is characterized as proprioceptive rather than merely informational: it lets the user "put their hands on the thing being changed and step inside," instead of waiting passively for a result. Notably, the distinction is not strictly architectural - chat-based interfaces can function as a workbench if they expose plans and assumptions and permit partial intervention at intermediate steps, rather than only final accept/reject. Transparency, in this framing, does not require surfacing every line of underlying code or every intermediate computation; what is required is "a way in" at the moment a user wants to understand or change something - availability of an entry point rather than exhaustive disclosure.

3.3 Discretion in Tool Use

A third theme addresses when, rather than how, these tools should be used. The talk draws an analogy to email: possessing the capability to send a message instantly does not imply that every situation calls for sending one - some matters are better handled face-to-face or postponed. AI capability is treated analogously: at times speed is wanted, at times a user prefers to draft rough material independently first, and at times the appropriate response to having "had enough analysis" is to seek a conversation with another person instead of a further AI response. No single choice among these is presented as more virtuous; what is asserted as necessary is that the practitioner retain a clear personal reason for each choice.

This theme is reinforced autobiographically: a relocation from San Francisco to Taipei is described as partly motivated by a desire to stop evaluating every activity by its contribution to work output. An intentionally empty calendar is described as forcing a daily reassessment of what was wanted, absent the usual identification with a job title - evidence that time without immediate productive output can still be worthwhile, since "life gives you things worth making" rather than competing with creative work for attention.

4. Technical Insights

Three interface design guidelines are derived and stated as directly implementable for builders of agentic or generative tools:

1. Make assumptions visible and keep changes small. Important assumptions underlying a generated plan or artifact should be surfaced explicitly, and each discrete change should be scoped small enough that a user can evaluate and try it individually rather than evaluating an entire bundled output at once.
2. Offer more than binary accept/reject at each step. Granular intervention points - partial acceptance, modification of a sub-component, redirection of a sub-plan - should be available throughout execution, not only at the final output stage.
3. Remove obstacles to independent judgment rather than substituting for it. Tool design should prioritize preserving room for the user to form an opinion, which may require deliberately withholding a fully resolved answer at points where user reflection is the desired outcome.

A key architectural implication follows from the chat-interface observation in Section 3.2: the service counter/workbench distinction is a property of information exposure and intervention granularity, not of surface modality. This has practical consequence for teams building conversational AI products - a chat UI with opaque, single-shot completions functions as a service counter regardless of its conversational framing, while a chat UI that surfaces intermediate plans and diffs can function as a workbench. The trade-off is one of cognitive overhead versus epistemic preservation: exposing plans and assumptions at each step increases the user's processing burden relative to a single finished answer, and the design guidelines above implicitly accept that cost as justified by the judgment-formation benefit.

5. Discussion

The broader implication of this analysis is that interface design choices in generative tools function as choices about where human judgment is permitted to occur, not merely as choices about efficiency or output quality. A tool architected as a service counter optimizes for throughput at the cost of removing the moments at which a user would otherwise register and act on a personal reaction; a tool architected as a workbench trades some throughput for the preservation of those moments. This reframes "transparency" in AI tool design away from a disclosure-maximization problem (showing all underlying computation) and toward an intervention-point design problem (identifying where a user needs an entry point and ensuring one exists there).

A second implication concerns collaboration. The talk extends the workbench logic from human-AI interaction to human-human interaction, using a jazz ensemble metaphor: musicians do not compete to play the most notes or prove superiority but carry melody and leave space for others, producing something none could produce alone. Much of the speaker's own professional judgment is attributed to others pointing out things he had missed - a collaborator noting something "felt odd," or fixating on a detail he considered trivial. A stated concern is that defaulting to the most agreeable, lowest-friction responder - characteristic of current AI assistants tuned for helpfulness - risks eliminating the discomfort through which a person is changed by someone genuinely different from themselves. This suggests a gap meriting further investigation: whether and how AI systems designed for agreeableness can be paired with, or deliberately introduce, forms of productive friction currently supplied mainly by human collaborators.

A knowledge gap remains in operationalizing "assumption visibility" and "granular intervention" as measurable interface properties rather than design aspirations; the talk offers no metrics, user studies, or comparative evaluation of workbench versus service-counter tools, leaving empirical validation of the framework to future work.

6. Conclusion

The analysis's central contribution is a reframing of the primary risk posed by highly capable generative AI: not displacement of skilled labor, but quiet substitution of a tool's stated justification for a practitioner's own reasoning, with the consequence that users become skilled at judging plausibility while losing practice in reasoning from their own experience. The service counter/workbench distinction, together with its three derived design guidelines, offers a concrete vocabulary for evaluating and building tools that counteract this substitution by preserving intervention points rather than maximizing completion quality alone.

The practical takeaway for builders is to treat plan visibility, change granularity, and intervention points as first-class design requirements, independent of surface modality. The practical takeaway for individual practitioners is procedural: upon receiving a polished AI output, identify one decision within it that has not yet been personally considered, make one small modification, and show the result to another person - a discipline intended to keep the act of making things a means of discovering and expressing judgment rather than a race to match a tool's completeness.

Sources

• 当我们什么都能做，还知道自己想做什么吗？When We Can Do Anything, Do We Still Know What We Want? - Ryo Lu, ex-Cursor - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub