Tools for one, or tools for many?
A couple of weeks ago I published a small open source project, the protein-modeling-toolkit. It's a collection of tools for working with protein structures. Right now there are two of them. The first is ssa, a command line tool that reads a PDB or mmCIF file and tells you, residue by residue, whether it's part of a helix, a sheet, or a coil. In other words it does secondary structure prediction, all in pure Python, using the same hydrogen bond model DSSP uses, so you don't need to install anything else. The second is a molecular viewer that runs in your browser. You can pick one of the bundled samples, pull down any structure from the PDB, or drop in your own file, and then spin it around, change styles, hover over residues and share a link to exactly what you're looking at. There's a live demo if you want to play with it. Hemoglobin is a good place to start.
I didn't write any of the code. Kiro Crew did all of it. My job was to test the tools, tell it what wasn't working, and keep pushing on things I cared about. A lot of that was the UX. The first version of the viewer worked, but it looked like something a scientist built for themselves, and I wanted it to feel polished. So we went back and forth on layout, on dark mode, on how the cartoons were drawn, until it felt right. If you read my last post, this is the same kind of collaboration I described there, just pointed at code instead of a trip to Africa.
Why proteins
There are a few reasons I built this, and they're all a bit personal.
The first is that it's a reminder of a past life. Before I spent my career building infrastructure and developer tools, I was a scientist. Protein structures and modeling were my world for a long time. Coming back to it, even in a small way, felt good.
The second reason is a practical one. I still know how to (kind of) evaluate the output. When an agent writes code in a domain I don't understand, I can tell whether it runs, but I can't really tell whether it's right. Here I can. I know what a helix should look like, what crambin's secondary structure should be, and whether a viewer is showing me something sensible. That matters a lot when you're not writing the code yourself. The agent found and fixed real bugs in how beta sheets were assigned, and I could actually check that the fix made sense rather than taking it on faith.
The third reason is that these tools could be useful to someone else. Which brings me to the question I keep coming back to.
Who are these tools for?
I can see three kinds of people getting something out of this. The first is a bioinformatician who is curious about AI and wants a starting point, something real to fork and extend with their own agents. Or they could just point their own agent at this repository and build from there. The second is someone who just needs a tool, a quick way to look at a structure or get a secondary structure breakdown without installing a big package. The third is someone who wants to collaborate and make these tools better. All three are welcome.
But here's the thing I'm genuinely unsure about. It's now so easy to build tools like this that I wonder whether many of these tools will end up being built for one person, or a small group, rather than for a community or larger user base.
Think about how open source has usually worked. Building something was expensive, so when someone built a good tool, other people tended to coalesce around it rather than building their own (physicists excepted, they always build their own :-)). That's how you got the big shared packages or tools like PyMOL that a whole field depends on.
That math is changing. If I can get a working, tested, reasonably polished viewer over a few hours across a couple of weekends, so can anyone else. Why would they contribute to mine when they can have one built exactly the way they want? Robin Sloan wrote a lovely piece a few years ago about an app being a home-cooked meal, software made for the people you love and nobody else. That idea feels a lot more real today. We might end up with a lot of home-cooked tools, each one fitted to the person who asked for it. The apps I've been building for my son are exactly that.
At the same time, I'm not convinced that's the whole story. Some things are still hard to get right on your own, and the hard part isn't the code. It's knowing what the right answer is, having test data people trust, and agreeing on how things should work. Science runs on shared methods. And I remain convinced that the shared hive mind can be better than each individual idea because ideas feed on each other. What does seem definite is that the code itself will become the easy, disposable part, but the ideas that are represented in the code could (or perhaps should) come from many.
While I have opinions about this, but I don't really know how it will end up. The space is moving far too quickly. I'd like to find out, and the best way I can think of to do that is to put these tools out there and see what happens. If you're one of those three people, take a look, try the demo, fork it, open an issue. I'm curious whether anyone shows up.
