"Coming up with candidate drugs is the easiest part of the process."
This sounds quite similar to Claude's impact in enterprise SWE, where "writing the code" is sometimes the easiest part of the process vs. alignment between humans, understanding the requirements and problem space, and all the other things that make SWE slow.
Anthropic has made so many bombastic and often untrue (reflecting my personal experience) claims about their ability to speed up software engineering that my knee jerk reaction here is skepticism.
I find anthropic to be such an unsavoury company. I am not an AI doomer and frankly I don't care much about datacentres and so on, it's just how scammy they come across.
The authors of Claude Code churn out so much BS that gets just eaten up by credulous engineers & engineering leaders. "I posted 250 changes today with claude code!" - author of claude code. What's your point? If we don't care about quality, I can output 50,000 changes in a day.
I see them as 95% sales 5% engineering and it's irritating to have marketers constantly throw gasoline on the AI hype fire & have people still regard them as engineers. The claude models themselves are alright.
I can't really understand what you're describing. You have form on left & results on right, but you're requesting the new form state & re-rendering the form HTML on each request? Why? My naive understanding is that you could use something like hx-target to have the response to the form submissions update only the results area & the form should not need rerendered at all.
Why does the form need rerendered on a per request basis? HTML/Browser already tracks the current form state.
Because the form changed based on the selections you made. Like facet search.
Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable options that can’t be combined together) + the product results for those filters". But that was just a lot of HTML to ask for after each change.
So decoupling it so that the form never refetched, just the results, made it a lot snappier. But you still have the form state issue where you want to update the options based on selections. So the form became a little Alpine data component and the results stayed as an HTML partial.
Ah OK, so you had a level of dynamic behaviour in the form itself that warranted an applet/data component for the form. I can see how HTMX would not help with that.
This sounds quite similar to Claude's impact in enterprise SWE, where "writing the code" is sometimes the easiest part of the process vs. alignment between humans, understanding the requirements and problem space, and all the other things that make SWE slow.
reply