What happens when AI starts rewriting the tools bioinformatics depends on?
Last month, members of C3G and the HeDS‑D2R team attended the Canadian Bioinformatics Hub Conference (CBHC) 2026, held over three days at MaRS in Toronto. The meeting brought together researchers from across Canada and, like many conferences this year, was defined by a strong focus on artificial intelligence.
Among those attending was Senthilkumar Kailasam, PhD, a C3G alumnus and now Scientific Data Analyst at HeDS‑D2R. Reflecting on the discussions at CBHC, Senthil was struck not only by how AI is accelerating the development of new bioinformatics tools, but by a quieter shift: its growing role in rewriting the tools the field already depends on. In the think piece that follows, Senthilkumar explores this emerging trend and its implications.
Senthilkumar Kailasam reflects on AI at CBHC 2026
At CBHC this year, it was impossible to ignore the gravitational pull of AI, with keynote addresses, panel discussions, and a small but growing cluster of abstracts presenting AI agents in bioinformatics.
Hamed D. Najafabadi, Associate Professor in Human Genetics at McGill University, and Haibe-Kains, Senior Scientist at the University of Toronto Princess Margaret Cancer Centre, ran a fireside chat with one of the best titles on the schedule: “Do we really need another bioinformatics tool? To build or not to build.” It’s exactly the right question, but there’s a quieter one hiding just behind it, and that’s the one I couldn’t stop turning over: “How do we rewrite the tools we already have, both efficiently and responsibly, with AI?”
Because here’s the thing nobody quite put on a slide: while we debate whether to build new tools, AI coding agents are already quietly rewriting the old ones, such as samtools, fastqc and half of nf-core, in a language most of the room has never compiled a line of. “To build or not to build” assumes you’re starting from a blank file. The rewrite wave doesn’t. It starts from someone else’s twenty-year-old C++ and a prompt that says, “port this to Rust.”
Melanie Courtot, Senior Director of Genome Informatics at the Ontario Institute for Cancer Research, delivered a talk that nailed the adjacent truth: the promise of AI rests on clean, structured, interoperable data, and investing in those basics is a prerequisite for AI to deliver. The same logic applies one layer down; a fast rewrite rests on correctness, and correctness matters just as much.
The Rust ecosystem is already substantial
The Rust ecosystem in bioinformatics has been steadily growing, with several tools now widely used in day-to-day workflows, including:
- rust-htslib (BAM/VCF/CRAM/HTS bindings)
- perbase (per-base metrics)
- pymol_rs (structure visualization)
- sourmash (sketching and similarity search)
- varlociraptor (variant calling)
- alevin-fry and salmon 2.0 (single-cell and transcript quantification)
- RustQC (sequencing QC)
The question isn’t whether Rust can deliver performance. It clearly can. The harder question is what it takes for a rewrite to earn the same level of trust as the tools it replaces.
What some skeptics say
On the OMGenomics podcast, host Robert Aboukhalil, PhD, argues that rewriting software is nearly always a bad idea, with one narrow exception [2]. Their core point is simple: established tools accumulate years of edge cases. Every weird FASTQ from a dying sequencer, every undocumented workaround someone depended on gets baked in. Even if the tool was written by overworked trainees, that code is now doing critical work for thousands of analyses.
The reported risk isn’t crashes; those are usually caught quickly, but code that is confidently and silently wrong.
Naming Conventions
Using an “_rs“ suffix can make Rust rewrites easier to find, but it can also unintentionally borrow the reputation of the original tool.
This workable rule of thumb can help;
- If the name refers to a general algorithm (like bwa or minimap2), adding “_rs” is usually fine and uncontroversial.
- But if the name is a distinct, recognizable tool (like Salmon or Kraken), it’s better to choose a new name and clearly reference the original in the README. That way, you acknowledge the lineage without seeming to trade on an existing project’s reputation.
When a rewrite makes sense
The following criteria come up again and again: rewrite only when you understand the original well enough to tell an essential compromise from an incidental choice.
Salmon 2.0 is a good example of what that looks like in practice. It’s a from-scratch Rust rewrite by COMBINE-lab (the original authors), and its migration guide shows what care looks like [3]:
- Quant.sf output is unchanged;
- The new index format rejects old indices with a clear error rather than producing wrong results;
- Per-transcript parity with the C++ version is reported as ≈0.999, with exact flags documented to reproduce old mapping counts;
- And removals (e.g. salmon alevin → alevin-fry) are explicit rather than silent.
This is the pattern the skeptics tend to endorse: rewrites done by the people who know exactly which parts of the original code are load-bearing. It’s the same approach Felix Krüger took when rewriting Trim Galore in Rust [4].
Shared principles: rewrites.bio
Seqera (the team behind Nextflow) has turned these concerns into a manifesto [5]. At a high level, the message is straightforward:
- Credit the original authors
- Emulate exactly (an “improved” output is a different tool)
- Be transparent about AI and how it was verified
- Think big, but validate one function at a time
- Benchmark on real and edge-case data
- Build only what you need and fail loudly otherwise
- Pin versions and document parity
The appeal is clear. In one example, a Rust-based RNA-seq QC pipeline (RustQC) reported being roughly 63× faster than the traditional stack on a 10 GB BAM, saving roughly 1.5 million CPU-hours and about 150 t CO₂e per year at 100k samples [6].
Questions worth thinking about
One question cuts through this debate: How would you know your rewrite is correct, and could you prove it to a skeptic?
“It compiled” and “the badge is green” are confident guesses, but not a validated tool. It’s important to ask the following questions:
- Do you understand the original’s essential behaviours?
- Have you validated on real, awkward data?
- Does your name help users or borrow a reputation?
- Have you credited the people you’re standing on?
The Rust is the easy part. The validation always was, is, and will be the hard part.
What this means for C3G
From C3G’s perspective, the shift toward utilizing AI tools reinforces our priority of choosing the tools that improve efficiency in terms of time and computational resources, as well as building better and more reliable workflows. But as rewritten tools become more common, especially those generated entirely or assisted by AI, there’s an added need for caution. Not all rewrites faithfully reproduce the behaviour of the original, even if they promise significant performance gains. The same applies when using AI agents to design pipelines: they may suggest faster or more modern alternatives, but these are often newly rewritten tools whose underlying algorithms may not fully match the originals. In this context, careful validation and informed tool selection become just as important as performance.
References
- Canadian Bioinformatics Hub Conference (CBHC) 2026, Bioinformatics.ca. MaRS, Toronto, 27–29 May 2026. https://bioinformatics.ca
- Aboukhalil, R. & Nattestad, M. Software rewrites. OMGenomics Podcast. https://youtu.be/0o2XnEBDxrI
- COMBINE-lab. Migrating from C++ salmon (≤ 1.12.0) to salmon 2.0 (Rust). salmon repository, MIGRATION.md. https://github.com/COMBINE-lab/salmon/blob/master/MIGRATION.md
- Krueger, F. Trim Galore v2 — a Rust rewrite of the original Perl tool. https://github.com/FelixKrueger/TrimGalore
- rewrites.bio — Principles for rewriting bioinformatics tools with AI. https://rewrites.bio
- Seqera Labs. RustQC — benchmark details. https://seqeralabs.github.io/RustQC/rna/benchmark-details/
