patrickkidger
Joined 4 years ago
Joined 4 years ago
AI+pharma startup, and each person owns a program, from concept to clinic. (Further details omitted, still in stealth.) We hire anyone exceptional in AIxBio, we don't look to fill defined roles.
Founding team (including me! https://kidger.site) are ex-{Cradle, Google, Oxford, ETH}, backgrounds in protein language models, antibody design, JAX scientific ecosystem, neural differential equations.
"RenTech of pharma"!
:)
Yeah it's totally true you can't build a one-size-fits-all foundation model, the data just isn't there. But also... no-one needs that. It's totally fine to tweak a foundation model for any individual problem, and that's the bulk of what is being described in the linked blog post / in the underlying paper.
FWIW whilst at Cradle we had a lot of doubts going into this. Like, thermostability is clearly evolutionarily correlated so it was always pretty likely that by hook or by crook the models could do that correctly. But, binding? Aggregation? Not at all clear that the same principles should hold. And the exciting finding was that yes, yes they do.
I used to work for Cradle and writing this paper was the last thing I did before leaving – on good terms – to found my own startup. :D And we'll 100% be using Cradle for our lead optimization.
(On the off-chance: I'm at PEGS Boston this week chatting all things AI+antibodies, in particular for rare diseases. If this topic is of interest to any other protein+tech geeks here then send me an email, let's grab coffee.)
We've got Claude Managed Agents, Claude Agent SDK, Claude API, Claude Code, Claude Platform, Claude Cowork, Claude Enterprise, and plain old 'Claude'. And honourable mention to Claude Haiku/Sonnet/Opus 4.{whatever} as yet another thing with the same prefix. I feel like it's about once a week I see a new announcement here on HN about some new agentic Claude whatever-it-is.
I have pretty much retreated in the face of this to 'just the API + `pi` + Claude Opus 4.{most recent minor release}', as a surface area I can understand.
I learnt a lot the first time around, so the newer one is much better :)
I've not tried a couple of things you mention (e.g. background images) but e.g. for dynamic placing there are libraries like https://typst.app/universe/package/meander
The core of Typst is a pretty featureful well-thought-out FP language. This makes expressing libraries for any piece of functionality very pleasant.
That said, the documentation on this matter is close to nonexistent.
Not sure where I got it from, it just seems clean. I don't think I see this super frequently in the ecosystem at large, although anything I've had a hand in will tend to use this style!
C.f. "the intention here is that only names imported using the form X as X will be exported" from PEP484. [1]
I'm generally a fan of the style of putting all the implementation in private modules (whose names start with an underscore) and then using __init__.py files solely to declare the public API.
(Though it's really a pretty tiny library that just does what it says on the tin, not sure how many questions there can be. :D )
Also worth noting the Array API standard exists now. This is generally also trying to straighten out the sharp edges.
Helix:
https://github.com/helix-editor/helix/
Like vim, but already has an LSP etc out of the box. Things are already there so the config files are minimal.
I realise this may be out-of-scope as it's kind of baked into the file format, but does Nobie offer any functionality in that direction?