Chatbots ask new users to imagine what artificial intelligence (AI) can do, while code editors invite them inside a workflow they already understand. This structural difference also represents a trust difference.
Even two AI products that use similar underlying models can create very different first-session outcomes. The difference often has less to do with model capability than with how the user interface introduces the model to a new user.
Reach and retention are no longer the same problem. In a16z’s March 2026 analysis of consumer AI apps, ChatGPT had reached roughly 900 million weekly active users. Yet Amplitude’s 2025 Product Benchmark Report found that more than 98% of new users abandon a product within two weeks if they have not experienced value. ChartMogul’s 2025 SaaS Retention Report adds a sharper AI-specific signal: AI-native products at a price of under $50 per month retained just 23% of their gross revenue—that is, 20 percentage points below comparable business-to-business (B2B) and business-to-consumer (B2C) software-as-a-service (SaaS) products at the same price tier.
Champion Advertisement
Continue Reading…
AI code editors provide a useful counterexample. In GitHub’s randomized study of Copilot at Accenture, 81.4% of developers installed the integrated development environment (IDE) extension the same day they received a license, and 96% of those who installed it began accepting suggestions that same day. Cursor had passed $500 million in annualized revenue by June 2025 and reportedly reached more than $2 billion by February 2026. While these numbers do not prove that AI code editors always improve productivity or code quality, they do show that code editors address one problem earlier and more structurally than chatbot-first products did: first-session trust.
This article identifies the onboarding patterns that AI code editors use, connects these patterns to trust-in-automation research, and proposes a four-gate evaluation framework that UX professionals can apply to any AI product’s first session.
First-Session Trust Is the Hardest Problem in AI
Trust is not a feeling that users bring with them. A user interface builds or breaks users’ trust by what it lets them see, try, control, and undo.
AI products face a problem that earlier software did not. The capabilities of AI products are open ended, their outputs are probabilistic, and their failure modes are unfamiliar to many users. A first session, therefore, is not just a usability moment. It is the first trust-calibration event between the user and the system.
Hoff and Bashir’s 2015 review, “Trust in Automation: Integrating Empirical Evidence on Factors That Influence Trust,” synthesized 127 empirical studies into a three-layer model of trust. Dispositional trust is what a user brings before touching the product. Situational trust depends on context, including stakes, expertise, workload, and framing. Learned trust develops through interaction with a specific system—first through reputation and expectation, then through what the user observes during use.
A first session cannot fully change dispositional trust. Users arrive with their own concerns and expectations and a user interface must serve both. What the first session can shape is situational trust and learned trust: Does the task feel safe enough to try? Does the system provide evidence that it understands the user’s context? Does the user interface make limits visible before the user over relies on the AI’s output?
Lee and See’s 2004 paper, “Trust in Automation: Designing for Appropriate Reliance,” adds an important caution: the goal is not maximal trust. The goal is calibrated trust. Trust that runs ahead of system capabilities results in misuse, while trust that lags behind system capabilities results in disuse. Users can calibrate trust through three bases:
Performance—what the system does
Process—how the system works
Purpose—why the system exists
Good AI onboarding should activate these bases of trust early by letting users see a bounded contribution, understand why it has appeared, and decide whether to accept, edit, reject, or verify it.
Champion Advertisement
Continue Reading…
The Articulation Barrier and the Search-Engine Default
When users do not know what an AI can do, they treat it like the closest thing they already understand—usually search.
In 2023, Nielsen Norman Group (NN/g) named the underlying usability problem of AI the articulation barrier. When a generative-AI (GenAI) user interface begins by presenting an open text field, the user already needs to know what the system can do, decide what capability matches their need, translate that need into language to which the system responds well, and judge whether the result is useful. Each step is potentially an independent failure point.
NN/g’s diary study of three generative-AI chatbots provides behavioral evidence. The study included 18 participants and 425 conversations across ChatGPT 4.0, Bard, and Bing Chat over two weeks. Participants often transferred their search-engine mental model directly to the chatbot: ask a brief question, judge the first answer, and move on. Thus, a common pattern was the one-prompt query with no followup. Only 22.43% of conversations included any verification step. This behavior was not irrational. When a user interface presents a broad input field and few task-specific constraints, search becomes the safest inherited model.
It is tempting to say that today’s chatbots have fixed this issue by adding prompt suggestions. But they have not. ChatGPT, Claude, Gemini, and other major chatbot products now include prompt chips, examples, autocomplete, and follow-up suggestions. NN/g’s April 2025 evaluation found that these features help but often sit on top of the deeper issue rather than restructuring it. A suggestion chip can show a possible use case, but it does not necessarily know the user’s current workflow, artifacts, constraints, or intents. The user’s task remains: imagine what the AI can do for you, articulate it, and hope the result is good enough to continue.
Code editors take a different approach. They do not ask the user to begin by describing a task using abstract language. They observe the user’s existing work surface—the file the user is editing, the position of the insertion point, the programming language, the surrounding code, and the likely next action. They do not eliminate the prompt, but embed it inside the user’s work.
What Code Editors Get Right
The code editor’s onboarding is not a tutorial. It is the act of writing code in the same way the user already does—except now something useful appears that the user did not type.
Open an AI code editor such as Cursor and the environment is immediately familiar: Cursor imports Visual Studio Code settings, extensions, themes, and key bindings. The file tree, tabs, syntax highlighting, terminal, and keyboard flow remain recognizable. The AI appears as a gray inline suggestion beside the cursor. The user presses Tab to accept the suggestion or keeps typing to ignore it. The user writes no prompt. The user interface presents no onboarding questionnaire. Instead, before the user has to ask, the user interface answers this question: What is this AI here to help me do? The following tree structural patterns separate this experience from chatbot-first onboarding.
Pattern 1: Embed the AI in an existing workflow instead of creating a new destination. Copilot and Cursor add intelligence to the IDE that the developer already uses. The mental model remains stable: this is still a code editor. The AI is an addition, not a separate place to visit. This supports Hoff and Bashir’s concept of initial learned trust because the user observes the new behavior within a familiar container.
Pattern 2: Show value before requesting input. The first useful moment in Copilot does not require the user to formulate a prompt. The Accenture study reported the average time from a developer’s first viewing a suggestion to first accepting a suggestion was about one minute. This matters because users typically calibrate performance through evidence, not through claims. The system shows a bounded output before asking the user to make significant effort.
Pattern 3: Make the AI’s scope legible at the moment of use. An instance of code completion appears inside a function, in a specific language, at a specific line. The user can see what the AI thinks he wants to type and reject it without consequence. The scope is visible because the work surface makes it visible. This supports the process basis of trust. In a chatbot, the user often has to test boundaries one prompt at a time. By the time the user understands what the system can do, the first session may already be over.
NN/g’s 2025 article “Scope in Generative AI Features” supports this pattern. Across qualitative usability research, narrower AI features tended to be easier for new users to understand and adopt than broad, open-ended ones. While this finding does not mean broad AI systems lack value, it does mean breadth is more difficult to onboard. AI code editors are technically capable across many tasks, but the first interaction is narrow by design. The product does not begin with every possible task; it begins with the current file and the next likely action.
These products will keep changing. Both Cursor and ChatGPT have already evolved toward agent-style user interfaces and explicit action modes. The specific user interfaces that I’ve described here will likely look different in two years. The point of identifying these three patterns is not to establish code editors as the answer but to identify the underlying principles that any AI product can apply, regardless of the form of its user interface: embed in existing context, show value before demanding input, and make scope legible.
Scope and Embedding Beyond Code Editors
The most usable AI feature is often not the broadest one, but the one whose purpose, limits, and next action are easiest to understand.
Other AI products can apply the same principle without becoming code editors. Perplexity lowers first-session friction by using the familiar shape of a search box, even though its founder has described the product as an answer engine or knowledge-discovery engine rather than a traditional search engine. The user interface borrows an existing mental model to make the first action obvious: ask a question and receive an answer with sources.
Lovable takes a different route. Its primary entry point still includes a prompt box, but the product also surfaces remixable community apps, featured projects, and templates. This lowers the cold-start burden. Instead of forcing users to begin with what should I ask, Lovable lets them start with what can I adapt.
The shared lesson is not that every AI product needs a feed, template gallery, or inline completion. The lesson is that users should not have to discover the product’s best use case by guessing. The first session should put the use case into the environment, the artifact, or the first meaningful decision.
A Healthcare Lesson
Trust signals do not substitute for relevance signals. Trust logos that appear before the user understands the path could be read as anxiety, not credibility.
Healthcare shows why calibrated first-session trust matters beyond productivity software. AI and automation often appear in moments of vulnerability—a patient who is anxious about costs or appropriateness or a clinician who is worried about accuracy, the documentation burden, or liability. Stanford Health Care’s pilot of Nuance DAX Copilot illustrates the value of embedding AI in an existing clinical workflow. The system listens to a clinical conversation, generates a draft note, and delivers it to the clinician for review. In a preliminary survey of 48 physicians across five specialties, 96% reported that the technology was easy to use, and 78% said it expedited notetaking. The lesson was not simply that physicians liked the tool but that the AI supported a task they already had to complete. Clinicians never had to leave the patient conversation to find value.
A non-AI experiment from Irrational Labs and One Medical reinforces the same principle. Small changes to the onboarding experience for new employer-sponsored members produced a 20% lift in appointment bookings relative to the control. The user interface both recommended a specific provider for treatment and showed bookable appointment times. It did not merely add more trust badges. It made the next action concrete.
Both of these examples point to the same design principle: when the system makes the next action specific and supports it, users move forward; when the system asks users to interpret a generic user interface, they leave. When we place supporting information at the point of decision, it becomes useful evidence. However, when we present it before users understand what action they are about to take, the same information can feel like noise.
A First-Session Evaluation Framework: Four Gates
Each of the four following gates maps to a trust layer that the first session can either build on or skip—a specific trust mechanism from the human-factors research that I outlined earlier. These four gates can turn the code-editor pattern into a practical review tool for any AI product.
Gate 1: Legibility—Before asking for input, the user interface should answer this question: What is this AI here to help me do? A first session is successful when the new user can describe the product’s primary job without any documentation. The first session fails when the main screen communicates broad capability—Ask anything or Create anything—without showing the desired starting behavior. Legibility supports initial learned trust.
Gate 2: Constraint—A first session should narrow the possibility space enough for the user to act. Constraint can come from the workflow itself, visible templates, suggested modes, or the user’s existing artifact. The experience is successful when the first action is specific and low risk. It fails when the product asks the user to decide on both the goal and the method before receiving any help. Constraint supports process-based trust.
Gate 3: Proof—The product must demonstrate value before asking the user for major trust, data, or configuration. A useful completion, a relevant citation, a draft clinical note, a flagged anomaly, or an improved paragraph can function as proof. The experience is successful when users can evaluate a concrete output during the first session. It fails when users must complete setup, connect systems, or disclose sensitive data before seeing any value. Proof builds dynamic learned trust.
Gate 4: Calibration—The product should help users understand what the AI has done, why an output appeared, and what to do next by sharing sources, providing confidence cues, allowing editability or undo, reviewing steps, or communicating limitations or visible scope. The experience is successful when users can make an informed decision about accepting, editing, rejecting, or verifying an output. It fails when the AI is presented as magic or final authority. Calibration represents the difference between appropriate reliance and misuse or disuse.
When we use these gates early during design review, they can catch first-session problems before they become onboarding rewrites. Table 1 summarizes this framework.
Table 1—Four-gate first-session checklist with pass and fail signals
Gate
Pass Signal
Fail Signal
Legibility
A new user can describe the purpose of the AI without reading documentation.
The first screen promises broad capability—Ask anything or Create anything—but no clear starting job.
Constraint
The first action is specific, guided, and low-risk.
The user must invent both the goal and the method before receiving any help.
Proof
The product produces a concrete, evaluable output before requesting major commitment.
The user must configure, connect accounts, or disclose data before seeing any value.
Calibration
The user can accept, edit, or reject the AI’s output and understand why it appeared.
The output is presented either as magic or the final authority, with no recourse for the user.
Common Antipatterns
Antipatterns often look polished in a demo, but fail when a new user has to decide what to do first. The following four antipatterns recur across AI products. Each is easy to justify to a product team, but difficult to defend in front of a new user.
Capability-led messaging—Many AI products lead with breadth—for example, write, analyze, summarize, plan, generate, or automate. Breadth impresses in a demo but can paralyze the user during a first session because it forces the user to supply the missing context. The fix is to lead with a specific, useful job and reveal breadth later.
Premature data collection—AI products often require the user to create an account, complete an onboarding questionnaire, add workspace connections, or upload data before showing value. The problem is not always the request itself. The problem is the sequencing of the workflow. If the first session begins with data extraction, the product is asking for trust before earning it.
Trust signals before relevance signals—Logos, testimonials, security badges, clinical credentials, and compliance claims can support conversions, but they cannot replace the need for task relevance. Presenting them before the user understands the path can read as anxiety rather than credibility. Placing them at the moment of decision makes them evidence.
Treating chat as the entire product rather than one interaction mode—Chat is powerful for exploration and followup. However, on the first screen, chat often places the entire articulation burden on the user at once. Code editors provide an alternative. While a chat user interface can exist, the first proof of value should happen elsewhere—inside the work surface where the user already has intent.
These antipatterns share one flaw. They ask users to understand, trust, or configure the system before the system has made itself useful.
The Honest Counterpoint
Activation is not productivity, and productivity is not quality. First-session success should not be mistaken for long-term proof. Plus, it would be misleading to present AI code editors as a uniform success story. Recent evidence complicates the picture.
METR’s randomized controlled trial of 16 experienced developers working on 246 tasks in their own mature, open-source codebases found that AI assistance—using Cursor Pro with Claude 3.5 and 3.7—made developers 19% slower. Participants expected a 24% speedup and later believed they had experienced a 20% speedup. However, the measured result moved in the opposite direction. Perceived productivity inverted actual productivity.
The results of Stack Overflow’s 2025 Developer Survey also complicated the story. While the use of and interest in AI tools remained high, trust declined. The survey found that 84% of developers use or plan to use AI tools, while trust in AI accuracy dropped from 40% to 29% year over year. The most common frustration was that AI solutions were “almost right, but not quite.”
These findings do not invalidate the onboarding patterns that I presented earlier in this article, but clarify their limits. AI code editors can be excellent in helping users reach first value while still raising unresolved questions about long-term productivity, reliability, and code quality. This distinction is exactly why calibrated trust matters. A strong first session should not make the AI feel magical. Magic hides failure modes. A strong first session should make the AI’s contribution legible enough that users can accept help without surrendering their judgment.
Conclusion: The Scaffold Is the Onboarding
AI products do not earn first-session trust by explaining every capability. They earn it by making the user’s first useful action obvious, contextual, and safe to evaluate.
AI code editors do not win first-session adoption only by having better AI. They benefit from a workflow that the user already understands. The user brings a file, a point of insertion, a programming language, a task, and an expectation of progress. The AI enters that structure and proves itself through small, visible contributions. Many chatbot-first products still ask users to create that structure themselves. Prompt suggestions, chips, and examples reduce friction, but they are not the same as workflow context. They reduce the emptiness of the prompt box without changing the user’s burden of articulation.
For UX designers, the opportunity is not to copy code editors literally. It is to copy the principle behind them. Find a workflow that the user already understands and place AI inside that workflow. Narrow the first action. Show value before asking for trust. Make the system’s scope and uncertainty visible. First-session trust is not built through persuasion. It is built with scaffolding.
Sibanu specializes in designing artificial intelligence (AI), software-as-a-service (SaaS), and healthcare products. He has a Master of Science in Human-Computer Interaction from Indiana University-Purdue University Indianapolis. His work focuses on first-session design, following the principle that AI products must demonstrate value within a user’s initial interaction or lose them permanently. He has audited healthcare AI platforms processing more than 22 million consultations and led redesigns producing measurable improvements in patient engagement and booking conversions. His writing has appeared on UX Collective and Bootcamp, and his peer-reviewed paper on first-session trust design has been accepted at HCII 2026 for publication in Springer’s Lecture Notes in Computer Science. Read More
