With AI, code for RNA-Seq analysis can now be generated in a very short time. Ask how to perform an analysis, and AI will provide sample code. If an error occurs, it will help you fix it. This convenience will only continue to grow.
At the same time, however, we are facing a new problem: sample code can gradually come to be treated as the “standard.”
Sample Code Was Not Written to Define a Universal Standard
Software manuals and tutorials contain a great deal of sample code. However, such code is not necessarily written as “the optimal method for every type of data.” In many cases, it is written and selected as an easy-to-understand example based on considerations such as the following:
- It can be written concisely.
- It is easy to understand.
- It runs reliably.
- It is easy to explain.
Sample Code Continues to Be Copied
The problem is what happens afterward. Sample code is:
- quoted in blog posts,
- copied into GitHub repositories,
- distributed in university courses, and
- pasted into internal manuals.
Today, AI is further accelerating the spread and reuse of such sample code.
Even Sample Code in Manuals Is Intended to Be Modified
For example, in RNA-Seq analysis, sample code such as the following is sometimes presented for filtering out genes with low counts.
keep <- rowSums(counts(dds) >= 10) >= smallest_group_size
dds <- dds[keep,]
This code means: “retain only genes for which the number of samples with counts of at least 10 is equal to or greater than the number of samples in the smallest experimental group.” It is concise, easy to understand, and well suited for use in a tutorial.
However, it is of course not a standard procedure that should be applied to every dataset. Sample code of this kind is intended to be modified according to the characteristics of the data. Consider a common type of clinical dataset. When it is difficult to obtain biopsy samples from healthy individuals, there may be a large imbalance between groups, such as three healthy controls and 60 patients. Many people would probably recognize that applying this sample code unchanged to such a dataset may not be appropriate.
In practice, however,
this single line is often copied as part of a script containing nearly 100 lines.
Users may confirm that the code runs,
but they may not examine every line and ask:
“Why was this condition chosen?”
“Is it appropriate for my data?”
As a result,
sample code continues to be copied unchanged as though it were a standard procedure.
Writing Sample Code Has Become More Difficult Than Before
In the age of AI, a single piece of sample code may be copied tens of thousands of times around the world and repeatedly reused by AI, making it even more likely to become established as a standard. Once published sample code can be separated from its original context, take on a life of its own, and be repeatedly reused by AI, it becomes more important than ever to present it in a form that is as safe and resistant to misuse as possible.
However, no matter how carefully sample code is prepared, there is a limit to its ability to accommodate every dataset and research objective. Sample code remains only a sample, and when it is used in practice, the analyst must modify it appropriately. The problem is that we cannot expect AI to make those modifications automatically and reliably.
There Is More Than One Valid Way of Thinking
Let us briefly change the subject.
For example, ask AI:
“Is it wrong to use a t-test for RNA-Seq data analysis?”
AI will probably answer immediately that it is.
However, if you logically challenge each of the points it raises,
you may eventually arrive at a different conclusion.
For more details, see
“Choosing Between edgeR, DESeq2, and the t-Test in RNA-Seq Differential Expression Analysis: Principles and Practical Rules for Different Data Types.”
One tendency of AI is to strongly emphasize the general view that is most widely shared on the web. It may then present that view as though it were the only correct answer. It also frequently uses strong expressions such as “incorrect” or “statistically questionable” to dismiss claims that depart from the prevailing view. If another person said such things, the person on the receiving end might feel intimidated, assume that they were mistaken, and withdraw their opinion.
AI, however, is not a person. It should instead be treated as a tool with these particular tendencies. If you logically challenge each of the points it raises, it may change its position surprisingly easily. When your counterargument is logically sound, AI will not necessarily continue insisting on the prevailing view. Even so, it may suddenly revert to the conventional view in the middle of the discussion, requiring you to correct its course again.
What Kind of Scripts Does an AI with These Tendencies Produce?
The automation of data analysis using AI will continue to advance. We should make active use of its benefits.
However, AI-generated analysis scripts are not created by inventing entirely new analytical methods from scratch. In many cases, they are assembled from widely shared principles found on the web and sample code published in manuals, tutorials, blog posts, GitHub repositories, and similar sources. Even when each individual step is reasonable, the analysis as a whole may not remain internally consistent when those steps are combined.
This is easier to understand if we consider the ecosystems surrounding different analysis tools. Within each ecosystem, there is active discussion about how the tool should be used, and commonly accepted analytical procedures and sample code have accumulated over time. When asked about an individual step, AI can generate code that follows the practices widely accepted within that particular ecosystem. However, there is far less information on the web about the principles that should be used to connect different analysis tools and analytical steps.
As a result, AI may select generally accepted and reasonable code for each individual step and then assemble those pieces into an overall analysis. Even if none of the individual steps is problematic, a single research objective and a consistent analytical rationale may not be maintained throughout the entire workflow.
This is why, in the age of AI,
the perspective of
Analysis-wide Consistency—
examining how results are connected throughout the entire analysis—
becomes increasingly important.
This issue is explained in detail in
“Values Shown in a Heatmap. Values Used for DEG Analysis. Did You Know They May Not Be the Same? — Proposing Analysis-wide Consistency as a New Evaluation Criterion.”
Particular Care Is Needed When Departing from General Practice
Depending on the research objective, it may be necessary to depart intentionally from commonly used analytical procedures. For example, a researcher may explore the data while asking: “Could there be genes that show this particular type of change?” especially when searching for expression patterns that widely used methods may fail to capture. Such ideas, which are specific to an individual researcher or research question, are unlikely to be widely represented in the general information available on the web.
When AI is asked to perform such an analysis, standard procedures that are widely shared online may be incorporated into the generated script without the researcher noticing. Therefore, when performing an analysis that departs from prevailing practice, the analyst must carefully examine whether the generated script consistently reflects the research objective from beginning to end.
Nevertheless, this is by no means easy.
Dividing Roles Between AI and Subio Platform
As discussed above, AI-generated analysis scripts may have weaknesses in the parts that connect different analysis tools and analytical steps into a single workflow. AI may produce generally accepted and reasonable code for each individual step, but it may not maintain the same research objective or a consistent analytical rationale throughout the analysis as a whole.
One possible solution is a division of roles in which Subio Platform serves as the central environment for coordinating the overall analysis, while AI is used to write scripts for individual analytical tasks that are then executed in R or Python.
First, the data are organized in Subio Platform, where the overall workflow and the relationships between individual steps can be managed. The required data can then be exported for specific tasks, such as differential expression analysis, deconvolution analysis, or machine learning, and AI can be used to create the necessary R or Python scripts. The resulting outputs can then be imported back into Subio Platform and examined in relation to the original data and other analysis results.
With this structure,
there is no need to ask AI
to construct an entire large-scale analysis pipeline at once.
The tasks handled by AI can be limited to small, clearly defined units,
while the connections across the overall analysis
are maintained within Subio Platform.
Rather than allowing AI to take complete responsibility
for connecting different analysis tools,
the approach is to
use Subio Platform as a common foundation
and execute only the necessary analyses in R or Python
with the support of AI.
This integration of Subio Platform with R and Python
is explained more concretely in
“A New Style of RNA-Seq Data Analysis: Analysis in R/Python × Visualization and Data Management in Subio.”
AI is good at identifying and correcting local problems that prevent code from running, such as syntax errors or mismatched arguments. However, it is less capable of consistently judging, throughout an entire analysis, what each step means in relation to the research objective and how it connects to preceding and subsequent steps or to other analysis results. The fact that AI can produce an executable script does not mean that the script implements a consistent analysis aligned with the research objective.
Therefore, when AI-generated scripts are used for analyses that are central to a research project, the code should ideally be inspected line by line to determine whether it contains any steps that are inconsistent with the research objective. Compared with that enormous task, it may be far faster and more reliable to divide the analysis into smaller units, visualize the original data and analysis results in Subio Platform, and proceed while checking whether the results are as expected.
The situation is somewhat different when large volumes of data must be processed continuously. In such cases, a thoroughly validated program can perform the automated processing, while alerts are issued only for datasets that appear to require human review. Subio Platform can then be used to examine the flagged datasets in detail. At first glance, a human review step in an automated analysis workflow may appear unnecessary. However, because real-world data do not always behave as expected, combining automated analysis with Subio Platform may in fact provide a more efficient and practical operating model overall.
RNA-Seq data analysis is expected to change substantially through the use of AI and automated programs. However, the further automation advances, the more important it becomes to provide an environment in which humans can verify both the validity of the analysis and its consistency across the entire workflow (Analysis-wide Consistency). Rather than replacing every aspect of automated analysis, Subio Platform will play an increasingly important role as an environment in which the original data and analysis results can be visualized when necessary and the relationships between them can be examined.
