Shantanu Vishwanadha

For AI features, a support request is rarely only a bug report. It can expose an unclear default, a missing constraint, or a workflow that asks users to guess. Treating those signals as product input is part of adoption work.

The most useful AI documentation is often a decision boundary. “Use this when…” and “Don’t use this when…” save more time than a larger feature list. The second line gives people permission to stop forcing the tool into a problem it does not fit.

AI support should optimize for the next action, not the longest explanation. A good answer tells a developer what to try, what evidence to collect if it fails, and where to go next. That is more useful than a polished summary of every possible cause.

For developer tools, activation is not a first successful prompt. It is the moment a developer knows when to trust the tool, when to verify it, and how to recover when it is wrong.

The dangerous AI demo is the one where output looks finished before anyone asks whether it fits the repository, the policy, or the user's intent. Fluency shortens review only when provenance and reversibility are part of the workflow.

AI answers in support should be judged by the decision they enable, not their tone. A concise case summary with product area and evidence is often more valuable than a perfect reply. It lets a human decide whether to answer, escalate, or fix the docs.

Developer documentation is part of an AI system's control surface. When the canonical answer is stale, fragmented, or hidden behind access, retrieval reproduces that confusion at speed. Fix the source before tuning the prompt.

A support assistant needs a visible "I can't tell" path. If it cannot point to the source, state uncertainty, or hand off cleanly, it turns missing knowledge into confident prose. That is worse than a slow search.

For practical AI adoption, time-to-first-draft is a weak metric. The useful metric is time-to-verification: how long it takes someone to decide the output is safe to send, ship, or act on. If verification stays slow, the workflow has not improved much.

I’m skeptical of AI features that hide uncertainty to sound decisive. A concise answer with visible sources or a clear “I don’t know” gives users something they can check. Confidence without a path to verify it creates more support work later.

For developer tools, prompts are part of the interface. Changing a prompt can alter behavior as much as changing an endpoint. Version them, test representative tasks, and record what changed. “We improved the prompt” is not a release note.

An AI answer without its input and source context creates a support problem. When a user reports a bad result, the team needs the task, retrieved context, tool calls, and output. Otherwise no one can reproduce the failure.

“Human in the loop” is too vague for product design. Can the reviewer see the source material, the assumptions, and the exact change before acting? If not, the person is being asked to approve an opaque result, not review it.

A thumbs-down button is a weak AI feedback loop. It records dissatisfaction, but not the task, missing context, or expected correction. Make it easy to add that detail at the point of failure, then give teams a way to group the reports by pattern.

An AI answer can cite the right documentation and still guide someone to the wrong decision when the docs cover several versions. Retrieval needs version and environment filters, not only better search. Otherwise the citation makes a bad answer look verified.

A feature can save five minutes per task and still be a poor trade if it adds ten minutes of review to high-stakes work. Adoption advice needs to name the review cost, not treat every generated draft as a free productivity gain.

I would rather see an AI product say “I’m unsure because the docs conflict” than quietly choose one version. Uncertainty is useful information. A confident answer built on stale context creates work for support and makes the next answer harder to trust.

For an AI feature, “it gave the wrong answer” is a weak bug report. The useful report includes the task, the source context, the output, and the correction the person expected. Product teams need that trace; support teams need a way to collect it without making customers do QA.

For practical AI work, I trust a small evaluation set maintained by the team more than a polished benchmark number. The useful cases are the ones that expose where a tool is unsafe, confusing, or too expensive for the workflow.