320 karma · joined January 21, 2023
Talk to me about computational chemistry, bioinformatics, and molecular biology!
I think that's actually a good way to look at it. I use AI to help produce code in my day to day, but I'm still taking quite a while to produce features and a lot of it is because of that. I'm spending most of my time reading code, adjusting specs, and general design work even if I'm not writing code myself.
There's no free lunch here, the workflow is just different.
I am stealing that phrase haha
I don't think all means-to-end people are just in it for money, I'll use the anecdote of myself. My team is working on a CAD for drug discovery and the goal isn't to just siphon money from people, the goal is legitimately to improve computational modeling of drug interactions with targets.
With that in mind, I care about the quality of the code insofar as it lets me achieve that goal. If I vibe coded a bunch of incoherent garbage into the platform, it would help me ship faster but it would undermine my goal of building this tool since it wouldn't produce reliable or useful models.
I do think there's a huge problem with a subset of means-to-end people just cranking out slop, but it's not fair to categorize everyone in that camp this way ya'know?
But you can have an extremely well designed product that functions flawlessly from the perspective of the user, but under the hood it's all spaghetti code.
My point was that consuming software as a user of the product can be quite different from the experience of writing that software.
Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product.
I'd just be careful to separate code elegance from product experience, since they are different. Related? Yeah, sure. But they're not the same thing.
1. You treat your code as a means to an end to make a product for a user.
2. You treat the code itself as your craft, with the product being a vector for your craft.
The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster.
Personally, I fall into the first camp.
No one has ever made a purchasing decision based on how good your code is.
The general public does not care about anything other than the capabilities and limitations of your product. Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively.
With that said, I do have respect for people in the latter camp. But they're generally best fit for projects where that level of craftsmanship is actually useful (think: mission critical software, libraries us other devs depend on, etc).
I just feel like it's hard to talk about this stuff if we're not clear on which types of projects we're talking about.
Like sure, is it a VS code fork with agents stapled to it? Yes. But are they on the same scale as most of the people mentioned? Ehh probably not.
It reads more like a hit piece from someone with a grudge against random SF companies than anything else.
It's focused on structural analysis right now, but the goal is to allow for biologists, crystallographers, chemists, etc to quickly analyze large samples of structural data for patterns and find where those patterns break down.
Our goal is to make it a platform to analyze the output of various papers, tools, and structures to build a single unified biological model of your druggable target. For example, what if your alphafold output disagrees with pre-existing literature? If Diffdock says your candidate can bind to a pocket on a protein that hasn't been validated yet, what's the implications of that on the underlying biological mechanism?
Biology is extremely complicated, so scientists create simplified lenses of the world to make sense of things. Biologists are looking at different things than crystallographers, crystallographers are looking at different things than computational chemists, etc, etc.
Finding disagreements in these simplified lenses early can save a lot of money before things move to lab experiments.
Most of these organizations are looking for customizations that B2B SaaS struggles to provide since they have to walk a line of catering to a market segment broadly then building customization for specific clients.
I've seen a huge surge in organizations investing in small software development teams to do internal builds for things that they just aren't getting from these tools. Technology is not the value center for these companies.
I work in healthcare, so my perspective is heavily contextualized by that, but I'm seeing providers (especially specialty providers) build internal engineering teams to create ancillary systems that sit on top of their EHR. They are doing this instead of buying similar modules that might be up sold by the EHR.
Anyway, I just feel like these market trends are deeper than what this article implies.
What complicates things is the experimental data we get back from labs to validate MD behavior is extremely tricky to work with. Most of what we're working with is NMR data which shows flexibility in areas of the proteins, but even then we're left with these mathematical models to attempt to "make sense" of the flexibility and infer dynamics from that. Sometimes it feels like an art and a science trying to get meaningful insights for lab data like this.
It's extremely difficult to experimentally verify any MD model since, as mentioned in the article, most of the data we're working with are static mugshots in the form of crystal structures.
>The increased amounts of calcium, phosphate, and fluoride in the drinks limited the severity of erosion by changing the solubility of the enamel [82]. The decline in enamel’s surface microhardness and mineral loss were both dramatically halted by the addition of CaGP to the carbonated drinks.
Most seltzer water has fluoride in it, and your tap water has fluoride in it (if you're making your own at home).
Also the methodology in this study was purely in vitro, not real world conditions. Notably, the lack of saliva.
>Under normal circumstances, human saliva forms a physical barrier, a film, and prevents direct contact between the tooth enamel surface and acidic beverages, thus protecting teeth from erosive attack by acids [45,84,85,86]. However, the erosion tests were carried out without saliva
Also, seems like the study was more on soft drinks in particular and not "other acidic drinks" which may include seltzer water.
>Soft drink consumption during meals was linked to mild to severe tooth damage [65]. No matter when they were consumed, other acidic meals and beverages were not linked to tooth damage [40].
Anyway, net is this: I'm not saying sparkling water carries absolutely no risk, but linking a study like this and cherry picking quotes to make it sound like sparkling water is going to destroy your teeth is misleading.
If drinking sparkling water helps you kick your soda habit, please definitely make the switch. It's so much better for you. The increased risk from drinking sparkling water compared to still water is not worth worrying about if sparkling water provides a quality of life increase for you.
Everything in healthcare is about moderated risk and counterbalancing it against lifestyle.
This has also let us bid on projects as fixed rate instead of T&M since we budget time as appetite instead of how long we think something will take to build.
There are still some hurdles we have to overcome, like we can still run into unexpected things that we didn't know about during the betting process, but deep behind the philosophy of Shape Up it feels like something that translates extremely well to more creative R&D development projects like what we do.
It sort of feels closer to heterodyning and "demodulating" the signal encoded in the softmax. Those tiny little errors we're trying to denoise with this technique are almost closer to carrier waves (when encoded to softmax) than noise imo. This wouldn't get rid of noise in the training data or noise in the dimensionality of the key / value space. It's really only removing noise introduced by the process itself.
If that is the case, then the "signal" in this case would be the softmax that encodes the dimensions captured by the query / key space. Since the noise ideally is the same in both softmax encodings, subtracting them should "cancel out" the noise.