How Researchers Use AI Assistants for Analysis and Writing: What Usage Patterns Reveal

    A large-scale, de-identified summary analysis of AI assistant conversations in research settings shows that scientists most often use these tools for data analysis and writing, while rarely using them for data collection, lab work, or hypothesis generation. This article explains why certain tasks are easier to delegate, how usage varies by discipline, and offers practical advice for embedding AI assistants into reproducible research pipelines.

    Research work makes highly differentiated demands on tools: some tasks rely on code, statistics, and visualization, while others depend on literature review and written expression. A recent large-scale, de-identified summary analysis of AI assistant conversations in research contexts shows that researchers most often use these capabilities for data analysis and writing/communication, and far less often for raw data collection, experimental work, and research ideation or hypothesis generation. This distribution is not accidental—it closely relates to whether a task can be formalized and whether it can produce verifiable output within a conversation.

    It is worth emphasizing that the underlying observations retain only classification labels such as discipline, subfield, and task type. They do not extract substantive content such as hypotheses, methods, or unpublished results, and conclusions are presented only in aggregated form. What follows is therefore a discussion of usage structure, not the specific findings of any particular lab.

    Discipline Distribution: Quantitative Research Generates More Conversations

    By discipline, computer science, mathematics, and statistics show the heaviest usage; physical sciences and medical/health fields that require extensive offline experiments, sample processing, or clinical workflows use these tools relatively less. Even after normalizing for researcher population, computer science, mathematics, and statistics show usage intensity above their share of researchers. AI coding tools focused on code and computational workflows are even more concentrated: computer science accounts for a limited share of researchers globally but contributes a disproportionately high share of code-related research conversations. AI and machine learning show the same pattern of “low population share, high conversation share.” Arts, humanities, and parts of the social sciences show lower usage.

    This does not mean these fields “don’t need AI tools”—the task shapes differ. Lab operations, ethics review, field observation, and qualitative interviews rarely close the loop within a chat window, while algorithm implementation, statistical testing, visualization, and paper structure can be broken into executable steps. Disciplinary differences therefore reflect both population size and task computability.

    Task Structure: Analysis and Writing Exceed Their Share of Working Hours

    In terms of specific tasks, data analysis accounts for roughly one-third of general research conversations and nearly half of code-related conversations. For comparison, researchers typically spend a little over a quarter of their working hours on data analysis. Writing and communication make up about one-third of conversations, well above the share of time researchers spend on such tasks (roughly one-sixth).

    Conversely, data collection usually consumes nearly 30% of researchers’ working hours but only about 10% of conversations. Research ideation and hypothesis generation account for even fewer conversations (around 4% and 2% respectively), while researchers spend about 7% of their time on them. The intuitive explanation: collection and ideation depend heavily on the field site, instruments, ethics, and domain intuition, while analysis and writing make it easy to hand “intermediate artifacts” to a model—cleaning scripts, chart code, paragraph drafts, reviewer-response outlines.

    For developers and research engineers, this means AI tools work best as an “acceleration layer” for intermediate work, not as a replacement for research judgment.

    Why Analysis and Writing Fit Into Workflows More Easily

    Data analysis tasks typically share three characteristics: structured inputs (tables, logs, experiment records), testable objectives (significance, error, reproduction scripts), and versionable outputs (notebooks, pipelines, charts). AI coding tools can generate data-processing code, check for missing values and outliers, suggest statistical models, interpret diagnostic plots, and solidify the process into reproducible scripts. Writing tasks have a different set of characteristics: relatively stable conventions, clear reader expectations, and low iteration costs. Models are well suited to generating structural outlines, condensing verbose methods sections, unifying terminology, and checking against submission checklists—but conclusions and causal claims must be verified by researchers.

    Data collection and hypothesis generation often lack these characteristics: the data is not yet digitized, constraints are not written down, and correctness depends on whether experiments succeed. Forcing them into a conversation tends to produce fluent but unverifiable text, which increases rework.

    Practical Advice for Embedding AI Assistants Into Research Pipelines

    First, turn “one long conversation” into reproducible artifacts. For analysis tasks, request scripts, dependency notes, random seeds, and test steps rather than a single conclusion sentence. For writing tasks, request outlines, paragraph function annotations, and a list of facts that still need verification.

    Second, use task boundaries to reduce hallucination risk. Suitable to delegate: variable renaming and type conversion, descriptive statistics and visualization drafts, structuring literature notes, submission format checks. Not suitable to hand over on their own: unverified causal claims, processing of ethically sensitive participant information, claims of an “optimal model” that cannot be reproduced.

    Third, choose entry points by discipline. Computational and statistical fields can start with experiment tracking, batch processing, and visualization. Experimental sciences can start with instrument log parsing and QC report templates. Medical and health research must put de-identification and minimum-necessary principles at the front of any workflow. Humanities and social sciences benefit most from coding assistance and first drafts of thematic synthesis, not from replacing qualitative judgment.

    Fourth, establish human review checkpoints. For data analysis, review at minimum: data definitions, control setup, multiple comparisons, and robustness. For writing, review at minimum: whether citations are real, whether methods match what was actually done, and whether limitations are clearly stated. AI tools improve draft speed, not evidence quality.

    Implications for Research Engineering and Cloud Collaboration

    Research conversations depend heavily on intermediate results in code, notebooks, and object storage. In practice, teams can rely on common capability combinations: object storage for raw and cleaned data, container platforms to pin analysis environments, logging and monitoring to record batch job failures, and message queues to connect collection and analysis stages. AI coding tools should generate and explain pipeline fragments—not become the only system. That way, even if a conversation cannot be reproduced, the pipeline still can.

    Enterprise labs and university computing centers planning to scale up should pay attention to: permission isolation between conversations and code repositories, ensuring no unpublished results are mixed into training or fine-tuning data, and avoiding pasting identifiable samples into prompts. Aggregate statistics can guide resource allocation (for example, providing more code-related capacity for quantitative disciplines), but they cannot replace disciplinary norms.

    Limitations and Realistic Expectations

    Current aggregate data can only show “which tasks people handed to assistants”—it cannot directly equate to “these tasks were completed at high quality.” High usage intensity may mean a task is well suited to automation, or simply that the group developed code habits earlier. Low usage in arts and humanities does not mean models are worthless; it more likely reflects that evaluation criteria are hard to automate. The low share of hypothesis generation is also a reminder: exploratory thinking still depends heavily on researchers’ understanding of literature gaps and experimental constraints.

    A reasonable expectation, then, is that AI assistants significantly compress the time spent iterating on analysis scripts and text, while offering limited—and auditable—help with data collection and research framing. Only by aligning working-hour structure with conversation structure can teams avoid “writing fast and erring fast.”

    Summary

    The mainstream use cases for AI tools among researchers are data analysis and writing/communication; code-related conversations concentrate in quantitative disciplines; data collection and hypothesis generation still happen mainly in the lab and in researchers’ heads. For developers and research teams, the key is not chasing any particular assistant brand, but turning formalizable tasks into reproducible pipelines and keeping non-formalizable judgments at human checkpoints. Following this division of labor is what allows AI coding tools to become part of the research infrastructure—rather than an untraceable black box.