Recently, I came across rewrites.bio, a manifesto proposing principles for rewriting bioinformatics tools with AI. It begins with a prediction: “A wave of rewrites is coming.” The authors argue that this work should credit the original developers, disclose the use of AI, validate results carefully, preserve compatibility, and include a real plan for maintenance.
Much of that advice is thoughtful and responsible. Still, I felt some hesitation as I read it, particularly around the principle to “emulate exactly.” I could not immediately articulate why. Faster and more maintainable versions of important tools sound unambiguously useful, especially in a field where performance has often taken a back seat and analyses can cost more and take longer than they should. Even as each recommendation seemed reasonable, my attention kept moving beyond the manifesto's focus on rewrites, toward what else we might create with the new capacity AI affords us.
Making sense of that inclination has required me to work through what I believe AI is useful for, where I want human judgment to remain, and what kind of software our field actually needs. Allow me to share some background so you can see where I'm coming from.
A brief aside
Though my title now includes “Director,” I am a software engineer at heart. Overall, I would not consider myself a true early adopter, but I am also not afraid to try something new after a bit of a settling period (I have long had a rule that I will try any new tool for two weeks before I dismiss it!).
After a few months of tinkering, AI has become a regular part of my workflow for writing and reviewing code. I am not quite as bullish as many on my LinkedIn timeline: working carefully with AI as a partner, not as an independent agent, strikes the right balance of control and quality for me. Perhaps curmudgeonly, I still review every line of code produced by either the AI or me; no loop engineering utopia for me.
More broadly, I see how differently people are responding. Some are experiencing significant productivity gains and breaking into new fields; others are working through technical concerns and deeper uncertainty about what AI means for their work and the world at large. I do not think its impact on each person's life requires a uniform response, and my own view ultimately remains unsettled.
However, a few pieces of my worldview have begun to solidify with time. I want to record them here, both to remind my future self and to establish the philosophical underpinnings for the rest of this post.
-
To the extent that we do use AI, we should use it to make better things rather than become more productive at making mediocre things. AI has made implementation easier, but making something amazing still requires a great deal of ingenuity and sweat equity. Building something once you have decided what to build has become easier; deciding what deserves to exist remains hard. This is not a claim about whether AI should be used, only how I believe it should be used when it is.
-
We should use AI to emphasize our individual humanity. Every use of AI involves a choice: whether it extends your ability to express your own judgment and individuality or substitutes some aggregate form of everyone else's humanity for your own. Using AI exists on a spectrum. Typing a question into an LLM and passing its response along verbatim without critically evaluating it or contributing thinking of your own does little to express your individuality because the model has supplied both the substance and its expression. Having AI implement code that you have architected and whose details you review is different: the tool helps with implementation, but the direction, judgment, and accountability remain yours. As I'm defining it here, creation is a human act of deciding what should exist and giving it form. AI should help you do more of that, not make it easier to present work you have neither understood nor made your own.
-
AI does not solve the general planning problem for us. In classical AI, planning is often formulated as a search through a state space: begin with the current state of the world, define the actions available, describe how each action changes the world, and search for a path to some desired goal. Even simplified planning problems become difficult quickly because the number of possible states and paths grows combinatorially (Berkeley offers a good introduction).
The planning problem we face in the real world is harder still because the goal itself is often unsettled. The space of possible tools, methods, experiments, and questions we could pursue is unimaginably large. AI may allow us to explore parts of that state space faster and make individual paths cheaper to follow, but it cannot search the space exhaustively. Human judgment remains responsible for choosing where to look, which possibilities seem promising, what a good outcome would look like, and when a result is worth pursuing.
Long before AI became part of everyday life, science fiction was already exploring this dynamic. In The Hitchhiker's Guide to the Galaxy, Deep Thought spends millions of years calculating the Answer to Life, the Universe, and Everything, only for everyone to realize that they do not know the question. That old joke feels newly relevant: we have an imperfect, deeply human ability to look at an unimaginably large possibility space and sense which questions matter, which paths seem promising, and what deserves to exist.
Software that is cared for
A few years ago, I wrote that genomics needs more talented software engineers. I still believe that. If anything, I have become more convinced of it. There is a significant gap between how software is often developed in bioinformatics and how it should be developed. Much of this boils down to incentives: those writing software are rewarded more for publishing new tools than maintaining existing ones, leaving many important tools without long-term support.
A common pattern in bioinformatics is a tool whose real specification lives partly in its maintainer's head. One or two people carry it for years, accumulating scientific judgment through edge cases and user reports. Much of that judgment never becomes explicit in the code, documentation, or tests. The result can be a tool that only its original maintainer can safely change, making it difficult for anyone else to maintain or improve.
These shortcomings follow in large part from the system we have created around bioinformatics software. Academic incentives reward novelty and publication, while documentation, testing, user support, and long-term maintenance receive far less funding or recognition. Even authors of widely used tools are often expected to fit this work around the activities their institutions reward. Many lack the time, funding, or recognition required to sustain it.
After much thought, the expression I have arrived at is simple: software should be cared for. Publishing a tool should be only the beginning of that relationship. A tool can work, accumulate citations, and become a dependency of important scientific workflows while remaining difficult for users to understand and risky for maintainers to change. Care means making the judgment inside the tool visible, protecting its scientific meaning over time, and giving its users and future maintainers something sturdier than the original author's memory to depend on.
Returning to rewrites
Thinking about care helped me understand why I found some parts of rewrites.bio compelling. The manifesto asks authors to validate against real data, document versions and parameters, credit the original authors, plan for governance, preserve compatibility, and contribute discoveries upstream. Its authors put the underlying tension well: “Fast code is now cheap. Scientific insight, validation, and trust are not.”
On the other hand, despite connecting with these positives, I still had misgivings that I couldn't place. I assumed they must come from one of the manifesto's individual recommendations, but the more I sat with them, the more reasonable they seemed. I kept searching for the principle I disagreed with and came up empty. Eventually, I realized that my hesitation began before any of those principles applied—with the decision to spend this newfound capacity on a rewrite in the first place.
A rewrite arrives with most of the planning problem already solved. The existing tool supplies the goal, the observable behavior, the validation target, and an obvious measure of success. If the new implementation produces the same results in a fraction of the time, we know how to describe the accomplishment.
Rewrites.bio makes this standard explicit with its principle to “emulate exactly.” The reasoning is sound: compatibility matters, and software that sits beneath scientific conclusions cannot casually change its outputs. The manifesto even encourages authors to rethink the architecture around a tool, including opportunities to combine steps and avoid unnecessary I/O.
Still, the behavior of an existing tool represents more than hard-won scientific judgment. It also reflects the constraints under which the tool was built: the time and funding available, the language and libraries of the moment, the needs of its earliest users, the workflows it first had to fit into, the interfaces that were easiest to expose, and the assumptions its original author never had the resources to explain. Exact emulation preserves that entire inheritance without distinguishing which parts remain valuable.
Glossing over these details makes rewrites unusually attractive AI projects. They are easier to specify, easier to validate, and easier to celebrate with a concrete performance number. Developing methods that answer questions existing tools cannot or make previously impractical analyses tractable begins in a much less comfortable place. That kind of work sets us adrift in a vast sea of possible questions, methods, interfaces, and tradeoffs. There is no previous implementation to serve as a map and no established output to tell us when we have arrived.
For that reason, I do not think rewrites should become the default use of this new capacity. To be fair, the manifesto does not present them as the ideal outcome. My concern is not what it claims, but what the attention around rewrites may encourage the community to prioritize in practice.
The value of choosing a different direction
The technology behind today's large language models offers a clear example. Before the transformer, the dominant models for processing language relied on recurrent or convolutional neural networks. Rather than continue building around those architectures, the transformer's authors proposed a model built around attention, dispensing with recurrence and convolutions entirely. That decision became the foundation for modern language models and changed the direction of the field (without it, I probably would not be writing this essay).
Closer to home, the same pattern appears in bioinformatics infrastructure. One example
is noodles, which began well before the current
AI wave. Rather than build on htslib or reproduce the behavior of a single command-line
tool, noodles was developed independently as a bold attempt to build a better
foundation, with testing and documentation treated as core parts of the work. Where
rust-htslib provides a Rust API backed by
the C implementation of htslib, noodles implements the formats directly in Rust
against their specifications. In practice, HTSlib can accept some records that fall
outside those specifications; noodles provides a fast, safer boundary where tools can
reject that data before it enters an analysis. Today, that foundation is
powering the next generation of bioinformatics tools, including the latest version of
one of the field's most widely used tools,
Salmon 2.
By choosing not to reproduce htslib exactly, noodles created a safer, well-tested
foundation other tools could share. Each carefully implemented format is one less
component future authors must rebuild, letting them start closer to the scientific
problem. That compounding benefit may matter more than a successful rewrite, whose gains
are generally confined to one tool. Its impact appears in tools that are easier to build,
mistakes their authors avoid, and new directions the ecosystem can pursue.
Transformers and noodles operate at very different levels, but both began with people
recognizing that existing approaches constrained what could come next. That required an
informed conviction about where the field should go without an old implementation
supplying the complete destination. For me, this is where invention and care meet:
choosing a foundation that opens a useful direction, then doing the work required to
make it trustworthy.
That is the opportunity cost I had been struggling to articulate. When rewrites become the most visible expression of AI-assisted bioinformatics, they can quietly narrow our sense of what this new capacity is for. We begin moving faster through familiar waters while leaving most of the possible future unexplored.
Making scientific judgment visible
One promising use of AI is helping us communicate the scientific decisions already encoded in our tools and pipelines. These decisions are numerous, dense, and often poorly documented. A study of 465 RNA-seq papers found that about 25% described every essential computational step, with fewer still reporting all of the parameters required for complete reproducibility. The alignment tool was reported in 88% of papers, while the preprocessing tool appeared in only 24% (Simoneau et al., 2021).
The effort that goes into a rewrite could also be used to recover as much accumulated knowledge as possible from an old tool by tracing its behavior through code, papers, documentation, tests, and user reports. AI can make that investigation more tractable. Once the reasoning is visible, we can revisit the scientific principles behind the tool, distinguish durable choices from historical constraints, and pursue methods that produce better results rather than only the same results faster.
A parameter is rarely just a knob. It often represents an assumption about the data, a compromise between sensitivity and specificity, or a judgment about the biological question being asked. Tool documentation usually tells users what a parameter is called, its type, and its default. Cared-for software should also explain why the default exists, when it may be inappropriate, what evidence should lead a user to change it, and how that decision affects the interpretation of the result.
AI can help an author turn that knowledge into documentation, examples, and guidance. The author still has to supply and verify the underlying judgment. A fluent explanation generated from the code alone can be more dangerous than no explanation at all, because it gives an undocumented decision the appearance of having been understood.
Putting care into practice
The practical standard I've arrived at is simple: a tool author can delegate implementation, but cannot delegate understanding or judgment. Bioinformatics software turns scientific assumptions into repeatable actions. The people responsible for a tool must understand the code well enough to explain its important behavior, defend the decisions it encodes, and recognize its limitations. That responsibility can be shared across a team; it cannot be handed to an agent.
The same principle should extend to provenance. A tool should make it easy to recover the version that ran, every parameter used (including defaults), the reference data involved, the inputs consumed, and any warnings or assumptions that affected the result. These details are tedious to collect manually, which makes them exactly the kind of supporting infrastructure AI can help us build. Provenance should be a normal artifact of running a tool, rather than something a workflow engineer has to reconstruct after the fact.
Tests should protect scientific meaning as well as software behavior. A byte-for-byte comparison can establish compatibility, but it cannot tell us which behaviors represent essential scientific decisions and which are historical accidents. AI can help generate scaffolding and explore cases, but the author must decide what each test means and why it deserves to keep passing.
None of these practices ends at release. Documentation drifts as behavior changes. Example datasets need to grow as users discover new edge cases. Tests need to be revisited when the science changes, and someone has to respond when a user encounters a result the original authors never anticipated. This continuing work is what turns publication into a relationship.
AI can reduce some of the mechanical burden, but care still requires time, attention, and scientific judgment. Academic institutions have to make room for that work. Maintenance and foundational infrastructure need to count as meaningful contributions, teams need enough continuity to carry knowledge forward, and authors need time to understand what they are responsible for. Otherwise, AI will help us publish more software into the same system that already struggles to care for what it has.
Conclusion
Some rewrites are clearly worthwhile. Faster tools can reduce cost and time to results, and rewrites.bio offers thoughtful safeguards for pursuing that work responsibly. Its authors do not claim that rewrites are the final destination. I would go further: rewrites should occupy only a small part of our larger ambition for AI in bioinformatics.
A wave of rewrites may be coming. I hope it becomes one small part of a much larger wave of invention and care. We should use this new capacity to build better things—and create an ecosystem capable of caring for them.