Writing Good Code Just Got (Too?) Easy
In February this year, I prompted an AI coding assistant to rewrite dupRadar, a well-known RNA-seq QC tool, in Rust. I've never written Rust. Within an hour, the new CLI tool was producing matching output, and by the end of the weekend I had a working beta that covered 15 different QC steps from the nf-core/rnaseq pipeline. The result, RustQC, achieves a >60x speedup while producing near-identical output. The full story is in our companion post.
Three days into my effort, and entirely independently, Rob Patro (author of Salmon, alevin-fry and more) published a blog post describing how he'd used AI to rewrite the SSHash sequence dictionary and the piscem read mapper from C++ to Rust in under four days, with 100% concordance against the original outputs. Then earlier this week, Fulcrum Genomics released fgumi, a Rust reimplementation of their fgbio UMI toolkit that achieves a 25x speedup, also developed with AI assistance.
Recently, AI coding tools seem to have crossed a threshold where they are able to craft end-to-end software packages autonomously. LLMs generate the code and use deterministic output comparison to provide validation, iterating in a loop until outputs match the upstream tool. Now, a domain expert who understands what a tool should produce can reimplement it using coding skills that they themselves may not possess, at a pace that simply wasn't possible before.
Why This Needs Principles
Writing fast code has become cheap, however the scientific insight, careful validation, and community trust behind the original tools remain hard-won. The tools that bioinformatics depends on represent years of work: algorithm design, edge-case handling, user feedback, and ongoing maintenance - any AI-assisted rewrite stands on that foundation.
The opportunity of gains in the order of 60x speedups are self-evident: if used in a popular pipeline, that translates to millions of saved CPU-hours and meaningful reductions in compute cost and carbon footprint. It also unlocks previously impractical scientific analysis methods and approaches. But an unchecked proliferation of subtly different tool reimplementations could fragment an ecosystem that currently benefits from (relatively) canonical tool implementations. A slightly different rounding strategy or an alternative handling of multimapped reads may not affect a single study, but it compromises cross-study comparability and the reproducibility of datasets in public repositories. And it’s not just the results themselves - without proper attribution, the original authors lose credit for the algorithms that make rewrites possible in the first place. The bioinformatics community is already familiar with the cost of unmaintained one-off projects, and a wave of AI-generated rewrites could make that problem much worse.
4 Themes for Responsible Rewriting
To try to address these risks head-on, we've published rewrites.bio with some best-practice principles for AI-driven tool rewrites. It’s intended as a starting point for a conversation within the community, rather than a canonical set of commandments.
Philosophy
The original authors' work should be credited prominently: in the README, the paper, the documentation, and any downstream reports. If a rewrite produces output consumed by tools like MultiQC, it should identify itself using the original tool's module so that citations flow correctly. Outputs should be emulated exactly, because a rewrite that changes results is a different tool. It cannot inherit the original's validation history and it can't serve as a drop-in replacement. Any optimizations that change output should be opt-in and clearly documented. If AI coding assistants wrote the code, that should be stated openly, along with how correctness was validated, so that users can make informed decisions about trust.
Planning
A rewrite is an opportunity to rethink the architecture, not just translate code line by line. Consolidating multiple tools into a single pass, eliminating redundant I/O, and choosing better data structures can deliver performance gains far beyond what a language switch alone provides. At the same time, the implementation should proceed in tight iteration loops with continuous output comparison. AI coding assistants are good at generating code but unreliable at judging whether the output is correct, so each step needs validation before moving on.
Building
Benchmarks should use real data, not synthetic inputs, with documented hardware, datasets, exact commands, and output comparisons so that anyone can reproduce the results. It's better to reimplement the subset of features your pipeline actually uses and do them correctly than to attempt full coverage and get some of it wrong. Unsupported features should fail with a clear error pointing to the original tool. Claims of equivalence should specify the exact upstream tool version it was validated against.
Stewardship
Publishing a rewrite is a commitment to maintain it, which means triaging issues, re-validating when original tools release updates, and growing a contributor community. Output format compatibility should be preserved so the rewrite is hot-swappable: users and pipeline developers should be able to drop in the new implementation or revert to the original with no change to their results or downstream pipelines.
If at all possible, the code should be open source. The tools being rewritten are typically built by the open-source community, and a rewrite that closes the source extracts value without contributing back. When the process of building a rewrite surfaces edge cases in the originals, those should be reported upstream, but with care. AI agents are often confidently wrong in very subtle ways, so before filing bugs, verify manually with the original tool on clean data and never use AI-generated test cases as evidence. Open-source maintainers are usually volunteers, and in many cases are already suffering under a firehose of AI-generated slop issues.
A Conversation, Not a Checklist
These principles are a starting point. Every rewrite is different, and some will be easier to honor than others depending on context. What matters is that the intent behind each one shapes the decisions people make. We've done our best to apply these principles to RustQC, a Rust reimplementation of 15 RNA-seq QC tools that achieves a >60x speedup while producing identical output. Read the companion post for the full story of how it was built, the benchmarks, and what it means for Nextflow pipelines.
We'd love to hear what you think. The principles are on GitHub and contributions are welcome. If you're working on a rewrite of your own, or thinking about one, we hope rewrites.bio is useful.
- →Principles: rewrites.bio
- →Contribute: github.com/seqeralabs/rewrites.bio
- →RustQC: Companion blog post