Proteomics is heavily reliant on software to make sense of the deluge of data produced by ever quicker and more sensitive methods – to process spectra, identify and quantify peptides, and visualize data. These tools are usually developed in interdisciplinary groups including analytical chemists, computational biologists, and software engineers. One such group is Mike MacCoss’s lab at the University of Washington, USA.
Although an analytical chemist by training, MacCoss is no stranger to coding. As an undergraduate intern at Merck Research Laboratories in 1995, he wrote scripts that linked proteomics search results to the corresponding protein sequences in a Merck database. Then in graduate school, he developed an isotope distribution prediction tool for use with enriched stable isotope labeled molecules. As a postdoc in John Yates' lab, he wrote a tool called RelEx to process the data from early quantitative proteomics experiments.
“As an analytical chemist, it's essential to be able to write programs and scripts to process and visualize results,” he says. “But when I started my own lab, the students, postdocs, and staff I worked with were much better programmers than I was.” So instead of writing code, MacCoss uses his knowledge of mass spectrometry and the proteomics literature to suggest algorithms and to participate in testing.
For over three decades, this approach has worked well. MacCoss has contributed in this way to several widely used proteomics software tools, including Skyline, Comet, Crux, Percolator, EncyclopeDIA, Hardklor, Panorama, BiblioSpec, and Carafe. Working with trainees, he sketches out an idea for an algorithm along with a plan for evaluating it, before working closely with his team to make sure the implementation matches what was discussed.
However, MacCoss recently embarked on a surprisingly successful AI experiment that could change how he and his team collaborate to develop software tools – with potential implications for the field more broadly.
Prototype to platform?
There has been recent discussion in the field about AI’s potential to help scientists develop software tools by allowing them to describe what they want using natural language – namely, “vibe coding” – as opposed to writing code by hand.
Jesse Meyer, Assistant Professor of Computational Biomedicine at Cedars Sinai, USA, used generative AI to create a proteomics analysis interface – in under 10 minutes, using four prompts, and under $2. Although lacking many of the features – and validation – of the tools his lab had developed previously using traditional methods, Meyer was able to reach an initial working state in minutes, rather than weeks or months of manual development.
“This highlighted how much faster exploratory software development and hypothesis testing can now be, even though careful engineering and validation remain essential for mature tools,” he said (see: Vibe Coding Comes to Omics).
Randall Julian, CEO, CSO and Founder at Indigo BioAutomation, responded with a piece that argued that The Analytical Scientist’s description of Meyer’s tool as a “fully functional analysis platform” isn’t quite accurate. “The tool does not handle raw mass spectrometry files. It does not perform peptide identification. It does not do protein inference, batch correction or experimental design modeling,” he said (see: Vibe-Reporting Comes to Omics?).
Meyer’s main takeaway was that generative AI allows researchers to test ideas quickly and abandon those that do not work. But, as Julian pointed out, that’s a far cry from vibe-coding a truly fully functional software tool that could be used by the proteomics community.
However, Mike MacCoss’s recent work appears to be bridging that gap. He and his team have developed an open-source, peptide-centric DIA proteomics search tool, known as Osprey. MacCoss created the original entirely by vibe coding with Claude: roughly 30,000 functional lines of Rust, plus about 12,000 lines of tests. Brendan MacLean, Principal Developer at the MacCoss Lab, then used the same vibe-coding approach to translate it into C# and incorporate it into ProteoWizard.
“Neither of us typed a single line of the code by hand,” says MacLean. (Incidentally, there is a curious historical connection between the lab and Claude’s development. Anthropic co-founder Dario Amodei previously worked in mass spectrometry proteomics and, while based at Stanford University, collaborated with MacCoss, MacLean and colleagues on a DIA method that was later incorporated into Skyline and ProteoWizard, the lab’s established software project.)
MacCoss began experimenting with agentic programming tools in early 2025, starting with simple tasks before attempting to reproduce an established proteomics scoring algorithm in Python. The process took a week and required him to break the calculation into individual stages and check each one. While the resulting search engine did function, it was too slow for practical use.
That experiment led MacCoss to consider a more ambitious project: to create a tool he could use to explore new approaches to DIA analysis. He needed something that could handle real experimental datasets – often comprising hundreds of files – and perform at a similar speed and standard to existing search tools. He chose Rust because it offered much greater speed than Python and an opportunity to learn a new programming language.
“At the time, I didn't anticipate anyone else working on Osprey, or using it for that matter,” he says. It took about three months to get to something that produced results MacCoss could visualize in Skyline. By then, the agentic AI tools had also improved considerably.
“Once I could inspect the output in detail in Skyline, iteration got much faster, because I could find clear examples of where Osprey was working and where it wasn't,” he says.
In DIA, the instrument fragments everything within a wide m/z window rather than isolating one peptide at a time, so the resulting spectra are chimeric mixtures. A peptide-centric search inverts the usual question: instead of asking what peptide explains a spectrum, it asks whether there’s evidence for a specific peptide in the data.
Osprey’s main function is detection and scoring; then it writes out the peak boundaries and a spectral library that Skyline reads directly. “That last part matters more than it sounds,” says MacCoss. “It means every identification Osprey makes can be pulled up in Skyline and inspected visually, chromatogram by chromatogram. As a mass spectrometrist, I appreciate being able to look at the data behind every number.”
There are already tools such as DIA-NN and Spectronaut that work well for this purpose. “They represent the state of the art and are excellent tools,” says MacCoss. But the problem is that both are closed source. Spectronaut is a commercial platform, and DIA-NN is free for academic use but the source is not available.
“That means the algorithms at the center of a large and growing fraction of published quantitative proteomics cannot be inspected, verified, modified, or built upon by the community that depends on them,” says MacCoss. “For a field that has spent twenty years insisting on open data formats and reproducible analysis, having the analysis step itself be a black box is a real gap. The proteomics community would benefit from more open source options here.”
Learning to trust – and test – AI
Brendan MacLean has spent more than 35 years in software development, including eight years at Microsoft and 10 at various startups, before joining the MacCoss Lab. He describes his initial view of AI coding tools as “skeptical, for two solid years.”
But, encouraged by a friend’s experience, MacLean began asking ChatGPT to produce small, self-contained pieces of C# code that he could verify independently, which seemed to work. He later moved to Claude Code in mid-2025. MacLean became more convinced when MacLean watched Claude Code investigate a failed software test. Within a testing process defined by MacLean, it added the information needed to diagnose the problem, traced the failure to its underlying cause, and corrected the code.
“That’s when I realized an LLM can accept a tightly defined validation cycle and work to success within its confines,” he says.
For MacCoss, the process of working with an AI coding agent felt a lot like working with a trainee who is developing a tool to analyze their own data.
“You have a plan for what you want to implement and, just as importantly, a plan for how you are going to assess whether it was implemented correctly,” says MacCoss.
That assessment was not always straightforward. Claude sometimes implemented features differently from how MacCoss expected, while errors introduced by later changes could take time to emerge. “That is the core limitation in my experience,” he says. “Generating code is the easy part now. Knowing whether the code does what you asked is the hard part, and the tool is not always a reliable narrator of its own work.”
MacCoss’s experience with DIA data proved essential. He inspected Osprey’s outputs in Skyline and compared them with results from established tools, allowing him to recognize when something did not make sense. He also maintained detailed documentation so that he did not have to re-explain the project at the beginning of every Claude session. As a check, he would ask one session to describe an algorithm or file format and another to assess whether that description matched what had actually been implemented.
“The two disagreeing was usually a sign that something deserved a closer look,” says MacCoss.
“Stunning, and stunningly far from correct”
MacCoss already had a wealth of experience with DIA searching from his lab’s development of EncyclopeDIA and extensive use of DIA-NN. He had also tested Osprey on familiar datasets, inspected its output in Skyline, and compared its performance with DIA-NN.
“When someone with his judgment is that excited about how a tool performs, you believe it’s worth a closer look,” says MacLean.
MacLean became involved when MacCoss began encouraging the Skyline developers to incorporate ideas from Osprey’s Rust code. Translating individual components into C# without first establishing that the two versions produced equivalent results was risky, so MacLean decided to create and validate a complete C# port.
Claude produced the first C# port over a weekend. The result was both “stunning” and “stunningly far from correct,” says MacLean. The new version generated roughly the same number of peptide identifications as the original, which initially appeared encouraging. But that headline measure concealed serious problems.
“Whole pipeline segments weren’t implemented – we found them weeks later,” he says. “The seductive aggregate metric made it look like progress, but the substance wasn’t there.”
The AI had focused on matching the final identification count without establishing why the results differed. MacLean therefore divided the pipeline into seven stages and compared the C# version with the original at each one. Only when one stage produced virtually identical results could they move to the next.
“I replaced a weak success metric with a rigorous, decomposed, verifiable one,” he says.
MacCoss had taken a similar approach when validating the original version. He checked the implementation using unit tests, visualized intermediate outputs, and compared Osprey’s results with those of another search tool.
“We converged on the same rigor from opposite directions,” says MacLean. “We both knew the LLM results needed validation.”
Once the port had been validated, MacLean incorporated it into ProteoWizard and restructured the code to make it easier to maintain. Automated tests now flag when a change disrupts something that previously worked, while additional reports allow the team to assess Osprey’s false-discovery-rate control more quickly.
“I have learned a great deal since Brendan started working on it,” says MacCoss. “He has created an environment where I can keep fixing bugs and adding features while a very experienced software developer digs through everything I add.”
Osprey remains a – promising – work in progress. The team is testing it across more datasets and instrument types, comparing its performance with DIA-NN, and addressing gaps including post-translational-modification site localization. Their aim is to make Osprey the preferred search tool within the MacCoss Lab, integrate with Skyline, and, eventually, reach an official release.
“It’s a long list,” says MacLean. “And it will be maintained for a long time in step with Skyline and ProteoWizard.”
Top Tips for Vibe-Coding Success
With Brendan MacLean
Adopt a training mindset: treat the model like a talented new hire you're onboarding, not a vending machine for code. Build a knowledgebase around your work as you go – and every time the model takes a wrong turn, ask how the growing knowledgebase could have prevented it, then record the answer so you never re-explain it. The method is: explain, capture, build on success, and keep training.
It is true that you don't have to write the code. Osprey was produced without Mike or me writing a single line by hand. On both sides, our expertise was in knowing what to ask for and how to validate what the LLM produced – which felt deeply familiar to us as managers of teams.
Both software and analytical science prize highly validated results, but human programmers are flawed at producing correct code, and analytical scientists are flawed at producing correct discoveries. Both disciplines have already built rigorous systems – testing, review, benchmarking, reproducibility, peer review – precisely because humans err. Those same systems apply directly to what an AI produces. The output of a model isn't a new kind of untrustworthy thing; it's the same fallible-author problem we face as humans.
AI and vibe-coding present the opportunity to create fully automated validation loops where the AI must reason its way to the desired outcome. So start small, explain what you want, capture what you teach, validate what you get back, and keep building on what you learn.
Beyond the proof of concept
Does Osprey undermine Julian’s distinction between vibe-coded prototypes and trusted scientific software? MacLean sees it less as a rebuttal than an extension of Julian’s argument.
“His core point – that the real value lies in validation, reproducibility, and earned trust, rather than the code itself – I completely agree with,” he says. “Our whole process is that point in action.”
Where Osprey goes further, MacLean argues, is in demonstrating that AI-generated code can progress beyond a small proof of concept without being manually rewritten by professional developers. Osprey has reached a formal development environment through the same testing, benchmarking and engineering practices that Julian identifies as essential – and every line remains vibe-coded.
“What separates a serious tool from a throwaway won’t be whether an AI wrote the code, but whether the work went through real validation and a sound development process, exactly as we judge code written by hand,” says MacLean. “I agree with Randall Julian that our trust in software comes from the validation it's earned. Osprey has shown that rigorous validation can happen inside a vibe-coding project where researchers and software developers are working together on the code.”
Osprey has also changed who participates directly in software development within the lab. MacCoss would previously have proposed an algorithm before working with a trainee or developer to implement and test it. MacLean, meanwhile, would have regarded porting approximately 30,000 lines of Rust as too large an undertaking to begin. Instead, the lab’s principal investigator and principal developer both became hands-on contributors.
“Vibe coding lowered the barrier to starting enough that we both just began, to see what was possible,” says MacLean. “It produced something neither of us could have built alone or without vibe coding.”
Their experience is now influencing other developers on the team. Inspired by Osprey, Matt Chambers – who has worked on ProteoWizard for 20 years – decided to explore whether its C++ codebase could be ported to C# and .NET 8.0. What began as an experiment has developed into a serious project. Although the new version still requires extensive validation, Chambers now regards it as the future of ProteoWizard.
The broader lesson, according to MacLean, is that LLM-based coding is flattening long-established barriers – who can create software, what it costs, at every level of expertise.
“Mike began with deep problem knowledge and a collection of Python scripts, and without vibe-coding he'd likely have kept dabbling at that level,” says MacLean. “For me, porting Mike's roughly 30,000 functional lines of Rust (plus about 12,000 more in tests) would have looked like an un-startable undertaking. Instead, it became a fun challenge, and the speed of progress was frankly stunning – even after 35 years in software development.
“Generative AI also changes the register at which a domain expert communicates. Mike now arrives with working code, not just papers or observations someone else has to translate. When producing code is no longer the limiting factor, you can argue over a running artifact instead of a whiteboard sketch. The scientist can communicate in working code. And producing a diagnostic plot that might have been a week of work for a trainee is now just a request away with vibe-coding.”
Newsletters
Receive the latest analytical science news, personalities, education, and career development – weekly to your inbox.
