Ten Rules for Keeping AI Honest in Computational Biology

Artificial intelligence has swept into computational biology faster than almost any tool before it, and the field is now grappling with a question that sounds simple but is not: where does legitimate AI assistance end and dangerous delegation begin? A new perspective published in PLOS Computational Biology by Noam Auslander of The Wistar Institute lays out ten concrete rules for researchers who use large language models and generative AI in bioinformatics, coding, and data analysis. The core warning is stark. Unlike experimental biology, where AI-fabricated microscopy images or altered PCR plots are universally condemned as misconduct, computational biology occupies a gray zone in which AI-generated code, analyses, and visualizations can appropriately become part of publishable outputs. That dual role, the paper argues, is precisely what makes the field so vulnerable, because the same chatbot that helps debug a plotting script can also quietly reshape the scientific conclusions a paper claims to support.

Auslander’s first and most emphatic rule is that generative AI must never be used to create, modify, or cosmetically enhance primary data, figures, or analytical outputs. The reasoning is technical as much as ethical. Large language models are prone to hallucination, producing plausible-looking content that reflects the expectations embedded in the user’s prompt rather than the structure of the underlying data. Because chatbot responses are highly sensitive to how questions are phrased, interactions can deliberately or inadvertently steer results in ways that are nearly impossible to audit afterward. The paper catalogs the kinds of prompts that must be explicitly banned: asking how curves can look more different, requesting outlier removal to make a trend clearer, or smoothing plots to render a pattern more convincing. Even seemingly innocent requests, such as rescaling axes, recoloring visualizations, changing normalization schemes, or combining samples to emphasize a pattern, can constitute manipulation. Instead, all data processing and visualization should run through auditable, deterministic workflows, such as Python or R scripts maintained in version-controlled repositories like GitHub, with AI restricted to supporting tasks like refining or debugging the visualization code itself.

The second rule extends this logic to statistics. LLMs should not be enlisted to generate quantitative results, whether p-values, confidence intervals, regression coefficients, or model predictions, because such outputs may be wrong, irreproducible, or built on flawed assumptions. The tools can legitimately explain commonly used statistical methods, describe the situations in which they are typically applied, and suggest broader analytical strategies, provided researchers independently check those suggestions against established statistical resources. Crucially, the final choice of statistical test must remain with the researcher and should be fixed before data analysis begins. Auslander highlights a subtle danger here: handing statistical test selection to an LLM dramatically lowers the technical barrier to rapidly cycling through alternative analyses, transformations, and outcome definitions until something significant turns up. That is essentially p-hacking made effortless, and it overlaps with well-documented questionable practices including selective reporting of outcomes or predictors, outlier exclusion, variable transformation or discretization, scale redefinition, and model parameterization.

Coding is where the paper gets most concrete, and where its guidance is likely to provoke the most debate. Rule three holds that generative AI can accelerate code development only for users who already possess sufficient expertise, and the paper proposes a precise test for what that means: researchers should be capable of independently developing the underlying algorithmic solution without AI help before they incorporate LLM-generated code into their work. Under this principle, AI serves primarily to improve efficiency, assisting with technical implementation such as optimization, parallelization, or software packaging, provided the user can verify correctness, for instance by testing against a reference implementation or benchmark inputs. If the user lacks the problem-solving skills to address the underlying problem unaided, gains in speed come at the expense of correctness and reliability. The principle also enables a practical sanity check: the core logic of LLM-generated code should reflect constructs the researcher could have derived independently, even when the implementation is more technically sophisticated than anything they could produce. LLMs remain fair game for learning new approaches, but researchers must understand and master the underlying solution before relying on AI code in their research.

Rule four is the one already echoing across social media: do not vibe-code science. Vibing, in the paper’s definition, means pasting a subjective description into an LLM, accepting the output with minimal scrutiny, and running it without deep understanding of the underlying logic, assumptions, numerical stability, edge cases, or statistical validity. Auslander argues this practice risks irreproducible, biased, incorrect, or outright fabricated results, and that code which merely feels right or produces superficially attractive plots substitutes aesthetic persuasion for empirical integrity. The paper takes on a common counterargument, that trainees should be allowed to use generative AI because it is standard in industry, on two fronts. First, since AI entered software development only recently, the vast majority of today’s industry professionals were trained without it and possess the foundational skills needed to judge its output, whereas letting trainees lean on AI may prevent those skills from forming. Second, science and industry have fundamentally different goals: code that merely runs is often sufficient for industry, but the goal of academic research is reaching correct scientific conclusions. The paper adds a pointed observation that poorly written bioinformatic packages frequently fail on first application yet their associated papers continue to be widely cited. Researchers should therefore treat LLM-generated code as a contribution from an anonymous user, verifying every line, checking mathematical correctness, testing with reconstructed input-output pairs and benchmarks, and confirming the code handles domain-specific hazards such as missing data, low sequencing coverage, batch effects, multiple-testing correction, and outliers, with units, scaling, and normalization always checked against the biological problem at hand.

Not every rule is restrictive, and several describe genuinely productive uses of AI that the paper explicitly endorses. Rule five encourages researchers to deploy generative AI as an additional code reviewer, generating unit tests, input validation procedures, and assertions that improve software reliability. In computational biology this extends to domain-specific failure modes: incorrect gene identifier conversions, sample-label mismatches, missing metadata, reference genome inconsistencies, sparse matrices, and malformed sequencing files. Increased test coverage can catch errors before they contaminate downstream biological interpretation, which matters especially when expert code review is scarce. But the caveat is firm: AI-generated tests and bug reports should never be assumed correct or comprehensive, and the same independent verification demanded of AI code applies equally to AI-suggested fixes. Rule six offers perhaps the most memorable heuristic in the piece: use chatbots to recall syntax, not scientific reasoning. A computational biologist moving from Python to Bash for command-line work, or from Python to R for plotting with Matplotlib or ggplot2, typically already understands the algorithmic, statistical, and biological logic of the analysis and merely lacks fluency in the required syntax. Seeing the correct syntax is often enough to produce an accurate implementation. This yields another practical test: if a researcher can independently verify that AI output correctly implements a decision they have already made, the tool is an accelerator; if they cannot evaluate the output because the underlying decision was outsourced, the use has become delegation.

Rule seven carves out a sanctioned exploratory role. LLMs can help identify candidate patterns, generate hypotheses, and suggest avenues of exploration, for instance by answering questions about which enzymatic reactions are over-represented among a set of metabolites, what functions are shared across proteins, or what properties unite a collection of amino acids. They can also reconcile heterogeneous naming conventions, matching drug names, model organism nomenclature, transcript identifiers, and gene aliases that would otherwise resist straightforward comparison. But this exploration must be restricted to de-identified and public-domain data, and its outputs must be treated as inherently preliminary, to be validated against the primary literature, curated databases, or rigorous quantitative, statistical, computational, or experimental analysis. Consistent with the earlier rules, LLMs should not be asked to produce quantitative measures, statistical outputs, or figures even during exploration; they supply directions for follow-up, never evidence.

The final three rules address data protection, agentic systems, and publication hygiene. Rule eight urges extreme caution with clinical and identifiable data, noting that medical, clinical, and most sequencing datasets carry sensitive or personally identifiable information bound by strict legal and ethical sharing restrictions, and that submitting such data to public or third-party LLM services risks permanent storage, use in model training, memorization, and security breaches endangering patient privacy, intellectual property, biosecurity, and collaborative advantages. The paper translates this into three tiers: protect, meaning never input raw sequence, clinical, confidential, or proprietary data into public LLMs absent explicit institutional authorization; obtain permissions before using LLMs with drafts, unpublished results, code, ideas, or algorithms; and use responsibly for low-risk tasks such as identifying software packages, querying terminology, or debugging isolated commands. Rule nine extends responsibility to agentic AI, the increasingly capable systems that can now carry out literature review, hypothesis generation, code development, data analysis, and manuscript drafting. With permissive settings or insufficient oversight, such systems may violate software licenses, reuse copyrighted code, or irreversibly modify or delete valuable research data, and they can lower the barrier so far that inexperienced users flood maintainers with low-quality software contributions. Rule ten is the gentlest: LLMs are genuinely useful for catching inconsistencies between a manuscript’s main text, supplementary materials, figures, code, and analysis workflows after repeated revisions, but only once human review has been exhausted, and every suggested correction must be independently verified. Taken together, the ten rules draw a line the field has lacked: AI belongs in computational biology as a checked and verified accelerator under human control, never as an unsupervised generator of scientific conclusions.

Subject of Research: Guidelines for responsible use of AI and large language models in computational biology research

Article Title: Ten simple rules for responsible use of AI and LLMs in computational biology

Article References: Auslander, N. (2026). Ten simple rules for responsible use of AI and LLMs in computational biology. PLOS Computational Biology, 22(10), e1014882. https://doi.org/10.1371/journal.pcbi.1014882

Image Credits: AI Generated

DOI: 10.1371/journal.pcbi.1014882

Keywords: artificial intelligence, large language models, computational biology, bioinformatics, research integrity, p-hacking, vibe coding, data privacy, agentic AI, scientific reproducibility, generative AI, code verification